Earlier this month we told you what to do when your phone asks you to approve a sign-in you did not start: say no, then change your password. That advice stands. But it only works when the attacker has to ask. The attacks in this month’s news do not ask. You sign in yourself, you approve your own prompt, everything looks normal, and somebody else walks away holding your session.
Attack one: the sign-in page that is really a mirror
On 7 September, researchers at CloudSEK published what they found after getting into the control panel of a phishing service called BigBear 2.0. It is rented out to other criminals, it targets Microsoft 365 and nothing else, and it had completed MFA bypasses at 258 organizations, with more than 5,000 stolen credential records from over 40 countries.
The trick is an old one done well. The link in the email opens a page that looks exactly like the Microsoft sign-in, because it is the Microsoft sign-in, passed through the attacker’s server on the way. You type your password; they see it and pass it on. Microsoft asks for your MFA; you approve it, because you really are signing in. Microsoft then hands your browser a session cookie that says “this person already proved who they are”, and the attacker keeps a copy. From then on they do not need your password or your phone. The cookie is enough.
Two details make BigBear nastier than most. It routes each victim through a home internet connection in the victim’s own country, so the sign-in does not look like it came from abroad. And it runs code on the fake page that switches off the browser’s support for security keys and passkeys, the one kind of MFA it cannot copy, so you get pushed to a code or a phone prompt instead.
The tell: the address bar. Microsoft’s sign-in lives at login.microsoftonline.com (and a few other microsoft.com addresses). A page that looks like Microsoft but sits on any other address is not Microsoft, however perfect it looks. And if the passkey or security key option you normally use has quietly disappeared, stop. That is not a glitch.
Attack two: the real page, the wrong code
The second trick does not need a fake page at all. Some devices cannot show a normal sign-in: a conference room TV, a printer, a command-line tool. For those, Microsoft has a device code sign-in. The device shows a short code, you go to microsoft.com/devicelogin on your phone or laptop, type the code, sign in, and the device is let in.
Now imagine the “device” is the attacker’s laptop. They start a device sign-in, get a code, and email it to you dressed up as a shared document, a voicemail, or a “security verification”. You go to the genuine Microsoft page, type their code, sign in with your password and your MFA, and you have just logged them in to your Outlook, Teams and OneDrive. Nothing about the page was fake. The address bar was right. That is why it works.
This is not a lab curiosity. The FBI issued a public warning in May about Kali365, a subscription phishing kit sold on Telegram that does exactly this, and one device code campaign earlier this year reached more than 340 Microsoft 365 organizations in a matter of weeks.
The rule: only type a device code that is on a screen in front of you, that you asked for, a moment ago. A code that arrived in an email, a Teams message or a text is somebody else’s sign-in. Close the page.
What to do if you think you fell for one
- Tell IT straight away, and say which kind. “I typed a code from an email” and “I signed in from a link” are both emergencies, and both are fixable if they hear about it in minutes rather than days.
- Change your password, but know that on its own it is not enough. A stolen session cookie or device sign-in can keep working after the password changes. IT needs to sign you out everywhere, which throws away every session, including the attacker’s.
- Check what changed. New inbox rules that forward or delete mail, a new phone added to your MFA, sign-ins you do not recognise. Attackers set these up in the first hour so they can come back later.
For the people who run the tenant
Both attacks beat MFA that is typed or tapped. They do not beat MFA that is tied to the device and the real site. That is where the fixes are.
- Block device code flow with Conditional Access. Most organizations need it for almost nobody. Check the sign-in logs for who uses it today (the authentication protocol shows as “Device code”), leave a narrow exception for the conference rooms or tools that genuinely need it, exclude your break-glass accounts, and block it for everyone else. While you are there, block authentication transfer too. This is the FBI’s own recommendation.
- Require a compliant or joined device for anything that matters. A cookie stolen through a proxy page is replayed from the attacker’s machine, and their machine is not one of yours. A Conditional Access rule that demands a managed device stops the replay cold. Location rules alone do not, because BigBear signs in from the victim’s own country.
- Move to phishing-resistant MFA, admins first. Passkeys, FIDO2 keys and Windows Hello for Business check the address of the site they are signing in to, so they cannot be relayed through a mirror. Then make sure a user cannot simply choose a weaker method: an authentication strength policy that requires phishing-resistant MFA takes away the downgrade BigBear relies on.
- Know how to kill a session. Resetting a password does not revoke a stolen session or refresh token. Revoking the user’s sessions in Entra ID does. Practise it before you need it, and put it in the incident checklist next to the password reset.
- Alert on the pattern. A successful sign-in with MFA, followed minutes later by activity from a different device or network, is the fingerprint of a stolen session. So is a device code sign-in from someone who has never used one.
MFA is still the best single thing you can turn on, and none of this means it has stopped working. It means attackers have moved from knocking on the second door to walking through it behind you. The habits that stop them fit on the same sticky note as last time: check the address before you type the password, never type a code someone sent you, and if your usual sign-in option has vanished, stop.
Seen one of these lures? Post it (with the links removed) in The Patch Panel so others know what to look for. And if you are working out a Conditional Access policy for device code flow and want a second pair of eyes, The Patch Panel is the place for that too.
Sources: CloudSEK’s BigBear 2.0 research, as reported by BleepingComputer on 7 September 2026; FBI public service announcement I-052126-PSA (21 May 2026) on Kali365; Proofpoint and Cloud Security Alliance research on device code phishing.
