From Job Offer to Ring 0: Lazarus, CVE-2026-68820 and FudModule 3.1

A zero-day in the Windows kernel is worth six figures on the open market. Lazarus spent one on a PDF sent to an aerospace engineer who thought he was applying for a job.

In August 2026, Check Point Research published its analysis of a campaign that had been running quietly since early in the year: a revival of Operation Dream Job, North Korea's long-standing fake-recruiter playbook, carrying something the operation had never carried before. That something was a previously unknown local privilege escalation in the Windows kernel, exploited in the wild for roughly five weeks before Microsoft shipped a fix.

The bug is CVE-2026-68820, a use-after-free in afd.sys, the Ancillary Function Driver for WinSock. Microsoft rates it Important at CVSS 7.0: local only, requires code execution first, no remote reachability. That score badly undersells what it bought the operator. It is a clean, driver-free path from a low-privilege user process to SYSTEM and a kernel read/write primitive, and from there to the newest build of the FudModule rootkit, which proceeds to dismantle the telemetry your EDR depends on to see any of it.

This post walks the whole chain: the lure, the two delivery variants, the in-memory downloader, the exploit, the rootkit, the backdoor, and the compromised web infrastructure that carried the traffic. Then it does the part that actually matters for a defender, which is separating what you can realistically detect from what you cannot, and turning that into an exercise you can run.

A note on names: what Google calls these groups now

Before the technical detail, a housekeeping point that affects anyone mapping this campaign into a threat model. On 24 July 2026, Google Threat Intelligence Group replaced its actor-naming scheme. Mandiant's APTnn and FINnn numbering and TAG's separate identifiers are being folded into a single two-word cryptonym: a memorable first word for the cluster, plus a second word encoding origin or motivation.

"APT" survives all this as a generic descriptor, and MITRE keeps its APTnn group entries. Google is retiring only its own numbering. Old names stay indexed and searchable inside Google Threat Intelligence, next to ATT&CK mappings and other vendors' aliases, so nothing you have already written breaks. UNC designations survive too, for clusters still under investigation, and the gap between the two carries weight: a cryptonym means GTIG has reached an attribution judgement, a UNC number means it has not.

Google's initial batch covered several dozen of the most active groups, with the rest renamed on a rolling basis. Lazarus did not appear in the published examples at the time of writing, so this post keeps using the community name. If you maintain a group taxonomy in a SIEM or an emulation platform, the practical takeaway is to treat actor names as aliases pointing at a cluster, never as primary keys, and to key your detections on technique IDs instead. Those are the one identifier nobody has renamed.

The lure: two ways into the same downloader

The social-engineering front end is the classic Dream Job pattern: a recruiter approach over LinkedIn or a messaging platform, aimed at staff at defence, aerospace and aviation firms, with an observed preference for organisations working on surveillance sensors, drones and robotics. One decoy document was built around a Lockheed Martin job description. Confirmed victims sit in France, Germany, India and Brazil, a spread corroborated across independent reporting.

One detail deserves its own sentence, because it is the kind of thing that defeats sender-reputation controls. At least one compromised French organisation was subsequently used as the sending party for further spear-phishing, so the second wave of targets received their lure from a real, trusted, industry-peer mailbox.

From there the campaign ran two parallel delivery chains.

Chain 1 · The encrypted archive and the side-loaded DLL

1. The archive. The victim downloads a password-protected ZIP. Inside: a legitimately signed, MuPDF-based PDF viewer, an encrypted PDF, and a malicious libmupdf.dll placed where the viewer expects its real dependency.
2. The side-load. The user runs the viewer. Windows resolves libmupdf.dll from the application directory first, and the signed binary loads the attacker's library into its own trusted process. Signature checks on the parent executable pass, because the parent executable is genuinely clean.
3. The decoy. The decoy PDF renders on screen exactly as expected, a job description and a compensation summary, while the side-loaded DLL stages the MISTPEN downloader in memory. Nothing about the user's experience suggests failure.

Chain 2 · "SecurityPDF" and the SEO-poisoned vendor

From July 2026 the operators added a second route that removes the suspicious archive entirely. Phishing mail impersonated Enveil, and the choice of brand is doing real work here. Enveil is a genuine privacy-enhancing-technology firm, founded in 2016 by US intelligence community alumni and led by a former NSA cryptography researcher, selling homomorphic encryption into government and defence. An aerospace engineer who gets mail from that vendor saying a document is encrypted and needs their viewer has little reason to hesitate. Victims were pointed at three lookalike sites (envell[.]xyz, enveil[.]online, uxtramine[.]org) deliberately optimised to rank in search results. A victim who did the responsible thing and searched for the vendor instead of clicking the link landed on attacker infrastructure anyway.

Those sites served SecurityPDF, a modified MuPDF viewer presented as the tool required to open an "encrypted" document. Per Check Point's reverse engineering, the trojanized build parses any PDF it is given, looking for the marker string:

This document is encrypted with sumatrapdf reader!!!!!!!!!!!!

When the marker is present, the viewer extracts the appended blob, decrypts it with a single-byte XOR key (0x39), writes new.exe, and executes it. That binary then reflectively loads the Troy backdoor DLL into memory. Any other PDF opens normally. The malicious behaviour is gated on content the analyst may never have, which is precisely the point: submit the viewer alone to a sandbox and it is a functioning PDF reader.

Splitting delivery this way, with a benign-looking tool from one host and the trigger document from another, is a deliberate reduction of detection surface. Neither half is convicting on its own.

MISTPEN: a downloader that lives in your tenant

MISTPEN is the campaign's staging layer, an in-memory modular downloader with no meaningful on-disk footprint. Its command channel is the part worth studying, because it is designed to be indistinguishable from ordinary corporate traffic: it talks to its operators through the Microsoft Graph API, reading and writing AES-encrypted files in OneDrive.

There is no attacker-controlled domain to block, no unusual TLS destination, no newly registered infrastructure in the netflow. The traffic goes to Microsoft, over 443, from a Windows host in a Microsoft-centric enterprise. Domain blocklists, newly-observed-domain rules and threat-intel feeds are all structurally blind to it.

MISTPEN pulls task-specific modules on demand instead of shipping every capability up front:

The LPE loader is selective, and that selectivity is itself tradecraft. Check Point documents a four-stage handshake that runs before the exploit is ever delivered:

1. Fingerprint the host: exact OS build and installed security products.
2. Request a public key from the C2, keyed to that fingerprint.
3. Derive a session key using Kyber / ML-KEM, a post-quantum key encapsulation mechanism, with transport encrypted under GOST-CBC using 16-byte random session keys.
4. Deploy FudModule, invoked through the exported function DestroyEnv.

The zero-day is never sprayed. It goes only to hosts whose build the exploit is known to work against, and that discipline accounts for most of why five weeks of exploitation stayed quiet. The crypto is its own tell. A post-quantum KEM negotiation wrapped around a Russian block cipher makes a distinctive network fingerprint, and it puts post-quantum cryptography inside offensive tooling well ahead of most enterprise TLS.

CVE-2026-68820: winning a race inside afd.sys

afd.sys is the kernel-mode driver sitting under WinSock. Every socket operation a user-mode process performs, every connect() and every send(), is ultimately serviced by it. That makes it a permanently reachable kernel attack surface from any process that can open a socket, including heavily sandboxed ones. Attackers keep returning to it for that reason.

The flaw is a use-after-free reached through a race condition. Two of the driver's own code paths can operate on the same socket state simultaneously without synchronisation. Trigger both at the right instant and one path dereferences memory the other has already released. Win that race with the freed allocation reclaimed by attacker-controlled data, and the result is the primitive that matters: arbitrary kernel read and write, which converts to SYSTEM by rewriting the process token.

Two scopes get conflated when this campaign is summarised. The vulnerability reaches back across a broad range of Windows versions, as far as Windows 10 under Extended Security Updates. The exploit Check Point observed was built for Windows 11 builds 26100 (24H2) and 26200 (25H2) specifically, matching the fingerprint-first delivery above. A host can sit unpatched for weeks without ever having been a target.

Why this matters more than the CVSS suggests: BYOVD without the D

For years the standard route to kernel code execution has been Bring Your Own Vulnerable Driver: drop a signed-but-flawed third-party driver, load it, abuse it. The whole defensive apparatus built since then assumes that step exists. Microsoft's vulnerable driver blocklist, HVCI, driver-load telemetry and hunting rules for unexpected .sys files in C:\Windows\Temp all watch for a driver arriving.

Exploiting afd.sys skips all of it. Nothing is dropped and nothing is loaded. The vulnerable driver is already resident, already Microsoft-signed, and already required for the machine to have a network stack. Every control that watches for the arrival of a bad driver observes nothing at all.

Disclosure timeline

That is roughly five weeks of live exploitation against a targeted victim set. If your defence model assumes patch latency is the only exposure window, this is the counterexample: for those five weeks, patching was not an available control to anyone.

The fix ships in KB5121003 for Windows 11, taking builds to 26100.9168 and 26200.9168, and KB5120249 for Windows 10 under ESU. One operational caveat that is easy to miss in a compliance dashboard: because the fix replaces a kernel driver, installing the update is not sufficient until the host reboots. A patched-but-unrebooted machine is still exploitable, and most patch reports will happily count it as remediated.

FudModule 3.1: the rootkit as a telemetry demolition tool

FudModule is not a persistence mechanism and it is not a backdoor. It is a data-only kernel rootkit whose single purpose is to make the rest of the intrusion unobservable. Version 3.1 is injected into a SYSTEM-level msiexec.exe process and, once operating on kernel structures, works through a checklist:

• Callback teardown. Removes process, thread and image-load notification callbacks, plus object and registry callbacks. These are the kernel hooks EDR products register to observe activity. Strip them and the EDR keeps running perfectly well. Nobody tells it anything.
• Minifilter removal by altitude band. File-system filter drivers are unlinked by altitude range, cutting file-activity visibility for whole classes of security product at once.
• ETW blinding. Check Point counts a kill-list of 94 ETW provider GUIDs; other write-ups describe it more conservatively as "over 90". Either way it takes out the event tracing pipeline that Defender, Sysmon-adjacent tooling and threat-hunting queries all rest on. The NT Kernel Logger session is killed alongside it.
• Crash-dump suppression. Kernel work is error-prone, and suppressing dumps removes both the forensic artefact and the bugcheck that would otherwise announce the operation.
• A driver selection engine with explicit preserve and kill rules, so the rootkit disables what it needs to without destabilising the host.
• A WFP stage activated specifically when Kaspersky is present, which is per-vendor branching inside a rootkit.
• Privileged handle forgery via a two-hop route, services.exe to SYSTEM msiexec.exe, manufacturing the handles it needs rather than requesting them.

The new capability: switching off Smart App Control

What makes 3.1 a genuine version bump is the Smart App Control tampering stage, and this one is corroborated beyond the primary analysis. Smart App Control is the Windows 11 reputation-based execution control that blocks untrusted and unsigned binaries outright, a meaningful obstacle to a toolkit that wants to run unsigned payloads.

Independent coverage describes the capability as resetting Smart App Control's verified-and-reputable policy state. Check Point gives the mechanism: the rootkit sets VerifiedAndReputablePolicyState to zero, then invokes NtSetSystemInformation with information class 0xA4 and option 0x10000000 which forces Windows to re-read its code integrity policy on the spot. The system does not reboot, no policy file changes on disk, and the machine simply stops enforcing the control it believes it is still enforcing.

Version 3.1 also drops two things present in v3: the dedicated Microsoft Defender suspension stage, now generalised into broader security-product suppression, and the PPL-stripping routine aimed at AhnLab's asdsvc.exe. That is a maintained codebase with a release process, not a one-off tool.

Troy: 17 commands and a debug path left in

Troy is the hands-on-keyboard implant, a single 64-bit DLL and one of the campaign's newly documented components. It ships with an unstripped PDB path, which is both an excellent hunting artefact and a small window into the developer's build environment:

E:\HK\Tool_Module\Troy_Handle\1Troy_Create_Dll_Tool\x64\Release\Test_Dll.pdb

On start it iterates three hardcoded C2 URL and port pairs until one answers with the string CONNECTED, completes a challenge-response authorisation, then registers with a client identifier and a profile: user directory, account name, Windows version, IPv4 address and working directory. Tasks arrive Base64-encoded. Results go back in a JSON envelope of the form {"to":"<channel>","msg":"<base64>"}, chunked when large.

The injection routine is textbook and worth naming for detection purposes: allocate RWX memory in the remote process, write the loader and payload, execute via RtlCreateUserThread. Note also what is absent. There is no credential dumping, no built-in lateral movement, no domain enumeration. Troy is an espionage tool for reading files off a specific engineer's workstation, not a ransomware precursor.

RelayShell: when someone else's CMS is the C2

The campaign runs no attacker-owned C2 servers in the traditional sense. Command traffic is relayed through compromised legitimate web servers, specifically Roundcube webmail instances, WordPress sites and PrestaShop stores, each running a PHP webshell tracked as RelayShell. Check Point identified at least 17 distinct relay identifiers, implying a comparable number of compromised nodes. Operators reach them through commercial VPN egress to obscure origin.

The Roundcube compromises are notable because they chain a known bug with commodity criminal supply. The operators used dark-web credential leaks to authenticate, then exploited CVE-2025-49113, a CVSS 9.9 PHP object deserialisation RCE in Roundcube's upload.php that requires authentication, to land the shell. That flaw was patched in Roundcube 1.5.10 and 1.6.11 and has been in the CISA KEV catalog since February 2026, so every node in this relay pool was an unpatched, credential-reused webmail server. Building the relay pool cost them a credential dump and a public exploit, and nothing beyond that.

RelayShell itself is a bidirectional relay with two modes. In victim mode it creates a password-selected session, decrypts a hidden configuration with a custom substitution cipher to recover a backbone URL and a unique PID, and POSTs to that backbone to signal the session is live. In operator mode it scans for the most recent .ses session files, checks connectivity, updates configuration, uploads and deletes files with Base64-encoded paths and content, and retrieves activity logs. Both sides talk by dropping files instead of holding a socket open. Each one is named for its session, with a trailing digit saying who wrote it: 1 for the victim, 2 for the operator.

If you run an internet-facing Roundcube, WordPress or PrestaShop instance, this is your reminder that you are not only a target, you are potential infrastructure. Those .ses and <id>1.log / <id>2.log files under a webroot are a directly huntable artefact.

Mapping it to MITRE ATT&CK

The full chain, mapped against the current enterprise matrix. Check two IDs before importing any of this into a detection stack, because several write-ups of this campaign have them wrong. T1574.001 is now simply "Hijack Execution Flow: DLL", and the old T1574.002 (DLL Side-Loading) no longer appears in the matrix, having been folded into it. And exploiting a kernel flaw for elevation is T1068, not a sub-technique of T1548, whose sub-techniques cover UAC bypass, sudo and macOS-specific mechanisms.

Where the detection window actually is

Once T1068 succeeds and FudModule is resident, your endpoint telemetry stops being evidence. The callbacks are gone, the minifilters are unlinked, the ETW providers are silent. Hunting queries against that host return clean results because the data was never generated, not because nothing happened. Any detection strategy that depends on catching the rootkit after it lands is already lost.

So the whole defensive problem reduces to one question: can you see the chain before ring 0? Concretely, these are the events that still exist in that window.

• Anomalous image loads. A PDF viewer, or any MuPDF-family binary, loading a DLL from its own directory whose signer does not match the vendor. This is the single highest-value signal in the chain, and it fires before anything else happens.
• Process lineage. A document viewer spawning new.exe or any unsigned child. Legitimate PDF readers do not create executables.
• Graph API from the wrong process. Traffic to graph.microsoft.com and token requests to login.microsoftonline.com originating from a process that is not Office, OneDrive or a known line-of-business app. You cannot block the destination, so identify the caller.
• SYSTEM msiexec.exe with no MSI. An msiexec.exe running as SYSTEM with an implausible parent and no installer package on the command line is the injection target for FudModule.
• Telemetry going quiet. Treat the absence of expected events as an alert condition. A host that stops emitting from an ETW provider it has emitted from every day for a year is not a healthy host. This is the one signal that survives the rootkit, and almost nobody instruments it.
• Smart App Control state changes. A transition out of enforcement with no policy deployment to explain it.
• Server-side artefacts. .ses files and <id>1.log / <id>2.log pairs under a Roundcube, WordPress or PrestaShop webroot, and Roundcube authentications from unexpected ASNs preceding them.

So the best detection opportunity in this whole intrusion is a DLL load inside a PDF reader, about five minutes in, long before any of it looks like an attack.

How to emulate this kill chain

Reading an advisory tells you what an actor did. It does not tell you what your environment would have said about it. The purple-team question here is narrow and answerable: of the observable behaviours in this chain, which ones produce an alert in my environment today? What follows is a plan you can run with whatever tooling you already have.

Run it in order. A flat checklist of techniques only shows which behaviours alert on their own. Running them as a chain shows the first point at which the intrusion becomes visible to you.

1. Delivery and execution. Emulate T1574.001, T1204.002 and T1036.005 using a benign side-loaded library next to a signed binary. This is the pre-escalation window, the part you can actually win. If the image-load detection does not fire here, nothing later will matter.
2. Discovery and collection. Run T1082, T1057, T1518.001 and T1113. Cheap, noisy, and routinely unalerted. Most teams discover here that screen capture and security-software enumeration produce no signal at all.
3. Cloud-service C2. Exercise T1102.002 against a legitimate cloud endpoint and check whether an unusual process talking to a trusted destination raises anything. This is where identity and egress telemetry earn their keep, so correlate wherever that lives for you: Sentinel and Defender for Endpoint on the Microsoft side, Splunk for the Linux and web-server tail.
4. Escalation and defence evasion, simulated only. Do not weaponise CVE-2026-68820, and be sceptical of any tool that offers to. Exercise the detection paths for T1068, T1055, T1562.001 and T1553 through safe proxies: an unprivileged process opening a handle it should not, a benign injection into a SYSTEM process, a reversible tamper with a test ETW provider, a Smart App Control state read.
5. Read the result per technique, not per campaign. A single pass/fail for "Lazarus" is useless. What you want is a verdict for each technique, backed by the specific events that prove it, rolled up by tactic so the gap has a shape.

What emulation cannot tell you

Emulation reproduces behaviour, not exploits. Nothing in a purple-team run tells you whether your hosts were vulnerable to the AFD.sys race. That is a patch-state question, answered by inventory and by confirming those hosts actually rebooted after KB5121003.

What emulation does tell you is whether the surrounding behaviours are visible: the side-load, the injection, the cloud C2, the defence tampering. That distinction matters, because it is where the real gap usually sits. Most organisations were patched within days of 11 August. Far fewer can prove they would have seen an unsigned DLL load into a signed PDF viewer on 3 July.

All of the above is a manual exercise today, and a fairly laborious one: five phases, roughly twenty techniques, correlated by hand against whichever SIEM holds the relevant logs. That workflow is what Cyllex is being built to collapse into a single phased campaign, with the destructive tail gated instead of executed and the per-technique verdicts produced automatically. Cyllex is still in pre-release at the time of writing. When it ships, this chain is one of the profiles it is designed to carry, and this post is the specification for it.

What actually reduces exposure

• Patch, then confirm the reboot. KB5121003 closes CVE-2026-68820 on Windows 11, KB5120249 on Windows 10 ESU. Because the fix replaces a kernel driver, an installed-but-unrebooted host is still exploitable. Report on reboot compliance, not install compliance.
• Alert on missing telemetry. Build a detection for ETW providers and EDR agents that go silent on a host that was previously reporting. Against a rootkit whose entire job is suppression, absence is the only signal left.
• Do not rely on Smart App Control alone. It is a reputation control, and this campaign demonstrates it is reachable from the kernel. Pair it with policy-based application control such as WDAC, and with ASR rules that constrain what a document viewer can spawn in the first place.
• Attribute cloud egress to processes. Blocking graph.microsoft.com is not an option, so the control has to key on process identity, not on destination. Ask which binaries in your estate legitimately hold Graph tokens.
• Harden internet-facing CMS and webmail. Patch Roundcube to 1.5.10 or 1.6.11, enforce MFA on webmail, and hunt your own webroots for stray .ses and .log session files. Your unpatched marketing WordPress is somebody's relay node.
• Brief the people being targeted. The victims here are engineers in defence, aerospace, drones and robotics, approached with a credible job offer, sometimes from a compromised peer organisation's real mailbox. Generic phishing training does not cover a recruiter conversation that runs for two weeks before a file is ever sent.

A five-week zero-day window means patching was never available as a control. What was available, the entire time, was noticing that a signed PDF reader had loaded a DLL nobody signed. Go and find out whether yours would have.

Indicators and sources

Every hash, domain and address above points at its VirusTotal page instead of the indicator itself, so following one is a lookup and never a request to attacker infrastructure. For family-level context, Malpedia carries entries for FudModule, attributed there to Lazarus with a dozen prior write-ups and three YARA rules, and for MISTPEN, catalogued under UNC2970 from Mandiant's 2024 reporting. MISTPEN predates this campaign; only its delivery here is new. Troy has no Malpedia entry at the time of writing, which is what you would expect from a family first documented here. The actor page is Lazarus Group, and the vulnerability record is CVE-2026-68820 on NVD.

Indicators above are drawn from Check Point's report, which publishes the full hash sets for each family. The primary technical analysis is Check Point Research, "Shattering the Dream: When a Job Offer Becomes a Zero-Day Attack". The vulnerability details, CVSS rating and patch scope were cross-checked against Tenable's August 2026 Patch Tuesday analysis and the CISA KEV catalog; the campaign timeline and victimology against BleepingComputer, Help Net Security and Security Affairs. Actor naming follows Google Threat Intelligence Group's updated system. Every technique ID was checked against the live MITRE ATT&CK matrix instead of being copied from secondary reporting.

Where sources disagree, this post follows the majority. Reporting on the start of exploitation ranges from early June to early July 2026; the "early July" reading is used here because it is what Check Point's own timeline, BleepingComputer and the widely repeated "five weeks before the patch" framing all support.

Related reading on this blog: Scattered Spider's identity-first playbook, the mirror image of this campaign, where there is no malware to find at all, and Judgment Panda, on APT31's abuse of legitimate cloud services as a C2 channel.