A $289-a-month phishing kit turned fake RingCentral voicemails into live Microsoft 365 sessions that still worked weeks later. According to BleepingComputer reporting on August 4, 2026 citing ZeroBEC, operators of the Greatness PhaaS platform spoofed RingCentral emails that slipped past filters, pushed victims through adversary-in-the-middle or device-code flows, and walked away with MFA-approved authentication tokens. Those tokens unlocked Outlook, Teams, SharePoint, OneDrive, contacts, calendars, and registered apps via Microsoft Graph without another login, with access lasting more than two weeks in some cases.
That is the whole failure in one chain: a phishable second factor completed for the wrong party, then a cloud SSO session treated as proof forever.
Why RingCentral-spoofed mail hit inboxes with SCL -1
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 that the identity provider issues. Greatness has sold that class of kit 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 using fake voicemail and performance-review lures. Messages claimed to come from service@ringcentral.com. According to the same BleepingComputer coverage of ZeroBEC’s findings, the mail failed SPF and DMARC, carried no DKIM signature, and still landed with a Spam Confidence Level of -1 on Microsoft Exchange. Domain whitelisting for RingCentral did the heavy lifting. A fraudulent banner even told recipients the sender was verified by the organization’s safe-sender list.
Filters did not fail because the spoof was cryptographically perfect. They failed because operators had already decided RingCentral was trusted infrastructure. Once that trust was baked in, a cheap lookalike brand became a delivery channel for the kit.
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 BleepingComputer’s reporting is clear that a firm link cannot be made. Treat the data incident as adjacent context, not proven source material for this PhaaS campaign. RingCentral systems were the spoofed brand in the lures, not the systems Greatness broke into for the Microsoft 365 token theft.
How AiTM and device-code flows handed attackers MFA-approved sessions
Victims who clicked were not sent to a static fake form that only harvested a password. They were routed into live Microsoft 365 phishing that completed the full login, including the second factor, or into device-code style flows where the user is nudged to approve a code on a real Microsoft page while the attacker’s session is the one that gets issued.
In the proxy path, the password and OTP or push approval travel through attacker infrastructure in real time. The identity provider does what it is designed to do: it validates the factors and mints a session. That session cookie or authentication token is delivered to the adversary’s side of the proxy, not only to the victim’s browser. In the device-code path, the user still believes they are finishing a legitimate Microsoft sign-in. The cryptographic outcome is the same. An MFA-approved token exists in attacker hands.
Legacy one-time codes and push prompts do not bind the 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 ceremony, MFA is satisfied for the attacker. There is no second gate after that. The login is over.
| Control | What happened here | Why it failed |
|---|---|---|
| Email authentication | Failed SPF/DMARC, no DKIM | RingCentral domain whitelisting forced SCL -1 |
| OTP or push MFA | Completed inside AiTM or device-code flow | Factor is transferable and origin-unbound |
| Cloud SSO session | Token issued to attacker infrastructure | One proof unlocks many M365 apps |
| Long-lived access | Replay from VPS and commercial VPNs | No fresh login required at app boundaries |
Nothing exotic happened after the factors cleared. The identity system behaved correctly for a broken authentication design.
What two weeks of token replay unlocked across Microsoft 365
Once the tokens were stolen, authentication was already finished. Attackers replayed Microsoft 365 authentication tokens from VPS hosts and commercial VPN infrastructure. According to ZeroBEC’s findings as reported by BleepingComputer, that access reached Outlook, Teams, SharePoint, OneDrive, contacts, calendars, and registered apps through Microsoft Graph. In some cases the window lasted more than two weeks.
SSO multiplies the damage. A single cloud session is not a mailbox password. It is a skeleton key across every integrated workload that trusts the same sign-on. Mail, chat, files, and app consents ride the same proof. Zero-trust language says never trust, always verify at each boundary. Classic SSO does the opposite: it auto-signs the user into many apps from one earlier success. When that success was captured by a phishing kit, the blast radius is the entire federated surface, not a single app.
Shortening token lifetime would not have prevented the theft. It only forces the attacker to re-use or re-steal sooner. If the operator uses the open window to register their own authenticator or OAuth grants, lifetime limits stop mattering. They hold a legitimate factor. Recommended response after compromise, as covered in the public reporting, is blunt: revoke all access and refresh tokens, then review OAuth consent, Graph activity, and Microsoft 365 service access. That is containment after the fact. It is not how you stop the kit from minting the session in the first place.
The root cause sits at the login, not at the mailbox. Transferable OTP and push factors let the proxy finish authentication. Device-bound, origin-bound signatures never leave the hardware and never complete for a remote kit, so the session is never issued to the attacker. Residual risk after that shift is malware-grade theft on an already-enrolled endpoint, a harder problem than tricking someone into a voicemail lure. Revoke-and-detect remains hygiene for that harder path. It is not the main lesson of a campaign that harvested live sessions with a $289 subscription.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how device-bound authentication blocks Greatness-style AiTM session harvest.
FAQ
How did the Greatness PhaaS RingCentral campaign steal Microsoft 365 access?
The Greatness PhaaS RingCentral campaign stole Microsoft 365 access by spoofing RingCentral voicemail and performance-review emails that reached inboxes despite failed SPF and DMARC, then routing victims into real-time AiTM or device-code flows that captured MFA-approved authentication tokens. According to BleepingComputer’s August 4, 2026 reporting on ZeroBEC’s research, attackers replayed those tokens from VPS and VPN infrastructure into Outlook, Teams, SharePoint, OneDrive, and Graph-accessible apps, with access lasting more than two weeks in some cases.
Why did MFA not stop the Greatness Microsoft 365 phishing kit?
MFA did not stop the Greatness Microsoft 365 phishing kit because the second factor was a transferable OTP or push approval completed inside an attacker-controlled proxy or device-code ceremony. The identity provider issued a valid session to the adversary’s side of the flow. Once that token existed, later app access required no fresh login, so the failure was at authentication, not at a missing detection rule after the fact.
Did attackers breach RingCentral to run this Microsoft 365 campaign?
Attackers did not need to breach RingCentral systems to run this Microsoft 365 campaign. RingCentral was the spoofed brand on the lures. Messages claimed service@ringcentral.com and rode domain whitelisting to an SCL of -1 on Exchange. A separate RingCentral customer data incident disclosed on July 28, 2026 and claimed by ShinyHunters is only adjacent context. ZeroBEC suggested target lists might have come from it, but public reporting states that connection cannot be confidently confirmed.
Why could stolen Microsoft 365 tokens work for more than two weeks?
Stolen Microsoft 365 tokens could work for more than two weeks because cloud session and refresh tokens often remain valid for many days after a successful login, and replay does not re-run MFA. According to ZeroBEC via BleepingComputer, Greatness operators used VPS and commercial VPN infrastructure to present already-issued tokens to Microsoft 365 services. Shortening lifetime only compresses the window. It does not undo a token already harvested by an AiTM kit, and it does nothing if the attacker enrolls a new factor during access.
What should IT teams do if they suspect Greatness-style token theft?
IT teams that suspect Greatness-style token theft should revoke all access and refresh tokens for affected accounts, then review OAuth consent grants, Microsoft Graph activity, and sign-ins across Outlook, Teams, SharePoint, and OneDrive. That containment matters after a session is already stolen. Preventing the next wave means retiring phishable OTP and push at login so a proxy cannot complete MFA and receive the session in the first place.
