On May 18, 2024, Kaspersky’s Global Research & Analysis Team (GReAT), in collaboration with its partners, conducted the qualifying round of the SAS Capture the Flag (CTF) competition. This international contest, which draws cybersecurity experts from around the globe, is a highlight of the Security Analyst Summit conference. Over 800 teams participated, tackling challenges inspired by real-world cases encountered by Kaspersky GReAT. However, a few challenges remained unsolved, one notably involving a security vulnerability that allows kernel shellcode to be concealed within the system registry and executed during system boot on fully updated Windows 7 and Windows Server 2008 R2 systems. This vulnerability stems from an incomplete fix for the CVE-2010-4398 flaw. Despite the cessation of security updates and technical support for Windows 7 in early 2020, it was recognized long before that the patch only partially addressed the issue, with evidence of exploitation in a targeted attack as early as 2018. Kaspersky had alerted Microsoft about this exploitation, but the company opted not to address it, citing that the technique required attackers to have administrator privileges.
Vulnerability details
The design flaw exists in earlier versions of Windows operating systems, from Windows NT 4.0 through Windows 7, allowing kernel shellcode to persist and be executed at system boot by writing specially crafted data to various locations in the system registry. A key function, RtlQueryRegistryValues, enables querying multiple values from the registry subtree with a single call. The syntax for this function is as follows:
NTSYSAPI NTSTATUS RtlQueryRegistryValues(
[in] ULONG RelativeTo,
[in] PCWSTR Path,
[in, out] PRTL_QUERY_REGISTRY_TABLE QueryTable,
[in, optional] PVOID Context,
[in, optional] PVOID Environment
);The values queried by this function are defined by the QueryTable parameter, which points to a table of _RTL_QUERY_REGISTRY_TABLE structures. Each entry in this table specifies the name of the value to query, its default type, and the buffer to store the value or the address of a callback function. The use of the RTL_QUERY_REGISTRY_DIRECT flag allows for direct storage of the queried value into the provided buffer, which can lead to unexpected consequences if the requested value’s type does not match the expected type, potentially resulting in a buffer overflow. Microsoft has since encouraged the use of an additional flag, RTL_QUERY_REGISTRY_TYPECHECK, to mitigate such risks, but its implementation has been inconsistent.
Exploitation
Attackers exploit this vulnerability through multiple stack buffer overflows in two drivers, utilizing the RtlQueryRegistryValues function in a two-stage process. Initially, they target the “dxgmms1.sys” driver, where insecure usage of the function allows them to write shellcode to a fixed location in kernel memory. In the second stage, they exploit the “dxgkrnl.sys” driver to overwrite the return address of a function, facilitating the execution of the previously written shellcode.
The SAS CTF challenge
Participants in the SAS CTF challenge were presented with a README.txt file alongside three other files: SOFTWARE, SYSTEM, and traffic.pcapng. The SOFTWARE and SYSTEM files represent the registry hives of a Windows system. The initial task involved identifying the registry piece causing a virtual machine (VM) to crash, which could be approached by locating executable code within the registry hives or attempting to reproduce the crash.
Identifying the VM and the OS
Using regipy to parse and dump the registry hives, participants could identify VirtualBox devices and confirm the correct version of the VirtualBox additions package. This process also allowed for the identification of the exact Windows build required, which was determined to be Windows 7 SP1 x64. Setting up a Windows 7 SP1 VM and building a timeline of the registry hive was essential for further analysis.
Set up the debugger
Before proceeding, participants were advised to enable kernel debugging within the VM. This setup would facilitate the analysis of any blue screen of death (BSOD) events that occurred. Additionally, a second Windows VM with the Windows Debugger was to be connected to the target VM for real-time debugging.
Crash!
Once the debugging setup was complete, participants were to replace the SOFTWARE and SYSTEM hives, leading to an infinite BSOD loop. This provided an opportunity to analyze the crash and extract relevant data for further investigation.
Analyzing the crash
Participants could either extract the crash dump for offline inspection or debug live with their debugger machine. By examining the stack and return addresses, they could identify the source of the crash and explore the vulnerability in the dxgkrnl and dxgmms1 drivers.
The shellcode
Upon analyzing the shellcode, participants discovered its purpose was to start a system thread and execute a payload. The payload, once decrypted, revealed itself to be a keylogger that collected keystrokes and transmitted them via UDP. The keylogger utilized a MachineGuid and a fixed binary string for encryption.
Usermode payload
The usermode payload injected as an Asynchronous Procedure Call (APC) was designed to log keystrokes and send them over the network. Participants were tasked with decrypting the payload and analyzing its contents.
The SAS CTF final competition
The SAS CTF does not conclude with the qualifying phase; it culminates in a final competition where the top eight teams will gather in Bali from October 22-25 to tackle even more complex challenges. The Security Analyst Summit conference can be followed using the hashtag #TheSAS2024.
