Ninous.dev

Disclaimer All data and screenshots are fully anonymized and used for educational purposes only. Summary A Windows 11 upgrade, a dormant Gootloader ZIP, and Defender’s behavioral correlation logic. A mix that led to one of the most interesting false positives I’ve seen. This case-study walks through how Defender pieced together legitimate upgrade activity into a multi-stage ransomware incident, and what it says about context in detection engineering. Story Time Recently, I worked on a multi-stage incident where the final stage turned out to be ransomware. Here’s how it unfolded. First things first: isolate, then investigate. ...

I recently stumbled onto a strange behavior in Microsoft Sentinel while testing a query I had built a few weeks earlier (Check my previous blog). I had pushed a rule in test mode to observe firing rate and fidelity. Two weeks later, while presenting the query, I ran it over historical data and got a hit. But when I checked the Incidents tab, the rule had never triggered. What happened? The Problem In my case, I had built a baseline query that looked back 14 days to map each UPN -> {Set_of_IPs}. The Analytics rule, however, was configured with a 2-day lookback. ...

Recently I received a ticket to create a detection for a client BEC. Microsoft Defender for Office 365 (MDO) didn’t flag the phishing email, but Entra ID raised Unfamiliar sign-in properties and the incident surfaced in Sentinel. Storytime: the signals we saw Sentinel incident: unfamiliar sign-in properties; RiskEventType: “unfamiliarFeatures” and “passwordSpray”. Indicators: User-Agent axios/1.11.0, sign-in source: M247-LTD Los Angeles Infrastructure (m247global.com); Classic hosting/DC footprint. Conditional Access forced MFA; logs confirm MFA was passed. The client confirmed compromise. The user was not using VPN or any odd third-party apps. I pivoted to URL clicks around the time of the malicious sign-in. In UrlClickEvents for the victim over the prior few minutes to hours, most URLs looked normal, but one stood out. Sandboxing showed a “file was shared -> enter email” lure that then redirected to a newly registered .ru page impersonating Microsoft 365. ...

Intro Earlier this year on LinkedIn, I shared a quirky “feature” in Microsoft Defender for Endpoint (MDE): it happily accepts input from the user as trusted without any validation. (LinkedIn Post). Example: curl.exe 142.250.69.142 -H "host: example.com" #One of Google's IPs In MDE, the RemoteUrl field will log example.com, not the actual destination domain behind the IP. Not an exploit, but a perfect way to hide malicious traffic under the “safe domains” umbrella. If your hunting queries filter out common benign sites, you’ll miss it entirely. ...

While onboarding a client to Microsoft Sentinel and MDE, I discovered a subtle misconfiguration involving internal device names leaking to public DNS. This blog breaks down how I found it, the detection logic I used, and how this seemingly harmless mistake could have led to credential theft through a supply-chain vector. The Setting A recent project involved onboarding a new client to Microsoft Sentinel. Their tenant and workspace were already configured, along with Defender XDR. My job was to reduce alert fatigue by fine-tuning analytics rules, whitelisting noise (after validating it wasn’t malicious), and creating new rules for coverage gaps. ...