Kurzfassung: Shims sind eigentlich ein Windows-Mittel, um alte Programme auf neuen Systemen lauffähig zu halten - ein Angreifer macht daraus einen Weg, eigenen Code in fremde Prozesse einzuklinken und Rechte auszuweiten. Application Shimming hinterlässt klare Spuren: den sdbinst-Aufruf, einen Registry-Eintrag unter AppCompatFlags und eine Shim-Datei außerhalb des Standardverzeichnisses. Drei sigma-cli-validierte Sigma-Regeln, dazu Härtung und der Test im Lab. Serie "Angriff erkennen".
Die Shim-Infrastruktur (Application Compatibility) sorgt dafür, dass ältere Software auf neueren Windows-Versionen läuft, indem sie zur Laufzeit kleine Korrekturen zwischen Programm und Betriebssystem schiebt. Genau dieser Mechanismus lässt sich missbrauchen: Eine präparierte Shim-Datenbank klinkt eigenen Code in einen Zielprozess ein und kann so Rechte ausweiten oder sich dauerhaft festsetzen. Die Technik ist leise, weil sie einen legitimen Windows-Dienst nutzt. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.
Einordnung in ATT&CK: Event Triggered Execution: Application Shimming (T1546.011), eine Untertechnik von Event Triggered Execution. MITRE führt sie in den Taktiken Privilege Escalation und Persistence; in dieser Serie steht sie in der Spalte Privilege Escalation, weil der eingeklinkte Code im Kontext des Zielprozesses und oft mit erhöhten Rechten läuft. Sie grenzt sich von anderen Event-Triggered-Wegen wie IFEO oder COM-Hijacking durch die eigene Shim-Infrastruktur ab.
Was der Angreifer tut
Der Missbrauch der Shim-Infrastruktur läuft - auf der Ebene des Prinzips, nicht als Anleitung - in wenigen Mustern ab:
- Eine Shim-Datenbank bauen. Der Angreifer erstellt eine .sdb-Datei, die einem Zielprogramm eine Korrektur zuordnet, welche in Wahrheit eigenen Code einklinkt.
- Die Datenbank registrieren. Mit sdbinst wird die Shim-Datenbank im System eingetragen; Windows vermerkt sie unter AppCompatFlags in der Registry.
- Auf den Auslöser warten. Sobald das zugeordnete Programm startet, greift die Shim und der eingeklinkte Code läuft mit - im Kontext und mit den Rechten des Zielprozesses.
- Dauerhaft bleiben. Die Zuordnung übersteht Neustarts, sodass die Shim zugleich als Persistenz dient.
Für die Erkennung ist entscheidend: Das Registrieren hinterlässt eine Spur - den sdbinst-Aufruf, den Registry-Eintrag unter AppCompatFlags und die Shim-Datei auf der Platte. Genau daran setzen die Regeln an.
Welche Logquellen die Technik zeigt
- Prozess-Telemetrie zuerst. Event 4688 zeigt sdbinst samt vollständiger Befehlszeile - also die registrierte Shim-Datenbank. Die wichtigste Quelle für den aktiven Einbau.
- Registry-Telemetrie. Sysmon Event 13 zeigt den neuen Eintrag unter AppCompatFlags\InstalledSDB oder AppCompatFlags\Custom und erfasst die Shim auch ohne sichtbaren sdbinst-Aufruf.
- Datei-Telemetrie. Das Anlegen der .sdb-Datei außerhalb des AppPatch-Verzeichnisses zeigt sich im Datei-Log und ergänzt die beiden anderen Signale.
- Werkzeug-Kontext. sdbinst ist ein mitgeliefertes Windows-Programm; Grundlagen zum Missbrauch solcher Bordmittel unter Living off the Land.
Das Muster im Log
Drei Signale tragen. Das erste ist ein sdbinst-Aufruf, der eine Shim-Datenbank registriert. Das zweite ist ein neuer Eintrag unter AppCompatFlags\InstalledSDB oder AppCompatFlags\Custom in der Registry. Das dritte ist eine frisch angelegte .sdb-Datei außerhalb des Standardverzeichnisses Windows\AppPatch. Legitime Treffer stammen aus Softwareinstallationen und Kompatibilitäts-Fixes, die eigene Shims mitbringen. Auffällig wird es, wenn eine Shim außerhalb einer bekannten Installation registriert wird, die Datei aus einem Temp- oder Benutzer-Ordner stammt oder der Aufruf von einem ungewöhnlichen Konto kommt. Der Blick auf Herkunft, Pfad und Programm trennt den Alltag vom Angriff.
Drei Sigma-Regeln
Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: den sdbinst-Aufruf, den Registry-Eintrag unter AppCompatFlags und die Shim-Datei außerhalb von AppPatch. Je eine wertet Prozess-, Registry- und Datei-Telemetrie aus.
1. Shim-Datenbank per sdbinst installiert (T1546.011). Ein Aufruf von sdbinst.exe. Die Regel steht auf level: medium.
title: Shim-Datenbank per sdbinst installiert
id: 5b3a8e42-6c94-4d71-a2f5-3d8c6b1e9a57
status: experimental
description: |
Erkennt den Aufruf von sdbinst.exe, mit dem eine Shim-Datenbank (.sdb) registriert wird. Angreifer
installieren eine praeparierte Shim-Datenbank, um Code im Kontext eines anderen Programms auszufuehren
und so Rechte auszuweiten oder sich festzusetzen (Application Shimming). Der Einsatz von sdbinst ist im
Normalbetrieb selten.
references:
- https://attack.mitre.org/techniques/T1546/011/
author: blue-team.net
tags:
- attack.privilege-escalation
- attack.t1546.011
logsource:
product: windows
category: process_creation
detection:
sel_img:
Image|endswith: '\sdbinst.exe'
condition: sel_img
falsepositives:
- Einzelne Softwareinstallationen registrieren legitime Shims per sdbinst - bekannte Installer und Datenbanken als Baseline ausnehmen
level: medium2. Shim-Eintrag in der Registry unter AppCompatFlags gesetzt (T1546.011). Ein Eintrag unter InstalledSDB oder Custom. Ebenfalls level: medium.
title: Shim-Eintrag in der Registry unter AppCompatFlags gesetzt
id: 8e4c6a23-7d81-4b63-b5f2-9c3d7a4e1b68
status: experimental
description: |
Erkennt das Setzen eines Eintrags unter AppCompatFlags\\InstalledSDB oder AppCompatFlags\\Custom in der
Registry. Windows vermerkt dort registrierte Shim-Datenbanken und zugeordnete Programme; ein neuer
Eintrag belegt eine installierte Shim-Datenbank (Application Shimming). Der Registry-Weg erfasst die
Technik auch dann, wenn sdbinst nicht ueber die sichtbare Kommandozeile aufgerufen wurde.
references:
- https://attack.mitre.org/techniques/T1546/011/
author: blue-team.net
tags:
- attack.privilege-escalation
- attack.t1546.011
logsource:
product: windows
category: registry_set
detection:
sel:
TargetObject|contains:
- '\AppCompatFlags\InstalledSDB\'
- '\AppCompatFlags\Custom\'
condition: sel
falsepositives:
- Legitime Software und Kompatibilitaets-Fixes legen Shim-Eintraege an - bekannte Programme und Datenbanken als Baseline ausnehmen
level: medium3. Shim-Datenbank-Datei außerhalb des Standardverzeichnisses angelegt (T1546.011). Eine .sdb-Datei außerhalb von Windows\AppPatch. Ebenfalls level: medium.
title: Shim-Datenbank-Datei ausserhalb des Standardverzeichnisses angelegt
id: 2a9e5c37-4d82-4f61-b3d7-7c2e8b4a1f69
status: experimental
description: |
Erkennt das Anlegen einer Shim-Datenbank-Datei (.sdb) ausserhalb des Standardverzeichnisses
Windows\\AppPatch. Angreifer legen die praeparierte Shim-Datenbank oft in einem Temp- oder
Benutzer-Verzeichnis ab, bevor sie sie registrieren (Application Shimming). Eine .sdb-Datei ausserhalb
des AppPatch-Verzeichnisses ist im Normalbetrieb ungewoehnlich.
references:
- https://attack.mitre.org/techniques/T1546/011/
author: blue-team.net
tags:
- attack.privilege-escalation
- attack.t1546.011
logsource:
product: windows
category: file_event
detection:
sel_sdb:
TargetFilename|endswith: '.sdb'
filter_std:
TargetFilename|contains: '\AppPatch\'
condition: sel_sdb and not filter_std
falsepositives:
- Einzelne Installer legen Shim-Datenbanken ausserhalb von AppPatch ab - bekannte Faelle nach Pfad und Programm als Baseline ausnehmen
level: mediumHärtung: der Angriff, der ins Leere läuft
- sdbinst einhegen. Den Einsatz von sdbinst.exe auf Endgeräten per AppLocker oder WDAC auf die Konten und Hosts beschränken, die ihn wirklich brauchen.
- AppCompatFlags überwachen. Änderungen unter AppCompatFlags\InstalledSDB und Custom als privilegierte Registry-Pfade gezielt protokollieren und auswerten.
- Adminrechte eng halten. Das Registrieren einer Shim-Datenbank erfordert erhöhte Rechte - lokale Administratorrechte streng begrenzen, damit dieser Weg gar nicht erst offensteht.
- Gezielt überwachen. sdbinst-Aufrufe, AppCompatFlags-Einträge und .sdb-Dateien außerhalb von AppPatch als feste Erkennungen führen.
Der Test
Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon - mit einer harmlosen Test-Shim, die danach wieder entfernt wird:
- Für Regel 1 eine harmlose Test-Shim-Datenbank mit sdbinst registrieren und prüfen, dass Event 4688 den Aufruf samt .sdb-Pfad zeigt.
- Für Regel 2 kontrollieren, dass Sysmon Event 13 den neuen Eintrag unter AppCompatFlags\InstalledSDB meldet.
- Für Regel 3 eine .sdb-Datei in einem Temp-Pfad anlegen und prüfen, dass die Regel greift; die Test-Shim danach mit sdbinst -u wieder entfernen.
- Breiter wird der Test mit den Fällen zu T1546.011 aus Atomic Red Team.
Fehlalarme und Tuning
- Softwareinstallation. Manche Programme bringen eigene Shims für Kompatibilitätszwecke mit. Bekannte Installer, Datenbanken und Pfade als Baseline ausnehmen, bevor die Regeln scharf geschaltet werden.
- Kompatibilitäts-Fixes. Administratoren setzen gelegentlich bewusst Shims für Altsoftware ein. Diese Vorgänge und Hosts gezielt behandeln.
- Pfad entscheidet. Eine Shim im AppPatch-Verzeichnis einer bekannten Installation ist Alltag; dieselbe aus einem Temp-Ordner ist es nicht - danach priorisieren.
- Kette schlägt Einzelzeile. sdbinst, der Registry-Eintrag und eine .sdb aus einem Benutzer-Ordner zusammen sind weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.
Fazit
Application Shimming macht aus einem Kompatibilitätsmechanismus einen Weg zur Rechteausweitung: Eine präparierte Shim-Datenbank klinkt eigenen Code in einen Zielprozess ein und übersteht Neustarts. Die verlässlichen Signale sind ein sdbinst-Aufruf, ein Eintrag unter AppCompatFlags\InstalledSDB oder Custom und eine .sdb-Datei außerhalb von Windows\AppPatch. Die wirksamste Härtung ist das Einhegen von sdbinst per Anwendungssteuerung, zusammen mit eng begrenzten Adminrechten und der Überwachung der AppCompatFlags. Grundlagen zum Missbrauch signierter Bordmittel zeigt das Living off the Land; weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Privilege Escalation.