During an outage, attackers don't scan servers, they phish people

During the 20-hour Microsoft 365 outage that began on 12 November 2026, my own edge saw 1 Microsoft-themed probe, fewer than on a normal day, when it sees 2 to 6. Nothing outage-themed reached it, only the usual background noise. That is not luck. During a big outage, attackers mostly leave servers alone and go after people, by email, text and phone.

Contents · 8 sections

TL;DR #

• My small edge saw no rise in Microsoft or Exchange probes during the outage, and no outage-themed attacks. The two spikes it did see were routine.
• That edge is one small, anecdotal sensor with no Microsoft mail flow, so “no impact seen” means “no sensor there”.
• After CrowdStrike in July 2024, government warnings, a fake hotfix carrying the Remcos trojan and lookalike domains all appeared within about a day.
• This week the Isle of Man’s Cyber Security Centre and the bank ING warned about outage scams on 13 November.
• The defence is a staff checklist people have seen before the outage, not a firewall rule.

What my own edge saw #

First, what this sensor is. My edge is small: a few public websites, one SSH honeypot and one mail server, seeing roughly 100 to 200 outside addresses an hour. It has no Microsoft mail flow at all. Treat everything in this section as an anecdote from one small edge, not a picture of the internet. I counted requests and addresses only. I did not profile any person.

I compared the 24 hours from 18:00 UTC on 12 November with the same 24 hours on each of the six days before. Microsoft dates the start of the incident to 16:17 UTC; moving my window back two hours changes nothing.

Here is what came out:

• Total web requests were the highest of the week, 23,804. That sounds alarming until you look at the hours. 14,216 of them arrived in a single hour just after midnight UTC, and one source sent 99% of those. It was a generic sweep for leaked .env and .git/config files across about 60 of my hostnames. Without that hour the day sat at about 9,600 requests, inside the normal weekly range.
• Distinct sources were the lowest of the week: about 2,437, against 2,523 to 5,899 on the other days.
• Microsoft and Exchange probes did not rise. There was one hit in the outage window. All 26 such hits in eight days were the usual fingerprinting checks that scanners have run for years.
• Web login attempts were normal: 9, inside a weekly range of 1 to 54.
• My intrusion-detection system raised zero Microsoft-related alerts, in the window or in the previous 32 days.

The SSH honeypot did have its busiest evening of the week: 4,025 connections between 18:00 and midnight UTC, about 2.8 times the weekly mean. But the cargo was the same as always. A handful of addresses from one hosting network worked through about 1,100 to 1,300 default username and password pairs each, the kind of root/admin spraying that IoT botnets do all day. The same hourly pattern shows up on five of the six days before. The only cloud-flavoured username in the mix was azureuser, which has been on those lists for years. Nothing was themed on Microsoft or on the outage.

One small irony: scanners hosted on Microsoft’s own cloud kept probing me throughout. That is unremarkable. The outage hit Microsoft 365 email and collaboration, not Azure compute.

What I can’t say is just as important. My mail server never talks to Microsoft-hosted mail, and I have no synthetic check against any Microsoft service. So “I saw no impact” means I had no sensor there, not that there was no impact. And the one local sensor that could catch outage-themed phishing, the spam and phish verdicts on my inbound mail, I haven’t analysed yet. That is my next step.

Why the attackers didn’t show up on my servers #

Because that is not where the money is. An outage creates a crowd of confused, frustrated users who all want the same thing at the same time: to get their email back. That is a gift for a social engineer. A scanner hitting random servers gains nothing from Microsoft being down. A phishing email that says “Your mailbox was suspended during the outage, sign in to restore it” gains a lot.

In my library, Kevin Mitnick’s The Art of Deception names the core weakness: the “eagerness to help out a co-worker with a problem is, on the one hand, part of what greases the wheels of industry”. Outages turn that eagerness up. Everyone is helping, everyone is in a hurry, and the normal channels are broken. Ian Mann’s Hacking the Human, also on my shelf, says it more bluntly: “Fraudsters have long recognized that people are the weakest link in security”.

The best-documented precedent: CrowdStrike, July 2024 #

The CrowdStrike outage of 19 July 2024, when a faulty content update put about 8.5 million Windows machines into boot loops, is the clearest record of how this plays out.

• Government warnings came the same day. The US cyber agency CISA said in its first alert that it “has observed threat actors taking advantage of this incident for phishing and other malicious activity”, and repeated the warning in updates over the following week. The UK’s National Cyber Security Centre issued a parallel warning about a rise in phishing that referenced the outage, according to Computer Weekly.
• A fake fix carried real malware. CrowdStrike’s own intelligence team documented a file called crowdstrike-hotfix.zip, dressed up as a recovery tool, with Spanish-language instructions aimed at customers in Latin America. Running it loaded HijackLoader, which then installed the Remcos remote-access trojan. A separate booby-trapped “recovery manual” Word document dropped a new information stealer, according to CrowdStrike and Trellix.
• Lookalike domains appeared within hours. Researchers reported domains such as crowdstrikefix[.]com and crowdstrikeupdate[.]com, according to The Register, and fake support calls impersonating CrowdStrike were reported too.

The lures were live within about 24 hours. None of them needed a single exploit against a server. They needed a worried person and a believable story.

This week: the warnings have started #

This outage looks like it is following the same script, though the evidence so far is thinner. Here is what I can grade.

• Documented, dated 13 November: the Isle of Man’s Cyber Security Centre warned residents not to click unexpected sign-in or password-reset links, never to share passwords or codes, not to give an unsolicited caller remote access, and to be wary of anyone asking for payment to restore an account. It also pointed out that Microsoft does not make unsolicited support calls and that genuine Microsoft error messages don’t carry a phone number to call, according to Isle of Man Today.
• Documented, dated 13 November: the bank ING warned Australian customers that “scammers may contact you offering to resolve the Microsoft or other systems issues”, and the Customer Owned Banking Association warned that scammers switch to phone calls when email is down, according to Insurance Business.
• Reported, not verified by me: security blogs describe fake “Outlook password reset” and “mailbox suspended, sign in to restore” emails and texts, plus fake Microsoft support calls, circulating within hours. None of these posts gives indicators I could check.
• Not evidence: some search results that look relevant are about older outages. I left them out.

By 18:00 UTC on 13 November, no national CERT advisory and no vendor report with indicators of compromise had appeared for this outage. Microsoft said the cause was “not related to cyber”, and its status updates describe a change-driven failure, not an attack. LSN News, my news engine, counted 4,556 articles from 2,272 outlets in 55 languages on the outage; under 2% of the headlines even mentioned an attack, and most of those reported Microsoft ruling it out.

My own forecast, for what it is worth: I put the chance that a CERT or security vendor documents outage-themed phishing against Microsoft 365 customers within two weeks at about 70%. Every global outage since CrowdStrike has drawn lures within one or two days.

Checklist: what to tell your staff during an outage #

Here is the list I would hand to any team, whether the outage is Microsoft, Google, a bank or an airline system. Print it before you need it, because during the outage your email may not deliver it.

1. Nobody needs your password to fix an outage. A provider-side failure is fixed by the provider. Any message asking you to “sign in to restore”, “re-verify” or “reactivate” your account is a lure until proven otherwise.
2. Don’t click; navigate. To check status, type the provider’s status page address yourself or use a bookmark you saved earlier. Don’t use a link from an email, text or chat.
3. Hang up on unsolicited “support”. Big providers do not cold-call users about outages. End the call and phone back on a number you already know is genuine.
4. Never install a “hotfix” someone sent you. Fixes come through your IT team and your normal update channel, not as a ZIP file in an email or a link in a text.
5. Never share a one-time code or approve a login prompt you didn’t start. Modern phishing kits can steal a session even when you have multi-factor authentication, so the code or the tap is often the whole attack.
6. Pay nothing to “restore” anything. No outage has ever required a gift card, a transfer or a crypto payment to fix.
7. Know your out-of-band channel in advance. Agree now how IT will reach staff when email and chat are down: an SMS list, a phone tree, a page on a different provider. Then a message arriving any other way is suspect.
8. Report, don’t delete. Forward suspicious messages to your security team, or tell them by phone, so they can block the domain for everyone.
9. Expect a tail. The lures keep coming for a week or two after recovery: “outage compensation”, “confirm your details after the incident”, fake refunds.

For the people running the systems, two more. Add a simple synthetic check against the SaaS you depend on, because without one you will learn about the outage from your users, as I would have. And keep break-glass admin accounts that don’t depend on the provider that is down.

Frequently asked questions #

Was the Microsoft 365 outage of 12 November a cyberattack? #

No evidence says so. Microsoft said the cause was “not related to cyber” and described a chain that started with a network capacity change. No outlet in my news data reported an attack as fact.

Do attackers scan more during big outages? #

Not that I can see. On my small edge the scanning that night was the usual background noise, and Microsoft-themed probes did not rise. One small edge is an anecdote, but it matches the record: outage exploitation has been social engineering, not a jump in scanning.

How fast do outage scams appear? #

Fast. After CrowdStrike in 2024, CISA warned of phishing on the first day, and fake fixes and lookalike domains appeared within about a day. This week, dated warnings appeared on 13 November, the day after the outage started.

Does multi-factor authentication protect me? #

It helps, but it is not enough on its own. Phishing kits that sit between you and the real login page can capture the session after you enter your code. Never type a code or approve a prompt you didn’t start yourself.

The lesson #

My logs showed the internet’s usual background noise, not a wave of outage-themed attacks. That is not reassuring; it just means I was looking in the wrong place. The attack surface during an outage is your staff’s inbox and phone, and the best defence is a checklist they have seen before the screens go dark.