Drive-by Compromise erkennen: Angriff beim Besuch einer Webseite

Kurzfassung: Beim Drive-by-Compromise reicht der Besuch einer präparierten Webseite - der Code läuft im Browser, ohne dass das Opfer etwas anklickt oder bewusst installiert. Für den Verteidiger wird der Angriff dort sichtbar, wo der Browser aus seiner Rolle fällt: Er startet eine Shell, einen Skript-Interpreter oder einen signierten Helfer, oder er legt eine ausführbare Datei ab. Drei sigma-cli-validierte Sigma-Regeln, dazu Härtung und der Test im Lab. Serie "Angriff erkennen".

Die meisten Erstzugänge brauchen eine Handlung des Opfers: einen Klick, ein geöffnetes Dokument, eingegebene Zugangsdaten. Der Drive-by-Compromise kommt mit weniger aus. Es genügt, eine Webseite aufzurufen, die mit Schadcode präpariert ist - sei es die Seite selbst, eine eingebundene Werbung oder ein kompromittiertes Skript von Drittanbietern. Während der Angriff auf eine öffentlich erreichbare Anwendung den Server ins Visier nimmt und die externen Fernzugänge legitime Zugänge missbrauchen, trifft dieser Weg den Client beim ganz normalen Surfen. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Einordnung in ATT&CK: Drive-by Compromise (T1189). MITRE führt die Technik in der Taktik Initial Access; in dieser Serie steht sie entsprechend in der Spalte Initial Access. Sie beschreibt den Erstzugang über eine präparierte Webseite, die der Nutzer schlicht besucht - abzugrenzen vom gezielten Phishing, das zu einem Klick verleiten muss.

Was der Angreifer tut

Ein Drive-by-Compromise läuft - auf der Ebene des Prinzips, nicht als Anleitung - in wenigen Mustern ab:

  • Eine Webseite präparieren. Der Angreifer platziert Schadcode auf einer Seite, in einer eingebundenen Anzeige oder in einem Skript, das viele Seiten nachladen.
  • Den Browser treffen. Beim Besuch wird der Code im Browser ausgeführt, oft über eine Schwachstelle in der Engine oder einem Plugin, teils auch nur durch Täuschung des Nutzers.
  • Aus dem Browser ausbrechen. Der Code startet einen weiteren Prozess - eine Shell, einen Skript-Interpreter oder einen signierten Helfer - um außerhalb des Browsers weiterzuarbeiten.
  • Die Nutzlast ablegen. Häufig schreibt der Browser dabei eine ausführbare oder Skriptdatei auf die Platte, die anschließend gestartet wird.

Für die Erkennung ist entscheidend: Der Angriff verlässt irgendwann den Browser. Genau dieser Übergang - Browser startet einen Prozess oder legt eine Datei ab - ist der Punkt, an dem die Regeln ansetzen.

Welche Logquellen die Technik zeigt

  • Prozess-Telemetrie zuerst. Event 4688 und Sysmon Event 1 zeigen die Eltern-Kind-Beziehung: ein Browser als Elternprozess einer Shell, eines Interpreters oder eines LOLBins. Die wichtigste Quelle.
  • Dateiereignisse. Sysmon Event 11 (FileCreate) zeigt, wenn ein Browser eine ausführbare oder Skriptdatei schreibt - das Ablegen der Nutzlast vor der Ausführung.
  • Netzwerk und Proxy. Proxy- und DNS-Logs zeigen den Abruf der präparierten Seite und das Nachladen weiterer Komponenten; sie liefern den Kontext zum Endpunkt-Signal.
  • Werkzeug-Kontext. Die missbrauchten Helfer mshta, rundll32 und regsvr32 sind mitgelieferte Windows-Programme; Grundlagen dazu unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist ein Browser, der einen Kommandozeilen- oder Skript-Interpreter startet - cmd, PowerShell, wscript oder cscript als Kindprozess eines Browsers gibt es im Alltag praktisch nicht. Das zweite ist ein Browser, der einen signierten Helfer wie mshta, rundll32 oder regsvr32 aufruft, um Code getarnt auszuführen. Das dritte ist ein Browser, der eine ausführbare oder Skriptdatei schreibt. Legitime Treffer stammen aus Browser-Updates, Erweiterungen und einzelnen Web-Integrationen. Auffällig wird es, wenn der gestartete Prozess ein Interpreter ist, der Zielpfad im Benutzer- oder Temp-Bereich liegt oder kurz darauf weiterer Code startet. Der Blick auf Eltern, Kind und Zielpfad trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: den Browser, der einen Interpreter startet, den Browser, der einen signierten LOLBin aufruft, und den Browser, der eine ausführbare Datei ablegt. Die ersten beiden werten die Prozess-Telemetrie aus, die dritte die Dateiereignisse.

1. Browser startet Kommandozeilen- oder Skript-Interpreter (T1189). Ein Browser als Elternprozess von cmd, PowerShell, wscript oder cscript. Die Regel steht auf level: high.

Sigma
title: Browser startet Kommandozeilen- oder Skript-Interpreter
id: a1d4f8b2-6c37-4e59-9b02-7f3a1c6d8e40
status: experimental
description: |
  Erkennt, dass ein Webbrowser direkt einen Kommandozeilen- oder Skript-Interpreter startet - cmd.exe,
  powershell.exe, pwsh.exe, wscript.exe oder cscript.exe. Nach einem Drive-by-Compromise fuehrt der im
  Browser ausgeloeste Code haeufig ueber einen solchen Kindprozess weiter. Ein Browser, der einen
  Interpreter startet, ist im Normalbetrieb sehr ungewoehnlich.
references:
  - https://attack.mitre.org/techniques/T1189/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1189
logsource:
  product: windows
  category: process_creation
detection:
  sel_browser:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\iexplore.exe'
      - '\brave.exe'
      - '\opera.exe'
  sel_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: sel_browser and sel_child
falsepositives:
  - Einzelne Web-Apps oder Erweiterungen starten Hilfsprozesse - bekannte Faelle nach Browser und Kommandozeile als Baseline ausnehmen
level: high

2. Browser startet signierten LOLBin zur Ausführung (T1189). Ein Browser als Elternprozess von mshta, rundll32 oder regsvr32. Ebenfalls level: high.

Sigma
title: Browser startet signierten LOLBin zur Ausfuehrung
id: b7e2c9a4-1f58-4d63-8c07-3a9d2e6b5f14
status: experimental
description: |
  Erkennt, dass ein Webbrowser einen signierten, oft missbrauchten Windows-Helfer startet - mshta.exe,
  rundll32.exe oder regsvr32.exe. Nach einem Drive-by-Compromise wird heruntergeladener Code gern ueber
  einen solchen LOLBin ausgefuehrt, um als vertrauenswuerdig zu erscheinen. Ein Browser als Elternprozess
  dieser Helfer ist ein starkes Signal.
references:
  - https://attack.mitre.org/techniques/T1189/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1189
logsource:
  product: windows
  category: process_creation
detection:
  sel_browser:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\iexplore.exe'
      - '\brave.exe'
      - '\opera.exe'
  sel_lolbin:
    Image|endswith:
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: sel_browser and sel_lolbin
falsepositives:
  - Einzelne Web-Integrationen rufen rundll32 auf - bekannte Faelle nach Browser und Kommandozeile als Baseline ausnehmen
level: high

3. Browser legt ausführbare oder Skriptdatei ab (T1189). Ein Browser schreibt eine Datei mit der Endung .exe, .dll, .scr, .hta, .js oder .vbs. Die Regel steht auf level: medium, weil auch legitime Downloads vorkommen.

Sigma
title: Browser legt ausfuehrbare oder Skriptdatei ab
id: c3f9a1d7-5b26-4e84-9a13-6d2c8b7e4f05
status: experimental
description: |
  Erkennt, dass ein Webbrowser eine ausfuehrbare oder Skriptdatei schreibt - .exe, .dll, .scr, .hta,
  .js oder .vbs. Nach einem Drive-by-Compromise legt der Browser die Nutzlast auf der Platte ab, bevor
  sie ausgefuehrt wird. Ein regulaerer Download endet meist in einem Archiv oder Dokument; eine direkt
  abgelegte ausfuehrbare Datei aus dem Browser ist auffaellig.
references:
  - https://attack.mitre.org/techniques/T1189/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1189
logsource:
  product: windows
  category: file_event
detection:
  sel_browser:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\iexplore.exe'
      - '\brave.exe'
      - '\opera.exe'
  sel_file:
    TargetFilename|endswith:
      - '.exe'
      - '.dll'
      - '.scr'
      - '.hta'
      - '.js'
      - '.vbs'
  condition: sel_browser and sel_file
falsepositives:
  - Browser-Updates und Erweiterungen schreiben eigene Dateien - bekannte Pfade und Herausgeber als Baseline ausnehmen
level: medium

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

  • Browser und Plugins aktuell halten. Die meisten Drive-by-Angriffe nutzen bekannte Schwachstellen in Browser-Engine oder Plugins; zeitnahes Patchen entzieht ihnen die Grundlage. Die wirksamste Maßnahme gegen diesen Weg.
  • Angriffsfläche verkleinern. Veraltete Plugins entfernen, Skripte und aktive Inhalte einschränken und Werbung filtern, da eingebundene Anzeigen ein häufiger Träger sind.
  • Anwendungssteuerung. Mit AppLocker oder WDAC verhindern, dass ein Browser einen Interpreter startet oder eine abgelegte Datei ausgeführt wird.
  • Gezielt überwachen. Browser als Elternprozess von Interpretern und LOLBins sowie vom Browser geschriebene ausführbare Dateien als feste Erkennungen führen.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon - ganz ohne echten Exploit, allein durch Nachstellen der Prozesskette:

  • Für Regel 1 aus einem umbenannten oder testweise als Browser gestarteten Prozess einen Interpreter aufrufen und prüfen, dass Event 4688 die Eltern-Kind-Beziehung zeigt.
  • Für Regel 2 denselben Aufbau mit mshta, rundll32 oder regsvr32 als Kindprozess nachstellen und den Treffer in der Prozess-Telemetrie kontrollieren.
  • Für Regel 3 mit einem Browser-ähnlichen Prozess eine harmlose Datei mit der Endung .exe oder .js in den Downloads-Ordner schreiben und prüfen, dass Sysmon Event 11 erscheint.
  • Breiter wird der Test mit den Fällen zu T1189 aus Atomic Red Team.

Fehlalarme und Tuning

  • Browser-Updates und Erweiterungen. Browser schreiben und starten im Rahmen von Updates eigene Komponenten. Bekannte Pfade, Herausgeber und Hilfsprozesse als Baseline ausnehmen, bevor die Regeln scharf geschaltet werden.
  • Web-Integrationen. Einzelne Unternehmensanwendungen starten über den Browser Hilfsprozesse oder laden Dateien. Diese bekannten Fälle nach Browser und Kommandozeile ausnehmen.
  • Zielpfad ist entscheidend. Eine abgelegte Datei im Downloads-Ordner wiegt leichter als eine ausführbare Datei in einem Temp-Pfad, die sofort gestartet wird - danach priorisieren.
  • Kette schlägt Einzelzeile. Der Browser, der einen Interpreter startet, der kurz darauf eine Datei nachlädt, ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

Der Drive-by-Compromise braucht keinen Klick: Der bloße Besuch einer präparierten Seite reicht, und der Code läuft im Browser. Erkennbar wird er an dem Moment, in dem der Angriff den Browser verlässt - wenn dieser einen Interpreter oder signierten Helfer startet oder eine ausführbare Datei ablegt. Die wirksamste Härtung ist ein aktueller Browser mit kleiner Angriffsfläche, flankiert von Anwendungssteuerung. Wie der Angriff den Server statt den Client trifft, zeigt der Angriff auf eine öffentlich erreichbare Anwendung; wie die nachgeladene Nutzlast über ein Dokument zündet, die schädliche Datei mit Office-Makro. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Initial Access.

NH

$ whoami

Norbert Hofmann

Cyber Defense Analyst im Security Operations Center eines Managed Security Service Providers. Red und Blue Teaming, Malware-Analyse, Incident Response und Security-Awareness-Trainings. Finalist bei „Deutschlands bester Hacker“ 2022, mehrere CVE-Einträge für WordPress-Plugins.