M365 Mailbox Intrusion — Detection Engineering (Case Lab 3/3)

Case Context

Lab 3 of a 3-lab case on Threat Hunting Labs, following the Threat Hunt and Incident Response angles against the same Microsoft 365 BEC intrusion. This lab inverts the exercise: instead of querying to find the attacker, you write the rules that would have caught them, against a branching detection map that unlocks further stages once earlier branches clear.

Threat Hunting Labs has a strict no-public-writeup policy on active labs to protect scoring and leaderboards for other users, so this page is intentionally an overview: what I did and what I found, not the detection logic or the specific rule conditions that scored it.

Techniques Encountered

Four branches across the same access-to-persistence chain worked in the Threat Hunt and Incident Response labs, this time expressed as standing detection rules rather than investigative queries. Rules are scored on more than whether they fire — the objective panel splits scoring three ways: a baseline hit, satisfying every stated criterion, and a full-points tier weighing rule quality, precision, and any hint or retry penalties. Cleared every branch with a perfect score, no hints used, and a first-blood bonus.

Prioritising Findings — Pyramid of Pain

Not applicable to this angle. Detection Engineering scores on rule quality and precision rather than discrete IOCs, so no Pyramid of Pain breakdown was generated for this lab — a difference from the Threat Hunt and Incident Response angles worth noting in itself.

What I Practiced

• Translating investigation findings into standing detections, a different skill from finding them once — several fields that answered a question cleanly during hunting turned out to be the wrong basis for a durable rule, because they were specific to this instance rather than to the behaviour.
• Writing for precision under a scoring model that penalises imprecision — a rule that returns the right rows for the wrong reason still loses points, even when it matches the same output as a properly anchored one.
• Building detections that express the shape of behaviour rather than its instances — an aggregation scoped to breadth or sequencing holds up better than one that simply lists matching events, because breadth is what actually distinguishes reconnaissance from ordinary use.
• Working around a constrained query environment with several standard patterns disallowed outright, which forced re-deriving detection logic without the usual shortcuts.
• Defending each rule against the tenant’s own legitimate baseline traffic, which sat close enough to the hostile activity that a naive filter would have caught both.

Case Close

All three labs complete: Threat Hunt, Incident Response, Detection Engineering. The through-line across the case is that this intrusion never broke a control — a valid session, a satisfied MFA claim, every action riding a first-party Microsoft surface behaving normally. Microsoft’s own detection caught the forwarding rule within minutes and rated it at the lowest severity available, then mailed the alert to a recipient the tenant’s own mail system rejected. The detections worth building here are the ones that fire on sequencing and breadth, not on any individual event — because no individual event in this case looked wrong on its own.

Credential

Earned the completion certificate for this 3-lab case (Threat Hunt, Incident Response, Detection Engineering).

Verify: https://www.threathuntinglabs.com/certificates/i24dJJsDrmmU