Payroll Pirates (Storm-2755) — Microsoft 365 AiTM Session Hijack HuntPack

Arctic Wolf Labs and Microsoft (as Storm-2755) are tracking an active, widespread adversary-in-the-middle (AiTM) phishing campaign — publicly nicknamed "Payroll Pirates" — that has targeted hundreds of organizations across healthcare, education, manufacturing, government, and professional services in the US, Canada, and Europe since at least April 2026, with a large wave in July 2026. The attacker's objective is narrow and patient: use a voicemail-themed phishing lure to route victims through a multi-stage redirect chain into a real-time AiTM proxy that relays Microsoft's genuine login flow — capturing the authenticated session token even when MFA is satisfied — then use that stolen session to quietly enumerate payroll/HR/finance staff via Microsoft Graph, read mailbox content about invoices, payments, banking, and direct deposit, and in a smaller subset of cases stage payroll fraud by hiding relevant mail or manipulating HR platforms like Workday.

Because the exploit target is a live Microsoft 365 session rather than an endpoint, the highest-value defensive angle is identity telemetry, not endpoint EDR: Entra ID sign-in log anomalies (rare error codes, session/token replay across IPs, non-native user agents on the Outlook client), Microsoft Graph activity log ingestion (off by default in most tenants and the only visibility into the reconnaissance stage), and Exchange Online mailbox/audit telemetry (the specific ClientAppId/APIId pairing Arctic Wolf found in no legitimate Outlook traffic). Falcon endpoint sensors only see this attack chain if a managed device's browser resolves the phishing infrastructure directly — everything downstream of that click happens cloud-side.

Defender priority: password reset and MFA re-registration alone do not remediate this threat. The attacker already holds a live, previously-issued session/refresh token that survives both actions. The only action that ends attacker access is explicit session and refresh-token revocation, combined with review and removal of any OAuth application consent grants made during the compromise window (a persistence path that also survives password reset and MFA re-registration).

Seven sources were fetched and saved verbatim to PayrollPirates-Storm2755-AiTM-Hunt-sources/ for provenance. Two additional sources (Microsoft's own Storm-2755 writeup and Security Risk Advisors' multi-engagement IR blog) were pulled in via follow-up web search because they contain primary attacker infrastructure, MITRE mapping, and hunting-query detail the five originally assigned sources only partially covered.

Decision notes: the campaign clearly spans multiple infrastructure "waves" under the same actor cluster (Storm-2755 / Payroll Pirate) — domains and IPs rotate between the April 2026 Canadian wave (source 06) and the July–August 2026 wave (sources 01–05). This pack treats wave-specific atomic IOCs (domains, IPs, exact UAs) as hunt/enrich confidence rather than universal blocklist entries, and leans on the behavioral patterns that persist across waves (session/token replay cadence, Graph keyword enumeration, ClientAppId/APIId mail-access pairing, inbox-rule hiding of payroll keywords) for the highest-confidence detections.

Attack chain

Hunt hypotheses (ordered by fidelity)

1. H1 (high): Exchange Online MailItemsAccessed events pairing a specific ClientAppId with an APIId that never appears on legitimate Outlook traffic indicate stolen-session mailbox collection.
2. H2 (high): A New/Set-InboxRule operation whose parameters combine a payroll/bank/direct-deposit keyword with a delete/move-to-Deleted-Items/mark-read action is fraud staging, not personal mail filtering.
3. H3 (high): Entra sign-in error 90014 on the OfficeHome application is rare enough in most tenants that its appearance is a strong AiTM-relay artifact.
4. H4 (high): A single Entra sign-in sessionId observed from three or more distinct source IPs (or two or more countries) in a short window indicates token replay, not normal device roaming.
5. H5 (medium): Outlook-attributed sign-ins reporting a non-native browser/tooling user agent (Firefox 131/142, Python Requests, axios) indicate the AiTM kit or its session-maintenance automation, not the real Outlook client.
6. H6 (medium): A high count of non-interactive sign-ins on one sessionId from three or more distinct IPs indicates automated session-maintenance beaconing rather than a single roaming user.
7. H7 (medium): Bulk Microsoft Graph user enumeration ($top=999) combined with payroll/HR/finance keyword $search and $skiptoken pagination is reconnaissance, not routine directory sync.
8. H8 (medium): An OAuth consent grant or delegated permission addition carrying broad mail/directory scopes, occurring near an anomalous sign-in for the same user, indicates persistence staging.

Attack-chain steps 1, 3, and 10 have no Falcon-visible telemetry in this pack's scope (email gateway, cloud-side AiTM proxy internals, and HR/payroll platform audit are outside CrowdStrike's data model). These are carried forward as coverage gaps in §15 rather than papered over with an invented endpoint signal.

Residential-proxy source IPs reported by Security Risk Advisors (source 07) are treated as context, not blocklist entries — they are ephemeral proxy exit points, not stable attacker infrastructure, and are highly likely to belong to unrelated residential subscribers by the time this pack is read. They are not reproduced in §10's importable block for that reason; use the behavioral queries (Q3, Q6) instead of IP blocking.

Checks that don't require CQL — run directly in the Entra/M365/Purview admin surfaces. Useful both as a first-pass triage and as a way to validate that the CQL queries in §8 will have data to work with.

• Entra ID → Sign-in logs: filter Application = OfficeHome, Status = Failure, Sign-in error code = 90014. Cross-reference any hits against interactive sign-ins for the same user in the following 10 minutes.
• Microsoft Defender XDR advanced hunting: the built-in "Suspicious Exchange Online Graph Reconnaissance Activity" alert (Defender-native, distinct from this pack's Q5) fires on the same bulk-enumeration pattern and is a good corroborating signal if your tenant has Defender XDR licensed.
• Microsoft Purview → Audit (Unified Audit Log) search: Activities = New-InboxRule, Set-InboxRule. Manually review any rule whose parameters reference "direct deposit," "bank," "payroll," or "HR" combined with a delete/move/mark-read action.
• Entra ID → Enterprise Applications → Consent and permissions → Admin consent requests / user consent audit: review any application consented to during a suspected compromise window, particularly grants of Mail.Read, Mail.ReadWrite, full_access_as_app, or Directory.Read.All.
• Entra ID Identity Protection → Risky sign-ins / Risky users: cross-reference any user flagged here against Q1/Q3/Q7 hits — Identity Protection's own risk engine sometimes catches the anomalous device/location combination independently of this pack's queries.
• Exchange Online → Mailbox audit search: for any user suspected compromised, pull MailItemsAccessed events for the full suspected exposure window and manually confirm whether payroll/finance-relevant mail was opened.

This campaign is identity/cloud-native. Queries Q1–Q8 target SaaS/IdP repos (azure_signinlogs, azure_auditlogs, and O365/Graph activity logs). Entra sign-in/audit fields (Q3–Q8) match Microsoft's own lowerCamelCase schema (appDisplayName, ipAddress, etc.) and are documented in the canonical Falcon data model reference. O365 Management Activity / Exchange mailbox-audit fields (Q1–Q2) are parser-prefixed per tenant — how your Falcon NG-SIEM O365 connector names Operation, ClientAppId, etc. on ingest is tenant/parser-version dependent, so this pack renders them as lowercase snake_case placeholders (operation, client_app_id, ...). Validate each against one real sample event before deploying. Only Q9 targets native Falcon sensor telemetry.

// HUNT: MailItemsAccessed via anomalous ClientAppId/APIId pairing (Payroll Pirates AiTM)
// MITRE: T1114.002 (Email Collection: Remote Email Collection), T1078.004 (Valid Accounts: Cloud Accounts)
// CONF: high
// FP: low
// COST: low
// REQUIRES: O365 Management Activity API / Unified Audit Log (Exchange mailbox audit) ingested into Falcon Next-Gen SIEM
// ⚠ Field names below are lowercase placeholders — validate in tenant: operation, client_app_id, api_id, mailbox_owner_upn, client_ip (O365 audit schema is parser-prefixed per tenant, not in this skill's canonical Falcon field table — confirm exact casing against a live sample event)
// FALSE POSITIVES: none observed by source reporting for this exact pairing on legitimate Outlook traffic
// TUNING: if a legitimate mail migration tool or connector is later found to share this pairing, exclude by mailbox_owner_upn allowlist rather than dropping the pairing entirely
// LOOKBACK: 14d
#repo = o365_management_activity
| operation = "MailItemsAccessed"
| client_app_id = "5d661950-3475-41cd-a2c3-d671a3162bc1"
| api_id = "c999ed3e-27ae-4cb3-b3a2-46b056af63d3"
| table([@timestamp, mailbox_owner_upn, client_ip, client_app_id, api_id, operation])
| sort(@timestamp, order=desc)

// HUNT: New inbox rule created to hide or move payroll/bank/direct-deposit mail
// MITRE: T1564.008 (Hide Artifacts: Email Hiding Rules)
// CONF: high
// FP: low
// COST: low
// REQUIRES: O365 Management Activity API / Exchange admin audit log
// ⚠ Field names below are lowercase placeholders — validate in tenant: operation, parameters, user_id, client_ip (O365 audit schema is parser-prefixed per tenant, not in this skill's canonical Falcon field table)
// FALSE POSITIVES: legitimate personal inbox rules that happen to reference "bank" (e.g. a bank-statement filter) — the fraud-staging pattern is the keyword PLUS a hide/delete action together
// TUNING: narrow further to rules whose parameters combine a payroll/bank/direct-deposit keyword AND a DeleteMessage, MoveToFolder=DeletedItems, or MarkAsRead=true action — that combination is the pattern reported in source intel, not the keyword alone
// LOOKBACK: 30d
#repo = o365_management_activity
| operation = /^(New-InboxRule|Set-InboxRule)$/
| parameters = /(direct deposit|payroll|\bbank\b)/i
| table([@timestamp, user_id, operation, parameters, client_ip])
| sort(@timestamp, order=desc)

// HUNT: Entra sign-in failure errorCode 90014 on OfficeHome (AiTM proxy credential relay artifact)
// MITRE: T1557 (Adversary-in-the-Middle), T1078.004 (Valid Accounts: Cloud Accounts)
// CONF: high
// FP: medium
// COST: low
// REQUIRES: azure_signinlogs (Entra ID sign-in logs)
// ⚠ Field unverified — validate in tenant: errorCode (Entra sign-in schema field; appDisplayName is in this skill's canonical table, errorCode is not — confirm against a live sample event)
// FALSE POSITIVES: rare legitimate client-integration misconfigurations can also raise 90014
// TUNING: exclude any appId/clientId already known to be a first-party provisioning or bulk-onboarding tool that legitimately omits a credential field
// LOOKBACK: 7d
#repo = azure_signinlogs
| appDisplayName = "OfficeHome"
| errorCode = "90014"
| table([@timestamp, userPrincipalName, appDisplayName, errorCode, ipAddress, clientAppUsed])
| sort(@timestamp, order=desc)

// HUNT: Single sign-in session/token replayed from multiple source IPs (AiTM token theft)
// MITRE: T1550.004 (Use Alternate Authentication Material: Web Session Cookie), T1078.004
// CONF: high
// FP: medium
// COST: medium
// REQUIRES: azure_signinlogs with sessionId populated (Entra ID sign-in logs, interactive + non-interactive)
// ⚠ Field unverified — validate in tenant: sessionId (Entra sign-in schema field; not in this skill's canonical field table — confirm against a live sample event)
// FALSE POSITIVES: corporate VPN egress changes, mobile carrier IP rotation, and legitimate multi-device sync can show a session spanning 2 IPs
// TUNING: raise the DistinctIPs threshold to 3+ and add a distinct-country check; exclude known corporate VPN egress ranges with cidr() as a separate top-level filter stage
// LOOKBACK: 7d
#repo = azure_signinlogs
| sessionId = *
| groupBy([sessionId, userPrincipalName], function=[count(as=SignIns), count(ipAddress, distinct=true, as=DistinctIPs), collect(ipAddress)], limit=20000)
| DistinctIPs > 2
| sort(DistinctIPs, order=desc)
| table([userPrincipalName, sessionId, SignIns, DistinctIPs, ipAddress])

// HUNT: Outlook sign-ins reporting non-native browser user-agent (AiTM kit / session-maintenance automation)
// MITRE: T1557 (Adversary-in-the-Middle), T1078.004 (Valid Accounts: Cloud Accounts)
// CONF: medium
// FP: medium
// COST: low
// REQUIRES: azure_signinlogs (userAgent, clientAppUsed, appDisplayName)
// ⚠ Field unverified — validate in tenant: userAgent (Entra sign-in schema field; clientAppUsed is in this skill's canonical table, userAgent is not — confirm against a live sample event)
// FALSE POSITIVES: security scanners, RPA/automation tools with legitimate Graph/EWS integrations, some third-party mail clients
// TUNING: exclude known service-account UPNs used for approved automation; require clientAppUsed to indicate Outlook/native client paired with the anomalous userAgent to reduce noise
// LOOKBACK: 7d
#repo = azure_signinlogs
| appDisplayName = "Outlook"
| userAgent = /(Firefox\/131\.0|Firefox\/142\.0|Firefox\/151\.0|Python Requests|axios\/)/i
| table([@timestamp, userPrincipalName, appDisplayName, clientAppUsed, userAgent, ipAddress])
| sort(@timestamp, order=desc)

// HUNT: Recurring non-interactive token-refresh sign-ins from rotating source IPs (session-maintenance beaconing)
// MITRE: T1550.004 (Use Alternate Authentication Material: Web Session Cookie), T1078.004
// CONF: medium
// FP: medium
// COST: medium
// REQUIRES: azure_signinlogs (isInteractive, sessionId, ipAddress) — non-interactive sign-in category must be ingested
// ⚠ Field unverified — validate in tenant: isInteractive, sessionId (Entra sign-in schema fields; not in this skill's canonical field table — confirm against a live sample event)
// FALSE POSITIVES: a single roaming laptop moving between home/office/mobile networks can also show 2-3 distinct IPs on one session
// TUNING: require DistinctIPs >= 3 and SignIns >= 6 over the lookback window to separate beaconing token replay from a single roaming device; raise thresholds further if the tenant has a large remote workforce
// LOOKBACK: 7d
#repo = azure_signinlogs
| isInteractive = "false"
| appDisplayName = /(Outlook|Office 365 Exchange Online|OfficeHome)/i
| groupBy([sessionId, userPrincipalName], function=[count(as=SignIns), count(ipAddress, distinct=true, as=DistinctIPs)], limit=20000)
| SignIns > 5
| DistinctIPs > 2
| sort(SignIns, order=desc)
| table([userPrincipalName, sessionId, SignIns, DistinctIPs])

// HUNT: Microsoft Graph bulk user enumeration with payroll/HR/finance keyword search and pagination
// MITRE: T1087.004 (Account Discovery: Cloud Account)
// CONF: medium
// FP: low
// COST: medium
// REQUIRES: Microsoft Graph activity logs ingested into Falcon Next-Gen SIEM — NOT enabled by default in most Entra tenants; must be explicitly turned on (see Hardening §12)
// ⚠ Field unverified — validate in tenant: repo name, requestUri, appId (Graph activity log schema; not in this skill's canonical field table — confirm against a live sample event)
// FALSE POSITIVES: legitimate HR/IT provisioning tools performing bulk directory sync can trigger $top=999 pulls
// TUNING: allowlist known SCIM/HRIS provisioning app IDs (e.g. Workday or HiBob connector service principals) that legitimately enumerate all users
// LOOKBACK: 30d
#repo = graph_activity_logs
| requestUri = /\/v1\.0\/users/i
| requestUri = /(payroll|human|resources|finance|admin)/i
| requestUri = /\$skiptoken/i
| table([@timestamp, userPrincipalName, appId, requestUri, userAgent, ipAddress])
| sort(@timestamp, order=desc)

// HUNT: OAuth application consent grant with broad delegated mail/directory scopes (post-AiTM persistence)
// MITRE: T1098.003 (Account Manipulation: Additional Cloud Roles), T1550.004
// CONF: medium
// FP: medium
// COST: low
// REQUIRES: azure_auditlogs (Entra ID audit log)
// ⚠ Field unverified — validate in tenant: activityDisplayName, initiatedBy ("targetResources.modifiedProperties.newValue" is documented in this skill's canonical field table; the other two are not — confirm against a live sample event)
// FALSE POSITIVES: legitimate first-time SSO app onboarding also generates consent-grant audit events
// TUNING: correlate consent-grant events against users flagged by Q3/Q4/Q5 in the same session window; exclude pre-approved enterprise app IDs from an admin-maintained allowlist
// LOOKBACK: 30d
#repo = azure_auditlogs
| activityDisplayName = /^(Consent to application|Add app role assignment|Add delegated permission grant)$/
| "targetResources.modifiedProperties.newValue" = /(Mail\.Read|Mail\.ReadWrite|full_access_as_app|Directory\.Read\.All|offline_access)/i
| table([@timestamp, initiatedBy, activityDisplayName, "targetResources.modifiedProperties.newValue"])
| sort(@timestamp, order=desc)

// HUNT: Managed-endpoint DNS resolution of known Payroll Pirates AiTM redirector/proxy domains
// MITRE: T1566.002 (Phishing: Spearphishing Link), T1557 (Adversary-in-the-Middle)
// CONF: medium
// FP: low
// COST: low
// REQUIRES: Falcon sensor DnsRequest telemetry on the clicking endpoint. This is the ONLY attack-chain step visible to endpoint EDR in this pack (see Coverage Map, §15) — it fires only if the phishing link is opened from a Falcon-covered device; it does not cover BYOD/mobile clicks, and the AiTM session theft plus all post-compromise cloud activity are invisible to endpoint EDR entirely.
// FALSE POSITIVES: near zero for an exact domain match
// TUNING: refresh this domain list from current threat intel before each hunt run; do not rely on this query alone given domain rotation — pair with Q1-Q8, which cover the cloud-side stages that persist regardless of infrastructure rotation
// LOOKBACK: 7d
#event_simpleName = DnsRequest
| DomainName = /^(idp\.keyreniao\.com|idp\.korminel\.com|idp\.kualabemo\.com|mslogin\.milocaroline\.com|msonline\.logicalineonline\.com|msauth\.monlinelogicaline\.com|office\.ofrecie\.com|bluegraintours\.com)$/i
| table([@timestamp, ComputerName, UserName, DomainName])
| sort(@timestamp, order=desc)

Honesty note: a classic Falcon Custom IOA is a behavioral indicator evaluated by the endpoint sensor. It does not apply to SaaS/identity telemetry (Q1–Q8), which lives in Falcon Next-Gen SIEM, not on an endpoint. For those, the correct promotion path is a Scheduled Search / Correlation Rule in Next-Gen SIEM feeding an alert or Falcon Fusion SOAR workflow — not a Custom IOA. Q9 (endpoint DNS) is the one query in this pack eligible for genuine Custom IOA / Custom IOC treatment.

Promote to Scheduled Search / Correlation Rule (Next-Gen SIEM)

Keep Investigate-only (tune before promoting)

• Q5, Q6, Q8 — CONF medium and FP medium; run as scheduled hunts with analyst review rather than auto-paging until each has a documented 30-day benign baseline (§11).
• Q7 — depends on Graph activity logs being enabled at all; treat as Investigate-only until that ingestion gap (§5) is closed org-wide.

Q9 — genuine Custom IOA / Custom IOC candidate

Because Q9 runs against native Falcon sensor DnsRequest telemetry, the reported redirector/proxy domains can additionally be loaded as Custom IOC domain-block/detect entries (Falcon → Endpoint security → IOC Management) for immediate coverage, independent of the Scheduled Search. Given the domain-rotation caveat in Q9's tuning note, treat this as a short-lived tactical block, not a durable detection — refresh or expire it alongside the domain list.

Flagship alert package (Q1)

Scheduled Search Name: HUNT: Payroll Pirates AiTM - MailItemsAccessed Anomalous Client Pairing

Subject: 🚨 HUNT ALERT 🚨 — Payroll Pirates AiTM Mailbox Collection Detected (Possible Business Email Compromise)

Body: An Exchange Online mailbox was accessed using a ClientAppId/APIId pairing that source threat-intel reporting found in zero legitimate Outlook traffic. This pairing is associated with the active Payroll Pirates / Storm-2755 AiTM campaign, which steals live M365 session tokens (bypassing MFA) and then reads payroll, invoice, and banking-related mail. This is a mailbox-read event, not a login event — the account's session was very likely already compromised by the time this fired. Check the mailbox owner's role first (payroll/HR/finance = high urgency), then immediately move to §14's Isolate phase — do not wait for a password-reset confirmation, since a stolen session survives that action.

Investigation checklist:

1. Confirm the ClientAppId/APIId pairing exactly matches 5d661950-3475-41cd-a2c3-d671a3162bc1 / c999ed3e-27ae-4cb3-b3a2-46b056af63d3 in the raw event — not a partial match.
2. Check mailbox_owner_upn against your HR/payroll/finance group membership — escalate immediately if it matches.
3. Pivot to Q3/Q4/Q5 for the same UPN over the prior 24 hours to confirm the anomalous sign-in that preceded the mailbox read.
4. Pivot to Q2 for the same UPN to check whether a fraud-staging inbox rule was also created.
5. Pivot to Q8 for the same UPN to check for an OAuth consent grant made during the same window.
6. Begin §14 Isolate phase (session/token revocation) immediately — do not wait for full investigation to complete.
7. Notify Payroll/HR to freeze any pending direct-deposit or banking-detail change tied to this user for the suspected exposure window.

Pivot queries

>> YOU NEED: mailbox_owner_upn (from the alert)    >> FILL IN: mailbox_owner_upn="REPLACE_WITH_UPN"

// Host/user-scoped: all mailbox access for this UPN in the last 24h
#repo = o365_management_activity
| operation = "MailItemsAccessed"
| mailbox_owner_upn = "REPLACE_WITH_UPN"
| table([@timestamp, client_ip, client_app_id, api_id, operation])
| sort(@timestamp, order=desc)

// Environment-wide: frequency of this exact pairing across all mailboxes
#repo = o365_management_activity
| operation = "MailItemsAccessed"
| client_app_id = "5d661950-3475-41cd-a2c3-d671a3162bc1"
| api_id = "c999ed3e-27ae-4cb3-b3a2-46b056af63d3"
| groupBy([mailbox_owner_upn], function=count(as=Hits), limit=500)
| sort(Hits, order=desc)

Playbook A — Enforce phishing-resistant MFA + block legacy authentication

MITRE: T1557, T1078.004, T1550.004 → M1032, M1042  |  Estimated deploy time: 2–4 hours plus a pilot ring  |  Prerequisites: Entra ID P1/P2 licensing, Microsoft Graph PowerShell SDK, Conditional Access administrator role, at least one break-glass account excluded and tested  |  Reboot required: No (tenant/cloud configuration only)

Step 1 — Require phishing-resistant MFA via Conditional Access authentication strength

What it does: Forces FIDO2/Windows Hello/certificate-based auth for sign-in, closing the gap that lets an AiTM proxy relay a TOTP or push approval. Why it works: Phishing-resistant methods are bound to the origin the user is actually talking to, so a proxy site cannot successfully complete the challenge on the attacker's behalf.

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Policy.Read.All"

$params = @{
    displayName = "CA001-Require-PhishingResistantMFA-FinancePayrollHR"
    state = "enabledForReportingButNotEnforced"  # flip to "enabled" after pilot
    conditions = @{
        users = @{
            includeGroups = @("REPLACE_WITH_PAYROLL_HR_FINANCE_GROUP_ID")
            excludeUsers  = @("REPLACE_WITH_BREAK_GLASS_ACCOUNT_OBJECT_ID")
        }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{
        operator = "AND"
        authenticationStrength = @{ id = "00000000-0000-0000-0000-000000000004" }  # built-in Phishing-resistant MFA strength
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Verify:

Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'CA001-Require-PhishingResistantMFA-FinancePayrollHR'" |
  Select-Object DisplayName, State

Rollback:

$policy = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'CA001-Require-PhishingResistantMFA-FinancePayrollHR'"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -BodyParameter @{ state = "disabled" }

Compatibility note: pilot on the payroll/HR/finance group for 1–2 weeks in report-only mode before flipping to enabled, and confirm every pilot user has a registered FIDO2 key or Windows Hello for Business before enforcement — otherwise they lock themselves out.

Step 2 — Block legacy authentication tenant-wide

What it does: Denies sign-in for client types that cannot enforce Conditional Access or modern MFA at all. Why it works: Legacy protocols (IMAP/POP/SMTP AUTH/older ActiveSync) are a bypass lane around every control in Step 1 — closing it removes the attacker's fallback path.

$params = @{
    displayName = "CA002-Block-LegacyAuthentication"
    state = "enabledForReportingButNotEnforced"
    conditions = @{
        users = @{ includeUsers = @("All"); excludeUsers = @("REPLACE_WITH_BREAK_GLASS_ACCOUNT_OBJECT_ID") }
        applications = @{ includeApplications = @("All") }
        clientAppTypes = @("exchangeActiveSyncSupported", "other")
    }
    grantControls = @{ operator = "OR"; builtInControls = @("block") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Verify:

Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'CA002-Block-LegacyAuthentication'" |
  Select-Object DisplayName, State

Rollback:

$policy = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'CA002-Block-LegacyAuthentication'"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -BodyParameter @{ state = "disabled" }

Compatibility note: audit legacy-auth sign-in volume for 7 days first (Entra sign-in logs, filter Client App = legacy) — some line-of-business scanners/printers/older scripts genuinely use IMAP/SMTP AUTH and need a scoped service-account exception before this goes tenant-wide.

Playbook B — Harden session controls and application consent

MITRE: T1550.004, T1098.003 → M1036, M1018  |  Estimated deploy time: 1–2 hours  |  Prerequisites: Entra ID P2 licensing for CAE strict enforcement, Global Administrator or Authentication Policy Administrator role  |  Reboot required: No

Step 1 — Enforce strict Continuous Access Evaluation and shorten sign-in frequency

What it does: Forces near-real-time token revocation on risk signals and caps how long a replayed session stays useful. Why it works: Even if a token is stolen, CAE strict mode re-checks conditions continuously rather than trusting the token for its full lifetime, and a short sign-in frequency forces re-authentication (through the now phishing-resistant flow from Playbook A) on a tight cycle.

$params = @{
    displayName = "CA003-StrictCAE-ShortSessionLifetime-ExchangeSharePoint"
    state = "enabledForReportingButNotEnforced"
    conditions = @{
        users = @{ includeUsers = @("All"); excludeUsers = @("REPLACE_WITH_BREAK_GLASS_ACCOUNT_OBJECT_ID") }
        applications = @{
            includeApplications = @(
                "00000002-0000-0ff1-ce00-000000000000",  # Office 365 Exchange Online
                "00000003-0000-0ff1-ce00-000000000000"   # Office 365 SharePoint Online
            )
        }
    }
    sessionControls = @{
        continuousAccessEvaluation = @{ mode = "strictEnforcement" }
        signInFrequency = @{ value = 4; type = "hours"; isEnabled = $true; authenticationType = "primaryAndSecondaryAuthentication" }
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Verify:

Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'CA003-StrictCAE-ShortSessionLifetime-ExchangeSharePoint'" |
  Select-Object DisplayName, State

Rollback:

$policy = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'CA003-StrictCAE-ShortSessionLifetime-ExchangeSharePoint'"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -BodyParameter @{ state = "disabled" }

Step 2 — Disable self-service OAuth application consent

What it does: Requires an administrator to approve any new application's delegated permissions rather than letting an already-compromised user grant them. Why it works: Closes the persistence path SRA documented — a consented app with broad mail/directory scopes survives password reset, session revocation, and MFA re-registration entirely, since it doesn't depend on the user's credentials at all.

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Primary control surface is the Entra Admin Center:
#   Identity > Applications > Enterprise applications > Consent and permissions > User consent settings
#   Set to "Do not allow user consent"
# Graph PowerShell equivalent (verify exact cmdlet/property names against your installed SDK version):
Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{ PermissionGrantPoliciesAssigned = @() }

Verify:

(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions.PermissionGrantPoliciesAssigned
# Expect: empty array (no self-service consent policies assigned)

Rollback:

Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{ PermissionGrantPoliciesAssigned = @("ManagePermissionGrantsForSelf.microsoft-user-default-legacy") }

Compatibility note: disabling self-service consent will break any team's habit of clicking "Accept" on new SaaS integrations — pair this change with a published, fast admin-consent request process so it doesn't just push people toward workarounds.

Do not close the incident on password reset alone. Confirm explicit session/refresh-token revocation succeeded (re-run Q4 for the user — the previously-flagged sessionId should stop generating new sign-ins) before considering the account clean.

Overall: 6 of 11 mapped techniques have good CQL coverage, 3 have partial coverage from downstream artifacts, and 3 are structural gaps (email-gateway delivery stage, internal-spearphishing follow-through, and financial-platform impact) that sit entirely outside CrowdStrike's data model and require the mail-gateway, CASB, and HR-platform controls recommended in §12. All queries in §8 pass the validation gates in §11 before promotion to a paging alert; see §9 for the current promotion status of each.