A Real Microsoft Login Page, a Stolen Account: How Device Code Phishing Sidesteps MFA

Multi-factor authentication (MFA) can work exactly as designed, and an account can still be compromised. That is the unsettling lesson from a phishing campaign detailed by Group-IB: The victim did not enter a password on a fake Microsoft page. Instead, the sign-in took place on Microsoft’s genuine login portal, and the victim unknowingly approved an attacker-controlled sign-in.

That changes the protective question. It is not only, “Is this page fake?” It is also, “Did I start this sign-in?”

How the attack uses a legitimate Microsoft feature

Microsoft’s device code flow is a legitimate way for devices and applications with limited input or browser capability to sign in. Conferencing devices and command-line tools are examples of situations where this method can be useful.

The feature is not itself the problem. The attack abuses the process by persuading someone to complete a sign-in they did not initiate.

In the campaign Group-IB examined, a phishing email carried a business-themed PDF attachment. The PDF contained a link to an intermediary page, sometimes a SharePoint-themed document-access page, sometimes a human-verification challenge. From there, the recipient reached a page displaying a device code and instructions to copy it.

The recipient was then directed to Microsoft’s legitimate microsoft.com/devicelogin portal. They entered the code, signed in with their own Microsoft account, and completed MFA if prompted. The authentication happened on Microsoft’s real infrastructure. The attacker-controlled client could then receive an access token and, where supported and requested, a refresh token.

No password was collected on a phishing login page. MFA was not technically defeated: the user completed a legitimate authentication flow, but for a sign-in they had not started.

Why a real sign-in can still lead to account misuse

An access token is a credential that can grant access to resources permitted by the sign-in. Depending on the permissions and controls in place, tokens from a successful attack may enable mailbox or file access, data collection, and further abuse of the compromised account.

That is why defenses focused only on spotting counterfeit login pages or preventing password theft are not enough for this scenario. The destination can be genuine, and the sign-in may satisfy MFA requirements. A user seeing a familiar Microsoft domain is not, by itself, proof that the sign-in is safe.

The everyday clues are often in the request that led there: an unexpected prompt to enter a code to view an invoice, shared document, voicemail, or e-signature request.

What Group-IB observed, and what it does not prove

In its October 29, 2026 report, “MadApe: The Code That Opens the Door”, Group-IB described infrastructure associated with a reusable phishing kit. Its expanded dataset included 155 root domains, with device code phishing components observed on infrastructure associated with 97 of them.

Of 154 domains registered in 2026, 133 of them (86.4%) were registered through one registrar, Dynadot. A total of 117 were registered between mid-June and late August. Among 152 domains with full WHOIS timestamps, 105 shared an identical creation timestamp with at least one other domain. The largest observed batch was 10 domains registered on August 18, 2026, at 23:48:21 UTC. Registration continued into September and October, and Group-IB reported that the campaign remained active.

Those counts describe infrastructure, not confirmed victims. Names appearing in lures and subdomains are treated as intended targets, not confirmed compromises. Backend identifiers count records, not verified people or organizations. This is a global, infrastructure-level analysis, not a forecast that a particular local business is being targeted.

The lures referenced payments, invoices, contracts, proposals, and account statements, sometimes with organization-specific names. Group-IB observed them in at least nine languages: English, Hebrew, German, Portuguese, French, Spanish, Polish, Finnish, and Icelandic. Pages impersonated SharePoint, OneDrive, Microsoft Teams, Adobe Acrobat, DocuSign, and Microsoft sign-in, while sharing the same underlying device-code workflow. One Teams-themed page used a German-language voicemail notification.

Some parts of the delivery chain were designed to frustrate automated checks. Intermediary redirects appeared in dedicated folders on compromised, established third-party websites. Custom-built challenges (such as text CAPTCHAs, image selections, and press-and-hold controls) could keep automated scanners from reaching the final page. The researchers also found anti-analysis scripts that suppressed right-click and browser-inspection shortcuts, as well as fake business websites hosted on the same infrastructure.

The detail matters to business owners for one practical reason: A scanner or reputation check that stops at an intermediary page may not see the final device-code prompt.

A practical response: identify, quantify, mitigate, monitor

A useful response does not begin with buying another tool. It starts by understanding whether the flow is needed, who uses it, and how the business would respond if someone approved an unexpected sign-in.

Identify: Know what a device code request means

Tell employees that device codes are for signing in to a device or application they deliberately started, not a routine way to open an emailed invoice or shared file.

If a page asks someone to copy a code and enter it at Microsoft’s Device Login portal unexpectedly, they should stop and verify the request using a known, independent contact method. They should also read the confirmation prompt carefully: Microsoft’s legitimate page names the application requesting access. If they did not start that application on a device they control, select Cancel.

Quantify: Find out where your business relies on the flow

Ask your IT provider, if you have one: Which accounts, devices, and applications legitimately use device code authentication? Is that use documented and still required?

The provider can review Microsoft Entra sign-in logs using the Authentication Protocol filter to identify device code activity. Knowing what normal looks like helps distinguish approved business use from an unexpected authentication, and helps avoid disrupting legitimate work when controls are adjusted.

Mitigate: Restrict unnecessary use and prepare to contain an incident

Where the flow is not needed, ask whether your provider can restrict device code authentication through a Conditional Access policy using the Authentication flows condition and the Device code flow setting. Validate the policy in Report-only mode before enforcing it, and account for legitimate exceptions.

Ask whether Continuous Access Evaluation is enabled for supported apps. This can help supported applications respond to certain policy or account changes, but it is not a substitute for incident response. Blocking the flow does not necessarily terminate tokens already issued; they may remain usable until expiry. If an employee entered a code from an untrusted page, report it immediately. On suspicion of compromise, prompt session revocation and account containment, including revoking refresh tokens, are important steps.

Monitor: Look beyond the initial sign-in

Ask how your organization reviews unexpected device code sign-ins and checks what happened afterward. A suspicious sign-in may need to be correlated with mailbox activity, file access or downloads, unfamiliar application access, and messages sent from the account. The goal is to identify the scope and contain unauthorized access, not just block the link that first brought the user to the page.

For a practical starting point, explore B&R Computers’ business cybersecurity resources.

The takeaway: verify the sign-in, not just the page

A genuine Microsoft login page can still be part of a phishing attack when someone else initiated the authentication request. Employees should treat unexpected device-code requests as suspicious, read the application name in Microsoft’s confirmation prompt, and report a code entered from an untrusted page, even if nothing unusual is visible yet.

For help identifying legitimate device-code use, assessing the risk to your business, and prioritizing appropriate controls, request a Business Review or Strategy Session with B&R Computers.