CLFS Authentication Mitigation (HMAC + Merkle Tree)

Last updated: 2026-04-10
Related: Clfs, Mitigations
Tags: clfs, mitigation, hmac, merkle-tree, blf-integrity, kernel-mode

Summary

Microsoft’s MORSE (Microsoft Offensive Research & Security Engineering) team developed a structural mitigation for the CLFS exploit class: cryptographic authentication of BLF files using HMAC + Merkle tree. This directly addresses the root cause of all BLF-file-based CLFS exploits by making it computationally infeasible to forge valid BLF content.

Effect: When enforced, ALL BLF-file-based CLFS exploits (CVE-2022-24521, CVE-2022-37969, CVE-2023-23376, CVE-2023-28252, CVE-2024-49138, and all future variants in this class) are blocked.

How It Works

Merkle Tree Over BLF Blocks

Each metadata block in the BLF is hashed. The hashes are organized into a Merkle tree where:

• Leaf nodes = individual block hashes
• Parent nodes = hash of child hashes
• Root = single HMAC over the tree root

On BLF open, the driver:

1. Reconstructs the Merkle tree from the on-disk BLF
2. Verifies the HMAC signature at the root
3. Rejects any BLF whose HMAC does not match → parse never happens

HMAC Key Management

Keys are managed per-BLF and stored in a separate policy file (.cnpf — “CLFS Non-Paged File”). The key is not derived from the BLF content itself, preventing an attacker who can write to a BLF from forging the HMAC.

Deployment Modes

Learning Mode (90 Days)

When enabled, CLFS authenticates new BLF files it creates but also recognizes existing unauthenticated files:

• New files created during learning mode: HMAC computed and stored in .cnpf
• Pre-existing files: allowed to open without HMAC (no .cnpf exists yet)
• Purpose: Avoid breaking applications that have existing BLF files on the system before the mitigation was enabled

After 90 days, learning mode automatically transitions to enforcement mode (all pre-existing files now have .cnpf files from having been opened).

Enforcement Mode

All BLF opens require valid HMAC. BLFs without a corresponding valid .cnpf are rejected. Any BLF that has been tampered with (any byte changed) fails HMAC verification → parse blocked → exploit blocked.

Registry Configuration

HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication
  Value: AuthenticationMode
  Type:  REG_DWORD
  0 = Disabled (default on older builds)
  1 = Learning (90-day period)
  2 = Enforcement

fsutil Command

# Enable CLFS authentication (requires admin):
fsutil clfs setAuthentication Enabled

# Check current status:
fsutil clfs queryAuthentication

# Status output example:
CLFS Authentication Mode: Learning (expires 2026-07-10)

.cnpf Files

.cnpf (CLFS Non-Paged File) files are created alongside BLF files:

• Naming: <BLF_name>.cnpf in the same directory
• Contents: HMAC key + Merkle tree root hash
• Protected: readable only by SYSTEM/kernel — user cannot read or modify
• Deletion: if .cnpf is deleted, enforcement mode will reject the corresponding BLF

Limitations

1. IRP-based attacks NOT blocked: CVE-2025-29824 (UAF via IRP race) does NOT use BLF file crafting — it abuses IOCTL calls on open file descriptors. CLFS authentication does NOT protect against this class.

2. IOCTL integer overflows NOT blocked: CVE-2026-20820 (ScanContainers OOB) uses IOCTL parameters, not BLF file content.

3. Kernel pool grooming may still apply: If an exploit can corrupt CLFS state without a malicious BLF file (e.g., via memory corruption in IOCTL processing), authentication does not help.

4. Pre-existing BLF bypass: During learning mode, pre-existing BLFs created before enforcement are trusted. An attacker who can pre-stage a BLF before learning mode begins could bypass the mitigation.

Impact on Known CVEs

Defender Takeaways

• Enabling CLFS authentication blocks the historically most prolific CLFS exploit class
• Organizations with Windows 11 should enable enforcement mode immediately
• Monitor .cnpf file deletions as potential pre-attack staging behavior
• Remaining vulnerability surface: IOCTL-based attacks (UAF, integer overflow)

References

• Microsoft Security Blog — “Security mitigation for the Common Log Filesystem (CLFS)” — 2022/2023
• Microsoft MORSE team — internal development (referenced in security blog)