MICROSOFT 365 - IDENTITY COMPROMISE

Your company told everyone to set up a passkey. So did the attacker.

A call from the IT helpdesk about urgent passkey setup is the opening move in an active campaign. Microsoft says the passkey is usually not what they are after, which is what makes the story so hard to doubt.

SB

SafeBrowz Threat Research Security Research · 23 September 2026 · 11 min read

The security upgrade became the cover story

Start with what makes this work, because it is not technical.

Organisations everywhere are currently rolling passkeys out. Staff are being told, genuinely, that they need to set one up, that MFA is changing, that SSO is being reconfigured. The message is expected.

So here is the opening move, in Microsoft's words: "The attack often begins with a seemingly routine call or message on a user's personal phone number from someone claiming to be from the organization's IT helpdesk. The caller creates a sense of urgency, explaining that a passkey, multifactor authentication (MFA), or single sign-on (SSO) configuration must be updated immediately to avoid disruption."

Nothing about that sentence sounds wrong to an employee whose company has been sending exactly those emails for weeks. The rollout supplied the script.

The passkey is the story, not the target

This is the part worth reading twice, and it is stated directly rather than inferred:

"Despite the frequent use of passkey-themed lures, passkey enrollment is often not the actor's true objective. Instead, the passkey narrative serves as a convincing pretext to guide victims through adversary-in-the-middle (AiTM) phishing or device-code authentication flows."

So nobody is breaking a passkey here. The passkey is a subject line. What actually happens once you are on the page is one of two things Microsoft describes exactly: "In AiTM scenarios, the actor captures credentials and session tokens; in device code attacks, the victim unknowingly authorizes access on the actor's behalf."

Both of those are things we have written about on their own, the proxy that relays your real session and the device code you approve yourself. What is new is the wrapper. A cold phishing email asking you to sign in is suspicious. A helpdesk call about the passkey rollout your employer actually announced is not.

It is worth separating this from the other passkey story of this month. A published technique makes a sign-in page claim your browser cannot use passkeys, so you fall back to a password. That one has not been seen in the wild. This one has, since May 2026.

Why the address looks like your employer's

Here is the structural detail, and it is the part a person can actually act on.

Microsoft describes "registering generic domains and embedding the target organization's name as a subdomain, creating URLs that appear familiar at first glance", and gives the shape as companyname.maliciousdomain.com, with contoso.add-passkey.com as the worked example.

Read that left to right, the way people read. The first word is your employer. Everything after it blurs into the kind of technical noise that sits in corporate URLs all the time.

But the part that decides who controls the page is at the end, not the start. In contoso.add-passkey.com, the registrable domain is add-passkey[.]com, and anything in front of it is a label the owner of that domain chose to create. Your company name appearing there means nothing except that somebody typed it.

The domains Microsoft named, now all on our blocklist and returning danger:

• passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com
• integratedsso[.]com, oktasession[.]com

Note the last one and what it is doing. okta.com is a real identity provider that many companies genuinely use, and oktasession is built to borrow that recognition. It is a different domain owned by different people.

The reason a blocklist will always be a step behind

Microsoft includes an operational detail that explains why this keeps working.

These domains are "operational within hours, giving defenders little opportunity to identify and block the infrastructure before employees encounter it", and multiple domains are registered per target organisation so the attacker can rotate. The report names the registrar commonly observed, while adding that "registration alone should not be interpreted as evidence of registrar involvement in the activity", which is a fair caveat and worth repeating.

Draw the consequence honestly. Reputation-based defence, ours included, works on what has already been reported. A domain that is hours old and used against one company has no reputation to look up. The six above are blocked now because Microsoft published them, and the next six will not be.

What does survive rotation is the shape: an authentication page on a registrable domain nobody at your company has ever heard of, wearing your company name as a prefix.

The version that is hardest to refuse

One variant deserves its own warning, because the usual advice fails against it.

In a smaller number of cases the actors already hold a compromised account, and then, in Microsoft's description, use "a trusted employee identity" to send the same passkey-themed messages through Microsoft Teams, which "makes the request appear legitimate and significantly increases the likelihood of engagement".

Think about what that defeats. Check the sender, and the sender is a real colleague. Check the platform, and it is your internal one. The account is not spoofed, it is genuinely theirs, and someone else is typing.

Which leaves the address as the thing that has not changed, no matter how trustworthy the messenger is.

The only record of how it started is what somebody remembers

This is the finding that should change how a report is treated, and it is unusual enough to quote in full.

"This initial interaction may leave very little forensic evidence. If the victim opens the phishing link on a personal mobile device that is not onboarded to Microsoft Defender for Endpoint, the related activity may be absent from endpoint telemetry. In many investigations, the employee's recollection of a phone call or text message becomes the earliest and sometimes the only evidence explaining how the compromise began."

Read that as a design choice rather than an accident. The attack deliberately begins on the device the company does not manage and cannot see. By the time anything appears in corporate logs, the first chapter has already happened somewhere invisible.

The practical consequence is about culture, not tooling. A hazy report of a strange call is primary evidence. "I think someone from IT rang me on Tuesday and I might have clicked something" is not background noise to be waved off by an embarrassed employee or a busy service desk. In these investigations it is frequently the only thing that explains the beginning, and an organisation where people feel stupid raising it has removed its own earliest signal.

What to do when the call comes

1. Hang up and call back on a number you already had. Not the number that rang you, not a number the caller gives you. The internal directory, the intranet, the number on your badge.
2. Do not use a link sent to your personal phone. Real internal changes can wait the two minutes it takes to reach the same setting from your own bookmark or your company portal.
3. Read the end of the address, not the beginning. The registrable domain is what matters. If it is not one your company owns or one you recognise, stop, and check it before you type anything.
4. Treat a code approval as a sign-in. If anything asks you to enter or approve a short code, you are authorising a session for whoever is on the other end.
5. Report it even if nothing happened. Especially then, per the section above.

What we can block here, and what we cannot

Being exact about this matters, because the first half of this attack is not on the web at all.

We cannot hear a phone call. We cannot tell you whether the person claiming to be your helpdesk is your helpdesk, and no browser extension can. The call and the pretext are a human problem, and the callback rule above is what answers them.

The link is ours. Layer 1 runs local URL checks in the browser before the page renders. Layer 2 checks the address server-side against reputation sources, our blocklist and a brand database of more than 550 names, and it is the layer that reads the registrable domain rather than the whole string, which is exactly the trick being used here. Layer 3 is the AI deep scan, one free scan a day for everyone and unlimited on Premium at $14.99 a year across up to three devices.

One honest limit, stated because it is the limit that matters on this campaign. A fresh domain registered this morning for one target company has no reputation for anyone to look up, so the blocklist cannot be the thing that saves you. What holds is the structural read, and the habit of checking an authentication address before typing into it rather than after.