OAuth / workload-identity abuse detection

Why it matters: OAuth device authorization grant is designed for input-constrained devices and rarely originates from normal browser/desktop activity. Storm-2372 (Russian APT, Oct 2024) used it to phish access tokens — the victim is shown a legitimate-looking Microsoft device-code prompt and authorizes the attacker's session.

Fires when: A user (not a service principal) completes a successful sign-in with authenticationProtocol = "deviceCode".

Suppressed: None — device-code is rare enough that every instance is worth a look.

Why it matters: Storm-0558 / SolarWinds persistence pattern — attacker compromises an existing service account and adds a new client secret or certificate to maintain access. Diff-based detection fires regardless of whether Microsoft surfaced the change in directoryAudits.

Fires when: A new passwordCredential (secret) or keyCredential (certificate) appears on a service principal or application registration that already existed in the inventory.

Suppressed: Everything that existed before the connector detection baseline (a first sync into an established tenant is not 32 credential additions), entities younger than 7 days, a fingerprint first seen within an hour of its own inventory row, and both ITDR principals — the per-tenant connector app and the platform app.

Why it matters: Consent-phishing pattern — an attacker publishes a multi-tenant app named Microsoft Outlook or DocuSign Login and asks a user to consent. Rewritten 2026-09-04: the rule previously read local application registrations, which by definition are apps the customer registered, so it could not see a consent-phished multi-tenant app at all while alerting on legitimate in-house integrations. It now reads service principals, where a consented foreign app actually appears.

Fires when: ALL FOUR must hold: the app is externally sourced (its owner organization proves a foreign tenant belonging to neither Microsoft nor the customer), the display name LEADS with the brand on a word boundary (impersonation leads with the brand; a legitimate integration names the service it integrates with, as in Crowdstrike NG SIEM MS Sharepoint Connector), it appeared after the connector baseline, and it holds high-risk permissions.

Suppressed: Microsoft first-party principals — recognised by owner organization, Microsoft-reserved appId ranges, publisher domain or verified publisher, so one missing field cannot expose them — plus in-house registrations and both ITDR principals. A missing owner organization means the app cannot be proven third-party, and suppresses rather than reading as suspicious.

Why it matters: The same Microsoft Graph scope carries different blast radius depending on grant type. Application "Mail.Read" lets a service principal read every mailbox tenant-wide non-interactively. Delegated "Mail.Read" only acts as the signed-in user, bounded by Conditional Access. The previous single marker set scored both equally.

Fires when: No new alert — but existing rules that look at "high-risk permissions" now use a stricter application-permission list (adds Mail.Read, Files.Read.All, User.Read.All, full_access_as_app). Findings on app-permission grants of those scopes will rank higher.

Suppressed: N/A.