Inside Greatness: The PhaaS Platform That Gets Past MFA

A phishing-as-a-service (PhaaS) platform called Greatness relies on multi-factor authentication (MFA) bypass to compromise Microsoft 365 accounts.

Researchers at ZeroBEC identified the activity while investigating four emails sent to a protected organization, Cyber Security News reported. The emails failed every authentication check. They still reached the inbox.

The cause was inside the victim’s own environment. A safe sender list exclusion overrode the authentication failure, and it’s a pattern enterprise security teams are likely to see again.

What Is the Greatness PhaaS Platform?

Greatness began as a phishing kit and has grown into a full platform. It gives operators ready-made lures, configurable domains, and tools to target Microsoft 365, iCloud, Yahoo, and Google Workspace accounts. One recent campaign used fake RingCentral voicemail and performance-review messages.

This campaign also relied on a centrally managed operator service delivered through Telegram. The platform’s shared backend means the domains and infrastructure behind a campaign can change quickly, while the Adversary in the Middle (AiTM) phishing patterns stay the same.

How MFA Bypass Happens

The spoofed RingCentral emails failed SPF, DKIM, and DMARC, exactly as intended. None of the messages were sent from a legitimate RingCentral domain, so authentication correctly flagged them as unverified. The business’s own safe sender list overrode that failure. A domain-based exclusion, likely set up for convenience, told the email system to deliver the messages regardless of what authentication reported.

From there, Greatness runs an AiTM phishing sequence. The victim sees their company’s authentic branding, enters a password, and completes a normal MFA prompt. The relay then receives a token. The attacker never has to guess a password or defeat a second factor. They simply wait for the victim to finish a login that would otherwise be routine.

The Device Code Phishing Fallback

Greatness also offers a device code phishing route for situations where AiTM phishing isn’t practical. Document-themed pages persuade the victim to enter a device code and approve a sign-in that is, again, genuinely happening.

Why Safe Sender List Exclusions Are Dangerous

A captured session token isn’t limited to email. It can expose Outlook, Teams, SharePoint, OneDrive, calendars, contacts, and registered applications, giving an attacker a foothold well beyond the original inbox.

Few organizations maintain a live inventory of every safe sender entry across their environment. Exclusions accumulate over time and are rarely revisited. Without ongoing visibility into which vendors are trusted and why, a stale exclusion becomes indistinguishable from a necessary one, until a campaign like this one finds it.

What Enterprise Security Teams Should Do

Start with the safe sender list itself. Audit every entry and transport-rule exclusion, especially for common software vendors. A domain should only receive special treatment when its email also passes SPF, DKIM, and DMARC. A vendor breach notice should trigger the same review immediately, since a customer list can reveal which businesses are likely to trust that vendor’s domain.

Improving visibility across the entire company matters just as much as reviewing individual exclusions. Security teams need a current picture of every sender and configuration.

After a suspected compromise, responders should revoke access and refresh tokens, rotate credentials, inspect mailbox rules and OAuth application consents, and review Microsoft Graph activity for anything unfamiliar. Blocking known infrastructure helps, but monitoring behavior matters more, since PhaaS operators can replace domains and proxy infrastructure quickly.

Protecting Your Own Domain

This campaign spoofed RingCentral’s domain to get past a safe sender list exception. The next campaign could use your domain the same way.

Enforcing DMARC at p=reject on your own domains tells receiving servers what to do when a message claiming to be from you fails authentication: reject it. That instruction only works if the receiving organization follows it.

The RingCentral messages failed SPF, DKIM, and DMARC because they weren’t actually sent from RingCentral. A policy of p=reject then tells the receiving server to reject a failed message, but the receiving business’s safe sender list exclusion overrode that instruction and let the message through anyway.

You can’t control whether a receiving company follows that instruction, but you can control whether your own domain’s DMARC, SPF, and DKIM configurations are accurate and up to date.

Sendmarc’s platform gives security and IT teams centralized visibility into SPF, DKIM, and DMARC configurations across every domain they own, cutting down the manual investigation that stretched teams don’t have time for.

Most security teams find out their DMARC, SPF, or DKIM configuration has drifted only after something forces the question. Talk to our team before that happens to you.