Detection of Malicious Shim Database (.sdb) File Creation

Windows Application Compatibility shims are a legitimate mechanism used to ensure older applications run correctly on newer versions of the operating system by intercepting and redirecting API calls. However, this functionality is frequently abused by attackers to gain persistence or elevate privileges. By creating a custom shim database (.sdb) and installing it via the sdbinst.exe utility, an attacker can force the operating system to load malicious code into processes or bypass security checks. This detection focuses on monitoring filesystem writes to the %SystemRoot%\AppPatch\Custom directory, which is the standard location for user-defined shim databases. While legitimate administrative activity can occur here, unexpected file creation in this directory is a high-fidelity signal for security operations teams to investigate potential unauthorized persistence mechanisms.

Attack Chain

1. Attacker gains local administrative access to the target Windows system.
2. Attacker crafts a malicious Shim Database (.sdb) file containing redefined API hooks.
3. Attacker uses sdbinst.exe to register the malicious .sdb file within the system.
4. The malicious shim database is written to the %SystemRoot%\AppPatch\Custom directory.
5. The OS loads the shim database during process execution or system boot, depending on the scope of the shim.
6. API calls made by targeted applications or processes are redirected to the attacker-supplied malicious code.
7. Attacker achieves persistence or privilege escalation through the executed code.

Impact

Successful abuse of the shim mechanism can lead to persistent code execution and privilege escalation, as the malicious code is loaded by legitimate processes. This allows attackers to hide activities, bypass security software, and maintain long-term access to compromised environments.

Recommendation

1. Enable Sysmon Event ID 11 (FileCreate) to capture filesystem modifications.
2. Deploy the provided Sigma rule to detect file writes in the specified AppPatch directory.
3. Investigate any file creations in C:\Windows\AppPatch\Custom\ that lack a clear association with authorized software installation or maintenance.
4. Monitor for executions of sdbinst.exe associated with the creation of new .sdb files.