The Login Page Was Real. So Was the Attack.
Picture Dave. Dave runs a heating firm in Horsham with 14 staff. On Tuesday morning a message lands in Teams from a supplier he knows. New shared folder, here’s your code, pop it in at Microsoft to open it.
Dave has been trained. He checks the web address, and it’s Microsoft, the real one. He types the code, signs in, and approves the prompt on his phone. Every check he was ever taught comes back green.
He has just handed a stranger the keys to his mailbox.
There was no fake website, no dodgy link, and no stolen password. Dave did everything right, and that was the problem.
This piece goes with today’s Hot Take episode, which covers the same ground in about 11 minutes.
Why I’m writing this today
It has been a rotten week for anyone who runs on Microsoft 365. Outlook, Teams, and a good chunk of everything else fell over on Thursday, and plenty of you were still locked out on Friday morning. Microsoft says there is no indication of malicious or cyber activity behind it, and I have no reason to doubt that.
So why bring it up in a piece about phishing? Because millions of people have just spent the best part of a day waiting to get back into their email. Every one of them is primed for a message that says “we’re back, sign in again to restore your mailbox”. Add a code to that message and you have the attack that caught Dave, wearing this week’s headline.
I want to be straight with you: I have seen no evidence of anybody doing that yet. This is a warning, and I’m labelling it as one.
The report
KnowBe4 has published Volume 8 of its Phishing Threat Trends Report, dated October 2026. It runs to 39 pages and draws on data from KnowBe4 Defend, the company’s own email security product.
Every statistic in it comes from one vendor’s product watching that vendor’s customers. It is a real dataset. It is also a long way from a survey of British small businesses, and you should read every percentage with that in mind.
My verdict in one line: one idea worth your time, a few numbers I wouldn’t repeat at a dinner party, and a pitch at the end.
What the report gets right
Credit first, because the central idea is correct and well explained.
Attackers have stopped building fake websites. Fake sites get spotted, blocked, and taken down, so they have started borrowing the real ones. The login page is real. The domain is real. The only thing that’s fake is the reason you were asked to sign in.
Trick one: the code
Microsoft has a sign-in method built for kit with no keyboard: smart tellies, meeting room screens, printers. It’s called device code flow. The device shows you a short code, you type it into a Microsoft page on your phone or laptop, and Microsoft grants access to the device that asked.
That’s handy when the device is yours. Here is what happens when it isn’t, following the sequence the report sets out on pages 27 and 28:
- The attacker starts a sign-in on their own machine, and Microsoft gives them a code.
- They send that code to Dave with a friendly story attached.
- Dave goes to the genuine Microsoft page.
- Dave types the code and completes his multi-factor authentication (MFA).
- Microsoft grants access to the device that asked, which belongs to the attacker.
- The attacker collects a token that keeps working without asking Dave again. The report says these can last 90 days or more.
Dave never visited a suspicious site. His password was never stolen. His MFA was never beaten. It was borrowed, and Dave’s own approval did the work.
KnowBe4’s threat intelligence lead adds that these lures are moving out of email and into Teams messages, where people are used to clicking what colleagues send them. We covered one device-code phishing kit in our Threat Analysis of 5 November.
Microsoft is well aware of the problem. Its own documentation describes device code flow as a high-risk method that can form part of a phishing attack, and recommends blocking it wherever you can.
Trick two: the permission box
You have all seen the box that says an app would like permission to read your mail and your files. In this version, the attacker built the app. One click and their app has standing permission on your account.
The report makes a point on page 29 that every small business needs to hear. Changing your password does not remove that permission, and setting up MFA again does not remove it either. It sits there until someone with admin rights goes looking and takes it away.
Some perspective
I promised you no fear-mongering, so here is the number vendors usually bury. By KnowBe4’s own figure, device code abuse made up 2% of the toolkit-driven link phishing it saw between July and September.
Two per cent, from one vendor’s customers, so hold it loosely. My reading is simple: this is rare today, and it is cheap to shut the door before it stops being rare.
And before anyone writes in: keep your MFA switched on, everywhere, always. Nothing in this piece is a reason to turn it off. Today’s job is adding a second lock to the same door.
The awkward bit
Here’s where I started grinning.
KnowBe4 is best known for security awareness training. Teaching staff to spot a phish is what built the company. And this report, with KnowBe4’s name on the cover, says the victim of a device code attack did everything correctly: checked the address, completed the MFA, signed in on the real platform.
So the training worked perfectly, and the attacker still walked in. The same document then closes by explaining that standard email filters can no longer keep up, followed by a description of how KnowBe4’s own platform catches what gets past them.
I’ll leave you to draw your own conclusion. Mine is that training still earns its keep, but the lesson has to change. We have spent years teaching people to inspect the web address. In these attacks, the web address is the one honest thing on the screen.
The question for Dave has moved. It used to be “is this page real?” Now it’s “did I start this?“
60.7% of what?
Page 11 of the report has a chart about attackers jumping on the news. It is headed “Likelihood of an attack” after a major news agency posts breaking or planned coverage. For the UK, the agencies are BBC News, Sky News, and The Guardian, and the figure is 60.7%. The United States gets 76%. Canada gets 20.2%.
It is a lovely chart, and very quotable. So I went looking for what it means, and came back with four questions.
- Within what time? A 60.7% likelihood within an hour, a day, or a month are three completely different claims. The report doesn’t say.
- What counts as an attack? One email to one customer, or a campaign of thousands? The report doesn’t say.
- Compared with what? The BBC publishes breaking news all day. If attacks follow the news 60.7% of the time, how often do they turn up on a quiet afternoon? Without a baseline, the number has nothing to stand next to.
- Which stories counted? The report doesn’t say that either, and a note beneath the chart adds that the countries and agencies shown are only part of the full set.
I searched all 39 pages for a methodology section. I couldn’t find one.
Let me be precise about what I am claiming. I cannot tell you that number is wrong. KnowBe4 may have a perfectly sound method sitting in a drawer. What I can tell you is that nobody outside KnowBe4 can check it from what is printed, and a number you can’t check is a number you shouldn’t put in front of your board.
Regular readers will remember we did the same exercise on the government’s “43% of businesses breached” headline. The same rule applies to everybody: show your working.
The frustrating part
The behaviour underneath is real, and the report’s own examples line up with events you can verify independently.
- On 8 September, the UK’s air traffic control provider suffered a system failure and flights were cancelled across the country. KnowBe4 logs airline impersonation emails starting two days later.
- Dolly Parton died on 25 August. The report says fake memorial appeals were out within 16 hours.
- On 11 May, E.ON announced a deal to buy OVO. The report logs emails impersonating E.ON three days later, telling customers their accounts were being merged.
Criminals read the news, same as you do. You didn’t need a percentage to believe it. Our Threat Analysis of 9 November has a recent example of phishing aimed at one sector.
One more: the Russia figure
Page 24 says Russian infrastructure accounts for 25.4% of phishing entering the UK, against 0.8% for the United States. That is a share of what remains after the big shared cloud mail services have been filtered out. It is a slice of a slice.
Quote it without the filter and you have told people something the report never said.
Two small things that made me look twice
Neither of these changes the argument, but a report that wants to be quoted should survive a careful read.
On pages 13 and 14, two different events share a date and a description. The US 250th anniversary and a UK and Europe heatwave are both dated 4 July, and both carry the same one-line summary, word for word. That may be coincidence. It may be copy and paste. I can’t tell from the page.
And a phishing kit called Tycoon 2FA gets its own column in the industry table on page 19 and its own profile on page 22, yet it isn’t named in the volume ranking on page 17, where everything outside the top five is grouped as “Other” at 2%. The reader is left guessing how big it is.
How to read any vendor statistic
Every security vendor publishes a report like this. Here are five questions I ask before a vendor number gets anywhere near a decision.
- Who collected it? A vendor’s product, a government survey, and an academic study are three different kinds of evidence.
- From whom? A vendor’s customers already bought that product. They are a poor stand-in for everybody else.
- Over what period? A figure with no time window can mean almost anything.
- Measured against what? A percentage with no baseline is decoration.
- What are they selling? It doesn’t make the number false. It does tell you which numbers were likely to make the final cut.
Right of reply
KnowBe4, this part is for you, and the offer is genuine.
Send me the method behind the 60.7% figure: the time window, the definition of an attack, and the baseline it was measured against. I will publish your answer here in full, and I will say on the podcast that you responded. If the working holds up, I’ll say that too.
How to Turn This Into a Competitive Advantage
Bigger customers and insurers increasingly ask small suppliers how they protect their accounts. “We have MFA” is the answer everybody gives.
“We have MFA, device code sign-in is blocked, staff can’t approve apps on their own, and our incident plan revokes sessions” is a better one. It is specific, it can be checked, and it shows you understand how accounts are being taken over this year.
How to Sell This to Your Board
Three points that will land:
- Microsoft itself recommends it. Blocking device code flow is the platform owner’s published guidance, so this is an easy position to defend.
- It is mostly configuration. These are settings in the service you already pay for. Ask your IT provider whether your licence covers Conditional Access before you assume any new spend.
- Progress is easy to measure. Five questions, each with a yes or no answer. You will know within a week where you stand.
What This Means for Your Business
Most of this is a conversation with whoever looks after your Microsoft 365. I’ve written each one as a question you can copy and send on Monday morning.
1. “Is device code flow blocked in our tenant?” Microsoft publishes step-by-step instructions for blocking it. If you have a meeting room screen that needs device codes, your provider can allow that one thing and block the rest.
2. “Who is allowed to approve new apps on our accounts?” If nobody has ever changed the settings, the answer may well be everybody. Microsoft lets you switch off user consent so staff cannot grant permissions on their own.
3. “Can we turn on the admin consent workflow?” This is Microsoft’s approval queue. Staff who need an app click request, and someone who knows what they’re looking at says yes or no.
4. “Can you send me a list of the apps that already have permission?” Changing the consent setting only affects future approvals. Anything already granted stays granted. Go through the list together, and if nobody recognises an app, find out what it is before you remove it.
5. “Does our incident plan say revoke sessions?” Resetting the password is no longer a complete response to a compromised account. The instruction should read: reset the password, revoke the sessions, and check the app permissions.
Then send this to the whole team today. It costs nothing.
If somebody sends you a code and asks you to type it into a sign-in page, and you didn’t start that yourself, stop and ask. It doesn’t matter how real the page looks. After this week’s outage, expect messages telling you to sign in again to get your email back. Nobody fixes an outage by typing in a code a stranger sent them.
Dave did everything right. Let’s give him better questions to ask.
Listen to the full Hot Take, and send it to whoever looks after your IT.