# Greatness Phishing Kit Turns Your Safe-Sender List Against You
The attack that bypassed Microsoft Exchange's filtering didn't come from some exotic zero-day. It came from a whitelist — the exact security control your IT team added to stop blocking legitimate business email.
That's the sleight of hand at the center of a recently documented Greatness campaign that's worth understanding in detail, because it exposes a structural problem with how organizations deploy email security today.
## The Whitelist Trap
Greatness has been running as a phishing-as-a-service platform since at least 2022, sold for $289 a month over Telegram to anyone willing to pay. It's not novel in that sense — PhaaS has been industrializing credential theft for years. What's worth attention here is the specific technique operators used to slip past enterprise email defenses in this latest campaign: they impersonated RingCentral.
RingCentral is the kind of platform that ends up on corporate safe-sender lists. It sends legitimate voicemail notifications, call summaries, and system alerts. IT administrators whitelist it to prevent business-critical messages from hitting spam. Attackers claimed their emails came from service@ringcentral[.]com — the actual sender address pattern the platform uses — and the receiving systems let them through.
The emails themselves failed every authentication check that exists. Failed SPF. Failed DMARC. No DKIM signature at all. They originated from an IONOS mail server with no relationship to RingCentral. Under normal circumstances, that combination should trigger aggressive filtering or outright rejection.
Instead, because RingCentral sat on the safe-sender list, Microsoft Exchange assigned those messages a Spam Confidence Level of -1 — a score that tells the mail system to skip the filtering stack entirely and deliver directly to the inbox. The authentication failures were never evaluated.
There was one more layer: the emails included a fake banner claiming the sender had been verified by the organization's safe-sender controls. So a human looking at the message would see what appeared to be an IT-confirmed safe source. Two trust signals, both manufactured.
## After the Click: AiTM and Device-Code Flows
Clicking through took victims to Greatness infrastructure, and from there the platform routed them through one of two attack chains.
The first is adversary-in-the-middle phishing — the Microsoft 365 login page the victim sees is a real-time proxy sitting between them and Microsoft. When the victim enters credentials and completes MFA, the Greatness infrastructure captures the authenticated session token. The MFA challenge is satisfied, the token is valid, and the attacker has it.
The second is device-code phishing, a technique that exploits Microsoft's OAuth device authorization flow. Victims are prompted to enter a code at a legitimate Microsoft URL, which grants the attacker an OAuth token without ever seeing a credential. Both flows produce the same result: a working token that can be replayed elsewhere.
Post-compromise, operators moved methodically. They used Microsoft Graph to enumerate Outlook mailboxes, Teams conversations, SharePoint sites, OneDrive contents, contacts, calendars, and registered OAuth applications. In some cases, access persisted for more than two weeks. That's not smash-and-grab credential theft — that's patient reconnaissance with an active foothold in a Microsoft 365 tenant.
## The RingCentral Breach Connection
There's a thread worth pulling here that other coverage has been light on.
On July 28, RingCentral disclosed a data breach claimed by ShinyHunters — the same group responsible for a string of significant incidents including Ticketmaster and Snowflake customer data. RingCentral acknowledged the breach affected "a limited portion" of customers but hasn't released specifics about what data was exposed.
Researchers at ZeroBEC, who documented this Greatness campaign, note that the attackers targeted actual RingCentral users — not random Microsoft 365 accounts. They're careful to say no definitive link can be established, but the implication is clear: if ShinyHunters or affiliated actors had a list of verified RingCentral customer emails and organizational affiliations from that breach, selling or sharing that list with Greatness operators gives the campaign something more valuable than a generic phishing blast. It gives them a targeting list of people who would recognize a RingCentral notification as plausible.
That's a chained exploitation model: breach a communications platform, extract customer data, use it to make phishing campaigns against those customers credible, bypass email authentication via the same platform's whitelisted domain. Each step makes the next one more effective.
## HackWire Analysis
The whitelist problem isn't new, but this campaign crystallizes why it keeps getting exploited: safe-sender configurations are set during initial deployment and rarely reviewed. An IT team adds a domain to prevent a vendor's alerts from getting blocked, and that exception sits in the configuration for years — through staff turnover, through the vendor's own security incidents, through the evolution of attacker tooling.
The Greatness campaign lands at an uncomfortable moment for enterprise email security. Organizations have invested heavily in anti-phishing infrastructure — DMARC enforcement, secure email gateways, phishing simulation programs — and this attack walked past most of it by abusing a legitimate trust decision. The SCL -1 score isn't a bug. It's the system working as designed.
What this campaign reveals is that AiTM tooling is now commodity. Device-code phishing, which Microsoft has been warning about for two years, is now packaged into a $289/month SaaS product. The technical sophistication required to execute these attacks has dropped to the floor. What remains is operational skill — choosing the right lure, the right target list, the right impersonation.
The two-week dwell time is the detail defenders should fixate on. Token replay from VPN and VPS infrastructure, combined with Microsoft Graph enumeration across every major service — that's a complete tenant mapping. Incident responders inheriting one of these compromises aren't dealing with a single stolen inbox. They're dealing with an adversary who spent two weeks learning the organizational graph.
Defenders should treat safe-sender lists as attack surface, not security controls. Blanket domain exceptions need to be replaced with rules that require valid email authentication before any domain gets elevated trust. And token-based detection — looking for MFA-approved sign-ins from hosting infrastructure or commercial VPN ranges — has to be on by default, not optional.
The playbook for responding if you suspect compromise: revoke all access tokens and refresh tokens immediately, review OAuth consent grants (Greatness campaigns often register persistent OAuth applications), audit Microsoft Graph activity logs for enumeration patterns, and review every service the tenant exposes.
— HackWire Editorial
## Related Coverage