CVE-2024-21338: Windows Kernel — Privilege Escalation

Background

CVE-2024-21338 is a Windows kernel vulnerability in the appid.sys driver — the kernel component of Windows AppLocker. Lazarus Group exploited it as a zero-day in 2024, using it as a stepping stone to deploy their FudModule rootkit. This is the same rootkit observed in the CVE-2024-38193 campaign; Lazarus appears to have had multiple kernel LPEs in their toolkit simultaneously.

The significance here is that this is an attack on the AppLocker kernel driver itself — the security feature designed to control which software can run. By exploiting the very driver meant to enforce application control, Lazarus achieved a particularly elegant form of privilege escalation with potential to undermine the security stack.

Technical Mechanism

appid.sys is the kernel driver backing the Windows Application Identity service, used by AppLocker for application execution control. The vulnerability is in how the driver handles certain IOCTL (I/O Control) calls from user mode.

Windows kernel drivers expose IOCTLs to user-mode processes for communication. Certain IOCTLs in appid.sys are accessible from user mode and contain a vulnerability in their input validation:

1. A user-mode process sends a crafted IOCTL request to the appid.sys driver
2. The driver processes the request with insufficient bounds checking or type validation
3. This results in a write-what-where condition or similar primitive in kernel memory
4. The attacker exploits this to modify their process’s security token — specifically, replacing the token’s privilege level with a SYSTEM-equivalent token
5. The process now has SYSTEM privileges

Avast researchers who discovered this noted that the specific IOCTL abuse was known as a technique in the security research community but hadn’t been weaponised at scale before Lazarus used it.

Once SYSTEM is achieved, Lazarus loaded FudModule, which operates at the kernel level to:

• Disable ETW (Event Tracing for Windows) kernel callbacks
• Remove PPL (Protected Process Light) protections from antivirus processes
• Delete kernel callbacks registered by EDR solutions

The result: a fully blind security monitoring environment.

Real-World Exploitation Evidence

Avast researchers discovered the zero-day usage and published analysis in February 2024:

• Lazarus Group — confirmed exploitation; consistent with the group’s pattern of using Windows kernel exploits for the FudModule rootkit
• FudModule v2 — this campaign used an updated version of FudModule that no longer relied on BYOVD (Bring Your Own Vulnerable Driver) techniques, instead using this direct kernel exploitation
• Transition from BYOVD — Lazarus had previously used BYOVD techniques; moving to direct kernel exploitation shows continued investment in offensive capabilities
• Financial and defence targeting — Lazarus’s typical targeting of cryptocurrency and defence sectors

The sophistication here — a direct kernel exploit used specifically to deploy a rootkit that blinds security monitoring — represents top-tier offensive capability.

Impact Assessment

• Kernel-level privilege escalation to SYSTEM
• Security tool neutralisation — FudModule specifically designed to disable AV, EDR, and security monitoring
• Invisible persistence — with security tools blinded, the attacker can operate without triggering alerts
• Credential dumping — SYSTEM + blinded security = trivial credential harvest
• Long-term espionage — kernel rootkits are used for sustained, stealthy access
• Supply chain risk — Lazarus targets include crypto exchanges, tech companies, and defence contractors

Affected Versions

Remediation Steps

1. Apply February 2024 Patch Tuesday updates
2. Given FudModule deployment, standard patching is insufficient if already compromised:
   • Conduct memory forensics using tools outside the potentially compromised OS (bootable forensic environment)
   • FudModule operates in kernel space and may blind standard detection tools
3. If Lazarus activity is suspected:
   • Treat the entire host as compromised
   • Use offline forensics tools
   • Check for known FudModule indicators via memory forensics
4. Enable Secure Boot and UEFI attestation to make kernel-level persistence harder
5. Enable Hypervisor-Protected Code Integrity (HVCI) — this makes kernel driver exploitation significantly harder as unsigned code cannot execute in kernel mode:

   # Enable HVCI via Group Policy or MDM
   # Or: reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v HypervisorEnforcedCodeIntegrity /t REG_DWORD /d 1

Detection Guidance

Kernel monitoring — before FudModule deployment:

• Look for unexpected IOCTL calls to appid.sys
• Monitor for appid.sys driver exceptions or crashes (failed exploit attempts)

Memory forensics (for post-FudModule detection):

• Volatility plugins for detecting kernel rootkits
• Look for hooked SSDT entries or modified kernel callbacks

Avast detection guidance — Avast published indicators in their FudModule analysis report.

SIEM rule:

process_integrity_level = "System" AND
process_parent_integrity_level IN ("Medium", "Low") AND
NOT parent_process_name IN ("services.exe", "wininit.exe", "winlogon.exe")

Suricata signature:

alert tcp $HOME_NET any -> any any (msg:"Possible Lazarus FudModule/CVE-2024-21338 C2 Channel"; flow:established,to_server; content:"|00 00 00 04|"; offset:0; depth:4; dsize:>100; classtype:trojan-activity; sid:2034026; rev:1;)

Timeline