Skip to content

CVE-2023-28252

Common Log File System, OOB write via corrupted base log offset

Exploited in the Wild

This vulnerability was exploited in the wild before or shortly after patching.

Summary

Field Value
Driver clfs.sys
Vulnerability Class Buffer Overflow / Bounds Check
Vulnerable Build 10.0.22621.1265 (KB5023706)
Fixed Build 10.0.22621.1555 (KB5025239)
Exploited ITW Yes

The Story

CVE-2023-28252 is the CLFS vulnerability that Kaspersky caught the Nokoyawa ransomware operators using as a zero-day. It was the second CLFS zero-day associated with Nokoyawa (after CVE-2023-23376), demonstrating that the same ransomware group was actively hunting for new CLFS bugs or purchasing them from brokers. Kaspersky's Securelist blog provides the most detailed public analysis of the vulnerability and the Nokoyawa exploitation chain.

The root cause is, once again, unchecked offset fields in BLF metadata. This time the vulnerable functions are CClfsBaseFilePersisted::WriteMetadataBlock and ClfsBaseFlushMetadata, which trust cbSymbolZone and base block offset values without validating that they fall within buffer boundaries.

Affected Functions

  • CClfsBaseFilePersisted::WriteMetadataBlock
  • ClfsBaseFlushMetadata
  • CClfsLogFcbPhysical

The Same Pattern, Different Offset

The vulnerability follows the CLFS playbook established by CVE-2022-37969. A crafted BLF file with manipulated cbSymbolZone or base block offset fields causes the driver to compute a write target that falls outside the allocated metadata region. When CLFS processes the tampered metadata during routine log operations (such as creating or extending a container), the driver writes attacker-influenced data to a kernel address determined by the offset delta.

The corruption triggers when CLFS processes the tampered metadata. Calling CreateLogFile on the crafted .blf file from user mode reaches the vulnerable code path; no elevated privileges are required. The resulting relative write primitive lands in the kernel paged pool, targeting whatever allocation sits adjacent to the CLFS metadata buffer.

AutoPiff categorizes this as bounds_check with detection rules:

  • added_len_check_before_memcpy
  • added_bounds_check_on_offset
  • added_index_range_check

How Nokoyawa Got SYSTEM

Kaspersky's analysis reveals the full Nokoyawa exploitation chain. The operators used pool feng shui to shape the kernel heap layout before triggering the bug. Allocations of a controlled size (via NtQuerySystemInformation) were sprayed to position predictable objects adjacent to the CLFS container context in the paged pool. When the OOB write fired, it corrupted a field in one of these adjacent allocations, specifically the process token pointer in the current process's EPROCESS structure, overwriting it with a copy of the SYSTEM token.

The full chain: place a crafted .blf file on disk, spray the paged pool to position objects, open the BLF with CreateLogFile to trigger CLFS metadata parsing, which performs the out-of-bounds write through the corrupted offset. The write lands on the positioned object, enabling the token swap. After the swap, the process runs with SYSTEM privileges and the ransomware deployment begins.

Patch Analysis

The patch shipped in KB5025239 (build 10.0.22621.1555) adds bounds validation on offset fields within BLF metadata blocks before they are used as write targets. Range checks were introduced for cbSymbolZone and related offset fields. If an offset exceeds the valid range, the operation is rejected before any write occurs.

AutoPiff detects the fix through the added_len_check_before_memcpy, added_bounds_check_on_offset, and added_index_range_check rules.

Detection

YARA Rule

rule CVE_2023_28252_CLFS {
    meta:
        description = "Detects vulnerable version of clfs.sys (pre-patch)"
        cve = "CVE-2023-28252"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "clfs.sys" wide ascii nocase
        $blf_marker = { 42 4C 46 30 }
        $vuln_build = "10.0.22621.1265" wide ascii
        $func_write_meta = "WriteMetadataBlock" ascii
        $func_flush_meta = "FlushMetadata" ascii
    condition:
        $mz at 0 and $driver_name and $vuln_build and ($blf_marker or $func_write_meta or $func_flush_meta)
}

ETW Indicators

Provider Event / Signal Relevance
Microsoft-Windows-CLFS Event ID 6 (Container create/extend) Fires when a BLF container operation triggers the vulnerable WriteMetadataBlock path
Microsoft-Windows-Kernel-Audit Token modification events Detects SYSTEM token swap following successful exploitation
Microsoft-Windows-Security-Auditing Event ID 4672 (Special privileges assigned) Low-privilege process suddenly acquiring SeDebugPrivilege or SeTcbPrivilege after BLF interaction
Microsoft-Windows-Security-Auditing Event ID 4688 (Process creation) Post-exploitation child process spawned with SYSTEM integrity from a previously unprivileged parent
Microsoft-Windows-Kernel-Process Process token change Detects the EPROCESS token pointer overwrite used in the Nokoyawa exploitation chain

Behavioral Indicators

  • A low-privileged process calls CreateLogFile on a crafted .blf file with an abnormally large or negative cbSymbolZone field in the base metadata block
  • Burst of paged pool allocations via NtQuerySystemInformation immediately before the CreateLogFile call, consistent with pool feng shui spray patterns
  • Process token replacement observed at runtime: a standard user process suddenly holds SYSTEM-level token without going through legitimate elevation paths
  • Presence of suspicious .blf files in user-writable directories (e.g., %TEMP%, %APPDATA%) with metadata block offsets that exceed the file size
  • Post-exploitation deployment of ransomware payloads or security tooling termination from the newly elevated process

Broader Significance

CVE-2023-28252 is the best-documented CLFS ransomware exploitation chain, thanks to Kaspersky's detailed Securelist analysis. The Nokoyawa connection demonstrates that ransomware operators were not just opportunistically using CLFS bugs but actively investing in them as a persistent escalation capability. Two CLFS zero-days from the same ransomware operation within months of each other suggests either an in-house vulnerability research capability or a reliable broker relationship. See the CLFS Deep Dive for the complete attack surface analysis.

References