Greatness Phishing Campaign Steals Microsoft 365 Sessions Through Trusted RingCentral Lures

Attackers are impersonating RingCentral notifications to push Microsoft 365 users into phishing flows designed to steal authenticated sessions, abuse device-code login and gain access to corporate cloud accounts.

The campaign uses the Greatness phishing-as-a-service platform, a commercial toolkit that gives its customers ready-made infrastructure for targeting Microsoft 365 users. Instead of relying only on stolen passwords, the operation can capture session tokens after a victim completes multifactor authentication or trick the victim into authorising an attacker-controlled device.

Once a valid token is obtained, the attacker may no longer need the victim’s password or a second MFA prompt. In the incidents examined, stolen sessions were used to reach services including Outlook, Teams, SharePoint and OneDrive.

The campaign also exposed a separate weakness in the victim organisation’s email controls. The phishing messages reportedly failed SPF, DKIM and DMARC checks, but still reached inboxes because the impersonated RingCentral domain had been treated as a trusted sender.

That combination makes this more than another fake login-page campaign. It shows how identity protections and email-security controls can fail together when attackers target the session itself and trusted-domain exceptions are configured too broadly.

A trusted voicemail notification starts the attack

The observed messages were designed to resemble routine RingCentral communications, including missed-voicemail alerts and employee performance-review notifications.

These are effective lures because they do not immediately appear unusual. Voicemail notifications are common in corporate environments, and performance-related messages create enough curiosity or concern to encourage a quick response.

The emails contained links that directed victims into attacker-controlled authentication flows. Depending on the campaign configuration, the victim encountered either an adversary-in-the-middle login page or a device-code phishing process.

The investigation was published by ZeroBEC, which said it examined live Greatness infrastructure and post-compromise activity associated with the campaign.

The report does not establish how many organisations were targeted or how many accounts were successfully compromised. It does, however, document how the phishing infrastructure operated and how stolen authentication material was used after victims interacted with the lures.

The emails failed authentication checks but still arrived

One of the most important findings was that the phishing emails did not successfully pass normal domain-authentication controls.

SPF helps determine whether a sending server is authorised to send email for a domain. DKIM provides a cryptographic signature that can be checked by the receiving system. DMARC allows domain owners to define how messages should be handled when those checks fail.

In this campaign, the messages reportedly failed those protections.

They still reached the targeted environment because the impersonated RingCentral domain had been added to a safe-sender or allow-list configuration. That trusted status appears to have overridden protections that would otherwise have treated the messages as suspicious.

The RingCentral brand was being impersonated. The available research does not show that RingCentral sent the phishing emails or that its systems were used to deliver them.

RingCentral separately disclosed a security incident in July 2026, but there is currently no confirmed evidence that information from that incident was used to select victims for this campaign. Any connection between the two events remains unverified.

The email-control failure illustrates a wider problem with trusted-sender exceptions. Organisations sometimes create them to prevent legitimate business communications from being blocked. When those rules are too broad, attackers can exploit the trusted identity even when the underlying message fails technical verification.

How the attackers steal authenticated sessions

Greatness supports adversary-in-the-middle, or AiTM, phishing.

In a conventional credential-phishing attack, a fake page records a username and password. MFA may stop the attacker from immediately using those credentials because an additional approval or code is required.

AiTM phishing changes that sequence.

The attacker places infrastructure between the victim and the legitimate Microsoft authentication service. The victim sees a convincing login page and enters their credentials. The phishing system relays the authentication request to Microsoft in real time.

When Microsoft asks for MFA, the victim completes it.

The attacker’s infrastructure then captures the session token issued after successful authentication. That token represents an already authenticated session. Replaying it may allow the attacker to access the account without repeating the complete login process.

This does not mean every form of MFA is useless or that Greatness automatically defeats every Microsoft 365 security configuration. The attack depends on the authentication method, session policies, conditional-access controls and other protections in place.

But it demonstrates why MFA cannot be treated as a complete defence against modern identity phishing. If the attacker steals the authenticated session rather than merely the password, the security team may initially see what appears to be a successful, MFA-approved login.

Device-code phishing removes the fake login page

The campaign also used Microsoft’s device-code authentication workflow.

Device-code login is intended for devices or applications where entering credentials directly may be difficult. A user is shown a short code and asked to enter it on a legitimate Microsoft page to authorise the requesting device.

Attackers can abuse that process by initiating the login request themselves.

The victim receives a genuine Microsoft device-login page and a valid code. Because the page belongs to Microsoft, there may be no fake domain, copied branding or misspelled URL to expose the attack.

The danger lies in what the user is approving.

By entering the code, the victim may authorise a session initiated by the attacker. The attacker then receives access associated with the victim’s identity.

This is why device-code phishing can be difficult to recognise through traditional phishing checks. The user may never submit a password to an attacker-controlled website. Instead, the victim is manipulated into approving the attacker’s authentication request through a legitimate service.

Stolen access reached several Microsoft 365 services

After obtaining valid authentication material, the attackers were reportedly able to reach several parts of the Microsoft 365 environment.

Observed access included:

• Outlook
• Microsoft Teams
• SharePoint
• OneDrive
• Calendars
• Contacts
• Registered applications

Access reportedly remained valid for more than two weeks in some of the investigated cases.

Mailbox access can create several follow-on risks. An attacker may read sensitive conversations, search for invoices, identify business relationships, study internal writing patterns or send convincing messages from a trusted account.

Teams and SharePoint access can expose internal discussions and shared documents. OneDrive may contain financial files, contracts, customer information, technical records or personal data.

Registered application access may also reveal which cloud services are connected to the account, although the available findings do not establish that the attackers compromised every accessible service or performed every possible post-compromise action.

The research has not confirmed whether the stolen sessions were used for financial fraud, business email compromise, data theft or additional persistence through malicious applications.

Greatness lowers the barrier to advanced phishing

Greatness is not described as a single attacker-controlled campaign. It operates as a phishing-as-a-service platform that can be rented by other threat actors.

The service is promoted through Telegram and provides infrastructure for building phishing pages, managing victims and collecting authentication material. The report lists a subscription price of $289 per month.

Researchers also identified shared backend infrastructure across multiple Greatness phishing domains, suggesting that separate campaigns were being supported through a common service.

This commercial model matters because it allows attackers to obtain capabilities that once required greater technical skill. A customer may not need to develop an AiTM framework, reproduce Microsoft authentication pages or build a token-collection system from the beginning.

The platform reportedly supports services beyond Microsoft 365, including Google Workspace, iCloud and Yahoo. The detailed campaign described in the report, however, focused on Microsoft 365 accounts.

The size of Greatness’s active customer base remains unclear. Telegram subscriber numbers should not be treated as proof that every subscriber is a paying customer or an active criminal operator.

Why MFA alone did not stop the compromise

The campaign exposes a gap between having MFA enabled and having an identity environment that can withstand session theft.

MFA remains an important control. It blocks many attacks involving stolen or reused passwords.

But organisations also need to consider what happens after authentication succeeds.

A valid token may continue working until it expires, is revoked or encounters a policy requiring reauthentication. If an attacker uses the token from an unusual device or location, conditional-access policies and identity-risk detection may be able to interrupt the session.

The effectiveness of those controls depends on how they are configured.

Organisations relying heavily on email allow lists also face an avoidable risk. A domain associated with a legitimate vendor should not automatically be allowed to bypass authentication failures or other security checks.

Trusting the business relationship is not the same as verifying the individual message.

What organisations should review now

Microsoft 365 security teams should begin by examining whether RingCentral-themed messages or similar vendor impersonation reached users despite failing SPF, DKIM or DMARC validation.

Safe-sender lists, transport rules and security-gateway exclusions should be reviewed for entries that allow entire domains to bypass inspection. Any exception should be narrowly defined and supported by a clear business requirement.

Identity teams should also review sign-in and audit activity for unusual session use, unfamiliar devices, suspicious locations and unexpected access across Outlook, Teams, SharePoint and OneDrive.

Potentially compromised sessions should be revoked. Password resets may still be necessary, but changing the password alone may not immediately terminate every active session.

Where business requirements allow, organisations should limit or control device-code authentication. Users should be taught that entering a device code can approve access for another device, even when the code is entered on a genuine Microsoft page.

Phishing-resistant authentication methods, tighter conditional-access policies and shorter or risk-based session lifetimes can reduce exposure. Security teams should also monitor for new inbox rules, suspicious mail forwarding, unexpected application consent and other changes that may indicate an attacker is trying to preserve access.

These actions should be aligned with Microsoft’s official identity and session-remediation guidance rather than applied as isolated emergency changes.

The full scale of the campaign remains unknown

The available research explains how Greatness operated in the examined incidents, but it does not provide a verified victim count.

It is also unclear which industries were targeted most heavily, whether the same infrastructure remains active or whether stolen access was used for downstream fraud and data theft.

The involvement of a phishing-as-a-service platform makes those questions particularly important. Infrastructure can be replaced, lures can change and different customers can use the same underlying service for separate objectives.

The immediate lesson is not simply that attackers created another convincing Microsoft login page. In the device-code flow, the login page could be genuine. In the AiTM flow, the victim could correctly complete MFA.

The compromise succeeded by manipulating the entire authentication process and then using the trusted session that emerged from it.

The next meaningful development will be evidence showing how broadly the campaign spread and what attackers did after gaining access. Until that becomes clear, organisations should treat unexpected device-code requests, vendor-themed authentication prompts and unexplained Microsoft 365 sessions as signs that deserve immediate investigation.