Device-bound MFA 2.0 would have blocked Greatness AiTM

A $289-a-month phishing kit should not mint live Microsoft 365 sessions that still work two weeks later. According to BleepingComputer reporting on August 4, 2026 citing ZeroBEC, Greatness PhaaS operators spoofed RingCentral voicemail and performance-review emails, pushed victims through adversary-in-the-middle or device-code flows, and captured MFA-approved authentication tokens. Those tokens unlocked Outlook, Teams, SharePoint, OneDrive, contacts, calendars, and registered apps via Microsoft Graph without another login. Device-bound, origin-bound authentication would have blocked the phishable Microsoft 365 login path so the kit never received a usable session in the first place.

Why OTP and push finished Microsoft 365 login for the wrong party

Greatness has sold phishing-as-a-service tooling since at least mid-2022, priced at $289 per month on Telegram, and has targeted Microsoft 365 users in the United States, Canada, the United Kingdom, Australia, and South Africa before expanding to other platforms. ZeroBEC observed the RingCentral-branded wave. Messages claimed service@ringcentral.com, failed SPF and DMARC, carried no DKIM signature, and still landed with a Spam Confidence Level of -1 on Microsoft Exchange because RingCentral domains were whitelisted. A fraudulent banner told recipients the sender was verified by the organization safe-sender list.

An adversary-in-the-middle attack is a real-time proxy that sits between the victim and the real login page, capturing credentials and one-time factors as they are typed and receiving the authenticated session the identity provider issues. That was the primary initial-access path here. Device-code style flows produced the same cryptographic outcome through a different ceremony: the user approved a code on a real Microsoft page while the attacker’s session was the one issued.

Before any mailbox opened, attackers needed a transferable credential factor. Password plus OTP or push approval completed inside attacker-controlled infrastructure. The identity provider did what it is designed to do. It validated the factors and minted a session. That session cookie or authentication token arrived on the adversary’s side of the proxy, not only in the victim’s browser.

One-time codes and push prompts do not bind proof to the legitimate origin or to a hardware-held private key. They bind to whatever channel can display a code or tap Approve. When that channel is a proxy or a tricked device-code flow, MFA is satisfied for the attacker. There is no second gate after that. The login is over.

Operators then replayed stolen authentication tokens from VPS hosts and commercial VPN infrastructure. According to ZeroBEC’s findings as reported by BleepingComputer, access lasted more than two weeks in some cases and rode classic cloud SSO across many apps. After the tokens existed, replay required no fresh login. That second phase is not an authentication failure at the app boundary. Authentication had already happened. The root cause remains the phishable login that let the kit finish MFA for the wrong party.

Shortening token lifetime does not prevent that harvest. It only forces the attacker to re-use or re-steal sooner. If the operator registers their own authenticator or OAuth grants during the open window, lifetime limits stop mattering.

RingCentral published a separate security bulletin on July 28, 2026 about a customer data incident affecting a limited portion of customers, an event claimed by ShinyHunters. ZeroBEC noted Greatness operators may have pulled valid RingCentral user targets from that exposure, but public reporting states a firm link cannot be made. RingCentral was the spoofed brand on the lures, not the system broken for the Microsoft 365 token theft.

If you want more detailed information about this attack, read the related post on legacymfa.sucks: how Greatness PhaaS captured and replayed MFA-approved Microsoft 365 tokens.

How device-bound signatures keep the session from issuing at all

Prevention starts at the login the kit tried to complete. Device-bound credentials use public-key cryptography on the enrolled hardware. The private key never leaves the device, never crosses the network, and never appears in a proxy transcript. Each authentication produces a fresh signature that is origin-bound to the real enterprise identity provider. A lookalike domain cannot obtain a valid signature for the legitimate origin. A remote kit cannot complete the ceremony because there is no OTP to relay and no push prompt to fatigue.

In this campaign that means the AiTM path dies before a Microsoft 365 session is minted for the attacker. The device-code path dies the same way: there is no transferable factor the user can accidentally hand to the wrong party. The identity provider never issues the attacker a replayable cloud token, so the later VPS and VPN replay never begins. That is prevention, not detection applied to the exact failure ZeroBEC documented.

Against an AiTM kit, an enterprise IdP that issues only hardware-bound signatures holds the public key server-side and demands a fresh private-key signature on the real origin for every login. Nothing symmetric sits in a database waiting to be stolen. That is enough to stop Greatness-style login completion. It is not a claim about malware reading memory after a good login already happened.

SSO multiplies damage when the first proof is stolen. Classic federation issues one session many integrated apps trust. Mail, chat, files, and registered apps ride the same earlier success. Zero-trust language says never trust, always verify at each access boundary. Classic SSO does the opposite. It auto-signs the user into many workloads from one earlier proof. When that proof was captured by a $289 kit, the blast radius is the federated surface, not a single mailbox.

Device-bound design does not recommend bolting more detection onto broken SSO. Secure Explicit Sign-On keeps the same one-tap user experience while authenticating each application independently with its own fresh, device-bound signature. No shared reusable federation cookie exists to steal once and replay everywhere. For a Microsoft 365 estate hit by Greatness-style harvest, that architectural shift shrinks blast radius even if some other path later appears.

Residual risk after the login path is closed is different and harder. Remote phishing kits no longer harvest usable sessions. The remaining way to steal a live token is malware or an infostealer on an endpoint that already holds a legitimate session. Fooling a user into a voicemail lure is easy. Planting malware is not. Revoke of access and refresh tokens, review of OAuth consent and Graph activity, and shorter lifetimes remain hygiene for that harder path. They are not equivalent controls to stopping the kit at authentication.

Why hardening login alone is not the full identity fix

FIDO2 and passkeys harden the authentication act. They do not automatically harden enrollment, device onboarding, or recovery. If a tenant protects daily login with hardware-bound keys but still lets helpdesk or email OTP enroll a new authenticator, an attacker who controls those recovery channels can register their own device and thereafter produce signatures that look legitimate. This Greatness wave abused the login ceremony itself, not a documented re-enrollment path. Full lifecycle coverage still matters for the next operator who switches tactics. No phishable factor should appear at registration, onboarding, authorization, authentication, or decommissioning. The architecture that keeps every stage device-bound is what turns a hardened login into a hardened identity system.

Key Takeaways for Defenders

• Retire OTP and push for Microsoft 365 interactive login so AiTM and device-code kits cannot complete MFA for the attacker.
• Treat cloud SSO sessions as high-blast-radius secrets: prefer per-app device-bound proof over one reusable federation cookie.
• After any suspected Greatness-style compromise, revoke access and refresh tokens, then audit OAuth consent, Graph activity, and M365 service access.
• Do not treat shorter token lifetime as a substitute for phishing-resistant login; it only shrinks the replay window.
• Keep enrollment and recovery free of email OTP, SMS, and push so a later operator cannot register a rogue authenticator during a brief foothold.

The industry keeps buying better detection for sessions that should never have been issued to a proxy. Stop minting those sessions. Make the private key stay on the device, bind every signature to the real origin, and the $289 kit becomes an expensive way to capture nothing useful.

FAQ

Would device-bound MFA 2.0 have stopped the Greatness PhaaS Microsoft 365 campaign?

Device-bound MFA 2.0 would have stopped the Greatness PhaaS Microsoft 365 campaign at initial access by refusing the phishable login path the AiTM and device-code kits relied on. Private keys never leave enrolled hardware and signatures are origin-bound, so a RingCentral-spoofed proxy cannot complete authentication or receive a replayable Microsoft 365 session. Token replay after a session is already stolen is a separate residual problem that no MFA undoes; prevention keeps that residual path from opening via a $289 kit.

Why is shortening Microsoft 365 token lifetime not enough against Greatness-style AiTM?

Shortening Microsoft 365 token lifetime is not enough against Greatness-style AiTM because lifetime limits do not stop the kit from harvesting a valid session during login. According to ZeroBEC via BleepingComputer, stolen tokens already worked for more than two weeks in some cases when replayed from VPS and VPN infrastructure. A shorter TTL only forces faster reuse. If the attacker enrolls a new authenticator or OAuth grant during access, lifetime limits stop mattering entirely.

How does Secure Explicit Sign-On differ from classic SSO for this kind of breach?

Secure Explicit Sign-On differs from classic SSO by authenticating each application with its own fresh, device-bound signature instead of issuing one shared session many apps trust. In the Greatness PhaaS campaign, a single stolen Microsoft 365 cloud token unlocked Outlook, Teams, SharePoint, OneDrive, and Graph-accessible apps without another login. Classic SSO conflicts with zero-trust verify-at-each-boundary design. SES keeps one-tap UX while removing the reusable federation cookie that became a skeleton key after the AiTM harvest.

Would passkeys alone have closed every gap in the Greatness attack chain?

Passkeys alone would have hardened the Microsoft 365 login act against the Greatness AiTM and device-code flows if private keys stayed device-bound and origin-bound with no fallback to OTP or push. Passkeys do not automatically protect enrollment or recovery. This campaign’s documented path was the login ceremony, not helpdesk re-enrollment. Tenants that keep phishable factors for device onboarding still allow a later operator to register a rogue authenticator and produce signatures that look legitimate afterward.

What should security architects change first after reviewing the Greatness RingCentral campaign?

Security architects reviewing the Greatness RingCentral campaign should first remove transferable OTP and push from interactive Microsoft 365 authentication so a proxy cannot finish MFA and receive the session. Next, reduce reliance on a single cloud SSO cookie across mail, chat, and files by moving toward per-app device-bound proof. Keep revoke, consent review, and Graph auditing as containment for residual malware-grade theft, not as the primary answer to a phishable login.