// investigation guide

cloud account compromise (M365 / Workspace) — methodology

tenant compromise via OAuth consent is not the same as credential-stuffing ATO of a single mailbox. the attacker holds delegated permissions — they do not need ongoing user credentials and they do not trip MFA after the initial grant. evidence is unified audit log, sign-in logs, Entra audit, and defender alerts — correlate across exports with the saas audit correlator before password resets alone.

what evidence exists and how fast it dies

artifactvolatilitytime to loss
M365 unified audit log (UAL)rolling90 days default · up to 7 years with E5 + Audit Premium
Entra sign-in logsrolling7 days free · 30 days P1/P2 typical
OAuth2PermissionGrant recordspersist until revokedgrant event in audit log follows UAL retention only
MailItemsAccessed / FileAccessed detailconditionalrequires advanced audit — if never enabled, you may never know what was read
Defender for Cloud Apps alertsrollingvaries by license · export immediately at triage
exfiltrated content itselfgonealready on attacker infrastructure — not recoverable from logs

the first 10 minutes

  1. list all third-party OAuth apps with delegated permissions in the tenant.
  2. revoke any app not on the known-good list — do not wait for attribution.
  3. pull unified audit log for the last 30 days (or max retention) immediately.
  4. pull Entra sign-in logs for the consent grantor and affected users.
  5. pull Entra audit log (ApplicationManagement category).
  6. export OAuth2PermissionGrant records for suspicious apps.
  7. identify affected users via MailItemsAccessed and FileAccessed events.
  8. rotate tokens / force re-auth for all affected users.
  9. disable user consent for non-verified publishers tenant-wide.
  10. notify affected users per your jurisdiction's privacy obligations.

the path

  1. 1. office365 audit log analyzer

    export the M365 unified audit log (UAL) json or csv — 30 days minimum, longer if retention allows. surfaces high-scope OAuth consent, MailItemsAccessed, SharePoint file access, and admin role changes.why first: the consent grant and every Graph touch live in UAL. pull it before retention rolls.

  2. 2. microsoft365 audit log analyzer

    same UAL export — M365 forensic row view with impossible-travel and bulk-access heuristics.why second: cross-check consent + mail/sharepoint volume from a second parser before you trust one flag.

  3. 3. o365 audit log parser

    structured UAL parse — record counts, operation breakdown, suspicious summary for handoff.why third: you need a clean inventory of operations before correlating across other exports.

  4. 4. azure activity log analyzer

    Entra ID (Azure AD) audit log export — consent grant, delegated permission add, service principal removal.why fourth: UAL and Entra audit overlap but are not identical — revocation proof often lives here only.

  5. 5. saas overprivileged oauth scope detector

    OAuth2PermissionGrant export + UAL consent rows. flags Mail.Read, Files.Read.All, Sites.Read.All combos.why fifth: the scopes tell you what was possible — not just that an app existed.

  6. 6. microsoft account activity export forensic analyzer

    Entra sign-in logs — COO consent click, subsequent app sign-ins, Lithuania IP anomaly.why sixth: consent attacks generate app sign-ins to Graph, not always user MFA challenges.

  7. 7. microsoft defender cloud apps alert forensic analyzer

    Defender for Cloud Apps / MCAS alert export — throughput anomaly that triggered detection.why seventh: often the first automated signal — ties volume back to the rogue app name.

  8. 8. fatcousin saas audit export correlator

    drop all exports together — UAL, sign-in, grants, mailbox csv, SharePoint csv, defender alerts.why last: single timeline across exports for impact list and executive briefing.

common false leads

  • MFA was on, so the account is safe — OAuth consent bypasses MFA after the initial grant.
  • the app showed a trusted publisher badge — attackers impersonate Microsoft in app display names.
  • sign-in logs show no user anomaly — consent attacks generate app sign-ins to Graph, not user logins.
  • revoking the app makes it safe — anything already downloaded is already gone.

what we can tell you, what we can't

we can tell you:

  • which rogue app received consent, who granted it, and when
  • delegated scopes granted and whether they are overprivileged
  • per-mailbox and per-file access indicators from exported audit data
  • correlated timeline across UAL, sign-in, grants, and defender alerts

we can't tell you:

  • who registered the malicious app — Microsoft has that; you report via MSRC
  • recover exfiltrated content — it is on attacker infrastructure
  • determine legal notification obligations — counsel and compliance territory

handing it off

  • Microsoft: report rogue multi-tenant app to Microsoft Security Response Center with app id and consent timestamp.
  • affected users: privacy disclosure — what mailboxes/files were touched per your retention exports.
  • outside counsel: if regulated data (contracts, rates, PII) was in harvested mailboxes or SharePoint paths.

reference investigation

synthetic fixture hartmann-cloud-compromise — Hartmann Logistics M365 OAuth consent abuse (TeamSync 365), seed hartmann-cloud-compromise:v1. compare output via npm run check:flagship (32/32 fleet · 8 for this scenario).

proof page: /forensics/proof/hartmann-cloud-compromise · case playbook: case type tools

ready