Lazarus rode an afd.sys race for five weeks to plant FudModule

A Monday morning at a European defense supplier. An aerospace engineer opens the recruiter PDF from the weekend, the sort listing a senior role above their current title and a request to review the attached spec. The PDF drops a loader. The loader fires a burst of Winsock IOCTLs at the kernel, catches a socket object at the microsecond it is being freed, reclaims that pool chunk with attacker-controlled bytes, and drives the network driver to write into memory that used to be its own. Coffee still hot, and the process is running as SYSTEM with a fresh build of Lazarus's kernel rootkit resident in afd.sys memory. Check Point Research watched this pattern for five weeks before Microsoft shipped the patch for CVE-2026-68820 on August 11, 2026 (Check Point Research, The Hacker News). CISA added it to KEV the same day with a Federal Civilian Executive Branch deadline of August 25, and the CVSS is 7.0.

A race under the network driver

afd.sys is the Ancillary Function Driver for WinSock. Every socket, every send and receive, every asynchronous overlapped completion runs through this kernel driver, which ships with every supported Windows from Windows 10 through Server 2025 and stays one of the busiest drivers on any workstation that runs a browser and a chat client. Because it is on every box, it is on every attacker's shortlist for local privilege escalation, and it has been mined for this class of primitive four times in three years (Cyber Security News).

The bug is a use-after-free race. Two threads inside the same low-privileged process open a socket then race across its state machine, one pushing an IOCTL that dereferences a per-socket kernel object and one pushing an IOCTL that frees the same object. The driver reads the pointer, checks it against a validity marker, then reads it again on the branch that dereferences, and the free path can complete on the other physical core between those two reads. The dereference walks a pointer into freed pool memory and follows whatever function pointer it finds (SOC Prime, Help Net Security).

From a freed socket to arbitrary kernel writes

Winning that race is not free. A spray primitive runs alongside it: threads on the same process stream allocations of the pool size class the freed object came from, so when the free lands the chunk drops into a hot freelist and the next allocation hands the attacker the same address the driver still holds a pointer to. That chunk carries a function pointer at the exact offset the driver's next read looks at, and the dereference lands on the attacker's code. The rest of the ladder is textbook Windows kernel exploitation: read into the current process's EPROCESS, swap the token pointer for the token of the System process's EPROCESS, and every subsequent thread runs as SYSTEM.

FudModule v3.1 blinds the box it landed on

The payload after SYSTEM is a new build of FudModule, a data-only kernel rootkit Lazarus has been iterating on since 2022. The 3.1 build strips telemetry callbacks, disables file system minifilters, kills the NT Kernel Logger by zeroing the EtwpActiveSystemLoggers field inside the _ETW_SILODRIVERSTATE structure, and takes over ninety ETW providers offline by clearing their enable masks in place. It also tampers with Smart App Control and targets recent Windows 11 client builds including 26100 and 26200. The EDR console still shows a green tick, because the sensor is receiving no events from downstairs. FudModule writes kernel data structures rather than loading a driver, so Driver Signature Enforcement, HVCI, and the driver blocklist are irrelevant. All it needs is an arbitrary kernel write.

7.0 is the wrong knob to sort this by

7.0 sits inside every scanner's medium band. On a queue sorted by base score, this CVE finishes below a stack of 8s and 9s that touch nothing your defense engineers open PDFs on. That is the whole failure. The base score reflects the vulnerability in isolation: locally authenticated attacker required, high attack complexity, high impact. It cannot know that the driver is on every Windows endpoint, that the attacker has a five-week head start, or that the payload deliberately blinds the sensor you rely on to prove nothing is happening. A queue that reads context puts this above every unauthenticated web CVE on any box in a defense-adjacent enclave until the update lands.

How TRIS scores the same medium CVE differently on two workstations

TRIS is the Threat and Risk Intelligence Scoring engine inside CVEasy AI. It scores a finding against the endpoint it lives on, so the same CVE lands in different bands on two workstations pulled off the same golden image.

Exploitation status. Confirmed in the wild by a named research team with five weeks of telemetry and a working rootkit payload, and lifted to KEV the day of the patch with a two-week FCEB deadline. Top band ACT applies until the fix is on the box. A published proof of concept alone would not have put it there; sustained abuse against a specific target sector did.

Exposure surface. The base score assumes the attacker already has code execution on the endpoint. A workstation that opens external documents and runs a browser meets that condition daily by phishing rounds you do not see. A hardened jump host with no email client and application allowlisting drops several bands.

Downstream blast radius. TRIS walks what a SYSTEM shell on a given endpoint actually reaches: cached domain admin tokens, source signing keys on a developer workstation, prime contract documents on an engineering laptop, release signing certificates on a build box, and CI runner tokens on hosts running a private runner. A workstation on the defense engineering VLAN weighs far heavier than one on the sales segment.

Recovery cost. A confirmed FudModule presence is a rotation and reissuance job, not a re-image. Every credential the process could reach becomes suspect, every code signing key on the host has to be revoked and reissued, and every ETW-fed sensor over the exposure window has to be treated as blind. That work drives the timeline, not the fifteen minutes to install the cumulative.

What every Windows fleet owner needs to do by August 25

1. Deploy the August 11 cumulative to every supported Windows build. Windows 10, Windows 11 including 26100 and 26200, and Windows Server 2016 through 2025. FCEB is on the August 25 KEV deadline; every other operator should be inside that fence.

2. Hunt for the exploit signature and FudModule indicators. Pull the Check Point IOC set and search back to July 1. Two easier tells: unexpected user-mode processes making dense Winsock IOCTL bursts against overlapped socket handles, and gaps in ETW provider output that align with the exploit window on the same host. Both live above the kernel structures FudModule edits, so both are hard for it to hide.

3. Treat defense, aerospace, drone, robotics, and aviation employees as the current target. Operation Dream Job refreshed the recruiter PDF lure. Warn the humans, tighten inbound attachment filtering, and route external PDFs through a sandbox before delivery.

4. Rotate on any confirmed hit. Every credential the endpoint held, every cached token, every code signing key on the box, every EDR agent identity, and any Kerberos ticket cached during the exposure window. Re-image after the rotation; the rotation limits the second-order damage.

How CVEasy AI surfaces this on your own hardware

CVEasy AI is the number one local-first CTEM platform. It ingests Microsoft's Patch Tuesday feed, Check Point advisories, and CISA KEV entries as they publish, matches CVE-2026-68820 against your Windows inventory, and runs each affected endpoint through TRIS against your identity graph, data classification, and recent phishing telemetry. Output is a short list per host: which endpoints are on a vulnerable build, which sit in a defense-adjacent enclave, which opened an external PDF from an unknown sender in the last thirty days, and which hold keys a SYSTEM shell would need assumed lost. Inventory and telemetry never leave your infrastructure, which matters when the finding is that a laptop on your engineering VLAN might have been running someone else's rootkit for a month.

Sources: Check Point Research, The Hacker News, Help Net Security, SOC Prime, Cyber Security News, CISA KEV catalog