Lazarus didn't bring a vulnerable driver. They used the one already on every Windows PC.

The defensive playbook for kernel attacks has a name: stop bring-your-own-vulnerable-driver. Attackers who want kernel-level access often can’t find a bug in Windows itself, so they bring along a legitimately-signed but vulnerable third-party driver, load it, and exploit it to get into the kernel. Microsoft’s answer is the vulnerable-driver blocklist, a maintained list of known-bad drivers the OS refuses to load. It works because the bad driver is something foreign that has to be carried in.

CVE-2024-21338 sidesteps the entire model. The vulnerable driver here is appid.sys, the kernel driver behind AppLocker, Microsoft’s own application-control feature. It’s signed by Microsoft, it’s present on essentially every Windows machine, and the North Korean group Lazarus used it to get into the kernel. You cannot put appid.sys on a blocklist. It’s not a foreign object you can refuse; it’s part of the operating system. This is bring-your-own-vulnerable-driver with nothing to bring.

What the bug is

CVE-2024-21338 is an exposed IOCTL in the appid.sys driver with insufficient access control. The driver’s input/output control dispatcher accepted a crafted IOCTL request and, because it didn’t properly validate the user-supplied input, could be steered into executing attacker-controlled code in kernel mode. CVSS 7.8, local vector. Avast’s Jan Vojtěšek discovered it and reported it to Microsoft in August 2023 as an actively-exploited zero-day; Microsoft patched it on February 13, 2024. CISA added it to the Known Exploited Vulnerabilities catalog on March 4, 2024, with a March 25 deadline and the ransomware-use flag. It affects Windows 10 1809 through 22H2, Windows 11 through 23H2, and Windows Server 2019 and 2022.

What Lazarus did with it is the reason it matters. Kernel access let them run an updated version of their FudModule rootkit, a user-mode-to-kernel tool whose job is to blind security software. FudModule has been documented turning off or tampering with multiple endpoint products, including AhnLab V3, CrowdStrike Falcon, HitmanPro, and Microsoft Defender. Once an attacker is operating in the kernel, the security tools running in user mode are below them in the trust hierarchy, and a rootkit can disable or deceive them. The exploit is the key; the rootkit is what walks through the door.

The boundary Microsoft says isn’t one

There’s a policy wrinkle worth understanding, because it shapes how fast these get fixed. Microsoft has long held that admin-to-kernel is not a security boundary. The reasoning: an attacker who already has administrator rights is considered to have effectively conceded the machine, so a bug that takes them from admin to kernel isn’t treated with the same urgency as one that crosses a boundary Microsoft does defend, like user-to-admin or sandbox escape. Under that stance, admin-to-kernel elevation bugs may get fixed without being treated as critical, and sometimes without the speed an actively-exploited flaw would otherwise command.

Lazarus’s use of CVE-2024-21338 is the practical argument against that comfort. Admin-to-kernel may not be a boundary on Microsoft’s threat model, but it’s a hugely valuable step on a real attacker’s, because the kernel is where you go to defeat the defenders. The gap between “we don’t consider this a boundary” and “this is the exact capability nation-state actors build their rootkits around” is the gap defenders fall into when they de-prioritize EoP patches that are “only” admin-to-kernel.

What this means for how you defend

The takeaway isn’t really about one CVE; it’s about not over-trusting the controls that look like they cover this.

• The driver blocklist is necessary but not sufficient. It stops foreign vulnerable drivers. It does nothing about a vulnerability in a driver Windows ships itself, and CVE-2024-21338 proves attackers will hunt for exactly those, because a built-in driver can’t be blocklisted and is present everywhere. Keep the blocklist enabled, but don’t treat it as comprehensive coverage against kernel attacks.
• Patch admin-to-kernel EoP bugs on their real-world value, not Microsoft’s boundary classification. When a kernel elevation bug is on the KEV list and tied to a group like Lazarus, the “it requires admin first” caveat is not a reason to wait. The actors using these already have the admin foothold; the bug is the part they were missing.
• Watch for EDR going dark. A rootkit’s purpose is to silence your telemetry. EDR agents that stop reporting, security services that crash or get disabled, and tamper-protection events are signals that should be treated as potential active compromise, not maintenance noise. If you only trust the EDR’s own dashboard, a kernel-level tool can simply tell it everything’s fine.
• Assume kernel-capable adversaries can see past user-mode defenses. That argues for defense in depth that doesn’t live entirely on the endpoint: network-level detection, identity monitoring, and out-of-band logging that a compromised host can’t retroactively edit.

The reframe is about where the real boundary lives. Microsoft can define admin-to-kernel as outside its security boundary, and that’s a legitimate engineering decision about what they’ll commit to defending. But attackers don’t operate inside vendor threat models; they operate inside your network, and to them the kernel is the prize because it’s where the security tools lose. CVE-2024-21338 is what that looks like in practice: a built-in driver, a blocklist that couldn’t help, and a rootkit switching off the products you bought to catch exactly this. Patch the kernel bugs like the boundary is real, because to the people exploiting them, it is.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2024-21338 — 2024-02-13
• Microsoft MSRC: CVE-2024-21338 — 2024-02-13
• The Hacker News: Lazarus hackers exploited Windows kernel flaw as zero-day — 2024-02
• Nero22k: Windows AppLocker Driver Elevation of Privilege (CVE-2024-21338) — 2024
• Huntress: CVE-2024-21338 analysis — 2024