Device-bound MFA 2.0 would have blocked Greatness AiTM

$289 a month on Telegram. Live Microsoft 365 sessions that still work two weeks later.

That is Greatness PhaaS, not a clever zero-day. According to BleepingComputer 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.

Password plus OTP or push finished inside attacker infrastructure. Entra validated the factors and minted a session for the proxy. Classic SSO did the rest. MFA 1.0 opened the door. MFA 2.0 does not hand the kit a transferable factor.

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. It 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 (SCL) 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 between the victim and the real login page. It captures credentials and one-time factors as they are typed, and it receives 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. The attacker's session was the one issued.

OTP and push 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. The login is over.

Operators then replayed stolen authentication tokens from VPS hosts and commercial VPN infrastructure. According to ZeroBEC 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 Greatness finish MFA for the wrong party.

Shortening token lifetime does not prevent that harvest. It only forces the attacker to reuse 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.

For the attack-side walkthrough, see the related post on legacymfa.sucks: how Greatness PhaaS captured and replayed MFA-approved Microsoft 365 tokens.

How phishing-proof MFA 2.0 keeps the session from issuing at all

Stop the kit at the login it tried to complete. Device-bound credentials use public-key cryptography on 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 origin-bound to the real enterprise identity provider. A lookalike domain cannot obtain a valid signature for the legitimate origin. There is no OTP to relay and no push prompt to fatigue.

Against Greatness, that means the AiTM path dies before a Microsoft 365 session is minted for the attacker. The device-code path dies the same way. No transferable factor for the user to hand to the wrong party. No replayable cloud token for later VPS and VPN reuse. That is prevention of the exact failure ZeroBEC documented, not another detection rule on sessions that should never have been issued.

Passkeys and FIDO2 are phishing-resistant at the login act when private keys stay device-bound and origin-bound with no OTP or push fallback. That hardens the ceremony Greatness abused. Phishing-proof MFA 2.0 goes further across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. This wave's documented path was the login ceremony, not helpdesk re-enrolment. The next operator who switches to recovery is why the full lifecycle still matters.

It is not a claim about malware reading memory after a good login already happened. This path depends on a login that can be phished; replace it and the path ends there. Malware on a device that already holds a session is another attack class with a higher bar.

SSO turned one stolen proof into a skeleton key

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.

Bolting more detection onto broken SSO is not the answer. Secure Explicit Sign-On keeps one-tap UX 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 shrinks blast radius even if some other path later appears.

Residual risk after the login path is closed is different. A phishing kit then has no usable session to harvest. The remaining way to steal a live token is malware or an infostealer on an endpoint that already holds a legitimate session. Tricking a user into a voicemail lure costs an attacker little; compromising a device that is already signed in costs far more. 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.

The industry keeps buying better detection for sessions that should never have been issued to a proxy. Stop minting those sessions. Private key on the device. Signature bound to the real origin. The $289 kit becomes an expensive way to capture nothing useful.

If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.

FAQ

Would phishing-proof MFA 2.0 have stopped the Greatness PhaaS Microsoft 365 campaign?

Yes, at initial access. 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 by malware is a separate residual problem. Prevention keeps that residual path from opening via a $289 kit.

Why is shortening Microsoft 365 token lifetime not enough?

Lifetime limits do not stop Greatness 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 here?

SES authenticates each application with its own fresh, device-bound signature instead of issuing one shared session many apps trust. In this 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.

Are passkeys enough on their own against Greatness?

Passkeys are phishing-resistant at login if private keys stay device-bound and origin-bound with no OTP or push fallback. That would have hardened the Microsoft 365 login act Greatness abused. They do not automatically protect enrolment or recovery. This campaign's documented path was the login ceremony, not helpdesk re-enrolment. MFA 2.0 is phishing-proof across the full identity lifecycle, which is the gap beyond login-only resistance.

What should change first after this RingCentral-spoofed wave?

Retire transferable OTP and push from interactive Microsoft 365 authentication so a proxy cannot finish MFA and receive the session. 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 front door.