Key Takeaways

  • Greatness used spoofed RingCentral messages and safe-sender rules to evade normal email filtering.
  • Adversary-in-the-middle and device-code flows let attackers capture tokens even when MFA was enabled.
  • Defenders should tighten email exceptions, adopt phishing-resistant authentication, and investigate token activity.

The Greatness phishing-as-a-service operation has expanded its Microsoft 365 attack capabilities, combining trusted-brand impersonation with adversary-in-the-middle, or AiTM, and device-code phishing. The campaign shows how a single permissive email rule can undermine several other security controls.

Active since at least mid-2022, Greatness has targeted users in the United States, Canada, the UK, Australia, and South Africa. It has also broadened beyond Microsoft 365 to pursue iCloud, Yahoo, and Google Workspace accounts. According to BleepingComputer, access to the platform is currently sold through a Telegram channel with thousands of subscribers for $289 per month.

That subscription model matters. Phishing-as-a-service packages advanced attack infrastructure for cybercriminals who may lack the technical skills or resources to build it themselves. Templates, hosting, credential interception, victim routing, and administrative panels become part of a commercial service. The result is a lower barrier to running campaigns that can defeat conventional password protections.

In the latest activity, researchers at ZeroBEC found that Greatness operators impersonated RingCentral, a communications platform used for cloud calling, messaging, and voicemail. Messages appeared to come from service@ringcentral[.]com and targeted actual RingCentral users with fake voicemail or performance-review notifications.

The underlying messages contained multiple warning signs. They originated from an unknown IONOS mail server, failed SPF and DMARC validation, and lacked a DKIM signature. Yet receiving systems accepted them because RingCentral had been placed on a safe-sender list. The messages reportedly received a Spam Confidence Level of -1 in Microsoft Exchange, allowing them to avoid standard filtering.

The attackers were not merely copying RingCentral branding; they were exploiting the recipient's existing trust configuration. A fraudulent banner claiming that the sender had been verified by the organization's safe-sender list added another layer of social reassurance. This tactic helped reduce suspicion at the human level by making the message appear to carry an internal approval notice.

After a recipient clicked the embedded button, Greatness routed the session into one of two Microsoft 365 attack paths. Its AiTM flow proxied the authentication process and captured an MFA-approved session token. The device-code flow instead manipulated the victim into authorizing access through Microsoft's legitimate device authentication process.

Both approaches target the authenticated session rather than stopping at a stolen password. This distinction is critical. A user can enter a password and complete an MFA prompt, yet the attacker may still obtain a reusable token representing that approved login. NIST SP 800-63-3 warns that conventional MFA can remain exposed to verifier-impersonation attacks and supports authentication approaches designed to resist phishing.

Once inside, the Greatness operators replayed Microsoft 365 tokens from virtual private servers and commercial VPN infrastructure. They then used Microsoft Graph to enumerate Outlook mailboxes, Teams conversations, SharePoint sites, OneDrive files, contacts, calendars, and registered applications. In some cases, researchers observed access remaining active for more than two weeks.

That breadth turns one compromised identity into a business-wide intelligence source. Email can expose invoices and negotiations. Teams may reveal current projects. SharePoint and OneDrive can contain contracts, customer records, or operational documents. Registered applications and OAuth grants may provide additional persistence paths.

For security teams, the immediate priority is reviewing safe-sender lists and blanket domain exclusions. Trust rules can instead require successful SPF, DKIM, and DMARC authentication. Administrators can also examine Microsoft 365 sign-ins approved through MFA but originating from hosting providers or unfamiliar VPN addresses.

Where compromise is suspected, teams should revoke access and refresh tokens, inspect OAuth consent grants, and review Microsoft Graph activity across Outlook, Teams, SharePoint, and OneDrive. Phishing-resistant methods such as passkeys, FIDO2 security keys, and certificate-based authentication can reduce exposure to proxy-based theft. Familiar branding and completed MFA are useful signals, but neither should end the investigation.