Microsoft is actively resolving a global outage affecting Microsoft 365 and Outlook, disrupting email, collaboration, and authentication-dependent workflows for organizations worldwide. While Microsoft's engineering teams work the availability problem, security teams face a parallel and equally urgent threat: cybercriminals preparing to weaponize the chaos.
This is a well-established pattern I've watched repeat across every major SaaS outage of the past several years — AWS, Cloudflare, Azure AD, Google Workspace. The moment users lose access to a business-critical platform, three things happen predictably: users become desperate for updates and workarounds, help desks become overwhelmed and bypass verification controls, and attackers flood inboxes with convincing "outage status," "service restoration," and "credential re-verification" lures. Outages compress decision-making and degrade skepticism — exactly the conditions social engineers need.
If your organization relies on M365, your SOC should treat this outage window as an elevated-threat period for phishing, help-desk social engineering, MFA fatigue attacks, and credential harvesting. This post breaks down how attackers exploit these events and provides the detections and hardening steps you need now.
Technical Analysis: How Outage-Themed Attacks Work
The Attack Chain
Outage exploitation is not a vulnerability in Microsoft's code — it's a vulnerability in human workflow under stress. The typical attack chains I've observed during major SaaS outages include:
1. Outage-themed credential harvesting. Attackers spin up lookalike "Microsoft status" or "service recovery" portals within hours of an outage becoming public. Emails claiming "Your mailbox has been disconnected — re-authenticate to restore service" direct users to credential-harvesting pages that proxy or clone the legitimate Microsoft login flow, often using adversary-in-the-middle (AiTM) phishing kits to capture session tokens and bypass MFA. With legitimate Microsoft services genuinely degraded, users cannot easily verify the message against a working portal — the lures are contextually plausible in a way they never would be on a normal day.
2. Help-desk pretexting and IT impersonation. Threat actors call or message help desks and end users impersonating internal IT or "Microsoft support," claiming they need credentials, MFA approvals, or remote access to "restore mailbox access." Overwhelmed support staff working through an actual incident are dramatically more likely to skip identity-verification procedures.
3. MFA fatigue (push bombing). Attackers with previously harvested credentials time MFA push floods during the outage, betting that users — confused by login failures they attribute to the outage — will approve a prompt just to make the notifications stop and "get their email working again."
4. Malicious OAuth consent and persistence. Post-compromise, attackers frequently establish durable access via malicious inbox forwarding rules and rogue OAuth application consents. These mechanisms survive password resets and remain effective long after the outage is resolved — meaning the dwell time of an outage-day compromise routinely extends weeks beyond the incident itself.
Exploitation Status
This is an active, opportunistic threat pattern rather than a single named campaign. Security teams should assume in-the-wild phishing and social engineering activity scaled to the visibility of the outage. There is no CVE associated with this event — the exploitation vector is procedural and human. CISA and Microsoft have repeatedly warned that major service disruptions correlate with spikes in themed phishing; treat the current window accordingly.
Detection & Response
The detections below target the highest-fidelity post-exploitation behaviors I've seen in outage-window compromises: suspicious inbox rule creation, anomalous OAuth consent grants, and MFA push anomalies. These fire rarely in healthy environments and almost always matter when they do.
---
title: Suspicious External Inbox Forwarding Rule Created in Microsoft 365
description: Detects creation of inbox rules that forward or redirect mail to external addresses, a common persistence and exfiltration mechanism deployed after credential compromise during outage-themed phishing campaigns.
references:
- https://attack.mitre.org/techniques/T1114/003/
- https://attack.mitre.org/techniques/T1098/002/
author: Security Arsenal
id: 3f8a2c71-9b4d-4e6f-a1c2-5d7e9f0b3a45
status: experimental
date: 2026/04/06
tags:
- attack.collection
- attack.t1114.003
- attack.persistence
- attack.t1098.002
logsource:
product: m365
service: audit
detection:
selection:
Operation:
- 'New-InboxRule'
- 'Set-InboxRule'
Parameters|contains:
- 'ForwardTo'
- 'ForwardAsAttachmentTo'
- 'RedirectTo'
falsepositives:
- Legitimate user-configured forwarding to personal addresses (validate against policy; many organizations prohibit this entirely, making any hit actionable)
level: high
---
title: OAuth Application Consent Granted to Suspicious Permissions
description: Detects user or admin consent grants to OAuth applications requesting high-risk mail permissions (Mail.Read, Mail.Send, full_access_as_app), a technique used by AiTM phishing kits and illicit consent grant attacks that spike during outage-themed phishing waves.
references:
- https://attack.mitre.org/techniques/T1528/
- https://attack.mitre.org/techniques/T1550/
author: Security Arsenal
id: 8c1d4e92-6a3b-4f58-b2d9-7e4a1c6f8d21
status: experimental
date: 2026/04/06
tags:
- attack.persistence
- attack.credential_access
- attack.t1528
logsource:
product: azure
service: auditlogs
detection:
selection:
OperationName:
- 'Consent to application'
- 'Add app role assignment to service principal'
TargetResources|contains:
- 'Mail.Read'
- 'Mail.ReadWrite'
- 'Mail.Send'
- 'full_access_as_app'
- 'offline_access'
falsepositives:
- Legitimate third-party mail integrations (CRM, ticketing systems) — maintain an allowlist of approved enterprise application IDs and alert on anything outside it
level: high
---
title: Excessive MFA Push Notifications Followed by Approval
description: Detects MFA fatigue (push bombing) patterns where multiple denied or pending MFA requests precede a successful approval, indicating a user may have approved a malicious prompt during outage confusion.
references:
- https://attack.mitre.org/techniques/T1621/
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
id: 5e2b7f34-1c8d-4a96-c3e5-9b1f4d7a2e68
status: experimental
date: 2026/04/06
tags:
- attack.credential_access
- attack.t1621
- attack.initial_access
- attack.t1078
logsource:
product: azure
service: signinlogs
detection:
selection:
AuthenticationRequirement: 'multiFactorAuthentication'
Status|contains:
- 'MFA denied'
- 'Failed'
falsepositives:
- Users legitimately struggling with MFA during service degradation — correlate with subsequent successful sign-ins from new devices or unusual geographies before escalating
level: medium
// Hunt for post-phishing persistence indicators during the M365 outage window:
// inbox forwarding rules, new OAuth consents, and sign-ins from new devices.
let LookbackWindow = 48h;
// 1) Suspicious inbox rule creation (external forwarding)
let SuspiciousRules = OfficeActivity
| where TimeGenerated > ago(LookbackWindow)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend RuleParams = tostring(Parameters)
| where RuleParams has_any ("ForwardTo", "ForwardAsAttachmentTo", "RedirectTo")
| project TimeGenerated, UserId, ClientIP, Operation, RuleParams;
// 2) Risky OAuth consent grants
let RiskyConsents = AuditLog
| where TimeGenerated > ago(LookbackWindow)
| where OperationName has_any ("Consent to application", "Add app role assignment")
| extend Permissions = tostring(TargetResources)
| where Permissions has_any ("Mail.Read", "Mail.ReadWrite", "Mail.Send", "full_access_as_app")
| project TimeGenerated, Identity, OperationName, Permissions, IPAddress = tostring(InitiatedBy);
// 3) MFA push fatigue: multiple failures then success for same user
let MfaFatigue = SigninLogs
| where TimeGenerated > ago(LookbackWindow)
| where AuthenticationRequirement == "multiFactorAuthentication"
| summarize FailureCount = countif(ResultType != 0), SuccessCount = countif(ResultType == 0),
IPs = make_set(IPAddress), Apps = make_set(AppDisplayName)
by UserPrincipalName, bin(TimeGenerated, 1h)
| where FailureCount >= 3 and SuccessCount >= 1
| project TimeGenerated, UserPrincipalName, FailureCount, SuccessCount, IPs, Apps;
SuspiciousRules
| union RiskyConsents, MfaFatigue
| sort by TimeGenerated desc
-- Hunt endpoints for processes spawned by Outlook, indicating a user opened a
-- malicious attachment or link from an outage-themed phishing email.
-- Legitimate Outlook almost never spawns script interpreters or LOLBins.
LET suspicious_children = (
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(powershell|pwsh|cmd|wscript|cscript|mshta|rundll32|regsvr32|certutil)\.exe$'
)
SELECT C.Pid AS ChildPid,
C.Name AS ChildProcess,
C.CommandLine AS ChildCommandLine,
C.Username,
C.CreateTime,
P.Name AS ParentProcess,
P.Pid AS ParentPid
FROM suspicious_children C
JOIN pslist() P ON C.Ppid = P.Pid
WHERE P.Name =~ '(?i)outlook\.exe$'
# M365 Outage-Window Compromise Audit & Hardening Script
# Run with an account holding Exchange Online + Graph audit permissions.
# Review output before taking any removal action.
# 1) Audit all mailboxes for external forwarding rules (persistence check)
Connect-ExchangeOnline
$SuspiciousRules = foreach ($mbx in (Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox)) {
Get-InboxRule -Mailbox $mbx.UserPrincipalName -ErrorAction SilentlyContinue |
Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo } |
Select-Object @{N='Mailbox';E={$mbx.UserPrincipalName}}, Name,
@{N='ForwardTo';E={$_.ForwardTo}}, @{N='RedirectTo';E={$_.RedirectTo}}
}
$SuspiciousRules | Export-Csv -Path .\SuspiciousForwardingRules.csv -NoTypeInformation
Write-Host "[!] Found $($SuspiciousRules.Count) forwarding rules. Review SuspiciousForwardingRules.csv" -ForegroundColor Yellow
# 2) Audit recent OAuth consent grants via Microsoft Graph
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"
$StartDate = (Get-Date).AddHours(-72).ToString("yyyy-MM-ddTHH:mm:ssZ")
$Consents = Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $StartDate" -All |
Where-Object { $_.ActivityDisplayName -match "Consent to application" }
$Consents | Select-Object ActivityDateTime, ActivityDisplayName,
@{N='InitiatedBy';E={$_.InitiatedBy.User.UserPrincipalName}} |
Export-Csv -Path .\RecentConsentGrants.csv -NoTypeInformation
Write-Host "[!] Found $($Consents.Count) consent grants in last 72h. Review RecentConsentGrants.csv" -ForegroundColor Yellow
# 3) Hardening: block legacy authentication and disable user consent by policy
# (Legacy auth cannot enforce MFA and is a primary outage-window attack path)
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod","Policy.ReadWrite.PermissionGrant"
# Disable user self-consent for apps (forces admin review workflow)
Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{ PermissionGrantPoliciesAssigned = @() }
Write-Host "[+] User app consent disabled. Consent requests now require admin approval." -ForegroundColor Green
# 4) Verify number matching is enforced for MFA push (kills MFA fatigue attacks)
$MfaPolicy = Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
-AuthenticationMethodConfigurationId "MicrosoftAuthenticator"
Write-Host "[*] Review Authenticator settings — ensure number matching is REQUIRED, not optional."
$MfaPolicy | Format-List
Write-Host "[*] Audit complete. Escalate any unexpected rules or consents to IR immediately." -ForegroundColor Cyan
Remediation & Hardening
There is no patch for social engineering — the remediation here is procedural and configuration-based. Prioritize the following during and immediately after the outage window:
- Issue an all-hands advisory now. Tell users explicitly: Microsoft will never email you asking you to re-authenticate to restore service, and IT will never ask for your password or MFA code to fix an outage. A single clear message dramatically reduces lure click-through during high-chaos periods.
- Enforce number matching and disable SMS/voice MFA where feasible. Number matching in Microsoft Authenticator is the single most effective control against MFA push fatigue. Verify it is set to required, not optional, tenant-wide.
- Block legacy authentication protocols (IMAP, POP3, SMTP basic auth) via Conditional Access — these bypass MFA entirely and are a preferred fallback for attackers holding harvested credentials.
- Disable user self-consent for OAuth applications and route all consent requests through admin review, per the script above. Audit all consent grants made in the last 72 hours and revoke any that are unrecognized.
- Audit inbox forwarding rules tenant-wide. Treat any rule forwarding to an external domain created during the outage window as a probable compromise indicator: revoke sessions, reset credentials, and investigate the associated sign-in history.
- Reinforce help-desk identity verification. Require out-of-band verification (manager callback, known-device confirmation) before any password reset, MFA reset, or remote-access action during the incident window. Help desks are the softest target during outages.
- Force session revocation for any user who approved an anomalous MFA prompt. Use
Revoke-MgUserSignInSessionor the Entra portal, then investigate before re-enabling access. - Monitor Microsoft's official status channels only — the Microsoft 365 Status account and the Service Health Dashboard in the admin center — and communicate those channels to users so they don't go searching for "status updates" on attacker-controlled sites.
The outage will resolve. The compromises that happened during it won't resolve themselves. The persistence mechanisms deployed in this window — forwarding rules, rogue OAuth grants, hijacked sessions — are designed to survive password resets and remain quiet for weeks. Run the audits now, and again 30 days from now.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.