DLL-Hijacking erkennen: Sideloading und Search Order Hijacking

DLL-Hijacking erkennen ist deshalb schwierig und deshalb wichtig, weil der Schadcode nicht in einem fremden, verdächtigen Prozess läuft, sondern in einem bekannten und oft signierten. Der Angreifer startet keine eigene ausführbare Datei, sondern bringt eine legitime Anwendung dazu, seine DLL zu laden. Für Virenschutz und oberflächliche Prüfungen sieht alles normal aus: Ein signiertes Programm startet und lädt eine Bibliothek. Dieser Beitrag aus der Serie „Angriff erkennen“ zeigt die Technik aus Verteidigersicht, mit drei Sigma-Regeln, der Härtung und dem Test.

Was der Angreifer tut

Windows lädt eine DLL nicht über einen festen Pfad, sondern sucht sie in einer festen Reihenfolge von Verzeichnissen. Genau diese Reihenfolge ist der Hebel. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Search Order Hijacking. Eine Anwendung fordert eine DLL nur über den Namen an. Legt der Angreifer eine gleichnamige DLL in ein Verzeichnis, das Windows früher durchsucht als das eigentliche, wird seine Version geladen. Ein häufiger Sonderfall ist die fehlende DLL: Fordert ein Programm eine Bibliothek an, die gar nicht vorhanden ist, füllt der Angreifer die Lücke mit seiner eigenen.
• Side-Loading. Der Angreifer legt eine legitime, signierte Binärdatei zusammen mit einer präparierten DLL in einen Ordner, den er beschreiben darf. Startet die Binärdatei, lädt sie die DLL aus dem eigenen Verzeichnis. Die gültige Signatur der Binärdatei verschleiert den Start, der Schadcode steckt in der DLL daneben.
• Warum das attraktiv ist. Der Code läuft im Kontext eines vertrauten Prozesses, erbt dessen Rechte und Netzwerkfreigaben und übersteht oft die oberflächliche Prüfung, weil der sichtbare Prozess signiert und bekannt ist.
• Als Persistenz. Liegt die präparierte DLL neben einer Anwendung, die automatisch startet, lädt das System den Schadcode bei jedem Start erneut, ganz ohne eigenen Dienst und ohne Autostart-Eintrag.

Für die Erkennung ist entscheidend: So unauffällig der Start wirkt, die DLL selbst verrät sich. Sie wird irgendwann geschrieben, sie wird geladen, und ihr Pfad oder ihre Signatur passt nicht zu dem, was eine saubere Installation hinterlässt.

Welche Logquellen die Technik zeigt

• Die geladene DLL. Sysmon Event 7 (ImageLoad) protokolliert jede geladene Bibliothek mit Pfad, Signaturstatus und Hash. Das ist die direkteste Quelle, aber auch die lauteste; Event 7 muss in der Sysmon-Konfiguration gezielt gefiltert werden, sonst erschlägt das Volumen jede Auswertung. Wie du es sinnvoll aktivierst, steht unter Sysmon einrichten.
• Die abgelegte DLL. Sysmon Event 11 zeigt das Schreiben der DLL ins Dateisystem, etwa in ein Benutzer- oder Temp-Verzeichnis oder neben eine vorhandene Anwendung.
• Der Prozessstart. Sysmon Event 1 zeigt die startende Binärdatei mit Pfad, Elternprozess und Signatur. Ein signiertes Programm, das aus einem Benutzerverzeichnis startet, ist der Kontext, in dem Side-Loading sichtbar wird.
• Blockierte Ausführung. Wo Anwendungssteuerung mit DLL-Regeln aktiv ist, zeigt Event 8004, dass das Laden einer Bibliothek verweigert wurde, oft der früheste und sauberste Hinweis.

Das Muster im Log

Das stärkste Einzelsignal ist die Kombination aus Herkunft und Signatur: eine unsignierte DLL, die aus einem beschreibbaren Benutzerverzeichnis geladen wird. Legitime Anwendungen laden ihre Bibliotheken fast immer signiert und aus Programm- oder Systemverzeichnissen. Noch eindeutiger wird der Fall, wenn die ladende Binärdatei und die DLL im selben Benutzerordner liegen: Das ist das klassische Bild eines mitgelieferten Side-Loadings. Ein drittes, selteneres Muster ist eine DLL, die außerhalb einer Installation in ein Programm- oder Systemverzeichnis geschrieben wird, denn dort legt normalerweise nur ein Installer oder ein Windows-Update Dateien ab. Am überzeugendsten ist die Kette: Eine DLL wird in einen Ordner geschrieben, kurz darauf startet eine Anwendung von dort und lädt genau diese DLL.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste und dritte nutzen den Signatur- und Pfadkontext aus Sysmon Event 7, die zweite den Schreibvorgang aus Sysmon Event 11. Alle setzen voraus, dass die jeweiligen Ereignisse in der Sysmon-Konfiguration erfasst werden.

1. Unsignierte DLL aus einem Benutzerverzeichnis (T1574.001). Diese Regel erkennt das Laden einer unsignierten DLL aus einem beschreibbaren Pfad. Sie steht auf level: medium, weil portable und eigenentwickelte Software das ebenfalls tut; solche Quellen nimmst du als Ausnahme auf.

title: Unsignierte DLL aus einem Benutzerverzeichnis geladen
id: 2227b04e-78fc-4423-ae41-ec584da5e1a5
status: experimental
description: |
  Erkennt das Laden einer unsignierten DLL aus einem beschreibbaren
  Benutzerverzeichnis. Beim DLL-Seitenladen legt der Angreifer eine
  praeparierte DLL neben eine vertrauenswuerdige Anwendung und laesst sie
  beim Start mitladen. Legitime Programme laden ihre DLLs fast immer
  signiert und aus Programm- oder Systemverzeichnissen.
references:
  - https://attack.mitre.org/techniques/T1574/001/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1574.001
logsource:
  category: image_load
  product: windows
detection:
  selection:
    ImageLoaded|endswith: '.dll'
    ImageLoaded|contains:
      - '\Users\'
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
      - '\Public\'
    Signed: 'false'
  condition: selection
falsepositives:
  - Portable oder eigenentwickelte Software, die unsignierte DLLs aus dem Benutzerprofil laedt; bekannte Faelle ausnehmen
level: medium

2. DLL in ein geschütztes Verzeichnis geschrieben (T1574.001). Ein Schreibvorgang einer DLL nach Program Files oder System32 durch einen Prozess, der kein Installer ist, deutet auf das Platzieren einer Bibliothek in der Suchreihenfolge einer Anwendung.

title: DLL in ein geschuetztes Programm- oder Systemverzeichnis geschrieben
id: 2e2e5f20-897c-45b7-9b7a-86baad97889d
status: experimental
description: |
  Erkennt das Anlegen einer DLL in einem Programm- oder Systemverzeichnis
  durch einen Prozess, der kein Installer und kein Windows-Update ist.
  Angreifer platzieren so eine praeparierte DLL in der Suchreihenfolge einer
  Anwendung (Search Order Hijacking). Ausserhalb von Installationen und
  Updates werden dort nahezu nie DLLs geschrieben.
references:
  - https://attack.mitre.org/techniques/T1574/001/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1574.001
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith: '.dll'
    TargetFilename|contains:
      - '\Program Files\'
      - '\Program Files (x86)\'
      - '\Windows\System32\'
      - '\Windows\SysWOW64\'
  filter_installer:
    Image|endswith:
      - '\msiexec.exe'
      - '\TrustedInstaller.exe'
      - '\TiWorker.exe'
      - '\svchost.exe'
      - '\setup.exe'
  condition: selection and not filter_installer
falsepositives:
  - Software-Installationen und Updates, die nicht ueber die gelisteten Prozesse laufen; Wartungsfenster korrelieren
level: medium

3. Prozess und DLL aus demselben Benutzerverzeichnis (T1574.001). Startet eine Anwendung aus einem Benutzerverzeichnis und lädt von dort auch ihre DLL, ist das das typische Bild eines mitgelieferten Side-Loadings. Die Regel steht auf level: high.

title: Prozess und geladene DLL aus demselben Benutzerverzeichnis
id: f6cfb5f2-d61f-4f5c-a41a-36bee08543df
status: experimental
description: |
  Erkennt eine Anwendung, die aus einem beschreibbaren Benutzerverzeichnis
  startet und von dort auch ihre DLL laedt. Das ist das typische Muster eines
  mitgelieferten DLL-Seitenladens: eine signierte Binaerdatei und eine
  praeparierte DLL liegen zusammen in einem Ordner. Die Signatur der
  Binaerdatei verschleiert den Start, die DLL bringt den Schadcode.
references:
  - https://attack.mitre.org/techniques/T1574/001/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1574.001
logsource:
  category: image_load
  product: windows
detection:
  selection:
    ImageLoaded|endswith: '.dll'
    Image|contains:
      - '\Users\'
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
      - '\Public\'
    ImageLoaded|contains:
      - '\Users\'
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
      - '\Public\'
  condition: selection
falsepositives:
  - Portable Anwendungen und Entwicklungswerkzeuge, die vollstaendig aus dem Benutzerprofil laufen; bekannte Verzeichnisse ausnehmen
level: high

Härtung: der Angriff, der ins Leere läuft

• Anwendungssteuerung mit DLL-Regeln. WDAC oder AppLocker mit aktiven DLL-Regeln lassen nur signierte oder ausdrücklich erlaubte Bibliotheken zu. Das nimmt dem Side-Loading unsignierter DLLs die Grundlage, auch wenn DLL-Regeln Pflege kosten.
• Benutzer aus Programmverzeichnissen heraushalten. Wo Anwender nicht in Program Files und daneben schreiben dürfen, kann niemand eine DLL neben eine installierte Anwendung legen. Das schließt den häufigsten Side-Loading-Pfad.
• Sicheren DLL-Suchmodus erzwingen. Der sichere Suchmodus und das Vorziehen der Systemverzeichnisse (SafeDllSearchMode, KnownDLLs) verhindern, dass eine gleichnamige DLL aus dem Arbeitsverzeichnis das Original überholt.
• Portable und anfällige Software aussortieren. Bekannt für Side-Loading anfällige Anwendungen gehören inventarisiert und, wo möglich, durch gehärtete Versionen ersetzt oder aus Benutzerverzeichnissen verbannt.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon und eingeschaltetem Event 7:

• Für Regel 1 eine harmlose, unsignierte Test-DLL in ein Benutzerverzeichnis legen und von einem Testprogramm laden lassen. Sysmon Event 7 muss den unsignierten Ladevorgang zeigen und die Regel auslösen.
• Für Regel 2 mit einem normalen Programm, das kein Installer ist, eine harmlose .dll nach Program Files schreiben (im Lab mit Adminrechten). Sysmon Event 11 muss den Schreibvorgang zeigen.
• Für Regel 3 eine signierte Testbinärdatei zusammen mit einer harmlosen DLL in einen Ordner im Benutzerprofil legen und starten. Event 7 muss zeigen, dass Prozess und DLL aus demselben Pfad kommen. Vollständiger wird der Test mit den Fällen zu T1574 aus Atomic Red Team.

Fehlalarme und Tuning

• Event 7 ist laut. Das Laden von Bibliotheken ist ein Massenereignis. Ohne gezielte Sysmon-Konfiguration erzeugt Regel 1 zu viel. Filtere Event 7 bereits in der Sysmon-Konfiguration auf unsignierte Module und beschreibbare Pfade, statt alles zu protokollieren.
• Portable und Entwickler-Software. Portable Anwendungen, Installer im Temp-Ordner und Entwicklungswerkzeuge laden legitim unsignierte DLLs aus dem Benutzerprofil. Nimm die bekannten Pfade und Werkzeuge als Ausnahme auf und behalte den Rest scharf.
• Signatur auswerten. Reichere die Treffer mit dem Signaturstatus und dem Herausgeber aus Sysmon Event 7 an. Eine unsignierte DLL wiegt deutlich schwerer als eine signierte aus derselben Quelle.
• Priorität. Ein Treffer von Regel 3 gehört zu den hochprioren Alarmen, weil Binärdatei und DLL im selben Benutzerordner nur selten einen legitimen Grund haben.

Fazit

DLL-Hijacking versteckt den Schadcode im vertrauenswürdigen Prozess, aber nicht die DLL: Signatur, Pfad und die Nähe von Binärdatei und Bibliothek ergeben zusammen ein klares Muster. Wer Sysmon Event 7 gezielt konfiguriert, Benutzer aus den Programmverzeichnissen heraushält und Anwendungssteuerung mit DLL-Regeln betreibt, nimmt dieser Technik den größten Teil ihrer Wirkung. Weitere Wege, auf denen sich ein Angreifer den Zugang sichert, stehen unter Persistenz erkennen; weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik.