The M365 and Entra ID Detection Reference

AiTM phishing puts a reverse proxy between the user and the real login page, captures the authenticated session cookie after MFA completes, and replays it. The attacker never needs the password or the second factor again. The tell is in the sign-in risk signals: Entra Identity Protection flags these sessions with specific risk event types. Hunt for them directly rather than waiting for an alert.

The stronger signal is correlation. A user who clicks a phishing URL and then produces a risky sign-in within the hour is the AiTM pattern in two events. If you have Defender for Office 365, join the click to the sign-in:

Rather than steal a session, the attacker gets the user to consent to a malicious OAuth application, which is then granted a token with the scopes the user approved. The token persists independent of the user's password and MFA. Detection lives in the consent and app-role-assignment events in AuditLogs.

Password spraying tries one password across many accounts to stay under lockout thresholds. In the sign-in logs it is a single source (or a small set of sources) generating failures across a large set of distinct users, with the occasional success. The detection is a fan-out on failed sign-ins grouped by source.

Once an attacker has a valid password (from a spray or a dump), they trigger repeated MFA push notifications hoping the user approves one out of annoyance. The pattern is a burst of MFA challenges to a single user in a short window, ending in either repeated denials or one approval. The sign-in logs record each challenge and its result.

After compromising an account, the attacker registers their own MFA method so they can authenticate independently of the user going forward. This is quiet persistence and it is logged as a security-info registration in AuditLogs. Correlating it with a preceding risky sign-in turns a noisy event into a high-fidelity one.

If an attacker extracts the AD FS token-signing certificate, they can forge SAML tokens claiming any identity and any privilege, and those tokens are cryptographically valid. There is no clean signature, which is why this technique is dangerous. Detection is three anomaly patterns, not one rule. First, on the AD FS side, watch token-issuance events for volume anomalies from accounts that do not normally request them.

Second, on the cloud side, the forged authentications arrive at the service provider. Golden SAML logins appear in the sign-in logs with unusual IPs, unexpected user agents, or an auth context that does not match the user's normal pattern. The Microsoft 365 sign-in logs record the federation source, so a federated sign-in from an anomalous location for a privileged account is the second pattern to hunt.

Conditional access that requires a compliant or managed device is only as strong as the device-registration process behind it. An attacker who registers their own device, or joins one that gets marked compliant, turns a device-based control into a door they hold the key to. The high-signal pattern is not the registration alone, it is the sequence: a sign-in from an unusual platform where no CA policy applied, followed shortly by a new device registration for the same user.

An application or service principal can hold its own credentials. An attacker who adds a client secret or certificate to an existing app registration gets a persistent, password-independent way back in that authenticates as that app with all its granted permissions. This is one of the most durable M365 persistence techniques and it is a single audit event.

Conditional access is the control plane for authentication in Entra. An attacker with sufficient privilege does not bypass it, they edit it: disable a policy, switch it to report-only, or add their compromised account to an exclusion group. The change is logged, and the highest-fidelity version of this detection flags a CA modification made by someone who does not normally touch CA.

This is the cloud-side cousin of Golden SAML and one of the most powerful persistence techniques in a hybrid tenant. An attacker who can configure domain authentication federates a domain to an identity provider they control, or alters federation settings, and can then mint valid tokens for any user in that domain. Microsoft's own analytic rule watches the exact operations, and the full attack has a precursor chain worth hunting as a unit.

Sort by domain and time as above and the attack chain reads in order: the same actor adding an unverified domain, verifying it, then setting domain authentication to federated within a short window is the federation backdoor being built. The federation configuration detail itself is not in the audit event, so confirm with Graph: Get-MgDomainFederationConfiguration to inspect the issuer URI and signing certificate for an attacker-controlled IdP.

The clearest privilege-escalation signal in Entra is a role assignment to a high-privilege directory role: Global Administrator, Privileged Role Administrator, Application Administrator. An attacker who reaches one of these can grant themselves or a backdoor account standing admin rights. This is logged as a role-membership add.

An attacker in a mailbox creates an inbox rule that forwards or redirects mail to an external address, then keeps reading the victim's email long after the session ends and without logging back in. It is the stealthiest email-collection method because it persists silently. The detection watches the rule-creation operations for the forwarding parameters, and the key tuning move is excluding internal destinations so only external forwarding surfaces.

The refinement that cuts false positives, straight from Microsoft's alert-grading playbook, is checking whether the ISP or country that created the rule is normal for that user. A forwarding rule created from an ISP the user has never authenticated from in 30 days is the high-confidence version.

Instead of forwarding, an attacker grants their account delegate or full-access permissions on the victim's mailbox, then reads it directly. This is quieter than a forwarding rule because no mail leaves the tenant, and it is logged as an Exchange permission change.

When an attacker reaches SharePoint or OneDrive, the objective is bulk collection: download many files quickly. Normal users download a handful; an attacker staging exfiltration downloads dozens or hundreds in a short window. The detection is a volume threshold on file-download events per user per time bin.

A subset of malicious inbox rules exists not to forward mail but to hide it: moving incoming messages to a rarely-checked folder, marking them read, or deleting them, so the victim never sees the security notifications, replies to the attacker's lateral phishing, or bounce messages. This is defense evasion inside the mailbox, and it is the tell that a forwarding or BEC operation is actively being concealed.

The Microsoft 365 unified audit log is the source behind most of the detections in this reference. An attacker who reaches the Audit Logs role in Exchange Online can disable it with a single command, and from that moment mailbox access, file downloads, and rule creation stop being recorded. The disable action is itself audited, so this is your canary: if you see it and did not authorise it, assume active compromise and that subsequent activity is going dark.

After using a compromised mailbox to send internal phishing or move funds, an attacker deletes the evidence: hard-deleting sent items, purging the Deleted Items folder, or removing specific messages so the real user and investigators cannot see what was sent from their account. Exchange logs these as hard-delete operations.

Having gained access, an attacker enumerates the directory: who holds privileged roles, which accounts to target next, where the value is. In M365 this shows up as bursts of directory-read activity or, from a compromised session, tooling that lists users and roles. The pattern is a single principal reading an unusually broad slice of the directory in a short window.

Once inside a mailbox, an attacker uses it to phish other employees. These messages come from a real internal, trusted sender, so they sail past the filters tuned for external threats and land with the credibility of a known colleague. The detection looks for internal-to-internal mail carrying phishing indicators, or a sudden spike in a single internal sender messaging many internal recipients.

BEC has no clean signature because every individual action is something a normal user does: sign in, read mail, create a rule, send a message. It is the sequence that betrays it. The detection that works is a correlation rule chaining the earlier signals in this reference: a risky sign-in, followed by an inbox rule that hides or forwards mail, followed by outbound mail to finance or an external party about payment. No single event, the chain.

To slow the response once the fraud is in motion, or during destructive attacks, an attacker may reset the victim's password, revoke their sessions, or disable the account, locking out the real user while the attacker keeps a live token. In Entra this is a password reset or account state change made by an unexpected actor.

The AiTM chain is a phishing click, then a session from a new location using the stolen token. Neither event alarms on its own: users click links and travel constantly. Joined within a tight window, they are the attack. This correlation catches the compromise at the moment the token is first replayed, which is the earliest point you can act.

Business email compromise has a recognisable staging sequence: a suspicious sign-in, then an inbox rule that forwards or hides mail, usually within hours. This correlation is the single most useful BEC tripwire because it fires during staging, before the fraudulent mail goes out and before money moves.

Illicit consent phishing tricks a user into approving a malicious OAuth app, which then reads mail through the Graph API. The consent event and the subsequent programmatic mail access are separated by minutes to hours. Correlating the consent grant with a burst of application-driven mail reads confirms the app is doing what it was granted to do, which turns a noisy consent alert into a confirmed incident.

When an attacker takes over a privileged account, the giveaway is speed: a sign-in from an anomalous location followed almost immediately by a high-impact administrative action, a role grant, a CA policy change, a credential added to an app. Legitimate admins do administrative things from their normal locations and devices. The correlation flags admin actions taken shortly after a sign-in that Entra scored risky.

Distinct from server-side inbox rules, Outlook client rules (and the related Outlook Forms and Home Page techniques) can execute an action when mail arrives, historically including launching a payload. They persist in the mailbox and survive password resets. The detection watches rule creation for the client-side rule types and the tell-tale start-application or run-executable actions.

Teams holds as much sensitive conversation as email holds mail, and an attacker with a session or a stolen token reads it through the Graph API. Microsoft's expanded cloud logs record message-read access as the MessagesListed event, and the strongest signal is an anomalous application ID reading many messages quickly, the fingerprint of scripting rather than a human scrolling.

Rather than download files, an attacker builds a Power Automate flow or adds an outbound connector that copies mail or files to an external endpoint automatically. It is exfiltration with no interactive download to catch, and it persists as an automation. The detection watches for new flow creation and connector additions, especially those touching mail or files and pointing at an external destination.

Beyond the Golden SAML case, an attacker who steals a token-signing or AD CS certificate can forge authentication material directly. On-premises, watch for access to the AD FS DKM key and certificate export events; in the cloud, the forged tokens surface as the same claims-versus-reality mismatch described in the Golden SAML section. This technique overlaps with hybrid identity abuse, and the two are best hunted together.