SP-less Triage Loop

Issuance-then-use

index=* category=MicrosoftGraphActivityLogs earliest=-30d@d
    properties.appId="<appId under investigation>"
| rename properties.responseStatusCode as code, properties.requestUri as uri,
    properties.requestMethod as method
| where tonumber(code)>=200 AND tonumber(code)<300
| stats count as ok2xx values(method) as methods values(uri) as uris
    min(_time) as first max(_time) as last by properties.appId
→ any row = the app acted despite "no consent"; writes (POST/PATCH/DELETE)
  against roles, servicePrincipals or applications go straight to the verdict

Prerequisite: Microsoft Graph activity logs must be enabled through diagnostic settings (P1 or P2); off means a coverage gap, not a clean result. Per Microsoft's FAQ, some first-party app-only calls are not published to the service-principal sign-in log, so Graph rows you cannot pair with a sign-in are not evidence either way. Columns: MicrosoftGraphActivityLogs.

# which resource each all-zeros token was cut for

index=* category=ServicePrincipalSignInLogs earliest=-30d@d
    properties.appId="<appId under investigation>"
    properties.servicePrincipalId="00000000-0000-0000-0000-000000000000"
| fillnull value="-" properties.resourceDisplayName properties.resourceId
| stats count values(resultType) as results
    min(_time) as first max(_time) as last
    by properties.resourceDisplayName properties.resourceId
→ Graph rows: read the block above. Exchange, SharePoint and the
  Office 365 Management APIs reject an SP-less token and write no
  tenant-side log of it; those rows are attempts, and the only record

The resource column is also the exception evidence: Microsoft's freezes were scoped per resource, so a client allowed through to one resource may be blocked at another. Issuance rows for a resource the vendor never documented using belong in the verdict.

Persistence audit

# two views of one appId: what it DID (actor) and what was done TO it (target)
index=* category=AuditLogs earliest=-30d@d ("<appId>" OR "<app display name>")
    operationName IN ("Add member to role", "Remove member from role",
        "Add app role assignment to service principal",
        "Remove app role assignment from service principal",
        "Add service principal credentials", "Remove service principal credentials",
        "Update application – Certificates and secrets management",
        "Add service principal", "Remove service principal", "Delete application",
        "Add owner to application", "Add owner to service principal",
        "Consent to application", "Add delegated permission grant")
| rename properties.initiatedBy.app.appId as actor_app,
    properties.initiatedBy.app.displayName as actor_name,
    properties.initiatedBy.user.userPrincipalName as actor_user,
    properties.targetResources{}.displayName as target, properties.result as result
| eval side=if(actor_app="<appId>", "actor", "target")
| table _time side operationName actor_app actor_name actor_user target result
| sort _time

# churn: the same target gets an add AND a remove inside 60 min (operator or agent at the keyboard)
index=* category=AuditLogs earliest=-30d@d ("<appId>" OR "<app display name>")
    operationName IN ("Add member to role", "Remove member from role",
        "Add service principal credentials", "Remove service principal credentials")
| rename properties.targetResources{}.displayName as target
| eval verb=if(match(operationName, "^Add"), "add", "remove")
| transaction target maxspan=60m
| where mvcount(mvdedup(verb))=2
| table _time duration target operationName
→ actor rows: the app changed something (self-assigned a role, put a credential on another app)
→ target rows: someone changed the app (a credential added since the vendor's incident date is the way in)
→ sibling principals it touched go on the containment list

Operation names are Microsoft's audit activity reference names. The add → remove → add churn is what Huntress reported on Oct 26 ("A secret was added, removed, and added again"; the Global Administrator role granted then removed twice), and the self-assigned role is the Defender alert "Application self-assigned Global Administrator role" in Microsoft's Storm-0940 post.

Blast radius

# 1) resources the token was minted for, and from where
index=* category=ServicePrincipalSignInLogs earliest=-30d@d properties.appId="<appId>"
| stats count min(_time) as first max(_time) as last
    by properties.resourceDisplayName properties.ipAddress properties.autonomousSystemNumber

# 2) Graph: which object families, how many distinct users
index=* category=MicrosoftGraphActivityLogs earliest=-30d@d properties.appId="<appId>"
| rename properties.requestUri as uri, properties.requestMethod as method,
    properties.responseStatusCode as code
| eval family=case(match(uri,"/messages|/mailFolders"), "mail",
    match(uri,"/drives|/sites"), "files", match(uri,"/directoryRoles|/roleManagement"), "roles",
    match(uri,"/servicePrincipals|/applications|/oauth2PermissionGrants"), "apps",
    match(uri,"/users"), "users", match(uri,"/groups"), "groups", true(), "other")
| rex field=uri "/users/(?<user>[^/?]+)"
| stats count dc(user) as users values(method) as methods by family code
| sort family

# 3) mailboxes actually read (Microsoft 365 unified audit log; MailItemsAccessed is
#    Audit (Standard), on by default for E3/E5 mailboxes — if absent, that is a gap, not a zero)
index=* Workload=Exchange Operation=MailItemsAccessed ClientAppId="<appId>" earliest=-30d@d
| stats count dc(MailboxOwnerUPN) as mailboxes values(ClientIPAddress) as ips by ClientAppId
→ the "users", "mail" and "files" rows and the mailbox count are the notification scope

MailItemsAccessed is part of Audit (Standard), "enabled by default for users that are assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 license". In the mailbox audit schema the app is ClientAppId ("the Microsoft Entra app that performed the access"); AppId there is "the API pathway", for example Graph, so do not filter on it. The Graph URI families come from RequestUri.