Vulnerability · Identity Security

Greatness PhaaS Adds Device Code Phishing to Bypass MFA and Steal Tokens

August 5, 2026 · 6 min read

Most organizations that enabled MFA did so to stop credential stuffing and basic phishing. That was the right call. The problem is that the threat has moved. The Greatness phishing-as-a-service platform, which has been selling turnkey Microsoft 365 phishing capability since at least mid-2022, has now added OAuth device code flow abuse to its operator panel. That means attackers using Greatness can hand a user an authentication prompt that Microsoft's own infrastructure generates and signs, capture the resulting access token on the back end, and walk into the account while the user's MFA app shows a successful login. The password and the one-time code both worked. The session still got stolen.

What actually happened

Greatness is a phishing-as-a-service toolkit sold for around $289 per month through a Telegram channel. Email security firm ZeroBEC disclosed the platform's latest capability expansion in a report shared with The Hacker News: Greatness now bundles adversary-in-the-middle credential and token theft, device code phishing, and OAuth consent abuse from a single operator panel backed by shared infrastructure. That is a meaningful shift in what a relatively low-skill operator can run against your users.

The device code flow technique works like this. The OAuth 2.0 Device Authorization Grant was designed for devices that cannot display a browser, such as smart TVs or printers. The device requests a short-lived user code from the identity provider, displays it, and asks the user to visit a URL on a separate device to authorize the session. Attackers abuse that flow by generating the code themselves and then socially engineering the target into entering it at the legitimate Microsoft or Google authorization page. Because the authorization happens on a real Microsoft or Google page, the user's MFA challenge completes successfully, and the attacker's polling loop receives a fully authenticated access token with no further interaction required.

Greatness's implementation of this technique follows the pattern Okta observed in May 2026: device code phishing pages use CAPTCHAs and multi-hop redirect chains routed through legitimate infrastructure providers to defeat URL reputation filtering, along with anti-analysis techniques similar to those used by the Tycoon 2FA kit. Tycoon 2FA operators also combined their kit with OAuth device code authorization flows, and a global law enforcement operation disrupted 330 domains associated with Tycoon 2FA. Greatness appears to have treated that playbook as a template rather than a warning. In the week of July 20 through 26, 2026, ANY.RUN's threat intelligence tracking recorded 7,295 PhaaS uploads globally, with OAuth flow phishing rising by 194 tracked samples that week and overtaking classic credential harvesting as the primary adversary-in-the-middle technique.

The campaign footprint is broad. Greatness targets users in the United States, Canada, the United Kingdom, Australia, and South Africa, concentrating on manufacturing, healthcare, and technology firms. The toolkit has also expanded beyond Microsoft 365 to target iCloud, Yahoo, and Google Workspace accounts. In at least one observed campaign, operators abused the RingCentral communications platform to route phishing emails through infrastructure that email security filters trusted, which is a practical illustration of how the kit's IP filtering and platform-abuse features work together to reach inboxes.

Why this should matter to you even if you don’t run Microsoft 365

If your organization runs Microsoft 365, Google Workspace, or any environment that uses OAuth for authentication, this technique applies to you regardless of which specific phishing kit an attacker might choose. Device code phishing has existed since at least 2020. Russian-aligned actors used it throughout 2024. The release of the EvilTokens PhaaS in early 2026 commoditized the technique, and now Greatness has folded it into a platform that any Telegram subscriber can operate for a few hundred dollars a month. The barrier to running this attack is now lower than the barrier to running a basic credential-harvesting page was five years ago.

The reason this matters operationally is that most MFA deployments were sized to stop credential-based attacks. TOTP codes, SMS one-time passwords, and push notifications all protect the credential. They do nothing to protect the session token that gets issued after a successful authentication. When an attacker captures that token through device code flow abuse or an adversary-in-the-middle proxy, they hold a credential the identity provider already blessed. Your SIEM may not flag it. Your user will not see anything unusual. The attacker can use that token until it expires or until a policy revokes it.

Manufacturing and healthcare environments face compounding risk here because both sectors run a mix of legacy devices and cloud identity, which is exactly the scenario the device code flow was designed for. A printer, a lab instrument interface, or a shop floor terminal that cannot render a browser is a plausible pretext for an employee receiving a device code authorization request. That plausibility is part of why the social engineering component of this attack works: the request does not look suspicious in context.

The control that would have blunted it

The most direct control is blocking the OAuth device code authorization grant at the Conditional Access Policy level in Microsoft Entra ID (formerly Azure AD), or the equivalent policy control in your identity provider. Microsoft exposes this as an authentication flow condition in Conditional Access. Setting a policy that blocks the device code flow for all users closes the attack surface for this specific technique. LevelBlue's SpiderLabs team recommends that if you have devices or services that genuinely require the device code flow, those users and resources should be explicitly scoped out of the blocking policy with compensating controls rather than leaving the flow open organization-wide.

The longer-term answer is phishing-resistant MFA. FIDO2 hardware security keys, passkeys, and certificate-based authentication are bound to the specific origin or device at the protocol level. An attacker who tricks a user into authorizing a device code session cannot replay a FIDO2 assertion from a different context because the cryptographic binding will not match. That is a fundamentally stronger posture than TOTP or push MFA, both of which protect the credential exchange but leave the resulting token vulnerable to theft and replay.

In practice, most organizations cannot flip to FIDO2 overnight. The realistic path is to block the device code flow via Conditional Access now, audit your Conditional Access policies for coverage gaps (guest accounts, legacy authentication protocols, and service accounts are common blind spots), and build a phased rollout plan for phishing-resistant MFA starting with your highest-risk user populations: privileged administrators, finance, and anyone with broad access to production systems. The operational tradeoff is real. FIDO2 hardware keys have procurement and distribution costs, and passkey support varies across your application portfolio. Those are solvable problems, but they take time, so the Conditional Access block is the control that can be in place this week.

Cyber insurers increasingly ask about MFA coverage during underwriting and renewal, and several are beginning to distinguish between TOTP or push MFA and phishing-resistant MFA when assessing risk. If your policy renewal is coming up and your MFA deployment is based entirely on authenticator apps or SMS, it is worth documenting your Conditional Access configuration and your roadmap toward phishing-resistant methods. Underwriters want to see that you understand the gap, not just that you have MFA checked off on a form.

Strondex's MFA advisory and implementation services cover Conditional Access policy design, phishing-resistant authenticator rollout, and the documentation insurers ask for at renewal time.