A phishing campaign impersonating RingCentral demonstrates how attackers can turn an organization’s trusted-vendor configurations into a route around email security and eventually into Microsoft 365 account takeover. 

The campaign uses a phishing-as-a-service platform known as Greatness, which provides cybercriminals with ready-made tools for creating phishing emails, hosting deceptive login pages, capturing authentication tokens and managing compromised accounts. The platform supports both adversary-in-the-middle phishing and OAuth device-code attacks, allowing its customers to target Microsoft 365 users protected by multi-factor authentication.

In the activity investigated by researchers, attackers sent messages that appeared to originate from RingCentral and used fake voicemail and employee-performance notifications as lures. The recipients were actual RingCentral customers, which made the communications appear relevant and increased the likelihood that users would trust them.

The emails claimed to originate from a legitimate RingCentral service address, but the underlying messages were sent through unrelated mail infrastructure. They failed standard email-authentication checks and did not contain a valid DKIM signature. Under normal conditions, these failures should have caused the messages to be rejected or treated as suspicious.

Instead, the recipient organization had placed the RingCentral domain on its safe-sender list. That exclusion overrode the failed authentication results and instructed the email-security stack to treat the messages as trusted. The phishing emails were consequently delivered with a spam-confidence rating indicating that normal filtering should be bypassed.

The incident is especially instructive because the email-security system did not technically malfunction. It followed the configuration it had been given. The weakness was the assumption that any message claiming to come from a trusted vendor should be allowed, even when the sender could not prove control of that vendor’s domain.

Safe-sender lists can become security bypasses

Organizations frequently maintain safe-sender lists to prevent legitimate business communications from being blocked. Vendors may use several email systems, marketing services and notification platforms, causing occasional delivery problems that support teams resolve by excluding the vendor’s domain from normal filtering.

This may solve an operational inconvenience, but a broad domain exclusion can create a serious spoofing risk. If the rule checks only the visible sender domain and ignores SPF, DKIM and DMARC failures, an attacker can write the trusted domain into the message and inherit the same treatment as the legitimate vendor.

The Greatness campaign exploited exactly this weakness. The attackers did not need to compromise RingCentral’s mail system or gain control of its domain. They simply impersonated it in an environment where the customer’s own policy had already been configured to overlook evidence that the message was fraudulent.

Safe-sender rules should therefore never be based solely on the address appearing in the From field. Exceptions should require valid email authentication and, where practical, known sending infrastructure or approved message characteristics.

A legitimate RingCentral notification should be both recognisably branded and technically authenticated. A message claiming to come from RingCentral while failing every relevant authentication check should not become trusted merely because an administrator once wanted fewer support calls about missing voicemail alerts.

Fake trust banners reinforce the deception

The phishing messages also displayed a fraudulent banner claiming that the sender had been verified through the recipient organization’s safe-sender list.

This was not a genuine validation generated by the organization’s security system. It was content placed inside the email by the attacker to create confidence before the user had an opportunity to become suspicious.

Such banners exploit the way employees interpret security signals. Most users cannot independently evaluate SPF, DKIM or DMARC results and therefore depend on visible indicators suggesting that a message has been checked.

When a phishing email states that the sender has been verified by the organization, the recipient may reasonably assume that the security team has already confirmed its legitimacy.

Organizations should carefully distinguish genuine security banners from content that an external sender can reproduce. Authentic indicators should be inserted outside the message body by the email platform and designed in a way that ordinary email content cannot easily imitate.

Employees should also understand that text inside a message claiming that the sender is trusted is not evidence of validation. Attackers remain surprisingly willing to certify their own honesty.

RingCentral notifications provide an effective lure

RingCentral is widely used for cloud calling, voicemail, messaging and business communications. Its notifications therefore have a credible reason to reach employees across many roles.

A fake voicemail alert can create curiosity and urgency, particularly when it suggests that the message came from a customer, colleague or unknown caller. A performance-review notification can create even greater pressure because it appears personally relevant and may cause the recipient to act before considering whether the communication is expected.

The campaign reportedly customised display names and subject lines for the target organization, helping the messages resemble internal or vendor-generated notifications rather than generic mass phishing.

Attackers increasingly select brands based on the technology their victims actually use. A RingCentral-themed email is more effective against a confirmed RingCentral customer than against a randomly selected organization.

This raises a broader concern when vendor breaches or publicly available data reveal customer relationships. Even when the exposed information does not include passwords, a list showing which organizations use a particular platform can help criminals build more accurate phishing campaigns.

Researchers noted that RingCentral had recently disclosed a separate security incident affecting a limited portion of customer data. There is no conclusive evidence that the Greatness operators obtained their targets from that event, and the two incidents should not be presented as directly connected without proof. However, the campaign demonstrates how customer-relationship data could theoretically be weaponised.

When a vendor discloses an incident involving customer information, organizations using that vendor should review phishing controls and safe-sender exclusions rather than waiting to see whether the leaked relationship becomes an attack theme.

Greatness has evolved into a commercial phishing platform

Greatness has operated since at least 2022 and has developed from a conventional credential-harvesting kit into a broader phishing-as-a-service platform.

It is marketed through Telegram for a monthly subscription and provides customers with an operator panel, campaign statistics, phishing-domain configuration, CAPTCHA options, anti-bot controls and pre-built lure templates.

The platform targets Microsoft 365 as well as other major identity ecosystems, including Google Workspace, Yahoo and iCloud. Its ready-made templates include voicemail, document-sharing, QR-code and video-themed lures.

This commercial model lowers the technical barrier to conducting sophisticated identity attacks. A criminal no longer needs to build an adversary-in-the-middle proxy, design a convincing Microsoft 365 page or create infrastructure for capturing tokens.

The service provider develops and maintains the platform while customers concentrate on obtaining recipient lists and distributing phishing emails.

This division of labour resembles legitimate software-as-a-service operations, except the customer-support objective is to help subscribers compromise other people’s accounts. Cybercrime continues to adopt modern business practices while remaining curiously resistant to useful innovations such as ethics.

The redirect chain helps evade automated analysis

Clicking the button within a phishing message does not necessarily take the victim directly to the fake Microsoft login page. Greatness uses a multi-stage redirect chain involving tracking services, intermediate domains, anti-analysis scripts and human-verification pages.

Each stage helps conceal the final destination and filter out security scanners. The infrastructure checks browser characteristics, user-agent strings and indications of automated tools such as Selenium or headless browsers.

It can also monitor mouse movement, scrolling and other interaction signals to determine whether the visitor appears to be a real person rather than a security-analysis system.

A human-verification page resembling a CAPTCHA may then be displayed before the victim reaches the final phishing flow.

These techniques allow attackers to show harmless content to automated scanners while reserving the credential-harvesting page for genuine users. Email-security systems that inspect only the first link or visit the destination through an automated browser may therefore fail to observe the final attack.

Security products need to analyse redirect chains, page behaviour and relationships between sender domains and destination infrastructure rather than assuming that the first visible URL represents the complete journey.

Organizations should also be cautious about exempting links merely because the first stage uses a recognised tracking or redirection service. Legitimate redirect platforms can conceal malicious destinations just as efficiently as legitimate marketing pages.

Adversary-in-the-middle phishing captures approved sessions

The primary Greatness attack path uses an adversary-in-the-middle proxy rather than a simple static login form.

The phishing page relays the authentication process between the victim and Microsoft’s legitimate infrastructure in real time. It can display the target organization’s actual Microsoft 365 branding, making the page appear substantially more convincing than an ordinary imitation.

The victim enters the password, and the proxy forwards it to Microsoft. When Microsoft requests multi-factor authentication, the challenge is also relayed to the user.

The victim may receive a genuine Microsoft Authenticator notification and complete number matching correctly. From the user’s perspective, the authentication process appears successful because Microsoft genuinely approved it.

The attacker’s proxy captures the authentication token issued after the user completes MFA. That token can then be replayed from attacker-controlled infrastructure to access the account.

This is why conventional MFA does not always prevent adversary-in-the-middle phishing. The attacker is not trying to guess or bypass the second factor. The victim completes the factor successfully, and the attacker steals the resulting authenticated session.

MFA remains essential because it prevents many ordinary credential attacks, but organizations handling sensitive information should increasingly move toward phishing-resistant authentication such as FIDO2 security keys, device-bound passkeys and certificate-based access.

These methods cryptographically bind authentication to the legitimate service and make it more difficult for a proxy operating on another domain to obtain a usable result.

Device-code phishing offers another compromise route

Greatness also supports OAuth device-code phishing.

The device-code flow is designed for devices or applications that cannot provide a convenient browser-based login experience. An application displays a short code, and the user enters that code on Microsoft’s legitimate authentication page to authorise the device.

Attackers abuse this process by generating a device code for a system they control and convincing the victim to enter it.

The victim may be shown a fake document-sharing, voicemail or identity-verification message claiming that the code is required to access the content. The user then visits Microsoft’s genuine device-login page, authenticates and approves the request.

Because the Microsoft page is legitimate, the browser address and certificate appear correct. The danger lies in what the user is authorising, not where the authentication occurs.

Once approved, the attacker-controlled device receives tokens allowing it to access the victim’s Microsoft 365 account without learning the password.

Organizations that do not require device-code authentication should restrict or disable it. Where it remains necessary, security teams should monitor device-code sign-ins and investigate authorisations that do not correspond with an approved device or support process.

Employees should understand that entering a code on a genuine Microsoft page can still be dangerous when the code came from an untrusted email or website.

Compromised tokens provide broad Microsoft 365 access

After obtaining an authenticated token, Greatness operators accessed Microsoft 365 services through virtual private servers and commercial VPN infrastructure.

The observed post-compromise activity included enumeration of Outlook mailboxes, Teams conversations, SharePoint sites, OneDrive files, contacts, calendars and registered applications through Microsoft Graph.

Microsoft 365 has become the central information environment for many organizations. One compromised account may expose business correspondence, customer records, internal files, meeting details and collaboration history.

Attackers can search email for invoices, password-reset messages and confidential discussions. They can examine SharePoint and OneDrive for financial data, contracts, identity documents and intellectual property.

Teams conversations may reveal operational details and personal relationships useful for further social engineering. Contacts and calendars provide a map of the victim’s professional network and upcoming activities.

The compromised account can also be used to send additional phishing messages from a genuine internal identity. Messages sent from a trusted employee’s real mailbox are considerably more difficult for recipients and email filters to reject.

If the user has access to OAuth applications or administrative functions, the attacker may attempt to create broader persistence or reach additional organizational services.

Token theft must therefore be treated as a full identity compromise rather than a temporary mailbox incident.

Access may persist after a password change

Researchers observed access continuing for more than two weeks in some cases because the stolen tokens had not been revoked.

Changing the user’s password may stop the attacker from performing a new password-based login, but it does not necessarily invalidate every existing access token, refresh token or authorised application.

This distinction is critical during incident response. Organizations that respond to phishing only by resetting the password may leave the attacker’s existing session active.

When adversary-in-the-middle or device-code compromise is suspected, administrators should revoke all active sessions and refresh tokens, remove unauthorised devices, review OAuth grants and examine registered authentication methods.

Unknown applications, passkeys, recovery details and MFA methods should be removed. Mailbox forwarding rules, inbox rules and delegated permissions should also be checked because attackers often use them to maintain access or conceal messages.

The user’s activity should be reviewed across Outlook, Teams, OneDrive, SharePoint and Microsoft Graph rather than limiting the investigation to authentication logs.

Credentials for other services shared or stored within the compromised account may need to be rotated as well.

Conditional access can reduce token abuse

Conditional Access policies can make stolen tokens less useful by evaluating the device, location, risk level and application associated with each sign-in.

Organizations can require access to sensitive Microsoft 365 resources to originate from compliant managed devices. A token captured from an employee may then fail when replayed from an unmanaged attacker-controlled system.

Sign-ins from hosting providers, anonymisation services and commercial VPN exit nodes should receive additional scrutiny where such access is not expected.

Risk-based policies can require fresh authentication or block activity when the location, device or behaviour differs significantly from the user’s normal pattern.

However, Conditional Access must be configured and tested carefully. Researchers observed successful post-compromise activity where no relevant Conditional Access policy was applied.

Policies that exist only for administrators or selected applications may leave ordinary users and data repositories exposed.

Identity protection should reflect the value of the information accessible to the account rather than relying solely on whether the user holds an administrative title.

Safe-sender configurations require immediate review

The most practical defensive lesson from this campaign is the need to audit safe-sender lists, transport rules and filtering exclusions.

Organizations should identify every domain, address and service that bypasses normal authentication or filtering. Each exclusion should have a documented owner, business justification and expiry or review date.

Rules based on vendor domains should require successful SPF, DKIM or DMARC alignment. A claimed sender identity should never override evidence that the message originated from unauthorised infrastructure.

Where vendors send through multiple platforms, organizations should work with them to obtain accurate sending domains and authentication guidance rather than applying a blanket exclusion to the entire brand.

Security teams should also review whether external messages can imitate internal trust banners or verification notices.

Vendor-related exclusions should be reassessed following vendor data breaches because attackers may use exposed customer relationships to target organizations known to trust that brand.

Temporary rules created to resolve delivery problems should not remain indefinitely. Like most temporary enterprise configurations, they otherwise risk surviving several employees, two migrations and the original reason anyone added them.

Employees need context-specific phishing training

Generic advice to avoid suspicious links is insufficient when attackers are using services that employees genuinely use and displaying tenant-specific Microsoft branding.

Users should be trained to question unexpected voicemail, performance-review and document-sharing notifications, particularly when the message creates urgency or asks them to authenticate.

RingCentral notifications should be accessed through the installed application or a previously bookmarked official portal rather than through unexpected email links.

Employees should never enter Microsoft device codes supplied by an unsolicited email or webpage. A genuine Microsoft authentication page does not prove that the request being authorised is legitimate.

Users should also report unusual MFA prompts. If an employee did not intentionally start a login or device enrolment, approving the prompt can give attackers access even when the notification itself genuinely comes from Microsoft.

Reporting mechanisms should be simple and rapid. Users who suspect phishing should be able to notify the security team without navigating a bureaucratic obstacle course designed during a time when threats were apparently willing to wait for ticket assignment.

The broader cybersecurity lesson

The Greatness campaign demonstrates how modern phishing attacks exploit the interaction between trusted vendors, permissive security configurations and cloud authentication.

The attackers spoofed RingCentral because the target used RingCentral. The emails succeeded because the organization had instructed its security systems to trust that domain. The phishing platform then used Microsoft’s genuine authentication process to obtain MFA-approved tokens.

Every stage relied on a legitimate relationship or function that had been made too broadly trusted.

This is why modern identity defence cannot depend on one control. SPF, DKIM and DMARC provide limited value when exclusions override their results. MFA provides limited protection when attackers proxy the complete authentication session. Domain reputation provides limited protection when legitimate vendors and cloud services are impersonated or abused.

Organizations need layered controls that combine authenticated email, behavioural analysis, phishing-resistant login methods, conditional access, token monitoring and rapid incident response.

Most importantly, trust must remain conditional. A vendor domain should be trusted only when the sender proves that it controls the domain. An authenticated user should receive access only when the device, location and behaviour are appropriate. A Microsoft login should be approved only when the user intentionally initiated it.

Greatness has turned these weaknesses into a subscription service available to criminals without advanced technical skills. Its commercial model shows that sophisticated token theft and device-code phishing are no longer restricted to highly capable threat groups.

The platform provides the infrastructure, templates and operational dashboard while subscribers supply targets and distribute messages. This allows advanced identity attacks to spread at the speed of an ordinary online service.

Organizations should therefore assume that familiar brands, convincing login flows and correctly completed MFA can all appear within a phishing campaign.

The decisive question is no longer whether an individual component looks legitimate. It is whether the complete sequence makes sense in the context of the user and the organization.

A RingCentral voicemail leading to a Microsoft authentication prompt may appear plausible. A spoofed RingCentral message that failed authentication, bypassed filtering through a safe-sender rule and sent the user through several unfamiliar domains before requesting Microsoft access is not.

Security systems must preserve that context from the inbox through authentication and post-login activity. Otherwise, attackers can continue borrowing trust from one legitimate platform after another until they reach the information the organization believed those platforms were protecting.

The Greatness phishing-as-a-service (PhaaS) platform has expanded from credential phishing to adversary-in-the-middle attacks and device-code phishing targeting Microsoft 365 accounts. [...]

Source: Phishing service spoofs RingCentral to steal Microsoft 365 accounts via Bleeping Computer — published 04 Aug 2026.