Inside the VENOM PhaaS Platform: How Credential Theft Bypasses MFA

A five-month credential theft campaign targeting C-suite executives has exposed a previously undocumented phishing-as-a-service (PhaaS) platform called VENOM. Abnormal AI’s team identified the operation, which ran from November 2025 through March 2026.

The finding shows how a single PhaaS platform can neutralize multi-factor authentication (MFA) without exploiting a protocol flaw. This kind of credential theft doesn’t need a technical exploit, only patience and a well-run PhaaS platform.

This post walks through what the VENOM PhaaS platform is, how its emails evade detection, and why credential theft techniques succeed.

What is the VENOM PhaaS Platform?

VENOM is a closed-access PhaaS platform. It was operational for at least nine months before Abnormal researchers discovered it, and during that period, it didn’t appear in any public threat intelligence database or underground marketplace.

The platform includes a licensing and activation model, a full campaign management interface, and structured token storage. Attackers running campaigns on VENOM don’t need to build their own infrastructure. They activate access under VENOM’s licensing model and run campaigns through it.

Over the five-month campaign, VENOM operators targeted named C-suite executives, vice presidents, and chairs across more than 20 industries; 60% of targeted recipients held those titles.

This was not a spray-and-pray campaign. Targets were selected by name, which points to reconnaissance ahead of time and confirms the intent behind this credential theft operation was persistent, high-value account access rather than opportunistic fraud.

How the Email Evades Detection

Each VENOM campaign begins with an email impersonating a SharePoint document-sharing notification. The sender address is dynamically generated to match the target’s own domain, while the email itself is delivered through a rotating pool of compromised business accounts.

The email doesn’t contain a clickable link. Instead, it embeds a QR code, which moves the interaction off the corporate network and onto the target’s personal device. There are also randomized HTML elements, including fake CSS classes and comments designed to confuse automated scanners.

Once scanned, the QR code routes to a landing page that filters visitors before serving the credential theft page. The target’s email address is double Base64-encoded in the URL fragment, which is never transmitted in HTTP requests. Security researchers and sandboxes probing the link get redirected to benign websites.

Genuine targets alone reach the harvester, where one of two credential theft modes takes over. This filtering step is likely what let the VENOM PhaaS platform operate undetected for so long.

Two Types of Credential Theft: AiTM and Device Code

Once a target reaches the harvesting page, VENOM offers its operators two distinct methods of credential theft.

The first is Adversary-in-the-Middle (AiTM) mode. The harvester presents the target’s real identity provider (IdP), complete with the organization’s actual branding, a pre-filled email address, and, if the account is federated, the genuine login screen. Credentials and MFA codes are relayed to Microsoft’s own systems.

VENOM silently registers a second MFA device on the account, giving the attacker standing access that survives the original authenticator staying intact.

The second method focuses on the device code. Rather than presenting a login form, the page instructs the target to enter a code, approving what Microsoft presents as a sign-in request. The target authenticates directly with Microsoft. Tokens are delivered straight to the attacker’s backend.

Both paths achieve the same outcome: persistent access established before any remediation can begin. Whether through AiTM or device code mode, the result is a credential theft event that looks, from the outside, like a normal sign-in.

Why MFA Doesn’t Stop This PhaaS Platform

MFA is designed to stop credential theft that relies on a stolen password alone. The VENOM PhaaS platform defeats it via a different route. Neither method exploits a flaw in the MFA protocol itself. MFA is rendered ineffective not by breaking the protocol, but by operating within it.

In AiTM mode, credentials and MFA codes are relayed to Microsoft’s live API in real time, and the attacker’s silent registration of a second MFA device means the account now trusts two authenticators: the target’s original device and the attacker’s.

In device code mode, which requires no AiTM relay at all, there is no credential form to detect and no MFA to intercept. The target authenticates directly with Microsoft and approves what looks like a routine device sign-in, and that approval alone hands the attacker persistent access.

Whether through the AiTM relay or the device code flow, MFA and this form of credential theft coexist because the attacker obtains access through the authentication system itself.

This is the core lesson from the VENOM PhaaS platform. Organizations that treat MFA as a final barrier are exposed to exactly this kind of AiTM attack, and to its device code counterpart.

The Second Inbox: When Customers Face the Same Tactics

VENOM’s five-month campaign targeted executives, but the same underlying tactics – believable branding, urgency, and a plausible pretext – show up just as often in a second inbox: the customer’s. Retail and e-commerce brands see the same techniques used against their customers through fake delivery notices and refund scams that impersonate the brand’s own domain.

This risk is separate from the executive-targeting credential theft described above. It is a threat to brand reputation rather than to a single executive’s account, and it reaches every customer who trusts a message with the brand’s name on it.

A customer who receives a fraudulent refund-pending email that appears to come from a trusted retailer has no way to distinguish it from a legitimate message, unless the retailer’s domain is protected at the authentication layer.

Full DMARC enforcement blocks unauthenticated use of a company’s own domain, which stops attackers from sending emails that appear to originate from that domain. It is worth being precise about scope. DMARC enforcement doesn’t stop VENOM’s executive-targeting emails, since those originate from compromised accounts.

p=reject blocks unauthorized use of your domain. It does nothing for a compromised executive account, since that email is authenticated.

Once p=reject is active, BIMI reinforces legitimate brand email with a verified logo in the recipient’s inbox, giving customers a visual signal that a message is genuinely from the brand. Together, DMARC enforcement and BIMI address the risk that sits alongside, and separate from, the exec-targeting credential theft described above.

Defending Against VENOM-Style Credential Theft

The VENOM PhaaS platform demonstrates that MFA alone is not sufficient against this style of credential theft, and defense requires a layered response.

Security teams should revoke active sessions and token grants in Entra ID for any account suspected of compromise. Password resets alone don’t invalidate device code refresh tokens, so explicit revocation is necessary to close the access this credential theft method establishes.

Teams should also monitor for unexpected MFA device registrations, and alert whenever a device is added outside an IT-managed workflow. This is the clearest indicator that AiTM activity has taken place on an account.

And because the VENOM PhaaS platform was built specifically to defeat signature-based and pattern-matching tools, behavioral detection that flags anomalies in sending behavior and account activity catches what static rules miss.

On the domain side, deploying full DMARC enforcement and BIMI reduces unauthorized use of the business’s own domain. Lookalike domains, ones that mimic the brand without using its exact domain, fall outside what DMARC and BIMI cover and require separate monitoring, such as Sendmarc’s Lookalike Domain Defense.

See how DMARC Management and Lookalike Domain Defense close the domain-side gap.