Cyera researcher Assaf Morag describes a Microsoft 365 phishing campaign in which people complete a genuine Microsoft login and MFA check, but authorise a session on an attacker’s device. The important distinction is that the attacker seeks delegated access, not the victim’s password. That changes the defensive question from “was the login genuine?” to “what did this login authorise?” A real sign-in page can still be part of a fraudulent invitation.
Cyera Watch analysis
What happened
In an analysis dated 30 September, Morag describes a business-proposal lure that sends recipients to a website impersonating a document-sharing application. Before showing the supposed document, the site asks them to enter a code and authenticate through Microsoft.
According to Cyera, the attacker initiated that code through Microsoft’s device authorisation flow, which supports devices with limited input capabilities. When the victim enters it and signs in, they authorise the attacker’s session. The attacker can then obtain valid tokens without collecting the victim’s password.
The permissions attached to those tokens matter. Morag explains that access depends on the granted scopes and the account’s entitlements, potentially reaching mail, files, Teams information and directory data through Microsoft Graph. This is not a claim that every token opens every resource.
Cyera also describes a second stage: the victim is redirected to an Adobe-themed page offering an “update” to view the document. The researchers say the downloaded package contained a genuine, vendor-signed ConnectWise ScreenConnect client configured to give the attacker remote access. Their account describes misuse of a legitimate support tool, not wrongdoing by its vendor.
Why it matters
MFA checks who is authenticating. It does not, by itself, establish that the person understands whose device they are authorising. In the flow Cyera describes, the victim satisfies MFA legitimately while being misled about the purpose of the sign-in.
The analysis also connects this problem to AI agents, application registrations and service accounts with persistent delegated permissions across SaaS systems. An agent’s task may be narrow while its accumulated access is considerably less modest. Knowing which identity signed in is only half the investigation; the other half is what that identity can reach.
Our read
The useful takeaway is to review authorisation alongside authentication, not to declare MFA obsolete. Cyera’s account describes a specific route around a user’s judgement, rather than evidence that Microsoft’s authentication mechanism was cryptographically defeated.
For security teams, start by establishing where device-code authentication is genuinely needed, examining those sign-ins in Entra ID and mapping the data reachable by affected identities. Extend that permissions review to AI agents and connected applications, rather than treating their access as something settled once at installation.
For employees, the practical lesson is equally concrete: a genuine login page does not make an unsolicited request to enter a device code trustworthy. Check the request’s purpose before authorising it. The padlock is not a reference letter.
What to watch
- Whether organisations can distinguish expected device-code sign-ins from unexpected authorisations.
- Whether incident investigations map reachable data as well as identifying the account used.
- Whether reviews of AI-agent permissions remove persistent access that no longer serves a defined task.
Discussion spark: Should organisations restrict device-code authentication to explicitly approved use cases, even if that makes legitimate device setup less convenient?
Sources and evidence
- How Device Code Phishing Bypasses MFA in Microsoft 365 (1 October 2026, 22:27 UTC)
not affiliated with or endorsed by Cyera