OAuth Consent and Mailbox Forwarding in Microsoft 365
At 02:10, a SOC analyst sees a Microsoft 365 alert: a global administrator account signed in from an unusual location and consented to an OAuth application named “MailSync Pro.” The app requests Mail.Read, Mail.Send, and offline_access. The same account created an inbox rule that forwards finance mail to an external address. EDR shows no malware on the admin’s laptop. The tenant has 1,200 users, three global admins, and one shared service account with mailbox delegation. Unified audit log retention is 30 days. The admin says she approved an app after a convincing email from a “vendor.” Finance is in quarter close, and the CIO wants to avoid downtime. Legal has asked whether this is a reportable breach.
1. What containment actions should be taken in the first two hours, and in what order?
Read the worked answer
First, preserve evidence before changing state: export the audit log, sign-in logs, mailbox rule details, app registration metadata, consent grant, and relevant message trace. Second, revoke the admin’s sessions and refresh tokens, reset her password, and require MFA re-registration. Third, disable or remove the malicious enterprise application and revoke its OAuth grants so it cannot continue using Mail.Read and Mail.Send. Fourth, remove the inbox forwarding rule and check for delegate access changes. Fifth, review all other users’ consents for the same app ID and revoke them. I would not disable the entire tenant or block all mail, because that causes disproportionate downtime during quarter close and does not address the token-based access. The order matters: deleting the app before capturing metadata destroys evidence of what was consented to.
2. How would you determine the scope of data accessed using only 30 days of audit log retention?
Read the worked answer
I would pivot on the application ID, the admin’s account, source IPs, user agents, and the external forwarding address. I would search unified audit logs for consent events, mailbox rule creation, mailbox access, Send, and file access where applicable, then correlate with Entra ID sign-in logs for the app and the admin. Message trace can show forwarded or sent messages even if the audit log is thin. I would also check whether the app used Graph permissions to read other mailboxes, and sample finance and executive mailboxes for forwarding rules. Because retention is only 30 days, I would preserve what exists immediately and ask Microsoft support whether extended retention or export is available. Scope should be described as “confirmed,” “probable,” and “not excluded,” rather than claiming full certainty the logs cannot support.
3. What should legal and incident leadership consider when deciding whether this is a reportable breach?
Read the worked answer
The decision hinges on what data was actually accessed or forwarded and the applicable legal regime, not on the fact that an admin clicked consent. If finance mail contained patient data, financial account data, or personal information, counsel should assess state breach notification, HIPAA if protected health information is involved, GDPR if EU residents are affected, and contractual notification duties. The external forwarding address and mailbox rule are strong indicators of unauthorised access, but the team should establish whether mail was actually read or exfiltrated. I would provide legal with a timeline, data types, affected accounts, containment date, and evidence gaps. If the risk of harm is not excludable, notify per counsel’s advice and document the rationale. The CIO’s downtime concern is secondary to containment and notification obligations.