Ransomware Attackers Exploit Windows Zero-day to Exploit Privileges

Ransomware attackers exploit Windows zero-day vulnerabilities to gain elevated privileges. Zero-day vulnerabilities are undisclosed flaws that provide a direct way to bypass security measures.

By exploiting these vulnerabilities, threat actors can escalate their privileges, enabling them to:-

• Execute malicious code with higher system access
• Increase the impact of their ransomware attacks on Windows systems
• Increase the success rate of their ransomware attacks on Windows systems

Understanding CLFS (Common Log File System) is crucial to knowing the roots of vulnerability. Common Log File System (CLFS) has been a versatile log subsystem in Windows since 2003. 

OS and applications use this subsystem, and it relies on clfs.sys driver. The logs include metadata in a Base Log File (.blf) and data containers created with APIs. 

While Microsoft doesn’t document BLF’s format, as it’s decipherable with reverse engineering, which is aided by debug symbols for clfs.sys.

Ransomware Exploit Windows Zero-day

Microsoft doesn’t explicitly highlight, but documents mention CLFS optimization for performance, working in non-copy buffers flushed to disk. 

Despite its complexity and old code base, CLFS faces vulnerabilities. Over 30 elevations of privilege vulnerabilities, including four zero-days, have been patched since 2018. 

Analyzing the BLF file format reveals the following things at the start of each block:-

• Records stored in blocks
• Sector-sized (0x200 bytes) reads/writes
• A CLFS_LOG_BLOCK_HEADER

Block header in BLF files contains sectors, checksum, and less crucial info. While the key fields for researchers are:-

• RecordOffsets (array of record offsets)
• SignaturesOffset (points to original bytes’ location)

The BLF files have six blocks, but it has three different types with names like:-

• CONTROL
• GENERAL
• SCRATCH

Exploits leverage the standard BLF layout by avoiding needing a prebuilt file. Records in CONTROL, GENERAL, and SCRATCH blocks follow specific structures like:- 

• CLFS_CONTROL_RECORD
• CLFS_BASE_RECORD_HEADER
• CLFS_TRUNCATE_RECORD_HEADER

All starts with CLFS_METADATA_RECORD_HEADER, which features a DumpCount field used by the ReadMetadataBlock function.

CLFS_CONTROL_RECORD’s rgBlocks array holds info on the six BLF file blocks. CLFS_METADATA_BLOCK structures detail block size, offset, and a placeholder for kernel pointer, reads SecureList report.

While the GENERAL block stores key BLF data like:- 

• Clients
• Containers
• Security descriptors

The CLFS_BASE_RECORD_HEADER structure has large arrays with offsets. Symbols combine CLFSHASHSYM and CONTEXT structures for efficient search. cbSymbolZone field designates the zone for new structures. 

Structures in the symbol zone start with a unique magic number and size. CLFS_CLIENT_CONTEXT structure contains important fields like:-

• llCreateTime
• llAccessTime
• llWriteTime
• fAttributes

CLFS_CONTAINER_CONTEXT’s pContainer field stores a kernel pointer to the CClfsContainer class. If attackers inject a malicious CLFS_CONTAINER_CONTEXT into a BLF file without proper validation, they can hijack control flow and elevate privileges.

CLFS prioritizes performance over a sensible file format, and manipulating disk offsets can cause structures to overlap.

This helps in creating numerous vulnerabilities for easy exploitation. To avoid these risks, a reasonable file format is necessary.