Known Good

What an MFA prompt actually proves.

Sun, 04 Oct 2026 00:00:00 GMT

Every MFA prompt answers one narrow question: did someone have this factor, at this moment?

That is a useful question. It is also not the question most of us think MFA is answering. We treat a completed MFA prompt as proof that the right person is signing in, on purpose, to the right site. Most methods prove none of those three things.

The difference matters, because attackers do not need to break the factor. They only need to work in the space between what the factor proves and what we assume it proves.

Each row below is a common sign-in method. The columns ask what it proves, what it does not, and how that gap gets used.

Method	What it proves	What it does not prove	How it gets beaten
SMS code	Someone could read a message sent to that phone number	That the number is still on the user's SIM, or where the code was typed	SIM swap, SS7 interception, real-time phishing [1], [2]
Voice call code	Someone could answer a call to that phone number	Same as SMS: the number is not the phone	SIM swap, SS7 interception, real-time phishing [2]
Authenticator app code (TOTP)	Someone had the app or its seed when the code was generated	Which site the code was typed into	Real-time phishing relay [1], [2]
Push approval	Someone holding the enrolled device tapped Approve	That they started the sign-in	Push bombing until someone taps Approve [2], [3]
Push with number matching	The approver could see a sign-in screen showing the number	That the sign-in screen was the real one	A relay that passes the real number through to a fake page [2], [4], [10]
Passkey or FIDO2 security key	A private key scoped to this site signed a challenge, and the browser bound the request to the real origin	Who holds the session after sign-in	Session token theft after sign-in, fallback to a weaker method, help desk reset [3], [6], [7], [8]
Windows Hello for Business	A key tied to this device signed in, unlocked by a local PIN or biometric	Who holds the session after sign-in	Session token theft after sign-in, fallback to a weaker method, help desk reset [3], [8], [9]

Three things the table shows

The phone number is not the phone. SMS and voice codes go to a number, and a number can be moved to another SIM. NIST now treats the public phone network as a restricted authenticator, and advises verifiers to consider signals like SIM change and number porting before relying on it [1]. CISA ranks SMS and voice as the weakest form of MFA, vulnerable to phishing, SS7 attacks and SIM swaps [2].

Codes and taps do not know where they are going. An authenticator code is valid wherever it is typed. A push approval is valid for whichever sign-in triggered it. NIST is direct about it: OTP and out-of-band authentication are not phishing resistant [1]. Number matching fixed one specific problem. It stops someone approving a prompt they never started, because they now need a number from a screen in front of them [4]. Microsoft now has it on for every Authenticator push, with no opt out [5]. But a relay sits in the middle of the real session, so the number the victim sees is the genuine one, arriving on a page that is not [10]. CISA's own ranking says it plainly: number matching is resistant to push bombing and still vulnerable to phishing [2].

In 2022 Microsoft described a campaign that had targeted more than 10,000 organisations since September 2021 using exactly this gap [10]. The attacker sat between the user and the real sign-in page, relayed everything both ways, and kept the session cookie at the end. Microsoft's description of the outcome applies to every row above: the attacker "gets authenticated to a session on the user's behalf, regardless of the sign-in method" [10].

Only origin-bound methods check the address, and even they stop at the door. Passkeys, FIDO2 keys and Windows Hello for Business are different in kind. A WebAuthn credential works only with the entity it was registered to, and the origin the browser actually sees is part of what gets signed [7]. A lookalike domain gets nothing it can use. That is why CISA names FIDO/WebAuthn and PKI-based methods as the phishing-resistant forms of MFA [2], and why Microsoft's phishing-resistant authentication strength allows only Windows Hello for Business or platform credential, FIDO2 keys and multifactor certificate-based authentication [9].

Figure 1. Same lookalike page, two different outcomes.

But look at the third column for those rows. Strong MFA protects the sign-in. It does not protect the session that comes out of it. Microsoft's guidance on token theft puts it this way: replaying a token "issued to an identity that has already completed multifactor authentication" satisfies MFA, and access is granted [8]. Commodity credential theft malware steals browser cookies for exactly this reason [8]. And if an account can still fall back to SMS, or a help desk will reset the factor over the phone, the attacker simply picks the weaker door [3].

Figure 2. Three questions, seven methods. Only two methods check the site, and none protect the session after sign-in.

What happened at Uber

In September 2022, Uber published what happened to them [11]. Uber says it is likely the attacker bought the contractor's corporate password on the dark web, after malware had infected the contractor's personal device. The attacker then kept trying to log in. Each attempt sent the contractor a login approval request, and at first that blocked access. Eventually, the contractor accepted one, and the attacker was in [11].

Run that through the table. The password was already gone. The push prompt proved exactly what the push row says it proves: someone holding the enrolled device tapped Approve. It never proved that the person tapping had started the sign-in, and nothing in the flow asked.

Uber said it believes the attacker is affiliated with Lapsus$ [11]. The next year, a joint advisory on Scattered Spider described the same playbook at scale: repeated MFA prompts until someone presses Accept, SIM swaps, and social engineering of IT help desks to reset passwords or MFA tokens [3]. That advisory has since been updated with investigations running through June 2025, and now carries seven agencies including Australia's ACSC [3].

Why people press Approve

It is tempting to read the Uber story as a user who should have known better. I do not think that is the useful reading.

For most people, Approve is a button pressed often and almost always correctly. Repetition turns it into a reflex, not a decision. A push prompt asks someone to make a security judgement with no context, in a second, often while they are doing something else. Repeated prompts turn a refusal into a cost: the phone keeps buzzing until you make it stop. And the help desk is staffed by people whose job is to get colleagues back to work quickly.

None of those are failures of the people involved. They are properties of the design. A factor that relies on a person's judgement in that moment inherits every pressure that moment carries. The methods at the bottom of the table are stronger partly because they stop asking the human to make that call. The browser checks the origin. The person never has to.

What to do with this

Put phishing-resistant MFA where the damage would be worst first. Admins, finance and anyone who can approve payments. In Entra, that is the phishing-resistant authentication strength in Conditional Access [9].
Remove the fallback, not just the weak default. If SMS or voice remains a registered method, it is still a way in [1], [3].
Treat the help desk as part of MFA. Factor resets need verification that cannot be done by someone who has read the user's LinkedIn profile [3].
Assume a strong sign-in can still lead to a stolen session. Plan detection and response for token replay, not only for failed sign-ins [8], [10].

MFA is still one of the best controls we have. It just answers a smaller question than the one we keep asking it. Before trusting a prompt, ask what it actually proved.

References

[1] National Institute of Standards and Technology, "Digital Identity Guidelines: Authentication and Authenticator Management," NIST SP 800-63B-4, 2025. [Online]. Available: https://pages.nist.gov/800-63-4/sp800-63b.html

[2] Cybersecurity and Infrastructure Security Agency, "Implementing Phishing-Resistant MFA," Fact sheet, Oct. 2022. [Online]. Available: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf

[3] Federal Bureau of Investigation et al., "Scattered Spider," Joint Cybersecurity Advisory AA23-320A, Nov. 16, 2023, updated Jul. 29, 2025. [Online]. Available: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a

[4] Cybersecurity and Infrastructure Security Agency, "Implementing Number Matching in MFA Applications," Fact sheet, Oct. 2022. [Online]. Available: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf

[5] Microsoft, "How number matching works in multifactor authentication push notifications for Authenticator," Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match

[6] FIDO Alliance, "Passkeys." [Online]. Available: https://fidoalliance.org/passkeys/

[7] W3C, "Web Authentication: An API for accessing Public Key Credentials, Level 3." [Online]. Available: https://www.w3.org/TR/webauthn-3/

[8] Microsoft Security, "Token tactics: How to prevent, detect, and respond to cloud token theft," Microsoft Security Blog, Nov. 16, 2022. [Online]. Available: https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/

[9] Microsoft, "Conditional Access authentication strengths," Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths

[10] Microsoft Security, "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud," Microsoft Security Blog, Jul. 12, 2022. [Online]. Available: https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/

[11] Uber, "Security update," Uber Newsroom, Sep. 16, 2022, updated Sep. 19, 2022. [Online]. Available: https://www.uber.com/newsroom/security-update/

The MITRE ATT&CK most people are learning was retired in October 2025.

Wed, 09 Sep 2026 00:00:00 GMT

Last week someone messaged me asking a simple question: what should they read to understand MITRE ATT&CK properly, beyond my blog posts and the matrix?

I started typing a list. Then I stopped, because the honest answer is that most of what they would find teaches a version of ATT&CK that no longer exists.

What changed

On 28 October 2025, v18 was released, in which MITRE removed the Detections field and retired Data Sources entirely [1], [2]. Two new object types replaced them. A Detection Strategy describes the adversary behaviour you are trying to catch. It points to Analytics, which are written for one platform each and link to named log sources, which now live directly on Data Components rather than as separate objects [2].

MITRE ATT&CK prior to the change

The reason being the old guidance was too vague to act on. One sentence of detection advice had to cover Windows, Linux, cloud and containers at once, and it usually resolved to something like "use Sysmon" [2].

Then v19 landed on 28 April 2026 and moved the layer above it. Defense Evasion was retired as a tactic and split into Stealth, which inherited TA0005, and Defense Impairment [3], [4]. Stealth covers blending in. Defense Impairment covers switching your controls off.

MITRE ATT&CK v19

What that looks like on one technique

Open T1078, Valid Accounts, the technique behind most of the intrusions you might have read about this year.

Under Tactics it now says Stealth. The description below it still says Defense Evasion, because the prose has not caught up with the restructure yet [5]. I read that page twice before I trusted what I was seeing.

Scroll down and there is no detection paragraph. There is one Detection Strategy, DET0560, Detection of Valid Account Abuse Across Platforms, and it fans out into five analytics [5], [6]:

Analytic	Platform	What it reads
AN1543	Windows	Anomalous logon patterns, abnormal logon types, inconsistent geography or timing
AN1544	Linux	SSH logins, sudo and su abuse, service account anomalies
AN1545	Cross-platform	Interactive and remote logins at unusual hours, unexpected child processes
AN1546	Identity provider	Impossible travel, risky sign-ins, repeated MFA attempts and failures
AN1547	Containers	Service accounts and kubeconfigs used from unexpected nodes or IPs

Five analytics. Five different sets of telemetry. Under the old model this was one technique with one line of advice, and you could tick it off a coverage map without ever asking which of those five you could actually see.

That is the real change. The framework now forces you to answer the platform question before it will give you anything useful.

How to read it

The habit the matrix teaches is top-down. Pick a tactic, pick a technique, tick the box. It feels like coverage, and it measures nothing.

The new structure lets you go the other way, and the other way is honest:

Start with a log source you actually collect. Sign in logs. Sysmon. Auth logs.
Find the Data Components it feeds, then the Analytics that read them.
Walk up to the Detection Strategies, and from there to the techniques.

What you get is not a coverage map. It is a list of the techniques you are genuinely positioned to see, and the far longer list you are not. AN1546 is available to almost anyone with an identity provider. AN1547 is available to nobody who is not running Kubernetes. The old model let you blur those two together. This one will not.

What to ACTUALLY read

Not the tutorials. Read MITRE's own blog posts on the new detection model [1], [2], then the v19 release notes and the Defense Evasion crosswalk [3], [4]. After that, open Detection Strategies and Analytics on the ATT&CK site directly [6], [7] and pick one technique you care about. An hour spent walking a single technique down to its log sources will teach you more than a week of matrix diagrams.

Why I bothered writing it down

I never sent that list of links.

Instead I went and read the object model properly, walked one technique down to its log sources, and found that a good part of what I would have confidently told them a month ago was out of date.That would be wrong at the level of which objects the framework even has.

That is why I write in public. Publishing makes me check things I would otherwise assume, and being corrected in the open is a far cheaper way to learn than being quietly wrong in front of someone who knows better. Every post I put up is a bet that the checking is worth the exposure. So far it has been.

If any of this was useful to you, there is one small thing you can do with that.

I am a finalist in the AISA Cyber Security Awards 2026, Student of the Year category. Voting closes at midnight on Friday 18 September, and only AISA members can vote, so if that is you and this post earned its place in your afternoon, this is where to say so:

https://aisa.secure-platform.com/awards/gallery?roundId=82008

The link is member gated. Log in first or it will bounce you to a sign in page.

And if you are the person who sent me that message: this is the answer. Sorry it took a week.

References

[1] A. L. Robertson, "ATT&CK v18: Detection Strategies, More Adversary Insights," MITRE ATT&CK, Oct. 28, 2025. [Online]. Available: https://medium.com/mitre-attack/att-ck-v18-detection-strategies-more-adversary-insights-8f82d839ee9e

[2] L. Crumpton, "What Comes After Detection Rules? Smarter Detection Strategies in ATT&CK," MITRE ATT&CK, Oct. 22, 2025. [Online]. Available: https://medium.com/mitre-attack/smarter-detection-strategies-in-attack-7e6738fec31f

[3] A. L. Robertson, "ATT&CK v19: The Defense Evasion Split, ICS Sub-Techniques, New AI and Social Engineering Coverage, and Detection Strategies for Mobile," MITRE ATT&CK, Apr. 29, 2026. [Online]. Available: https://medium.com/mitre-attack/att-ck-v19-the-defense-evasion-split-ics-sub-techniques-new-ai-social-engineering-coverage-ff329cb65d66

[4] The MITRE Corporation, "Updates: April 2026," MITRE ATT&CK. [Online]. Available: https://attack.mitre.org/resources/updates/updates-april-2026/

[5] The MITRE Corporation, "Valid Accounts, Technique T1078, Enterprise," MITRE ATT&CK. [Online]. Available: https://attack.mitre.org/techniques/T1078/

[6] The MITRE Corporation, "Detection Strategies," MITRE ATT&CK. [Online]. Available: https://attack.mitre.org/detectionstrategies/

[7] The MITRE Corporation, "Analytics," MITRE ATT&CK. [Online]. Available: https://attack.mitre.org/analytics/

**All technique, strategy and analytic details verified against ATT&CK content v19.2 on 9 September 2026.**

Anatomy of an identity compromise

Tue, 18 Aug 2026 00:00:00 GMT

Why nothing fired

When a detection misses, the first instinct is to blame the rule. Wrong threshold, wrong table, wrong logic. Sometimes that is exactly right.

But there is a class of intrusion where every rule can be correct, every event can be present, every log can be enabled and retained, and still nothing fires because no single event in the sequence is anomalous. The attacker never drops a file. Never runs a binary. Never touches an endpoint you have an agent on. They sign in, they change a setting, they read some mail. Each action is one an ordinary user performs on an ordinary Tuesday.

This is the login-only intrusion, and it is the shape most identity compromises take.

What follows is the anatomy: seven steps, the event each one writes, and why each one reads as normal in isolation. Then a real intrusion that ran exactly this way. Then the part that matters: where the detection actually lives, which is never in the row.

Figure 1 — Anatomy of a login-only intrusion. Seven steps. One writes nothing. The rest write events that look like work.

What each step writes to your logs

#	Step	Event written	Why it reads as normal
1	Credential obtained externally	Nothing in your tenant	The intrusion starts before your telemetry does
2	Spray attempts	Sign-in log failures: 50126, 50053, 50055	Failed sign-ins are constant background noise
3	Sign-in succeeds	Interactive sign-in log: location, Conditional Access result	Valid credential from a plausible place
4a	Auth method registered	Entra ID audit log, Authentication Methods category [13]	Indistinguishable from someone setting up a new phone
4b	Consent granted / app added	Entra audit log: Consent to application, Add service principal, Add OAuth2PermissionGrant	Self-service consent is ordinary in most tenants
5	App uses its token	Non-interactive sign-in log	No user, no authentication factor, a log view most people never open
6	Inbox rule created	Unified audit log: New-InboxRule, Set-InboxRule [6]	Users create rules constantly
7	Mail read	MailItemsAccessed	The account reading its own mail is what the account does

A few of these deserve more than a row.

Step 2 is not a blind spot; it is an attention problem.

The failures are there, with codes attached: AADSTS50126 for an invalid username or password and AADSTS50053 when an account locks out after too many attempts [1]. Microsoft's own Sentinel analytic rule for password spray keys on exactly this family of failure codes [2]. So the telemetry exists, and a detection for it exists. The question is whether anyone is watching the tenant the spray landed in. Hold that thought for the next section.

One caveat if you build on this: Microsoft states plainly that these error codes are subject to change and that applications taking a dependency on the numbers will break over time [1]. Pin them in a lookup you control rather than hard-coding them into a rule.

Steps 4a and 4b are the same objective reached two different ways, and the difference is the most practically useful thing in this post.

Both steps answer the same attacker question: how do I keep this access after the password I stole gets rotated? They answer it differently, and the two answers fail to different responses.

4a attaches the persistence to the user. A new authentication method (an authenticator app or a phone number) is registered against the compromised account. Microsoft's audit logs for authentication methods exist precisely so admins can confirm which users have registered which methods [13]. From the attacker's side, this is cheap and quiet, and it survives a password reset on its own. From the defender's side, it is also the easier of the two to undo: the method belongs to the user object, so reviewing and stripping that user's registered methods closes it.
4b attaches the persistence to an application. Consenting to an application creates a service principal in the tenant with permissions of its own, and both the application registration and the permission grant are written as their own audit entries [5]. This is the part worth sitting with: that application does not authenticate as the user. It holds its own credentials and its own permissions. It never needed the stolen password, and it does not care that the password has changed.

Which means the standard credential-compromise runbook – reset the password, revoke the user's sessions, and re-register MFA – closes 4a completely and does nothing whatsoever to 4b. You can run that runbook, mark the ticket resolved, and leave the attacker's access entirely intact.

This is not hypothetical. It is the branch the intrusion in the next section took.

Step 5 is in a log most people have never opened.

Non-interactive sign-ins are a subset of the sign-in logs, performed by a client app on behalf of a user without the user providing an authentication factor, including a client app exchanging an OAuth 2.0 refresh token for an access token [3]. The interactive view, by contrast, is the one that records a person completing an authentication challenge [4]. If your queries only read the interactive view, this step is invisible to you even though it is fully logged.

On step 7: Microsoft's documentation does not agree with itself

One Microsoft Learn page places MailItemsAccessed in Audit (Standard), enabled by default for users with an Office 365 or Microsoft 365 E3 or E5 licence [7]. Another says capturing MailItemsAccessed operations requires E5 [8]. A third says mailbox audit events return only for E5 users when you search the unified audit log [9].

The event is real either way. Whether it reaches you is a licensing question, and the answer you get depends on which page you read. If you support tenants on Business Premium, do not assume this row is populated. Test it in a tenant you control before you rely on it in an investigation and note that these records are not retroactive, so discovering the gap during an incident is discovering it too late.

An intrusion that ran on identity alone

In late November 2023, the Russian state-sponsored actor Microsoft tracks as Midnight Blizzard ran a password spray against a legacy, non-production test tenant account that did not have MFA enabled [10].

From that foothold, the actor moved through the identity plane and nowhere else. They found a legacy test OAuth application that already held elevated permissions in the corporate environment. They created additional malicious OAuth applications and created a new user account for the sole purpose of granting consent to them. They then used the legacy test application to grant the Office 365 Exchange Online full_access_as_app role and authenticated to Exchange Online through those applications to reach corporate mailboxes [10].

Microsoft has said the actor accessed a small percentage of corporate email accounts, including members of the senior leadership team and staff in cybersecurity and legal functions and exfiltrated emails and attached documents [11]. Microsoft detected the intrusion on 12 January 2024.

No malware. No endpoint. No file written to disk anywhere an EDR agent could see it. Every step is a row in the table above, and step 4b is the branch it took.

Two things worth saying plainly about this case.

The first is that the spray in step 2 was not invisible. It was against a legacy, non-production test tenant. Microsoft has not said what monitoring that tenant had, and I am not going to claim it had none. What is documented is the interval: the spray began in late November; detection came in January. Whatever the reason, the events and the attention were not in the same place.
The second is scale. This is a nation-state actor against Microsoft's own corporate environment. If you run IT for a forty-seat accounting firm, the adversary in your tenant is not this one, and the lesson does not transfer by analogy. What transfers is the mechanism. The steps are the same steps, the log sources are the same log sources, and the Exchange Online application permissions used here exist in every tenant that has Exchange Online.

Figure 2 — Where the detection lives. No event on either side is suspicious. Every pair is.

The detection is never in the row

Look back at the table. Every one of those events, taken alone, is something a legitimate user or a legitimate application does. You cannot alert on any of them without alerting on your own organisation going about its day.

The signal is in the join.

Unfamiliar-location sign-in × security info registered in the same short window. Users do register new authentication methods. They usually do it from the office, on a device they have used before, not four minutes after a first-ever sign-in from a new country.
New authentication method × every subsequent sign-in using only that method. A user who adds a phone still has their old method and still uses it sometimes. An attacker who adds one uses nothing else.
Consent granted × first token use from a different address than the granting session. The person who consented and the thing that immediately started pulling data are not in the same place.
Inbox rule created × that session already flagged as unfamiliar. Rule creation is noise. Rule creation inside a session your own risk engine already had doubts about is not.

Each of these needs a time window. And the window is where the false positives live. Too tight and you miss the patient attacker. Too loose and you catch every user who registered a phone the same week they travelled. There is no correct number I can give you, it depends on the size of the tenant, how mobile the workforce is, and how much noise the team can absorb. Picking that number, and then revisiting it, is the actual engineering work. The joins are the easy part.

What changes Monday

I do not administer tenants for anyone's clients. What follows is what Microsoft's own documentation and the Midnight Blizzard disclosure add up to for the people who do.

Check whether your queries read the non-interactive sign-in log. If they only read the interactive view, step 5 is invisible to you regardless of what else you have configured [3].
Find out what Consent to application, Add service principal and Add OAuth2PermissionGrant look like in your tenants right now. Microsoft's own hunting guidance treats these as events that should be rare [12]. If they are not rare in your environment, you need to know why before you can use them.
Confirm MailItemsAccessed is actually populated for the licences your clients hold. Not from the documentation from a search in the tenant. See the callout above.
Test whether your credential-reset runbook closes 4b. Rotating a password, revoking sessions and re-registering MFA does not remove a consented application's permissions. Run the runbook against a test account with an app consented to it, and confirm what is still standing at the end. If your incident response stops at the password, it stops too early.
Ask which of your tenants nobody is actually watching. Legacy tenants, test tenants, tenants inherited from an acquisition, and the one spun up for a project that finished. In the case above, the way in was a non-production tenant that had been left behind.

Confirmed and open

Confirmed: every event and operation name in the table is documented by Microsoft and cited below. The Midnight Blizzard sequence is drawn from Microsoft's own security blog and MSRC disclosures.

Open: the MailItemsAccessed licensing position, which Microsoft's documentation states in three different ways. I have cited all three rather than picking one. If you know which is currently correct, I would like to hear it.

References

[1] Microsoft, "Microsoft Entra authentication and authorization error codes," Microsoft identity platform documentation. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes

[2] Microsoft, "SigninPasswordSpray.yaml," Microsoft Sentinel analytic rules, GitHub. [Online]. Available: https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Microsoft%20Entra%20ID/Analytic%20Rules/SigninPasswordSpray.yaml

[3] Microsoft, "Non-interactive sign-in logs," Microsoft Entra ID documentation. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-noninteractive-sign-ins

[4] Microsoft, "What are interactive user sign-ins in Microsoft Entra?," Microsoft Entra ID documentation. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-interactive-sign-ins

[5] Microsoft, "Audit log activities," Microsoft Purview documentation. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-log-activities

[6] Microsoft, "Identify who modified mailbox rules," Microsoft Purview documentation. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-log-identify-mailbox-rules

[7] Microsoft, "Use MailItemsAccessed to investigate compromised accounts," Microsoft Purview documentation. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts

[8] Microsoft, "Investigate shared mailbox activities using audit logs," Microsoft Purview documentation. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-log-identify-mailboxes

[9] Microsoft, "Search the audit log to investigate common support issues," Microsoft Purview documentation. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-troubleshooting-scenarios

[10] Microsoft, "Midnight Blizzard: Guidance for responders on nation-state attack," Microsoft Security Blog, 25 Jan. 2024. [Online]. Available: https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/

[11] Microsoft Security Response Center, "Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard," Jan. 2024. [Online]. Available: https://www.microsoft.com/en-us/msrc/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard

[12] Microsoft, "ConsentToApplicationDiscovery.yaml," Microsoft Sentinel hunting queries, GitHub. [Online]. Available: https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AuditLogs/ConsentToApplicationDiscovery.yaml

[13] Microsoft, "Microsoft Entra audit log activity reference," Microsoft Entra ID documentation. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-audit-activities

What your logs can't see

Wed, 05 Aug 2026 00:00:00 GMT

The premise

"A detection rule can only fire on evidence that reached the platform."

That sounds obvious written down, and it's routinely skipped in practice. When coverage gets audited, it gets audited at the rule layer, which usually consists of questions like how many techniques we've mapped, how many analytics are enabled, and which ATT&CK cells are green. That's one layer too high. Underneath every rule is a log source, and every log source is a lens: built to answer a particular question well, which means built not to answer others.

Those aren't bugs, and they aren't vendor failures. They're design boundaries, chosen deliberately for cost, performance, privacy or licensing. But they set the ceiling on what your detections can ever see, and most of them stay invisible until the day something doesn't fire.

Below is what nine commonly trusted sources cover and what each one structurally cannot.

The table

Log source	What it answers reliably	What it structurally cannot see	Why it's built that way
Entra ID sign-in logs	Who authenticated, from where, on what client, and how conditional access and MFA resolved	What the token holder does once the token is issued. An attacker who steals a session or refresh token can impersonate the user until that token expires or is revoked, carrying a session that already satisfied MFA [1]	Sign-in logs are an authentication record, not an activity record. Activity lives in a different log. Retention is also licence-bound: seven days on Entra ID Free and thirty on P1/P2, and the change isn't retroactive [2], [3]
Windows Security log event 4688	That a process was created, its image path, its parent, and the account that spawned it	What the process was actually told to do. The Process Command Line field is empty unless you explicitly turn it on, so you get `powershell.exe ran` without the argument that mattered [4]	Command lines are logged in plain text and often contain secrets, so Microsoft ships the field disabled and leaves the trade-off to you [5]
Sysmon	Process lineage, network connections, image loads, file and registry activity: the richest native Windows telemetry available	Anything its configuration excludes. Sysmon is disabled by default and produces almost nothing until you install it and give it an XML config [6]	Sysmon is a filter engine, not a firehose. Community baselines are deliberate about what they drop to keep volume survivable [7] and a filtered-out event is silently absent, not empty
EDR	Behavioural detection, process trees and response actions everywhere the agent is installed	Everywhere the agent isn't. Network appliances, hypervisors, unmanaged VMs, contractor laptops and BYOD aren't lightly covered; they're absent. Microsoft found that over 90% of ransomware attacks reaching the ransom stage used unmanaged devices for initial access or remote encryption [8]	Agent-based tooling requires something to install the agent on. Devices you don't manage are, by definition, devices you can't instrument
Firewall / NGFW	Connections: source, destination, port, volume, allow or deny, and session duration	Whatever crossed the connection. TLS hides the payload, so without inspection your firewall sees an encrypted blob to a legitimate-looking destination [9]. Behind NAT, egress logs give you the gateway address, not the host	Decryption is compute-intensive, breaks certificate-pinned applications, and carries privacy and legal weight, so most environments inspect selectively or not at all [9]
Email gateway	Inbound mail at the delivery boundary: sender, attachments, links, verdicts	Everything after delivery, and everything that never crosses the boundary. Mailbox rules, auto-forwards, reads, and internal-to-internal mail don't transit the gateway	The gateway is a perimeter control. Post-delivery actions are recorded by mailbox auditing in a different system entirely, and only if that auditing is configured
Microsoft 365 unified audit log	Tenant-wide user and admin activity across Exchange, SharePoint, Teams and Entra	Anything past your retention window, and historically events your licence tier didn't emit. Audit (Standard) retains 180 days; Audit (Premium) extends to one year, but only for specific workloads and only for users holding an E5 or equivalent licence [10], [11]	This gap isn't technical; it's commercial. Which is what makes it easy to miss during design and expensive to discover during an incident
AWS CloudTrail	Control-plane operations: who created, modified or deleted a resource, and who signed in to the console	What happened inside the resource. Data events, meaning S3 object reads and writes, Lambda invocations and DynamoDB item operations, are not logged by default and must be explicitly enabled [12]	Data events are high-volume and separately billed. The default is the cheap one, and the default is where most accounts stay
DNS resolver logs	Name resolution that passes through your resolver; a near-complete map of what your endpoints try to reach	Resolution that goes around it. With DNS-over-HTTPS, the query is encrypted inside ordinary HTTPS on port 443, bypasses your resolver entirely, and gateway logging is usually not possible [13]	DoH was designed for user privacy against network observers. Your enterprise resolver is a network observer.

How to read this

Two failure modes fall out of the table, and they look nothing alike from the console.

The first is a rule written against a source that can't carry it. The logic is sound, the ATT&CK mapping is correct, and the syntax validates, but the evidence never arrives. The rule stays silent, and silence gets read as safety.
The second is confidence drawn from a source covering less than assumed, almost always because a default was never changed. The rule fires, the tuning looks healthy, and the blind spot sits inside the alerts you're already receiving. This one is worse, because the alerts create the impression of coverage.

Neither failure produces an error message. That's the point of writing them down.

The gap that costs people the breach

The clearest documented case is Storm-0558. In June 2023, a US federal agency detected suspicious activity in its Microsoft 365 tenant by spotting MailItemsAccessed events carrying an unexpected application ID [14]. That single event type was how the intrusion surfaced at all.

Other affected organisations couldn't run the same check. At the time, MailItemsAccessed was gated behind premium licensing, so tenants without it had no way to see the mailbox access that had already happened [14]. The detection logic wasn't the variable. The log was.

Microsoft subsequently expanded the event to Standard-tier customers and raised default audit retention from 90 to 180 days [10], [14]. The fix is real, and it arrived after the incident that proved it was needed, which is the whole argument in one example: nobody noticed the boundary until an intrusion sat on the wrong side of it.

What actually changes

For anyone running detections across client environments, four things follow directly:

Name the source under every rule. For each detection you own, write down which log it depends on and which gap that log carries. If you can't name the source, you can't state the coverage.
Audit the defaults you inherited, not the ones you chose. CLI auditing, Sysmon config, mailbox auditing, and CloudTrail data events are all off or minimal out of the box, all cheap to enable, and all invisible until they matter.
Treat licence tiers as an architecture decision. Retention windows and event availability are coverage decisions made by procurement, usually without anyone in detection being asked.
Add sources to close named gaps, not to raise volume. More telemetry isn't more coverage. Telemetry that answers a question you couldn't previously answer is.

There's a reason this keeps biting. In the 2026 SANS detection engineering survey of 307 practitioners, cloud-native environments were named the number one coverage gap – more than two and a half times any other environment [15]. That isn't a rule-writing problem. It's a visibility problem wearing a rule-writing costume.

Your coverage stops where your telemetry does. It's worth knowing exactly where that is before an incident tells you.

References

[1] Microsoft, "Token Protection by using Microsoft Entra ID," Microsoft Community Hub, Jun. 2025. [Online]. Available: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/token-protection-by-using-microsoft-entra-id-/4302207

[2] Microsoft, "Microsoft Entra data retention", Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention

[3] Microsoft, "Microsoft Entra monitoring and health FAQ", Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reports-faq

[4] Microsoft, "4688(S) A new process has been created," Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4688

[5] Microsoft, "Command line process auditing", Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing

[6] Microsoft, "Enable and configure Sysmon in Windows", Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/windows/security/operating-system-security/sysmon/how-to-enable-sysmon

[7] SwiftOnSecurity, "sysmon-config: A Sysmon configuration file template with default high-quality event tracing," GitHub. [Online]. Available: https://github.com/SwiftOnSecurity/sysmon-config

[8] Microsoft, "10 essential insights from the Microsoft Digital Defense Report 2024", Microsoft Security Insider. [Online]. Available: https://www.microsoft.com/en-us/security/security-insider/threat-landscape/10-essential-insights-from-the-microsoft-digital-defense-report-2024

[9] Amazon Web Services, "TLS inspection configuration for encrypted traffic and AWS Network Firewall", AWS Security Blog. [Online]. Available: https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-traffic-and-aws-network-firewall/

[10] Microsoft, "Learn about auditing solutions in Microsoft Purview", Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-solutions-overview

[11] Microsoft, "Manage audit log retention policies", Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies

[12] Amazon Web Services, "Logging data events", AWS CloudTrail User Guide. [Online]. Available: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html

[13] National Security Agency, "Adopting Encrypted DNS in Enterprise Environments," Cybersecurity Information Sheet, Jan. 2021. [Online]. Available: https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSIADOPTINGENCRYPTEDDNSUOO102904_21.PDF

[14] Cybersecurity and Infrastructure Security Agency, "Microsoft Expanded Cloud Logs Implementation Playbook", CISA, Jan. 2025. [Online]. Available: https://www.cisa.gov/sites/default/files/2025-01/microsoft-expanded-cloud-logs-implementation-playbook-508c.pdf

[15] SANS Institute and Anvilogic, "The State of Detection Engineering 2026: What the Data Reveals About Accuracy, Automation, and AI Adoption," Jun. 2026. [Online]. Available: https://www.sans.org/white-papers/state-detection-engineering-2026

FortiBleed had around twenty people. JadePuffer had an agent. The way in was identical.

Tue, 21 Jul 2026 00:00:00 GMT

The thesis I had to throw out

Two intrusions dominated the last month, and the coverage of both led with AI.

FortiBleed: an initial-access operation running on around twenty people with a defined division of labour.
JadePuffer: an agent that reached a production database with nobody at the keyboard.

The AI is real in both. I know because I set out to argue the opposite: that it was mostly narrative, and the reporting had gone looking for a machine where there were people. A week of verification killed that thesis. SOCRadar's second FortiBleed whitepaper documents AI integrated into the crew's own workflow: penetration testing, vulnerability research, attack automation, and ransomware development [1]. That's tooling in the operational workflow – not hype applied afterwards by reporters.

What replaced my thesis is narrower and more useful. AI is an operational multiplier for people who are already skilled, and it did not lower the floor for FortiBleed. That operation is closer to a small software company than a gang [2]. And the way to gain initial access never changed: valid credentials, exposed interfaces, and unpatched internet-facing services.

JadePuffer sits at the other end of every axis you'd normally use to rank an adversary in a graph: one agent, pointed at an exposed Langflow instance, issuing extortion demands on its own [3].

Around twenty skilled operators at one end. One agent at the other. Both walked through the same neglected door.

I write Sentinel detections and publish them; there are eight in my lab, documented, including the ones that went wrong. Later in this post I run every detection I own against both of these.

Twenty people and a diagnostic command

FortiBleed is not a Fortinet product-vulnerability story, and reading it as one is the first place a defender's attention is misdirected.

The operation, as attributed by SOCRadar to Lynx and INC, Russian-speaking and active since at least February 2026, built a custom Golang tool called 'FortigateSniffer' around the native FortiOS diagnose sniffer packet command, capturing authentication traffic across roughly two dozen protocols [2], [4]. Not an exploit. A supported administrative feature, driven with valid credentials, on devices the operators were already authenticated to. A FortiCloud SSO SAML bypass, CVE-2026-24858, disclosed in January, has been discussed as a possible contributor to initial access in a subset of cases and remains under investigation [4].

Around 430,000 FortiGate firewalls were targeted across 659 documented harvest cycles that exposed over 110 million credentials — RADIUS, NTLM and Kerberos material among them [10]. Administrative access was achieved on 409 of them, and on 354 the full chain was completed: VPN compromise, domain controller, and domain admin [2]. Where credentials weren't already in hand, they came from cracking harvested hashes offline, which is why "we rotated the passwords" is a weaker sentence than it sounds and why the checklist at the end has something specific to say about it.

The part that reads like a company rather than a crew came out of a recovered internal tracking document: around twenty people with a clear division of labour, a small core of lead operators driving the high-impact intrusions, backed by specialists and support staff [2]. Target inventories. Automation scripts. Operational artefacts.

None of that requires a firewall zero-day. It requires organisation, division of labour, and infrastructure – the same things any product team needs.The AI sits inside that operation as leverage, not as a substitute for the people running it.

One agent and thirty-one seconds

JadePuffer, documented by Sysdig in early July, started at an internet-facing Langflow instance and CVE-2025-3248 — a vulnerability with a patch available and an exploit that requires no particular artistry [3].

From there it pivoted to an internet-facing production server running MySQL and Alibaba Nacos, authenticating with root MySQL credentials that did not come from the victim environment [3]. That detail is worth sitting with: somewhere upstream, a human compromise supplied those credentials. It exploited known Nacos authentication weaknesses dating back to 2021 and inserted a backdoor admin account.

The moment that got the coverage: a login failed, the agent read the error, worked out what it had got wrong, and regained access in thirty-one seconds with nobody assisting it. Over the course of the intrusion it generated more than 600 distinct, purposeful payloads, narrating its own reasoning in plain language as it went [3].

The clock is the difference. FortiBleed ran for months with a roster. JadePuffer ran a recovery cycle in under a minute with no one watching. Same year, same class of exposed service, opposite ends of every axis you'd normally use to rank an adversary.

And the ransom itself is where the machine shows its seams. Sysdig cannot say whether the Bitcoin address it produced is a real wallet or a string recalled from documentation it was trained on [3]. An operation that can self-correct in thirty-one seconds may not have been able to get paid.

Capability went up. AI sophistication didn't.

The tempting reading of those two sections is a ladder: crude attackers are at the bottom, organised crews are above them, autonomous agents are at the top, and AI is how you climb. The evidence doesn't support a ladder. It supports a spectrum, and AI is distributed across it unevenly.

LAMEHUG is the hinge. A state-sponsored actor embedded LLM prompting directly into malware, the most advanced adversary category we track, doing the most novel-sounding thing available and got no meaningful gain in effectiveness or sophistication for it [5]. Meanwhile, CrowdStrike's assessment across 2025 is that AI primarily enhances established tradecraft rather than creating original attack vectors and that adversaries who use it successfully generally need enough technical proficiency to catch the model's errors [5]. Capability and AI sophistication are two different axes, and they do not track each other.

ACTOR	AI in Play	WHAT IT BOUGHT THEM
JadePuffer	The agent is the operator.	31 seconds to self-correct
FortiBleed	Tooling inside workflow.	Leverage on skilled people
LAMEHUG	LLM embedded in malware	No measurable gain

All three started at an exposed internet-facing service
Capability rises down the table. What the AI contributes falls.

What all eight of my detections would have seen

A threat narrative is a targeting instruction for defender attention. That's the whole claim, and it isn't a claim about journalists. It's about what happens in your head between reading a headline and opening a query window.

"Autonomous AI ransomware" sends you hunting AI: agentic processes, model API egress, and curiosity about something new on the box. "Around twenty people and a native sniffer command" sends you somewhere else entirely – credential reuse, accounts authenticating from places they shouldn't, and administrative features being used exactly as designed by someone who shouldn't have them. Same fortnight, same reader, opposite queries. Only one of those two framings was ever going to be written up as interesting.

SCATTERED SPIDER is the external version of this. Domain credentials were reached in around three hours; one managed endpoint was touched, and a help desk was talked into the access [5]. No AI anywhere in the chain. It is the least unprecedented intrusion imaginable in write-up terms and one of the most effective in terms of outcome, and it maps onto exactly the telemetry most teams already collect and aren't querying because attention is somewhere more exciting, for instance, zero-days.

WHAT YOU READ ABOUT	WHAT THEY ACTUALLY USED
An autonomous AI agent	An exposed Langflow instance
AI-written ransomware	Root credentials that already worked
An AI-enabled criminal crew	A built-in command and cracked hashes
A sophisticated adversary	A phone call to a help desk

Which is a comfortable argument to make about other people. So I ran it against my own lab.

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

Eight documented rules. Two real intrusions. One table. To be exact about the method: I did not replay either intrusion's telemetry through Sentinel — I audited each rule against the log sources it reads and the events these two intrusions would have produced.

#	Rule	Reads	FortiBleed	JadePuffer	Why
1	Brute force	Windows Security 4625	Miss	Miss	Hashes were cracked offline; the login that followed was valid
2	PowerShell flags	Windows Security	Miss	Miss	Windows signature, neither platform
3	Registry persistence	Sysmon EID 13	Miss	Miss	No Windows registry in either intrusion
4	Recon burst	Windows process names	Miss	Miss	Windows process names only
5	MFA registration from an untrusted IP	Entra sign-in logs	Closest	Miss	Wrong platform, right logic
6	Shadow-AI execution	Sysmon EID 1, `.exe` list	Miss	Miss	Windows endpoint telemetry
7	AI egress	Sysmon EID 3	Miss	Miss	JadePuffer ran on Linux
8	Agentic process lineage	Sysmon EID 1	Miss	Miss	No `cmd.exe` on a Langflow box

All three of my AI-track detections — shadow-AI execution, AI egress, and agentic process lineage — miss both intrusions. Every one.

The honest reason isn't that they're badly written. It's telemetry scope. Every AI rule I own reads Windows endpoint telemetry: Sysmon Event IDs 1 and 3, and a process name list, an .exe. JadePuffer ran on Linux — Langflow, MySQL, Nacos, no cmd.exe anywhere near it. FortiBleed ran on FortiOS with credentials that were valid. A rule keyed to a Windows process starting cannot see either of those, no matter how good the logic inside it is. A detection is only as good as your understanding of what its data source can see, which I wrote about in Part 7 [6], about a gap in my own Sysmon baseline, and did not expect to be quoting back at myself this soon.

The row that mattered is Part 5.

Part 5 correlates a sign-in from an untrusted IP with a security-info registration inside a thirty-minute window [7]. I built it as Variant B, a downgraded, free-tier version because Entra P2 wouldn't activate and I couldn't have the signal I actually wanted. I wrote it before the AI track existed, when I wasn't thinking about AI at all.

Strip the platform off it, and that is FortiBleed's exact shape: a legitimate account, arriving from somewhere it shouldn't, doing something that matters.

let TrustedIPs = dynamic(["<office/home IP 1>", "<office/home IP 2>"]);
let UntrustedSignIns = SigninLogs
| where IPAddress !in (TrustedIPs)
| where ResultType == 0
| project SignInTime = TimeGenerated, UserPrincipalName, IPAddress, Location;
let MFARegistrations = AuditLogs
| where ActivityDisplayName == "User started security info registration"
| extend UserPrincipalName = tostring(InitiatedBy.user.userPrincipalName)
| project RegTime = TimeGenerated, UserPrincipalName;
UntrustedSignIns
| join kind=inner MFARegistrations on UserPrincipalName
| where RegTime between (SignInTime .. (SignInTime + 30m))
| summarize arg_min(SignInTime, *) by UserPrincipalName, IPAddress
| project SignInTime, RegTime, UserPrincipalName, IPAddress, Location

Wrong log source. Right detection logic. It generalises because it keys on a behaviour, which doesn't age, rather than a technology, which does.

Part 8 does have a real-world match; it just isn't either of these. It's the Nx npm compromise: malicious packages driving victims' own local AI command-line tools into generating credential-theft commands; more than 90 customers were affected [5]. My agentic-lineage rule [8] fires on that shape. It got almost no coverage.

What changes Monday

I don't manage FortiGates for anyone's clients. What follows is what CISA's guidance [9], SOCRadar's documentation and my own coverage audit add up to for the people who do - sourced on each item, so you can check them rather than take my word for it. Here's the checklist:

1. Rotation isn't recovery. Cracked hashes mean the old password was already usable. Rotation closes one door, not the intrusion.

2. Confirm the PBKDF2 rehash per device — following CISA's alert, not me. PBKDF2 replaced SHA-256-with-salt in FortiOS 7.2.11, 7.4.8 and 7.6.1, but a stored password stays on the old scheme until that admin logs in again, and a hidden old-password setting can retain the previous hash. On 7.2.x and 7.4.x, login-lockout-upon-weaker-encryption purges the residue. Verify device by device; assume nothing from the version number alone.

3. Log process lineage on local AI binaries. Not the model traffic — the parent/child chain. The Nx case is a developer's own CLI tool being driven, and lineage is what shows it.

4. Put valid-account abuse ahead of malware signatures. Most detections now are malware-free, and valid accounts dominate cloud intrusions. Neither of these two intrusions would have tripped a signature.

5. Audit your detection backlog for narrative bias. Sort by what you built after reading something alarming, then check which log sources those rules can actually reach.

Both of these intrusions came through a service that was exposed, reachable and authenticated. What was on the other end, twenty people or one agent, changed nothing about the door.

Still open

Whether JadePuffer's Bitcoin address is a real wallet or a string recalled from training data — Sysdig can't distinguish the two.

CVE-2026-24858's role in FortiBleed initial access — under investigation.

References

[1]	“FortiBleed Unmasked: Inside the Lynx and INC Ransomware Operation - SOCRadar,” SOCRadar® Cyber Intelligence Inc., July 09, 2026. https://socradar.io/resources/whitepapers/fortibleed-unmasked-inside-the-lynx-and-inc-ransomware-operation/ (accessed July 21, 2026).
[2]	Ameer Owda, “SOCRadar Links FortiBleed Campaign to INC and Lynx Ransomware Operations,” SOCRadar® Cyber Intelligence Inc., July 2026. https://socradar.io/blog/fortibleed-inc-lynx-ransomware-link/ (accessed July 21, 2026).
[3]	M. Clark, “Jadepuffer: Agentic Ransomware for Automated Database Extortion,” Sysdig.com, July 2026. https://sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion (accessed July 21, 2026).
[4]	Ameer Owda, “FortiBleed: The Campaign That Cracked 86,644 Firewalls,” SOCRadar® Cyber Intelligence Inc., June 16, 2026. https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised (accessed July 21, 2026).
[5]	“CrowdStrike 2026 Global Threat Report,” 2026. Accessed: July 21, 2026. [Online]. Available: https://www.crowdstrike.com/explore/2026-global-threat-report?utm_medium=dir
[6]	K. Dhanjal, “Building a Sentinel Detection Lab, Part 7: The Detection That Taught Me My Own Telemetry’S Blind Spot,” Kajal’S Security Notes, June 30, 2026. https://knowngood.au/writing/building-a-sentinel-detection-lab-part-7-the-detection-that-taught-me-my-own-telemetry-s-blind-spot (accessed July 21, 2026).
[7]	K. Dhanjal, “Building a Sentinel Detection Lab, Part 5: MFA Registration, a Missing License, and the First Detection That Talks Back,” Kajal’S Security Notes, June 21, 2026. https://knowngood.au/writing/building-a-sentinel-detection-lab-part-5-mfa-registration-a-missing-license-and-the-first-detection-that-talks-back (accessed July 21, 2026).
[8]	K. Dhanjal, “Building a Sentinel Detection Lab, Part 8: Watching for Agents, Not Just Attackers,” Kajal’S Security Notes, June 30, 2026. https://knowngood.au/writing/building-a-sentinel-detection-lab-part-8-watching-for-agents-not-just-attackers (accessed July 21, 2026).
[9]	“CISA Urges Hardening Fortinet Devices After Reports of Credential Exposure \| CISA,” Cybersecurity and Infrastructure Security Agency CISA, June 22, 2026. https://www.cisa.gov/news-events/alerts/2026/06/18/cisa-urges-hardening-fortinet-devices-after-reports-credential-exposure (accessed July 21, 2026).
[10]	“Dismantling FortiBleed: Inside a Russian Fortinet Compromise Operation - SOCRadar,” SOCRadar® Cyber Intelligence Inc., June 22, 2026. https://socradar.io/resources/whitepapers/dismantling-fortibleed-inside-a-russian-fortinet-compromise-operation/ (accessed July 21, 2026).

Consulted, not cited

Risky Business Features, "FortiBleed: the bleeding edge of AI cybercrime," podcast episode with E. Seker.
https://open.spotify.com/episode/4WNNxX0RVyLoQHU5fDo5LsDo5Ls

Building a Sentinel Detection Lab, Part 8: Watching for Agents, Not Just Attackers

Tue, 30 Jun 2026 00:00:00 GMT

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

Most process-lineage detections in SOC content are written to catch attackers—Office spawning PowerShell, a browser spawning cmd.exe. Part 8 is the same technique, pointed at a different actor. Not a human attacker. An AI agent.

Why lineage, not signature

Detections 6 and 7 were both signature matches: a known binary, a known process-plus-port pattern. This one is different by necessity. Agent frameworks: LangChain-style tools and AI coding assistants commonly do real work by shelling out. The agent decides to run a command, and a script process spawns a shell to execute it. No single process in that chain is suspicious on its own. Python launching cmd.exe happens constantly, for completely ordinary reasons. The signal here isn't either process alone—it's the combination.

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend ParentImage = extract(@"ParentImage:\s+(\S+)", 1, RenderedDescription)
| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))
| extend ParentProcessName = tolower(tostring(split(ParentImage, "\\")[-1]))
| where ParentProcessName has_any (
    "ollama.exe", "llamafile.exe", "lmstudio.exe",
    "claude.exe", "chatgpt.exe", "cursor.exe", "aider.exe",
    "python.exe", "node.exe"
  )
| where ProcessName has_any ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "bash.exe")
| project TimeGenerated, Computer, ParentImage, ParentProcessName, Image, ProcessName

Both the child (Image) and the parent (ParentImage) come off the same EID 1 event, extracted with the same regex pattern I've used since Part 1, normalized to lowercase. The rule only fires when the parent is a known AI/scripting process and the child is a command interpreter on the same event. It's conceptually closest to the behavioral approach from the recon-burst detection in Part 4—no single field tells the story; the relationship does.

Building and validating it

To generate a real test case rather than a synthetic row, I wrote the smallest honest stand-in for an agent I could: a two-line Python script that shells out to run echo.

subprocess.run("cmd.exe /c echo agentic_test", shell=True)

It's not a real agent framework. But structurally, it's exactly what one does under the hood: a script process deciding to spawn a shell. Ran it once: python.exe as a parent, cmd.exe as a child, caught cleanly on the first attempt. No debugging needed, which is rare enough in this lab to be worth noting on its own.

What I'm not claiming

I want to be specific about what one clean validation run does and doesn't prove. It proves the join logic works. It does not prove this rule is tuned for production. python.exe and node.exe as parent processes is a wide net—any ordinary dev workflow or build script that shells out for unrelated reasons would trigger this exact same pattern. I haven't run it against real-world Python or Node usage yet, so I genuinely don't know the false-positive rate. That's the next thing to find out, not something to guess at and write down as if I already know.

That distinction — a rule that's validated versus a rule that's tuned — has come up in nearly every post in this series. Saying it again here isn't repetition for its own sake. It's the actual discipline the job requires, and it's easy to let slip the moment something works on the first try.

What I took from this one

A clean first-try result is not the same as a tuned result. It's tempting to treat "worked immediately" as evidence of quality. It's evidence the logic is sound, nothing more, yet.
The honest scope of an untested assumption belongs in the rule, not just the writeup. The FP-risk caveat about python.exe/node.exe as parents is written into the rule's description in Sentinel itself, the same way the browser-logging gap from Part 7 is so the limitation travels with the rule, not just with this post.
A minimal stand-in is still a valid test if it's structurally honest. The two-line script isn't a real agent, and I'm not pretending it is. But it produces the exact process-lineage shape a real one would, which is the thing the detection actually checks for.

Three detections into the AI-tooling track now: execution, egress, and lineage. The next open thread is tuning: going back to 6 and 8 with real usage data instead of single validation runs and deciding whether that happens before or after detection 9.

#cybersecurity #sentinel #microsoft-sentinel #kql #detection-engineering #blueteam #azure #ai-security

Building a Sentinel Detection Lab, Part 7: The Detection That Taught Me My Own Telemetry's Blind Spot

Tue, 30 Jun 2026 00:00:00 GMT

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

Part 6 caught AI tooling launching. The natural next question was what happens once it's running—specifically, where does it talk to? This is the most useful failure I've had in this lab so far. Not because the detection didn't work, but because chasing down why it didn't work taught me something true about my own setup that I wouldn't have found any other way.

The plan

Simple idea: match Sysmon network-connection events (Event ID 3) against a list of known AI provider domains—OpenAI, Anthropic, Google's Gemini, and Hugging Face. Write the query, load a page, watch it fire.

It didn't fire. Not once.

Chasing the gap

First check: are EID 3 events even landing in the table at all? Yes — plenty of them. So the join logic wasn't the problem; the matching was.

Second check: what does DestinationHostname actually look like for connections I know are real? Even confirmed traffic—Ollama calling out, a browser loading Hugging Face—showed either a CDN edge hostname (*.bc.googleusercontent.com) or a blank field. Never the literal domain typed into the address bar. Domain-string allowlisting was never going to work reliably against this data, full stop.

Third check, and the one that actually mattered: I ran summarize count() by Image across EID 3 events. Zero msedge.exe rows. Not low — zero. Despite multiple tabs open, including a Hugging Face page I'd just loaded myself to test against.

The root cause: the SwiftOnSecurity Sysmon baseline config — the same config I've been running since Part 1—deliberately excluding browser processes from network-connection logging for noise reduction. This wasn't a bug in my query. It was a real, documented limitation of the telemetry source I'd chosen, and I hadn't known about it until I went looking.

Redesigning around what the data can actually show

Once I understood that, the fix wasn't a smarter regex — it was scoping the detection to match what's actually visible. I pivoted from domain-matching to process-plus-port matching: known AI-tooling processes (ollama.exe, llamafile.exe, python.exe, node.exe, etc.) making an outbound connection on 443 or 80, regardless of where it's headed.

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 3
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))
| extend DestinationHostname = extract(@"DestinationHostname:\s+(\S+)", 1, RenderedDescription)
| extend DestinationIp = extract(@"DestinationIp:\s+(\S+)", 1, RenderedDescription)
| extend DestinationPort = extract(@"DestinationPort:\s+(\S+)", 1, RenderedDescription)
| where ProcessName has_any ("ollama.exe", "llamafile.exe", "lmstudio.exe", "python.exe", "node.exe")
   and DestinationPort in ("443", "80")
| project TimeGenerated, Computer, Image, DestinationHostname, DestinationIp, DestinationPort

It's less precise about where the traffic goes but far more reliable given what I now know about my own config. Validated organically: Ollama on the VM was already making real outbound calls to Google-hosted infrastructure on port 443, caught without my needing to deliberately trigger anything. 8 matching rows once the new logic was in place.

The honest scope statement

This detection catches non-browser AI egress — local tools and scripts calling out directly. It does not catch someone pasting sensitive data into ChatGPT's web interface, because the browser traffic that would carry that simply isn't in this telemetry. That's a real, structural gap, and instead of letting it sit quietly in a comment somewhere, I wrote it straight into the rule's description in Sentinel: "Does not cover browser-based AI usage — SwiftOnSecurity Sysmon baseline excludes browser processes from EID 3 logging." Anyone reading the rule in six months, including me, sees the limitation without having to dig.

What I took from this one

A detection is only as good as your understanding of what its data source can see. I'd assumed Sysmon's network logging was comprehensive. It isn't, by design, and that design choice exists for good reasons but it has to factor into scope, not get discovered after the fact and quietly ignored.
"It doesn't fire" needs the same rigor as "it fires." Treating a non-result as a debugging problem, not a dead end, is what actually surfaced the real limitation here.
Document the gap in the rule itself, not just in your head. A scope limitation that only exists as something I personally remember isn't documentation—it's a landmine for whoever inherits this rule next.

Next up: a different kind of AI-related signal — not the tool running, not its traffic, but what it spawns. Part 8 picks up where an agent shells out and decides whether that pattern is worth flagging on its own.

#cybersecurity #sentinel #microsoft-sentinel #kql #detection-engineering #blueteam #azure #ai-security

Building a Sentinel Detection Lab, Part 6: Shadow AI and the Detection That's Honest About What It Hasn't Proven Yet

Tue, 30 Jun 2026 00:00:00 GMT

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

Five detections in, every one of them pointed at a fairly traditional attacker: brute force, malicious PowerShell, registry persistence, recon, and MFA abuse. Part 6 starts a different track—not an attacker at all, but a governance problem that's quietly become a SOC problem: AI tooling showing up on endpoints with nobody in IT knowing it's there.

This is the first detection in the lab that doesn't really map cleanly onto MITRE ATT&CK, and I'm not going to pretend it does.

The problem underneath the problem

Most "AI security" content jumps straight to prompt injection or model abuse. I had a more basic question first: how would I even know if someone on my network had installed a local AI tool in the first place? Ollama, LM Studio, and a desktop AI coding assistant—none of these are malware. They're also invisible to a SOC that isn't specifically looking for them, and they create a real visibility gap: unmanaged software with no enterprise logging, no DLP coverage, and a direct channel for whatever gets pasted or fed into it.

That's a process-creation problem before it's anything else. Sysmon Event ID 1 already logs every process that launches—the question was just whether I could build a reliable list to match against

The detection

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))
| where ProcessName has_any (
    "ollama.exe", "llamafile.exe", "lm-studio.exe", "lmstudio.exe",
    "chatgpt.exe", "claude.exe", "gemini.exe", "copilot.exe",
    "cursor.exe", "aider.exe", "openai.exe"
  )
| project TimeGenerated, Computer, Image, ProcessName

Same extraction pattern I've used since Part 1—pull Image out the unstructured RenderedDescription text, isolate the filename, normalize case with tolower() (Windows logs process names inconsistently, which is the same issue that caused the case-sensitivity bug in Part 4), then check it against a known list of AI tool binaries. No aggregation, no threshold—a single matching event is the full signal, the same design as the PowerShell detection in Part 2.

What I validated, and what I'm not claiming

I installed real Ollama on the lab VM — not a stand-in. winget install doesn't work on Windows Server 2022, so this meant a direct-download install, which was itself a small real-world gotcha I hadn't anticipated. Confirmed the process running with Get-Process ollama, then queried Sentinel: 5 matching rows, clean full path, nothing truncated.

What I haven't done is false-positive testing at scale. One tool, one validation pass. I want to be upfront about that rather than let the writeup imply a polish level it hasn't earned. A working detection and a tuned detection are different claims, and right now I'm only entitled to make the first one.
On the MITRE mapping

I've tagged this T1588.002 (Obtain Capabilities: Tool) because it's the closest fit ATT&CK offers, but it's worth saying plainly: that technique describes an attacker acquiring tooling pre-compromise, not an employee installing AI software on a managed endpoint. This rule functions more like a custom shadow-IT control than a classic threat detection. Forcing a cleaner ATT&CK story onto it than the behavior actually supports felt like the wrong move, so the repo says so directly.

What I took from this one

A governance signal is still a real detection, even without a clean MITRE mapping. Not every useful rule needs to be dressed up as catching an attacker.
"It worked once" and "it's tuned" are different sentences. Saying the second when I've only earned the first is the kind of overclaim I'd rather catch myself in than have a reviewer catch for me.
Small install gotchas are real findings too. The winget gap on Windows Server isn't a security lesson, but it's the kind of operational detail that separates a lab someone's actually built from one that's only ever been described.

Next up: the network side of the same problem—what happens when that AI tooling tries to talk to the internet and a telemetry blind spot I didn't know I had until I went looking for it. That's Part 7.

#cybersecurity #sentinel #microsoft-sentinel #kql #detection-engineering #blueteam #azure #ai-security

Humans Aren't the Weakest Link

Fri, 26 Jun 2026 00:00:00 GMT

"Humans are the weakest link."

You've seen it on a vendor slide. Probably more than one. It's the most repeated line in security awareness, and it's repeated for a reason: it's comforting. If the human is the weak link, then the breach wasn't a design failure, or a missing control, or an alert nobody tuned. It was someone in finance clicking a link. Problem named. Problem outsourced.

I want to push back on it—not because it's entirely wrong, but because it's lazy in a way that actively makes incident response worse.

The kernel of truth, and where it breaks

Let's be fair to the cliché first. Phishing, social engineering, weak passwords, someone plugging in a found USB—a large share of incidents do start with a person. That's real. I'm not going to pretend the human-shaped gap in the perimeter doesn't exist.

But "incidents often start with a person" and "the person is the weakest link" are two very different claims. The first is an observation. The second is a verdict. And the verdict smuggles in an assumption: that the fix is to make the human stronger—more training, more phishing simulations, more sternly worded emails—rather than to ask why one person's one mistake was allowed to matter that much.

This isn't only my take. Researchers who study the human side of security make the same argument. Dr. Iain Reid (University of Portsmouth) has talked through exactly why "the human is the weakest link" oversimplifies risk—and how something as mundane as time pressure quietly reshapes the decisions people make when an attack lands [1].

If a single click can compromise your environment, the click isn't your weakest link. Your architecture is.

Humans are also the only link that reports

Here's what the slide never says: the same humans are your detection layer.

I spend a lot of my time building detections—KQL analytics rules in Microsoft Sentinel mapped to MITRE ATT&CK [2]. And here's the thing those rules taught me: a detection doesn't respond to anything. It fires. That's it. Something has to read it, judge it, decide it's real, and act. That something is a person.

The employee who forwards a weird email to the security team instead of clicking. The SOC analyst at 2am who looks at an alert everyone else snoozed and says, "Wait—that's lateral movement." Those aren't weak links. They're sensors, often the only sensors that catch what slipped past the tooling.

You don't get those reports from people you've spent years telling they're the problem.

And this isn't wishful thinking — it's measurable. A MITRE study trained employees with hands-on practice and feedback instead of slides, then quietly tested them with simulated social-engineering attempts over a full year. Reporting of the malicious ones improved, and the effect held up for 12 months.[3] The paper's own word for trained employees is the one I keep coming back to: sensors.

Why this matters for IR specifically

This is where the "weakest link" framing stops being merely annoying and starts being expensive.

Incident response lives and dies on one number: how fast you find out. Dwell time: the gap between compromise and detection is the difference between "we contained it" and "we're calling a lawyer." And the fastest path to early detection is almost always a human who noticed something and said something quickly.

So ask: What does a "humans are the weakest link" culture do to the speed of that report?

It slows it down. If an organisation treats mistakes as moral failures, then the person who clicked or who realises they shouldn't have or who isn't even sure hesitates. They wait. They hope it's nothing. They check with a colleague before they admit it to security. Every one of those minutes is dwell time you're handing to the attacker, for free, because you built a culture where reporting feels like a confession.

Aviation worked this out decades ago. So did site reliability engineering. It's called a just culture, or blameless postmortems: you separate "What happened and how do we stop it recurring?" from "Whose fault is it?" Not because nobody is ever responsible, but because the moment people fear blame, they stop giving you information and in IR, information is the whole game.

Contain first. Blame never or at least not until the incident is dead and you're learning from it instead of prosecuting it.

The responder is human too

There's a second human in this story we talk about even less: the responder.

The person who clicked the phish was making a fast, low-attention decision under pressure: a plausible email, a busy Tuesday, fifty other tabs open. We love to judge that decision with the calm hindsight of someone who wasn't there. But that's exactly the dynamic Reid points to: under time pressure, people lean on mental shortcuts, and attackers design for precisely that moment. And the analyst three hours into an active incident is also a human under load—tired, stressed, with cognitive bandwidth shrinking, making high-stakes calls fast. There's a growing body of research on the psychological toll of serious cyber incidents on the people who respond to them too [4].

If we accept that responders make worse decisions under stress — and they do — then we owe the same grace to the user who clicked. Both are humans operating inside systems that asked too much of their attention at the wrong moment. The fix isn't to demand better humans. It's to design for the ones we have.

So what actually changes

Drop the "weakest link" frame, and an IR program starts to look different:

Make reporting frictionless and safe. One button, no judgement, no twelve-field form. The goal is speed, and speed comes from people not being afraid.
Run blameless postmortems. Ask what in the system let the mistake matter, not who made it.
Design alerts and playbooks for humans under stress, not for a well-rested analyst with infinite time. Clear, prioritized, low-noise.
Treat people as sensors. Their reports are detection telemetry. Tune them, value them, and close the loop with them, the same way you would a noisy rule.

The actual weakest link

Humans aren't the weakest link. They're the most adaptable component in the whole stack: the one that improvises, notices the thing that doesn't fit, and reports it when the tooling stayed silent.

The weakest link is a culture that punishes people for being human and then wonders why nobody spoke up until it was too late.

References

[1] Cybercrimeology podcast, The Human in Security: Deception, Weapons, Crime, Culture — featuring Dr. Iain Reid, Senior Lecturer in Cybercrime, University of Portsmouth. https://cybercrimeology.com/episodes/the-human-in-security-deception-weapons-crime-culture-7NBb6hrH

[2] My Sentinel detection lab: https://github.com/Kajal-Dhanjal/sentinel-detection-lab

[3] Caputo, D. D., Danley, L., & Ratcliff, N. J. (2024). Employee risk recognition and reporting of malicious elicitations: longitudinal improvement with new skills-based training. Frontiers in Psychology, 15, 1410426. https://doi.org/10.3389/fpsyg.2024.1410426

[4] Virtanen, T. (2024). The Psychological Effects of Continuity Threatening Cyber Incidents. Proceedings of the 23rd European Conference on Cyber Warfare and Security, 23(1). https://doi.org/10.34190/eccws.23.1.2268

Building a Sentinel Detection Lab, Part 5: MFA Registration, a Missing License, and the First Detection That Talks Back

Sun, 21 Jun 2026 00:00:00 GMT

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

Part 4 ended on this note: moving off the endpoint entirely and into identity, starting with attackers registering their own MFA methods on compromised accounts to keep access after a password reset. This is that detection — and it's also the first one in the lab that doesn't just sit there once it fires.

The plan, and where it hit a wall

The textbook way to build this is on Microsoft Entra ID Protection's risk score. Correlate a risky sign-in with a security-info registration that follows it, and you've got a clean detection for T1556.006 — Modify Authentication Process: MFA — with almost no extra work, because Microsoft has already done the hard part of scoring the sign-in for you.

My tenant said no. The P2 trial wouldn't activate. Try/Buy stayed greyed out — no error, no permission to request, nothing to appeal. This is a personal Azure free tenant (I'm global admin on my own setup, since my university tenant blocks Entra diagnostic settings outright—a separate wall I'm not getting through). P2 just wasn't on the table.

So the question changed from "how do I use the risk score" to "what do I actually have, and is it enough to build something real?"

What I was actually trying to catch

T1556.006 is dangerous because it's boring. An attacker with a stolen credential registers their own authenticator app or phone number as a second factor. From that point on, a password reset doesn't lock them out — their MFA method is now a legitimate part of the account. Nothing about "user registered a new MFA method" looks like an attack on its own. People switch phones constantly. The signal was never going to be the registration itself. It's what came immediately before it.

A risk score made out of what's free

Without a real risk engine, I needed a cheaper way to say "this sign-in doesn't look like the account owner." The signal every tenant has for free, license or not, is IP address. So I built what I've been calling Variant B: keep a short list of trusted IPs and treat a sign-in from anywhere else as untrusted. Correlate an untrusted-IP sign-in with a security-info registration on the same account inside a 30-minute window, and that's the detection.

It's a coarser signal than a real risk score—no device fingerprinting, no impossible-travel logic, and no threat-intel scoring behind it. I'm not going to dress it up as equivalent to something it isn't. But it's real, it's free, and it caught exactly what I simulated.

let TrustedIPs = dynamic(["<office/home IP 1>", "<office/home IP 2>"]);
let UntrustedSignIns = SigninLogs
| where IPAddress !in (TrustedIPs)
| where ResultType == 0
| project SignInTime = TimeGenerated, UserPrincipalName, IPAddress, Location;
let MFARegistrations = AuditLogs
| where ActivityDisplayName == "User started security info registration"
| extend UserPrincipalName = tostring(InitiatedBy.user.userPrincipalName)
| project RegTime = TimeGenerated, UserPrincipalName;
UntrustedSignIns
| join kind=inner MFARegistrations on UserPrincipalName
| where RegTime between (SignInTime .. (SignInTime + 30m))
| summarize arg_min(SignInTime, *) by UserPrincipalName, IPAddress
| project SignInTime, RegTime, UserPrincipalName, IPAddress, Location

Walking through it: pull successful sign-ins from untrusted IPs, pull security-info-registration events from the audit log, join them on the user, keep only pairs where the registration lands within 30 minutes of the sign-in, and then dedup down to one row per user/IP pair so a single real event doesn't surface twice in the same window.

The trusted-IP list itself should live in a Sentinel watchlist, not hardcoded in the query. That wasn't the plan — it's a workaround for a Defender XDR bug where the watchlist upload UI silently failed every time I tried to create one. I'm naming that explicitly instead of quietly shipping around it, because "the UI was broken so I hardcoded it" is a real tradeoff between maintainability and shipping something that actually works today.

Validating it for real

Same approach as every detection before this one — generate real telemetry, don't trust synthetic test rows. I signed in normally from my real IP first, to establish a baseline in SignInLogs.

Then I connected through Proton VPN to a Seattle exit node and signed in again from there. From that same VPN session, I registered a new MFA method — the actual technique, not just a suspicious login on its own. Both events correlated back to the same UserPrincipalName and fired the rule.

The part that's actually new: the detection talks back!

Every detection before this one stopped the second an incident was raised. This is the first one that doesn't.

I wired a Sentinel automation rule to fire on incident creation, triggering an Azure Logic App that calls Add comment to incident (V3)—posting an automated triage note recommending the first containment step (revoking active sessions) directly onto the incident; no analyst action required to get that documented.

The original plan was more ambitious: have the Logic App write the flagged IP straight to a watchlist as a lightweight auto-block. The same broken watchlist UI that forced the hardcoded IP list also made watchlist writes unreliable from Logic Apps. So I scoped the automation down to the smaller, reliable action instead. A working "add comment" beats a watchlist write that fails silently half the time—and knowing when not to build the more impressive version turned out to be its own skill, separate from knowing how.

What I took from this one

A missing license is a constraint to design around, not a reason to stop. Variant B isn't as good as a real risk score, and saying so plainly is more useful than pretending otherwise.
The reliable action beats the ambitious one more often than I expected. I had a more impressive automation in mind, and the platform itself talked me out of it. That's a real engineering decision, not a consolation prize.
Dedup has a blind spot I didn't see coming. My summarize-based deduplication only protects against repeats inside one query run's lookback window—it doesn't stop the same real event from raising a second incident if it's still inside the window on the next scheduled run. I found this from actual duplicate incidents during testing, not from reading the docs first. A production version needs state tracking across runs, not just within one.

The IR playbook

Detection is half the job. Here's what I actually do when this fires—written for a solo analyst, because that's what I am in this lab. No handoff tier, no triage queue; every step assumes I'm the only one responding.

Triage first: Is this real, or just a user on a new device?

Pull the user's sign-in history for the past week and look for a clean break—a normal-location baseline, then an abrupt shift to the flagged IP right before the registration. Then pull the audit log sequence for what was actually registered. A pattern of delete existing method → register new method, both from an untrusted IP, is the strongest tell—it suggests the attacker is replacing the victim's factor with their own, not just adding one. If the source IP traces to hosting or anonymizer infrastructure rather than a residential or known-VPN range, that alone is enough to skip straight to containment without waiting on the user to respond.

Why containment comes before full investigation here.

If the alert is real, the attacker may already have a working MFA method on the account. Every minute spent investigating first is a minute that the persistence mechanism survives a password reset.

Step 1 — Revoke sessions, not the account. Revoking active sessions (Revoke-MgUserSignInSessionor Users → [user] → Revoke sessions in the portal) is the right first move over disabling the account outright—it kills the attacker's stolen tokens immediately and forces re-authentication, without the broader disruption of locking the legitimate user out too.

Step 2 — Remove the attacker-registered MFA method. This is the step that actually evicts the persistence. Revoking sessions alone leaves the planted factor sitting there for the attacker to reuse the next time they authenticate.

Step 3 — Force a password reset. Credentials should be assumed compromised at this point.

Step 4—Re-enroll the legitimate user on a verified, out-of-band channel—not through any contact detail that might have been altered during the compromise. Sequencing matters here: revoke first, then remove the rogue factor and reset the password. Doing it in reverse order risks the attacker re-establishing a session before you've actually cut them off.

Eradication, before closing.

Check for inbox forwarding rules and newly consented enterprise applications—both common follow-on persistence techniques once an attacker has a foothold and easy to miss if you stop at "removed the MFA method."

Post-incident, hunt for the same pattern across other users.

If one credential set was compromised, there's a real chance others were too—the same correlation logic, run across the whole tenant for the past two weeks, surfaces anyone else with the same sign-in-then-registration pattern.

Escalation is about scope, not severity.

Single account, contained quickly → handle it end-to-end and close it. Multiple users, or a privileged account, in the same window → this isn't a single-account event anymore; treat it as a possible wider intrusion and broaden the hunt.

One thing I want to be explicit about: the Logic App automatically posts a comment recommending Step 1 the moment the incident is created, but it doesn't perform the revocation itself. That's a deliberate line, not a gap to fix later. Locking a user out is a judgment call (is this actually an attacker or the account owner traveling?), and that judgment stays with a person. Automating the recommendation but not the action was the right call for this one.

Where this is going

Five detections now—brute force, suspicious PowerShell, registry persistence, the recon-burst detection from Part 4, and this one. Next up: an isolated honeypot VM for Atomic Red Team validation and an AI-assisted triage layer sitting on top of the incidents this lab already generates. That's Part 6.

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

Building a Sentinel Detection Lab, Part 4: Catching Reconnaissance, and the Case-Sensitivity Bug That Made It Look Broken

Sun, 21 Jun 2026 00:00:00 GMT

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

This is Part 4 of the series where I build a Microsoft Sentinel detection engineering lab from scratch and write down what actually happened — including the parts where I got it wrong. Parts 1–3 covered a brute-force detection (volume threshold), a suspicious-PowerShell detection (signature), and a registry persistence detection (signature plus a false-positive I had to tune out).

This one is different. It's the first detection in the lab that doesn't look for a thing—it looks for a pattern of behavior. And it's the one that taught me the most, because for a while it just sat there returning nothing, and I was convinced I'd broken it.

The detection that returned nothing

Here's where I'll start, because it's the most useful thing in this post.

I wrote the rule. I ran the recon commands on my lab VM to generate test data. I ran the query. Empty. No results.

My first instinct — the wrong one — was to start rewriting the logic. Maybe my threshold was off. Maybe the time window was wrong. I poked at it for longer than I'd like to admit.

The actual problem: Windows doesn't log process names consistently. Some commands showed up in Sysmon as arp.exe. Others showed up as ARP.EXE. My filter was matching against a lowercase list, so every uppercase entry silently fell through. The data was right there—my detection just couldn't see half of them because of letter casing.

The fix was one function:

| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))

Normalize everything to lowercase before you compare. Obvious in hindsight. But the lesson stuck harder than the fix: when a detection returns empty, don't assume your logic is wrong—check whether your assumptions about the shape of the data are wrong. A detection that silently under-counts is more dangerous than one that errors out, because it looks like it's working. It'll sit quiet during a real attack, and you'll never know it missed.

That's the whole job, really. The query is easy. Knowing why it lied to you is the skill.

What I was actually trying to catch

Reconnaissance. The phase right after an attacker lands on a machine, before they move anywhere—when they stop and ask the box where am I? who am I? and what's around me.

They run things like whoami, net.exe, nltest, systeminfo, ipconfig, tasklist, hostname, nslookup, arp, route. In MITRE ATT&CK terms this spans a few discovery techniques—T1057 (Process Discovery), T1082 (System Information Discovery), and T1016 (System Network Configuration Discovery).

Here's the problem that makes this detection interesting: not one of those commands is malicious. A sysadmin runs ipconfig 50 times a day. whoami is harmless. If I alerted on any single recon command, I'd drown the SOC in noise, and the alert would get muted within a week.

So the signal isn't the command. The signal is varied in a short window. A real human admin doesn't fire off ten different discovery tools inside ten minutes. An attacker — or an automated recon script — does. They want the full picture, fast.

A third kind of detection: behavioural clustering

My first three detections were a volume threshold and two signatures. This one needed a different shape entirely. I wasn't counting how many times one bad thing happened, and I wasn't matching one known-bad string. I was measuring how many distinct recon tools showed up together.

That's dcount() — count distinct—not a plain count(). Here's the tuned query:

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))
| where ProcessName in ("whoami.exe", "net.exe", "net1.exe", "nltest.exe", "systeminfo.exe", "ipconfig.exe", "tasklist.exe", "hostname.exe", "nslookup.exe", "arp.exe", "route.exe")
| summarize ReconCommands = make_set(ProcessName), DistinctReconCount = dcount(ProcessName) by Computer, bin(TimeGenerated, 10m)
| where DistinctReconCount >= 5

Walking through it: pull Sysmon process-creation events (Event ID 1), extract the image path, and normalize the process name to lowercase (the fix from earlier); keep only known recon tools, then bucket everything into 10-minute windows per machine. make_set() collects which tools appeared and dcount() counts how many distinct ones. If five or more different recon commands cluster inside one 10-minute window on one host, it fires.

The make_set is there on purpose—when this alerts, the analyst immediately sees which tools ran, so they're not starting their investigation from zero.

Tuning in the opposite direction

In Part 3, my registry detection fired on a legitimate Windows process, and I fixed it by adding a narrow exclusion — I told the rule to ignore one specific benign pattern.

This detection's false-positive risk is completely different, so the fix is too. Here, the thing that might trip it innocently is a sysadmin genuinely multitasking—patching, troubleshooting, and running a handful of diagnostic commands in a burst. There's no single benign pattern to exclude; the behavior itself overlaps with legit admin work.

So instead of an exclusion, I tuned the threshold. I started at 4 distinct commands, and it felt slightly twitchy, so I raised it to 5. Fewer false alarms, and a real recon sweep still trips it easily because attackers don't stop at four.

The meta-lesson I took from running both detections back to back: the direction you tune depends on where the false positives come from. A specific benign actor → exclude it. A fuzzy overlap with normal behavior → move the threshold. Same goal, opposite move.

Validating it

I ran a burst of distinct recon commands on the lab VM, waited for ingestion (Sentinel log latency is real — if you run the query the instant you fire the commands, you'll scare yourself with an empty result that's just lag, not failure), then confirmed the rule fired once the distinct count crossed 5. Detection and the resulting incident are both screenshotted in the repo under evidences/.

What I took from this one

Three things:

An empty result is not proof the logic is correct. Check the data's actual shape before you touch the query. Case sensitivity, field formatting, and silent undercounting will fool you every time if you let them.
Some attacks have no bad ingredient — only a bad recipe. No single recon command is suspicious; the cluster is. Detection engineering is often about catching combinations, not items.
Tuning is a decision, not a default. Exclude a known-benign actor; raise a threshold against fuzzy overlap. Knowing which is which is the part that takes judgement.

Next up, I'm moving off the endpoint entirely and into identity—Entra ID detections, starting with attackers registering their own MFA methods on compromised accounts to keep access after a password reset. Different log source, different threat model. That's Part 5.

Full lab on GitHub.

Building a Sentinel Detection Lab, Part 3: My Detection Flagged Legitimate Windows Behavior. Here's How I Tuned It Without Going Blind

Mon, 15 Jun 2026 00:00:00 GMT

Part 3 of a series on building a detection engineering lab in Microsoft Sentinel. This post: registry persistence, a textbook false positive, and the single most important lesson in detection engineering.

The threat

To survive a reboot, malware commonly writes itself into a registry autostart location—or a Winlogon shell key—so it launches automatically at every login. Sysmon logs registry modifications as Event ID 13.

The naive detection

The logic seems obvious: flag any write to an autostart location.

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 13
| extend TargetObject = extract(@"TargetObject:\s+(\S+)", 1, RenderedDescription)
| extend Details = extract(@"Details:\s+(.+?)\s+(?:User:|Image:)", 1, RenderedDescription)
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| where TargetObject has_any (@"CurrentVersion\Run", @"CurrentVersion\RunOnce", @"Winlogon\Shell", @"Winlogon\Userinit")
| project TimeGenerated, Computer, TargetObject, Details, Image

I ran it. It fired straight away—three hits. All of them were userinit.exe writing ctfmon.exe to a run key.

The false positive

ctfmon.exe is the legitimate Windows text/input service (keyboard layouts, handwriting, and speech). Windows itself registers it to autostart via the registry. This happens on every Windows machine, constantly. It is 100% normal.

My detection wasn't wrong—it correctly matched "a write to an autostart location.""It was too broad. And this is the lesson:

A detection that fires on benign activity is worse than no detection at all.

Here's why. If a rule cries wolf on normal behavior, analysts learn to dismiss its alerts. Then, when a real attack trips the same rule, nobody looks. That's alert fatigue, and it's how real intrusions get missed in environments that are technically "monitored." Tuning out benign noise isn't cleanup work you do at the end—it is the detection engineering.

The fix: a narrow allowlist

The tempting fix is to exclude userinit.exe. That's the wrong fix—an attacker who abuses userinit.exe (a real technique) would then sail straight through. Good exclusions are narrow: they drop the exact benign pattern, not a whole process.

| where not(Image endswith "userinit.exe" and Details has "ctfmon.exe")

This excludes only the specific combination of userinit.exe writing ctfmon.exe. Anything else writing to those keys—including malware abusing userinit.exe — still fires.

Validating both sides

This is the part people skip. After tuning, I confirmed the detection went quiet on the ctfmon false positive. But "it stopped firing" proves only half a detection. The other half: Does it still catch real attacks? Over-tuning is the silent failure mode—you suppress the noise and accidentally blind the rule.

So I planted a fake persistence entry (harmless — the referenced file doesn't exist):

New-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "FakeTestMalware" -Value "C:\temp\evil.exe" -PropertyType String -Force

The detection caught it—while still ignoring the ctfmon write. True positive fires, false positive suppressed. That's a complete detection.

The scheduled rule then raised a high-severity incident, MITRE-mapped to T1547.001, with an attack-story graph linking the host. (I removed the fake entries afterward.)

The takeaway that matters most

The first two detections taught me how to write detections. This one taught me how to operate them:

Firing on benign activity is a failure, not a success. A noisy rule trains people to ignore it.
Allowlist narrowly. Exclude the exact benign pattern, never a whole process.
Validate both sides. A detection that stopped firing on noise but no longer catches attacks is worse than the noisy version—at least the noisy one worked.

That third point is the difference between someone who writes queries and someone who runs detections. You can't claim a detection works until you've watched it catch the real thing and ignore the fake one.

Full lab and all three detections on GitHub.

Building a Sentinel Detection Lab, Part 2: Suspicious PowerShell, and Why Some Detections Need No Threshold

Mon, 15 Jun 2026 00:00:00 GMT

Part 2 of a series on building a detection engineering lab in Microsoft Sentinel. This post: hunting malicious PowerShell with Sysmon, and the difference between volume detections and signature detections.

In Part 1 I built a brute-force detection that counted failed logins and fired when the count crossed a threshold. This one is different in a way that turns out to matter: it doesn't count anything. A single match is enough. Understanding why is one of the more useful distinctions in detection engineering.

The threat

Attackers love PowerShell because it's everywhere and powerful. They tend to launch it with flags that legitimate users rarely combine:

enc / -EncodedCommand — base64-encoded commands, to hide intent
w hidden / -windowstyle hidden — run invisibly
ExecutionPolicy Bypass — skip PowerShell's safety controls
downloadstring, iex, invoke-expression — download-and-run "cradles" that pull remote code

Sysmon logs every process launch as Event ID 1, including the full command line. That command line is what we hunt.

Extracting the command line

Same lesson as Part 1: the useful data lives inside RenderedDescription, not a tidy column. A Sysmon process-creation event packs in the image path, command line, parent process, user, and hashes — all as text. So I extract the two fields I need:

| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend CommandLine = extract(@"CommandLine:\s+(.+?)\s+CurrentDirectory:", 1, RenderedDescription)

The CommandLine extraction uses a lazy (.+?) and anchors on the next field (CurrentDirectory:) so it grabs exactly the command line and nothing more.

The detection

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend CommandLine = extract(@"CommandLine:\s+(.+?)\s+CurrentDirectory:", 1, RenderedDescription)
| where Image has "powershell" or Image has "pwsh"
| where CommandLine has_any ("-enc", "-EncodedCommand", "-nop", "-noprofile", "-w hidden", "-windowstyle hidden", "-exec bypass", "-executionpolicy bypass", "downloadstring", "iex", "invoke-expression", "frombase64string")
| project TimeGenerated, Computer, Image, CommandLine

The key operator is has_any(...) — it matches if the command line contains any of those suspicious strings.

Volume detection vs. signature detection

Here's the distinction that matters. The brute-force rule in Part 1 needed a threshold (count >= 5) because no single failed login is suspicious — volume is the signal. This PowerShell rule needs no threshold at all. A single encoded, hidden PowerShell launch is suspicious on its own — the signature is the signal.

So:

Volume detections aggregate and threshold (brute force, password spray, data exfil).
Signature detections fire on a single match (known-bad command flags, known-bad file hashes, known-bad registry keys).

Knowing which kind you're writing tells you whether you need summarize and a count or just a where clause that matches the bad thing.

Validation

There was no malicious PowerShell in my logs to start with — so unlike the brute-force rule (where failed logins already existed), I had to generate the test data first. I ran benign-but-suspicious-looking PowerShell on the VM:

powershell.exe -nop -w hidden -enc SQBFAFgA
powershell.exe -ExecutionPolicy Bypass -Command "Write-Host hello"
powershell.exe -windowstyle hidden -command "Get-Process"

These are harmless — they carry the flags attackers use but do nothing damaging. Importantly, the process launch is the logged event even when the command itself errors. The detection caught all of them, and the scheduled rule raised incidents under the Execution category.

Known false positives (and tbeing honest about them)

-nop and -ExecutionPolicy Bypass are occasionally used by legitimate admin scripts. In production I'd tune this — require two or more suspicious flags together, or allowlist known-good signed scripts by hash. For a lab, single-flag matching is fine and demonstrates the technique. But pretending a detection has zero false positives is how you lose credibility; naming them is part of the job.

Takeaways

Not every detection needs a threshold. Decide whether volume or signature is your signal.
has_any() is your friend for matching against a list of known-bad strings.
Generate test data first for signature detections — the malicious thing has to exist before you can catch it.

Next post: registry persistence — and the false positive that taught me the single most important lesson in detection engineering.

Full lab and detections on GitHub.

Building a Sentinel Detection Lab, Part 1: Catching Brute Force (and the Bug That Flagged the Wrong Account)

Mon, 15 Jun 2026 00:00:00 GMT

Part 1 of a series on building a detection engineering lab in Microsoft Sentinel from scratch. This post: writing my first detection, and the parsing bug that taught me more than the detection itself.

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

I'm building a detection engineering lab in Microsoft Sentinel — a Windows VM shipping security and Sysmon logs into a Log Analytics workspace, where I write KQL detections against simulated attacks. This is the first detection I wrote, and the first one that taught me why detection engineering is harder than it looks. The goal was simple on paper: detect a brute-force login attack. Someone hammering a machine with wrong passwords should trigger an alert. What I learned is that "simple on paper" hides three problems that only show up when you actually build it.

The setup

My VM forwards Windows Security events into a Log Analytics table. A failed login writes Event ID 4625 — the single most important number in this detection. So my first query was the obvious one:

Event
| where EventLog == "Security"
| where EventID == 4625
| where TimeGenerated > ago(2h)

To generate test data, I ran failed logins by hand on the VM:

runas /user:fakeuser cmd #wrong password
runas /user:hacker cmd #wrong password

Wrong password each time. Each attempt wrote a 4625. The query returned them. So far, so good—I had failed-login events flowing in. But a list of failed logins isn't a detection. It's a search. And the moment I tried to turn it into something that names who was attacked, the first problem appeared.

Problem 1: there's no clean username column

I expected a tidy TargetUsername column. There wasn't one. In my table, the entire human-readable event sits inside a single field, RenderedDescription, as one long text blob:

An account failed to log on. Subject: … Account For Which Logon Failed: … Account Name: …

To detect on the username, I couldn't just reference a column — I had to extract it from text. That meant regex. KQL has extract() for exactly this:

| extend TargetAccount = extract(@"Account Name:\s+(\S+)", 1, RenderedDescription)

This says: search the text for "Account Name:" followed by whitespace, then capture the next chunk of non-space characters. The 1 means "give me the first captured group." I ran it, looked at the TargetAccount column, and it said:

labadmin

Which is my own admin account. Not the attacker. That's problem two.

Problem 2: the regex caught the wrong account

It turns out a 4625 event contains two "Account Name:" lines:

The Subject — the account that ran the process triggering the login attempt. That was labadmin (me, in my admin shell, running runas).
Account For Which Logon Failed — the account that was actually attacked. That was fakeuser.

My regex grabbed the first match it found — the Subject — so my detection was reporting the legitimate user instead of the attacker. In a real SOC, this is not a cosmetic bug. A brute-force rule that names the victim's own admin account instead of the attacker sends responders chasing the wrong lead. The fix was to anchor the regex on the right section first, then jump to the next "Account Name:":

| extend TargetAccount = extract(@"Account For Which Logon Failed:[\s\S]*?Account Name:\s+(\S+)", 1, RenderedDescription)

The [\s\S]*? lazily skips everything (including newlines) between "Account For Which Logon Failed:" and the next "Account Name:". Now TargetAccount returned fakeuser. The detection was finally looking at the attacker.

Lesson: when you parse log text, don't trust the first match. Know the structure of the event, and anchor on the part you actually want.

Turning a search into a detection

Extracting the username gives you data. A detection needs a threshold — the logic that says "this pattern is suspicious." For brute force, that's volume: many failures in a short window.

Event
| where EventLog == "Security"
| where EventID == 4625
| extend TargetAccount = extract(@"Account For Which Logon Failed:[\s\S]*?Account Name:\s+(\S+)", 1, RenderedDescription)
| where isnotempty(TargetAccount) and TargetAccount != "-"
| summarize FailedAttempts = count(), TargetedAccounts = make_set(TargetAccount) by Computer, bin(TimeGenerated, 5m)
| where FailedAttempts >= 5

The two lines that matter:

summarize ... by Computer, bin(TimeGenerated, 5m) counts failures per machine in 5-minute buckets.

where FailedAttempts >= 5 is the threshold. Below it, normal. Above it, flag it.

That threshold line is the difference between a log search and a detection. And it created problem three.

Problem 3: the detection didn't fire — and that was correct

I ran it. No results. My first instinct was that the query was broken. It wasn't. The issue was my test data. I had run runas only a couple of times, minutes apart, while reading documentation between attempts. So my failures were scattered across different 5-minute buckets — no single bucket ever reached 5.

This is the central tension in detection tuning:

Too tight a window misses slow, low-and-slow attacks.
Too loose a window floods you with false positives from people fat-fingering their passwords.

A real brute-force bot makes dozens of attempts per minute, so a "5 in 5 minutes" threshold catches it instantly. My manual testing was slow and sparse, so it slipped through — not because the rule was wrong, but because my test didn't resemble a real attack's tempo. That distinction matters. The right move wasn't to lower the threshold to 1 (which would flag every typo in production). It was to recognize the rule was tuned correctly for real attacks, and that my test data simply needed to be a faster burst to validate it.

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$ctx = New-Object System.DirectoryServices.AccountManagement.PrincipalContext('Machine')
1..8 | ForEach-Object { $ctx.ValidateCredentials("attacker$_","WrongPass123!") | Out-Null }

Shipping it

I saved the query as a scheduled analytics rule: runs every 5 minutes, mapped to MITRE T1110 (Brute Force), severity Medium, with the host mapped as an entity so any alert builds an investigation graph. It's now a live detection — not a query I ran once, but a rule watching for brute force on its own.

What I'd do in v2

One refinement I left for later: right now the rule groups by host and collects targeted accounts into a set. A more precise version groups by individual account — flagging "5+ failures against one specific user" rather than "5+ failures total on the box." That's a better detection (password-spray vs. single-account brute force look different), and it makes the account cleanly mappable as an entity. That's the next iteration.

Takeaways

If you're starting detection engineering, the three things this rule taught me:

Log data is messier than the column names suggest. Be ready to parse text, and know the structure of your events before you write regex.
The first regex match is often the wrong one. Anchor on the section you actually want.
A detection not firing isn't always a bug. Sometimes your test data just doesn't look like a real attack — and understanding why is half the skill.

Next up in the lab: a Sysmon-based detection for suspicious PowerShell. More on that soon.

Full lab and detections on GitHub.

This is part of a series on building a detection engineering lab in Microsoft Sentinel from scratch.