OAuth Consent and MFA Fatigue in Microsoft 365
On Monday at 09:05 the helpdesk receives 14 reports of unexpected Microsoft 365 MFA prompts. Azure AD sign-in logs show six users approved a push notification, and four of those users subsequently granted an OAuth application named 'eM Client Sync' the Mail.Read and offline_access scopes. Within 20 minutes, a mailbox rule named 'RSS Feeds' appears in three mailboxes, and one user's mailbox sends 200 internal phishing messages. Conditional Access requires a compliant device for modern authentication but has a legacy-auth exclusion for two service accounts. The security team has EDR on endpoints, but no mail gateway logs older than seven days. The company has 4,000 users; finance and HR are high-risk. The SOC asks how to triage and contain without locking out executives who are traveling.
1. What is the most likely attack chain, and which two log sources would you query first to confirm scope?
Read the worked answer
The chain is consistent with MFA fatigue followed by illicit OAuth consent. The attacker repeatedly sends push prompts until a user approves, then uses the approved session to consent to an app with Mail.Read and offline_access. The refresh token lets the app read mail asynchronously, and the inbox rule hides replies or notification messages. The internal phishing from the compromised mailbox is likely lateral phishing to collect more credentials or consent.
Query the Azure AD audit logs for consent events, enterprise application creation, and service principal additions; filter for the app name and the four users. In parallel, query the Exchange Online unified audit log for New-InboxRule, Set-InboxRule, and Send events around 09:05 to 09:30. These two sources establish who consented, what the app can do, and which mailboxes are actively abused. Sign-in logs then add source IPs and user agents, but they do not prove consent or mailbox rule creation by themselves.
2. Would you revoke sessions, reset passwords, or both? Explain per user group.
Read the worked answer
Both, but not identically for every group. For the four users who granted OAuth consent, revoke refresh tokens and sessions first, remove the enterprise app consent and service principal, then reset passwords. Revoking sessions invalidates the token the app is using; a password reset alone does not kill an existing refresh token. Removing consent prevents re-authorization.
For the two users who only approved an MFA push but did not consent, reset the password and revoke sessions as a precaution. Their approval may have been the first stage, and the attacker may have a session token even without app consent. Review their mailbox rules and sign-in history.
For executives traveling, do not disable accounts. Use targeted session revocation and app removal, then require re-registration of MFA if there is evidence the push was approved by an attacker. Communicate through a separate channel and avoid a broad tenant-wide revoke that disrupts travel.
3. What containment action for the internal phishing should you take, and what detection gap remains?
Read the worked answer
Contain the internal phishing by purging the 200 messages from all mailboxes with a compliance search, blocking the sender and any embedded URL or attachment hash, and checking for replies or credential-entry pages. Search for recipients who clicked or consented, and remove any newly created inbox rules. Do not simply delete the original mailbox; preserve a copy for investigation.
The remaining gap is visibility. Mail gateway logs older than seven days are unavailable, so earlier phishing waves and delivery patterns cannot be reconstructed. The legacy-auth exclusion for two service accounts is also a blind spot because those accounts can bypass compliant-device Conditional Access. Recommend forwarding Exchange audit logs, Azure AD sign-in logs, and mail gateway events to the SIEM with at least 90-day retention, and remove or tightly scope legacy authentication. Until then, scope is limited to what Microsoft 365 audit data retained.