VENOM: C-Suite Credential Theft Campaign Bypassing MFA

What the VENOM campaign is

VENOM is a credential theft campaign aimed at senior executives, documented by Arsen after more than five months of observation. Targets are picked by name across more than 20 industries, and 60% of recipients hold a C-level, President or Chairman title. What sets it apart isn't the quality of the fake sign-in page, which has been good for years. It's what happens after the sign-in.

Classic phishing takes the password. This takes the token: the attacker captures the outcome of a correct authentication, second factor already satisfied. The campaign does that two ways. In the adversary-in-the-middle (AiTM) variant a proxy page sits inside a real login and collects the session cookie and refresh token on the way through. In the device code variant the victim signs in on Microsoft's genuine page, and the only irregularity is who the tokens are issued to at the end.

Executives are targeted for their reach and their correspondence, not for weaker security habits. A board member's mailbox holds draft contracts, deal timetables, and threads where a payment instruction raises no eyebrows. This is textbook spear phishing and whaling, with an authenticated session as the payload instead of a malicious attachment.

Scale: this is not a niche attack

The best documented example of this attack class comes from April 2026. Microsoft Threat Intelligence described an AiTM campaign posing as a corporate code of conduct that reached over 35,000 users across more than 13,000 organisations in 26 countries between 14 and 16 April. The sector split shows the targeting was anything but random: healthcare 19%, financial services 18%, professional services and technology 11% each.

The packaging is shifting too. In the first quarter of 2026 Microsoft analysed roughly 8.3 billion email-based phishing threats and named QR codes the fastest-growing carrier: 7.6 million attacks in January rising to 18.7 million in March, a 146% increase. By March, 70% of them arrived inside PDF attachments. The QR code is not decoration. It moves the click off a managed laptop onto a personal phone, past the proxy, the endpoint agent and the mail filter. Behind that packaging sits an entire market, because the tooling for campaigns like this is sold on subscription, which we cover in our piece on the FBI warning about the Kali365 platform.

The money sits at the end of this chain. The FBI's IC3 recorded $3.046 billion in BEC losses for 2025 across 24,768 complaints, roughly $123,000 per complaint. A hijacked executive mailbox is the shortest path to that transfer, because it lets the attacker hold the conversation from a real address, in a real thread, with knowledge of the real payment calendar. Poland's CERT Polska registered 260,783 incidents in 2025, 97% of them computer fraud, alongside nearly 250,000 domains added to its warning list, up 166% year on year.

The five phases of the attack chain

How device code flow turns into token theft

Device code flow is a legitimate OAuth 2.0 mechanism built for devices where typing a password is painful: televisions, consoles, command-line tools, IoT hardware. The device asks the identity provider for a short code, shows it to the user, and waits. The user goes to a sign-in page on a separate, trusted device, enters the code, authenticates normally, and the identity provider issues tokens to whoever requested the code.

The abuse breaks that assumption. The attacker initiates the flow and receives the code, then forwards it to the victim under the pretext of joining a meeting, confirming access, or verifying a device. The victim types the code on Microsoft's real page, completes real MFA, and sees a real success message. The tokens go to the attacker, because it was their device waiting for the result all along. Microsoft documented the technique in February 2025 alongside a campaign by an actor it tracks as Storm-2372, aimed at government, NGOs, defence and energy among others.

The refresh token is what matters. An access token expires within the hour, but a refresh token mints new ones for as long as it stays valid, with no fresh sign-in, no MFA, and no contact with the victim. The attacker then queries Microsoft Graph, searches the mailbox for words like "password" or "transfer", pulls files out of OneDrive, and sends messages from the victim's account. A password reset does not interrupt any of that on its own.

In Microsoft Entra logs the sequence has a recognisable shape. A device code authentication first leaves an entry with result code 50199, the pause while the code is entered, and moments later a successful entry for the same user, often from a different IP address and a client application that person never normally uses. The third entry, in the audit log, is the registration of a new authentication method, and that is the point where the attack stops depending on the stolen token.

// 1. Every device code sign-in in the last 14 days. Most tenants never use
//    this flow, so the baseline itself is the detection.
SigninLogs
| where TimeGenerated > ago(14d)
| where AuthenticationProtocol =~ "deviceCode"
| extend Country = tostring(LocationDetails.countryOrRegion)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Country, ResultType, CorrelationId
| order by TimeGenerated desc

// 2. The device code interrupt (50199) followed by a success for the same user
//    from another address within five minutes: the shape a phished code leaves.
let lookback = 14d;
let gap = 5m;
let prompts = SigninLogs
    | where TimeGenerated > ago(lookback) and ResultType == 50199
    | project UserPrincipalName, PromptTime = TimeGenerated, PromptIP = IPAddress;
let grants = SigninLogs
    | where TimeGenerated > ago(lookback) and ResultType == 0
    | where AuthenticationProtocol =~ "deviceCode"
    | project UserPrincipalName, GrantTime = TimeGenerated, GrantIP = IPAddress, AppDisplayName;
prompts
| join kind=inner grants on UserPrincipalName
| where GrantTime between (PromptTime .. PromptTime + gap)
| where PromptIP != GrantIP
| project UserPrincipalName, PromptTime, PromptIP, GrantTime, GrantIP, AppDisplayName

// 3. A new authentication method registered within an hour of a device code
//    sign-in. This is the persistence step, and it survives a password reset.
let tokens = SigninLogs
    | where TimeGenerated > ago(14d)
    | where AuthenticationProtocol =~ "deviceCode" and ResultType == 0
    | project UserPrincipalName, GrantTime = TimeGenerated, GrantIP = IPAddress;
AuditLogs
| where TimeGenerated > ago(14d)
| where LoggedByService == "Authentication Methods"
| where OperationName in ("User registered security info",
                          "User registered all required security info")
| where Result == "success"
| extend UserPrincipalName = tostring(TargetResources[0].userPrincipalName)
| join kind=inner tokens on UserPrincipalName
| where TimeGenerated between (GrantTime .. GrantTime + 1h)
| project TimeGenerated, UserPrincipalName, OperationName, GrantTime, GrantIP

Why MFA isn't enough, and which MFA is

"We have MFA" says nothing about resistance to this campaign, because MFA splits into two classes with very different properties. CISA draws the line explicitly: the phishing-resistant methods are FIDO2/WebAuthn and PKI-based authentication (PIV/CAC cards). Everything else, SMS, an authenticator app code, a push notification, is phishable, because it comes down to a secret a human can retype or approve in the wrong place. The gap is measurable: during 2025 Proofpoint observed attempted account compromises affecting nearly 3,000 user accounts across more than 900 Microsoft 365 environments, with a confirmed success rate exceeding 50%.

The third column is the one most often skipped. A passkey genuinely closes the AiTM variant, because the cryptographic signature is bound to the domain and cannot be reproduced on an intermediary page. It does not close the device code variant, because there the victim signs in on Microsoft's real domain and completes genuine, phishing-resistant authentication. The mistake is not how they signed in but where the code came from. That variant is closed by Conditional Access policy.

The platform is moving in one direction. From 1 September 2026 Microsoft Entra ID makes passkeys the default sign-in experience and automatically enables them for users on SMS or voice, and from 1 February 2027 it retires its own delivery of those two methods. After that date, anyone whose only second factor is SMS gets a blocking prompt until they register a passkey. Organisations that run the migration early and by choice will run it more cheaply than those doing it against a deadline.

Why Social Engineering Makes This Work

Technical sophistication is only half the story. The campaign succeeds because it exploits deeply ingrained behavioral patterns in executive workflows:

• Authority and routine — the impersonated platforms match daily executive workflows, so the response is habitual rather than considered
• Personalisation — sender domains and footers are drawn from the target's own organisation, creating the appearance of internal communication
• Device code subtlety — the target performs a genuine action on microsoft.com, so none of the learned heuristics ("check the address bar") ever fires

Telling a real sign-in request from this campaign

There is one recognition signal, and it needs no technical knowledge: a request to sign in or to enter a code that nothing you did set in motion. A real login is always the consequence of something you just did. A code arriving from outside "for confirmation" has no legitimate equivalent. The comparison below covers the rest of the signals.

The first 60 minutes after a suspected session hijack

Order matters more here than completeness. The goal of the first hour is to take valid tokens away from the attacker and remove whatever would let them mint new ones, before anyone starts analysing how it happened. The procedure below assumes access to Microsoft Entra and the audit log.

1. Minutes 0-10SOC on call
   Revoke sessions, not just the password

   Trigger sign-in session revocation for the account (the revokeSignInSessions operation in Microsoft Graph). That is what invalidates refresh tokens. Reset the password in parallel, but treat it as the second action, not the first.

2. Minutes 10-20Identity administrator
   Review the account's authentication methods

   Check the audit log for every authentication method registration in the last 30 days. Remove any the user does not recognise, and only then let them register a new one. Capture a snapshot of the state before you change anything.

3. Minutes 20-35Mail administrator
   Preserve, then clear mailbox rules

   Export mailbox and forwarding rules before deleting anything. Look for redirects to external addresses and rules that move messages containing "invoice", "transfer" or "bank" into rarely opened folders. Check delegations and mailbox permissions too.

4. Minutes 35-50Identity administrator
   Review OAuth application consents

   List user consents and admin consents for the tenant, paying particular attention to mail, file and directory read permissions. An application consent is an independent persistence mechanism that survives both a password reset and session revocation.

5. Minutes 50-60Incident lead
   Establish scope and secure the financial context

   Reconstruct from the logs which resources were reached through Microsoft Graph and what was sent from the account. If any thread touches payments, notify finance on a separate channel and hold transfers confirmed by email alone until they are verified by voice.

What is left after the first hour is the part that cannot be rushed: finding out how many other people received the same message, sweeping device code sign-ins across the whole tenant, and deciding whether the incident is notifiable. If personal data sat in that mailbox, the GDPR 72-hour clock starts when the breach is established, not when the analysis is finished.

What to close in advance

Prevention is unusually concrete here, because the attack relies on a countable set of platform mechanisms. The list below is ordered by effect against effort, from configuration changes to organisational ones.

The cost of this work breaks into several lines, and it is worth counting them separately rather than hunting for a single figure. On licensing, the Entra ID tier matters, because Conditional Access and token protection need more than the base plan. On hardware, the number of people who get a FIDO2 key and whether they need a spare. On team time, the inventory of applications still using device code, the weeks a policy spends in report-only mode, and the support load during passkey registration. On process, rewriting the response procedure so that token revocation is its first step.

Detection matters as much as configuration, because some signals only appear after the fact: a new MFA method, an unusual client application, a device code sign-in in a tenant that never used one. If nobody watches those events outside office hours, put that layer on 24/7 monitoring, and track executive data exposure in criminal sources separately (Flare).

Frequently asked questions

In closing

MFA remains necessary but is no longer sufficient for executive accounts. Once an attacker operates inside an authenticated session and adds their own sign-in method, what matters is not whether a second factor exists but which class it belongs to, which authentication flows were left open, and how fast tokens can be revoked. All three are settled before an incident, not during one. Executives and their assistants deserve a separate phishing and deepfake simulation programme, with hijacked-session detection handled by a 24/7 SOC.

The attack doesn't bypass MFA — it makes MFA irrelevant by operating inside the authenticated session itself. Defending against this requires rethinking what "secure authentication" actually means in 2026.