Microsoft 365 Global Outage: Outlook, Teams, and Copilot Down — Defender's Guide to Distinguishing Outage from Attack

Microsoft is investigating a widespread Microsoft 365 outage that has knocked Outlook, Microsoft Teams, and Copilot offline for users around the world, with connectivity failures reported across multiple regions. For most organizations, this is a business-continuity problem. For security teams, it is something more nuanced: a high-noise, low-visibility window in which your primary collaboration, email, and — critically — portions of your security telemetry and alerting pipelines may be degraded at the same time your users are confused, anxious, and primed to click on anything that promises to 'restore' their access.

Every major cloud outage I've worked through as an incident responder has been followed within hours by opportunistic phishing campaigns, fake 'service status' pages, and helpdesk social engineering. Adversaries know that during an outage, users expect broken login flows, IT is distracted, and the usual verification channels (email, Teams) are exactly the ones that are down. This post gives you a defensive playbook: how to confirm the outage is genuinely an outage and not an attack masquerading as one, how to hunt for outage-themed phishing and post-restoration account compromise, and how to keep security operations running when your productivity stack isn't.

What Happened

Per reporting from BleepingComputer, Microsoft acknowledged a broad service degradation impacting multiple Microsoft 365 workloads simultaneously — Exchange Online (Outlook), Microsoft Teams, and Microsoft Copilot among them — with users worldwide reporting sign-in failures, message delivery problems, and inability to join meetings or load the Copilot interface. Microsoft's service communications indicated the incident was under investigation, with updates flowing through the Microsoft 365 admin center Service Health Dashboard and the @MSFT365Status social channel.

Multi-workload failures like this typically trace back to shared infrastructure dependencies: Entra ID (Azure AD) authentication front-ends, networking/DNS layers, or a common service update gone wrong — the same failure pattern we've seen in previous large-scale M365 incidents. Until Microsoft publishes a post-incident report, defenders should treat the root cause as unconfirmed, which is precisely why 'is this an outage or an attack?' is a question your SOC must answer with evidence, not assumption.

Technical Analysis

Affected Services and Platforms

• Exchange Online / Outlook — mail flow delays, sign-in failures, OWA and desktop client connectivity issues
• Microsoft Teams — sign-in failures, chat/meeting join failures, presence degradation
• Microsoft Copilot (M365 Copilot and consumer Copilot surfaces) — service unreachable or degraded responses
• Knock-on dependencies: any third-party service or internal app that relies on Entra ID SSO or Exchange Online transport (ticketing systems, alert forwarding, approval workflows) may silently fail during the same window

There is no CVE associated with this incident — it is a service availability event, not a vulnerability disclosure. No proof-of-concept exploit, KEV listing, or adversary attribution applies. The security relevance is entirely in the second-order risk the outage creates.

Why Outages Are a Security Event

From a defender's perspective, a global M365 outage creates four concrete risks:

1. Telemetry and alerting gaps. If your SOC relies on email-delivered alerts, Teams-based incident channels, or M365-native detections (Defender for Office 365 quarantine notifications, etc.), portions of your detection-to-response loop are degraded exactly when noise is highest.
2. Outage-themed phishing. Campaigns spoofing 'Microsoft service restoration,' 'verify your account to restore access,' or fake status pages with credential-harvesting login forms reliably appear within hours of major outages. Lure documents and HTML attachments delivered through still-functioning mail gateways (or personal email) execute payloads on endpoints.
3. Helpdesk social engineering. Attackers call service desks impersonating users 'locked out by the outage' and push for MFA resets or password resets — the same playbook used in the Scattered Spider intrusions.
4. Post-restoration account compromise. If the outage has any authentication-plane component, token/session anomalies and impossible-travel sign-ins in the hours after restoration deserve scrutiny. Attackers also time credential-stuffing and password-spray runs to coincide with restoration, when login telemetry spikes and anomalies are harder to spot.

Exploitation Status

No exploitation of a software vulnerability is implicated in this incident. The 'exploitation' defenders must worry about is social exploitation of the outage itself — phishing, vishing, and helpdesk manipulation — which is opportunistic and begins almost immediately. Treat the 24–72 hours surrounding a major outage as an elevated-threat window.

Detection & Response

The detections below target the behaviors that actually show up around outage windows: phishing payloads executing from Office processes, script-based payload delivery, malicious inbox forwarding rules planted during the chaos, and anomalous sign-ins during and after restoration. They are tuned to fire on high-signal behavior, not general noise.

SIGMA Rules

---
title: Office or Teams Process Spawning Script Interpreter
description: Detects Outlook or Teams spawning command shells or script interpreters, consistent with phishing lure execution during outage-themed campaigns. High-fidelity in most environments.
references:
  - https://attack.mitre.org/techniques/T1566/001/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/27
status: experimental
tags:
  - attack.initial_access
  - attack.t1566.001
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\outlook.exe'
      - '\ms-teams.exe'
      - '\teams.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\mshta.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate add-in behavior; Teams screen-sharing helper spawning rundll32 on some builds
level: high
---
title: Mshta Executing Remote Content
description: Detects mshta.exe fetching content over HTTP/S, a common payload-delivery mechanism in phishing campaigns that surge during widely publicized service outages.
references:
  - https://attack.mitre.org/techniques/T1218/005/
author: Security Arsenal
date: 2026/01/27
status: experimental
tags:
  - attack.defense_evasion
  - attack.t1218.005
  - attack.initial_access
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\mshta.exe'
    CommandLine|contains:
      - 'http://'
      - 'https://'
  condition: selection
falsepositives:
  - Legacy internal HTA applications hosted on intranet servers (allowlist internal FQDNs)
level: high

KQL (Microsoft Sentinel / Defender)

Hunt across email, identity, and audit surfaces for outage-themed social engineering and post-restoration compromise. Adjust the time window to bracket the outage period plus 72 hours.

// 1) Outage-themed phishing emails hitting mailboxes during the disruption window
EmailEvents
| where TimeGenerated > ago(3d)
| where Subject has_any (
    "outage", "service disruption", "service restoration", "restore access",
    "Microsoft 365 down", "account suspended", "re-validate", "verify your account"
  )
| extend UrlCount = array_length(parse_json(UrlCount))
| project TimeGenerated, SenderFromAddress, SenderMailFromAddress, Subject,
          RecipientEmailAddress, AttachmentCount, ThreatTypes, DetectionMethods
| order by TimeGenerated desc;

// 2) Malicious inbox forwarding rules created during/after the outage (data theft persistence)
OfficeActivity
| where TimeGenerated > ago(3d)
| where Operation in~ ("New-InboxRule", "Set-InboxRule")
| where Parameters has_any ("ForwardTo", "ForwardAsAttachmentTo", "RedirectTo")
| mv-expand parse_json(Parameters)
| where Parameters.Name in~ ("ForwardTo", "ForwardAsAttachmentTo", "RedirectTo")
| extend ForwardTarget = tostring(Parameters.Value)
| where ForwardTarget !contains "<your-domain.com>"  // replace with tenant domain
| project TimeGenerated, UserId, ClientIP, Operation, ForwardTarget
| order by TimeGenerated desc;

// 3) Sign-in anomalies in the 24h after service restoration: impossible travel / first-time countries
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| summarize Locations = make_set(Location), Countries = make_set(LocationDetails.countryOrRegion),
            IPs = make_set(IPAddress), SignInCount = count()
         by UserPrincipalName, AppDisplayName
| where array_length(Countries) > 2
| project UserPrincipalName, AppDisplayName, Countries, IPs, SignInCount
| order by SignInCount desc;

// 4) MFA / auth-method changes while users are 'locked out' (helpdesk social engineering indicator)
AuditLogs
| where TimeGenerated > ago(3d)
| where OperationName has_any ("Update user", "Reset password", "Update authentication method")
| mv-expand TargetResources
| mv-expand TargetResources.modifiedProperties
| where TargetResources_modifiedProperties.displayName has_any ("Password", "StrongAuthenticationMethod")
| project TimeGenerated, OperationName, InitiatedBy.user.userPrincipalName,
          TargetResources.userPrincipalName, Result
| order by TimeGenerated desc;

Velociraptor VQL

Endpoint hunt for phishing payload execution: any script interpreter or LOLBin spawned by Outlook or Teams during the outage window.

-- Hunt for Outlook/Teams spawning script interpreters or LOLBins (phishing payload execution)
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Ppid IN (
        SELECT Pid FROM pslist()
        WHERE Name =~ '(?i)^(outlook|ms-teams|teams)\.exe$'
      )
  AND Name =~ '(?i)^(cmd|powershell|pwsh|mshta|wscript|cscript|rundll32|regsvr32)\.exe$'

Verification & Audit Script (PowerShell)

Use this during and immediately after the outage to (a) pull current service health from the Graph API so you're working from Microsoft's own incident data, and (b) sweep for the most common post-outage persistence mechanism — external inbox forwarding rules.

# Requires: Microsoft.Graph module, delegated/app perms ServiceHealth.Read.All + Exchange Online management
# 1) Pull active M365 service health incidents (confirm scope from Microsoft's own telemetry)
Connect-MgGraph -Scopes "ServiceHealth.Read.All" -NoWelcome
Get-MgServiceAnnouncementIssue -All |
  Where-Object { $_.Status -ne 'serviceRestored' } |
  Select-Object Id, Title, Status, StartDateTime, LastModifiedDateTime,
    @{N='ImpactedServices';E={ $_.Service -join ', ' }} |
  Format-List

# 2) Sweep all mailboxes for external forwarding rules planted during the outage window
Connect-ExchangeOnline
$windowStart = (Get-Date).AddDays(-3)
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-InboxRule -Mailbox $_.UserPrincipalName -ErrorAction SilentlyContinue |
    Where-Object {
      ($_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo) -and
      $_.WhenCreated -ge $windowStart
    } |
    Select-Object @{N='Mailbox';E={$_.MailboxOwnerId}}, Name, WhenCreated,
                  ForwardTo, ForwardAsAttachmentTo, RedirectTo
} | Export-Csv -Path ".\SuspiciousInboxRules_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

# 3) Report mailbox-level forwarding (SMTP forwarding set by admins or attackers)
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -ne $null } |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, DeliverToMailboxAndForward

Disconnect-ExchangeOnline -Confirm:$false

Remediation & Response Actions

Because this is an availability incident rather than a patchable vulnerability, 'remediation' means disciplined incident handling and closing the windows attackers exploit during the chaos:

1. Confirm the incident through authoritative channels only. Use the Microsoft 365 admin center Service Health Dashboard (health.office.com / admin.microsoft.com) and @MSFT365Status. Do NOT trust 'status pages' reached via links in emails or search ads — fake status dashboards are a standing phishing lure during real outages.
2. Establish out-of-band communications immediately. If Teams and Exchange are degraded, your IR channel cannot be Teams and Exchange. Pre-arrange an alternate: a Signal/Element group, a phone bridge, or a standing bridge on a non-M365 provider. Confirm your on-call roster can be reached without corporate email.
3. Brief the service desk before users call. Push explicit guidance: no password resets or MFA resets based solely on inbound calls during the outage; require call-back to a known number or manager verification. This single control defeats the most common outage-exploitation technique.
4. Warn users about outage-themed phishing through whatever channels still work (intranet banner, SMS, in-person). One clear message: Microsoft will never email you a link to 'restore' or 're-validate' your account.
5. Run the hunts above for the outage window plus 72 hours — phishing execution on endpoints, external inbox rules, MFA/password resets, and post-restoration sign-in anomalies. Treat any external forwarding rule created during the window as hostile until proven otherwise.
6. Verify your alerting survived the outage. Confirm Sentinel ingestion, Defender connectors, and any email-dependent alert paths resumed cleanly after restoration. A silent alerting gap is worse than a noisy outage.
7. Request and review Microsoft's post-incident report (PIR) when published, and reconcile it against your own tenant telemetry for the window — particularly if any authentication-plane issues were acknowledged.
8. Update your BCP/IR runbooks with lessons: which dependencies failed, which communication paths held, and how long your SOC operated blind. Outages of this scale are free tabletop exercises — capture the data.

Vendor reference: BleepingComputer coverage and the Microsoft 365 Service Health Dashboard in your admin center (incident IDs are tenant-visible there).

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub