How VENOM PhaaS Platform works

A SharePoint document-sharing notification reaches a senior employee. The message looks familiar, there is no executable attachment, and the next step is simple: scan a QR code to open the document.

That ordinary sequence is what makes VENOM worth looking at from a security operations perspective. The attack combines an email lure, QR-based delivery, anti-analysis controls, and legitimate Microsoft authentication flows so that each step can look plausible on its own.

Public reporting on the campaign describes activity observed between November 2025 and March 2026 targeting senior executives across more than 20 industries. The phishing messages impersonated SharePoint document-sharing notifications and used QR codes to move recipients into the next stage of the attack.

If you work in security, the important lesson is not simply that VENOM can operate against MFA-protected accounts. Once an attacker can relay or abuse a legitimate authentication flow, email security and identity security become part of the same incident.

What is the VENOM PhaaS platform?

VENOM is a phishing-as-a-service (PhaaS) platform. Instead of requiring every operator to build phishing pages, redirect logic, session relay, token handling, and campaign tooling from scratch, a PhaaS platform packages much of that infrastructure into a reusable service.

Reporting on VENOM describes licensing and activation functionality, campaign-management capabilities, and structured storage for captured authentication data. This makes the platform more than a collection of phishing templates. It supports multiple stages of the attack, from delivering the lure to handling the authentication process after the victim interacts with it.

That packaged infrastructure lowers the amount of technical work required to run a sophisticated credential-theft campaign. The operator can focus on targeting and delivery while the platform handles much of the underlying workflow.

VENOM PhaaS: the engine behind the campaign

One observed VENOM campaign impersonated Microsoft SharePoint document-sharing notifications. The visible message was designed to look routine, while the HTML behind it contained additional content intended to make automated analysis more difficult.

Infosecurity Magazine reported that the phishing template randomized disposable HTML elements between messages and inserted fabricated email conversation history tailored to the target. The recipient still saw a simple document-sharing lure, but a scanner processing the complete message had to evaluate a much noisier body.

The QR-code delivery was also unusual. Rather than relying only on a conventional embedded image, the campaign used QR codes rendered from text characters inside the HTML message.

This technique is not unique to VENOM. Earlier research into QR phishing documented attackers building functional QR codes from ASCII and Unicode characters specifically to make image-focused detection more difficult.

After the QR code was scanned, VENOM added another filtering stage. Public reporting describes a fake verification checkpoint that attempted to separate real visitors from automated scanners, sandboxes, and analysis tools. Visitors that did not pass those checks could be prevented from reaching the credential-harvesting page.

That gives you a practical problem if you open a suspicious URL once from an analysis environment, you may not see the same page the victim saw.

Why MFA does not automatically stop VENOM

MFA remains an important security control, but not every MFA method provides the same resistance to phishing.

VENOM demonstrates two different ways an attacker can operate around an MFA-protected account, real-time adversary-in-the-middle relay and abuse of Microsoft's Device Code flow. In both cases, the authentication service itself can continue to operate normally while the attacker manipulates the process around it.

The practical conclusion is straightforward: MFA remains important, but phishing-resistant authentication provides stronger protection against credential-relay and AiTM attacks.

Microsoft recommends phishing-resistant methods such as passkeys and FIDO2 security keys, Windows Hello for Business, and certificate-based authentication.

How the attack works

1. A familiar message reaches the target

The victim receives what appears to be a SharePoint document-sharing notification. The message is designed to resemble an ordinary Microsoft 365 workflow rather than a traditional malware delivery attempt.

There does not need to be an executable attachment. The email only needs to convince the recipient to continue.

2. The QR code moves the interaction away from the email

The recipient scans the QR code and opens the next stage in a browser, often on a phone.

That device transition can complicate monitoring. The original email may have been inspected inside a managed Microsoft 365 environment, while the next stage can happen in a mobile browser with a different set of endpoint, browser, and network controls.

The text-rendered QR technique creates an additional detection challenge because there may be no conventional image attachment for a scanner to extract and decode.

3. VENOM filters the visitor

Before displaying the authentication stage, the infrastructure can attempt to determine whether the visitor appears to be a real person or an automated security system.

A scanner may never receive the same page as the intended target. This type of conditional delivery makes simple URL reputation checks and one-time sandbox visits less reliable as the only source of evidence.

You should keep the surrounding context too: the original email, HTML structure, redirect chain, identity events, and what the user actually saw.

4. AiTM relay captures an authenticated session

In the AiTM path, attacker-controlled infrastructure sits between the target and Microsoft's authentication process. The victim enters credentials and completes the authentication challenge while the malicious infrastructure relays the exchange in real time.

The important point is that the MFA challenge is not necessarily removed. The victim can complete it successfully.

The problem is that authentication is occurring through an attacker-controlled session. Once the legitimate service accepts the sign-in, the attacker may obtain authenticated session material rather than being left with only a stolen password.

This is why describing every attack of this type simply as an MFA bypass can be misleading. The MFA mechanism may have worked exactly as expected, it was used inside a phishing session that the attacker controlled.

5. Device Code abuse uses Microsoft's real login flow

VENOM has also been associated with abuse of Microsoft's Device Code flow.

Device Code authentication exists for legitimate situations where an application or device cannot provide a normal browser-based sign-in experience. The device requests a code, and the user completes authorization separately through Microsoft's authentication service.

In a phishing scenario, the attacker starts that process and convinces the victim to complete it.

This can be particularly convincing because the victim may genuinely be sent to a Microsoft-owned domain and genuinely authenticate with Microsoft. The issue is not whether the login page is real. The issue is who initiated the authorization request.

Microsoft classifies Device Code flow as a higher-risk authentication flow and recommends blocking it wherever possible, with exceptions only where there is a documented business requirement.

6. Access may survive a password reset

Once an attacker has obtained session or token-based access, resetting the password should not be treated as the complete remediation.

The response also needs to consider active sessions, refresh tokens, registered authentication methods, OAuth access, and any changes made after the account was compromised.

Microsoft's guidance for revoking user access explains how administrators can invalidate refresh tokens and sign-in sessions as part of account containment.

After changing the credential, ask the practical question: what can the attacker still use?

How to defend against VENOM

Enforce phishing-resistant authentication

Prioritize phishing-resistant authentication for administrators, executives, and other high-impact accounts.

Passkeys/FIDO2, Windows Hello for Business, and certificate-based authentication provide stronger protection against credential relay than passwords paired only with OTPs or push approvals. These methods use cryptographic properties that bind authentication more strongly to the legitimate service.

This does not replace Conditional Access, identity monitoring, or email security. It removes an important weakness that real-time phishing frameworks attempt to exploit.

Restrict Device Code flow

Start with one question: does your tenant actually need Device Code flow? Then identify which applications or devices depend on it.

Microsoft recommends getting as close as possible to blocking the flow completely. A practical rollout is to first inventory current usage, deploy the Conditional Access policy in report-only mode, review the impact, and then move to enforcement.

Any exceptions should be narrow, documented, and regularly reviewed rather than granted to broad user groups.

Correlate email and identity telemetry

Treat the phishing message as the beginning of an identity incident, not the complete incident.

Analysts should correlate the email timeline with Entra sign-in activity, authentication protocols, newly registered authentication methods, unusual application activity, and session-revocation events.

An identity event that looks unremarkable on its own can become much more useful when it occurs immediately after a suspicious QR-based email interaction.

This is also why investigations should not stop when the original phishing message is deleted or quarantined. By that point, the most useful evidence may already exist in the identity layer.

Detect the workflow around the QR code

The unusual part of VENOM is not simply that it uses a QR code. It is the sequence around it, a familiar document-sharing lure, a transition to another device, conditional delivery, and an unexpected authentication or authorization flow.

Email controls should therefore look beyond basic image recognition. Message structure, unusual HTML rendering, sender history, redirects, and the context of the requested action can all provide useful signals.

You can keep the escalation rule much simpler for the people receiving these emails. A routine shared-document notification should not suddenly require an unfamiliar QR or Device Code authentication process without verification.

Respond to the session, not only the password

If compromise is suspected, containment should address every access path that may still exist.

Start by reviewing registered authentication methods. Then revoke sessions and refresh-token access where appropriate, inspect recent sign-ins and application activity, and check for suspicious mailbox changes such as new forwarding or inbox rules.

Any authentication method or application grant the user did not intentionally create should be investigated.

After containment, verify the result. Do not assume that changing the password automatically removed every active session or authorization.