AMSI-Umgehung erkennen: wenn der Scanner blind wird

Mit diesem Beitrag beginnt der Defense-Impairment-Teil der Welle: Techniken, die nicht Rechte ausweiten, sondern die Abwehr selbst abschalten oder blenden. AMSI - das Antimalware Scan Interface - ist dabei das erste Ziel. Es ist die Brücke zwischen Skript-Hosts wie PowerShell oder dem Windows Script Host und dem installierten Virenschutz. Erst wenn sie steht, sieht der Scanner, was ein Skript im Speicher wirklich tut. Genau deshalb versuchen Angreifer, sie zu kappen, bevor der eigentliche Code läuft. Der Beitrag bleibt auf der Verteidigerseite und bleibt konzeptionell.

Was der Angreifer tut

AMSI lässt sich auf mehreren Wegen aushebeln. Auf der Ebene des Prinzips, nicht als Anleitung, sind das vor allem drei:

• Speicher-Patch im eigenen Prozess. Die verbreitetste Variante überschreibt im laufenden Prozess die Funktion AmsiScanBuffer so, dass sie für jeden Inhalt ein sauberes Ergebnis zurückmeldet. AMSI prüft danach zwar weiter, bekommt aber nie ein Urteil zustande.
• Reflection auf interne Felder. Über PowerShell-Reflection wird ein internes AMSI-Feld wie amsiInitFailed gesetzt, sodass die Initialisierung als gescheitert gilt und die Prüfung übersprungen wird.
• Provider oder DLL manipulieren. Wird der AMSI-Provider in der Registry entfernt oder eine präparierte amsi.dll neben die Anwendung gelegt, meldet sich kein echter Scanner mehr. Das wirkt dauerhafter als ein reiner Speicher-Patch.

Allen gemein ist das Ziel: Der Schadcode soll laufen, bevor oder ohne dass AMSI ihn an den Virenschutz weiterreicht. Für die Erkennung ist das günstig, denn jeder dieser Wege berührt eine gut beobachtbare Stelle.

Welche Logquellen die Technik zeigt

• PowerShell Script Block Logging. Event-ID 4104 zeigt den entschlüsselten Skriptinhalt - und damit die typischen Bezeichner eines AMSI-Bypasses, selbst wenn der Code obfuskiert ankommt. Die Grundlage dafür legt PowerShell für Verteidiger.
• Registry-Telemetrie. Sysmon Event 13 zeigt Schreib- und Löschzugriffe auf die AMSI-Provider-Schlüssel unter HKLM\SOFTWARE\Microsoft\AMSI.
• Geladene Module. Sysmon Event 7 (Image Loaded) zeigt, aus welchem Pfad amsi.dll geladen wird - der Hebel für den DLL-Hijack. Dafür muss Sysmon das Laden von Modulen erfassen, siehe Sysmon einrichten.
• Der Virenschutz selbst. Defender protokolliert, wenn AMSI nicht sauber initialisiert - ein Nebeneffekt, der sich mit den übrigen Quellen korrelieren lässt.

Das Muster im Log

Das klarste Signal liefert das Script Block Logging: Bezeichner wie AmsiScanBuffer oder amsiInitFailed tauchen in regulären Verwaltungsskripten praktisch nie auf. Wer sie im Event 4104 sieht, hat mit hoher Wahrscheinlichkeit einen Umgehungsversuch vor sich. Das Entfernen eines AMSI-Providers in der Registry und das Laden von amsi.dll aus einem Nutzerverzeichnis sind seltener, aber mindestens so aussagekräftig - beides hat außerhalb einer AV-Installation kaum einen legitimen Grund. Weil ein erfolgreicher Bypass den Rest der Kette unsichtbar macht, ist ein Treffer hier besonders wertvoll: Er ist oft das letzte laute Ereignis, bevor es leise wird.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste nutzt die verräterischen Bezeichner im Skript, die zweite die Registry-Manipulation, die dritte den DLL-Hijack. Die erste ist in der Praxis die ergiebigste, weil PowerShell-basierte Bypasses am häufigsten vorkommen.

1. AMSI-Bypass-Muster im Script Block (T1685). Bekannte Bezeichner im entschlüsselten Skript. Die Regel steht auf level: high.

title: AMSI-Bypass-Muster im PowerShell Script Block
id: 2f9c1e07-5a4b-4c2e-9d61-7b8e4a1c3f22
status: experimental
description: |
  Erkennt bekannte Zeichenketten aus PowerShell-basierten AMSI-Bypasses im Script
  Block Logging (Event-ID 4104). Angreifer greifen ueber Reflection auf interne
  AMSI-Felder zu oder patchen AmsiScanBuffer, um die Pruefung auszuhebeln. Solche
  Bezeichner tauchen in legitimen Skripten praktisch nie auf.
references:
  - https://attack.mitre.org/techniques/T1685/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685
logsource:
  product: windows
  category: ps_script
detection:
  selection:
    ScriptBlockText|contains:
      - 'System.Management.Automation.AmsiUtils'
      - 'amsiInitFailed'
      - 'AmsiScanBuffer'
      - 'amsiContext'
      - 'amsiSession'
  condition: selection
falsepositives:
  - Sicherheitsforschung und Awareness-Demos auf dafuer vorgesehenen Testsystemen
level: high

2. Manipulation der AMSI-Provider-Registrierung (T1685). Schreib- oder Löschzugriffe auf die Provider-Schlüssel. Ebenfalls level: high.

title: Manipulation der AMSI-Provider-Registrierung
id: 8b3d6a19-0f27-4e5a-bc48-2a1f9d7c6e03
status: experimental
description: |
  Erkennt Schreib- oder Loeschzugriffe auf die AMSI-Provider-Schluessel. Wird der
  Provider-Eintrag entfernt oder auf eine fremde CLSID umgebogen, meldet sich bei
  jedem Scan kein Anbieter mehr und AMSI laeuft ins Leere. Aenderungen an diesem
  Schluessel sind ausserhalb von AV-Installationen sehr selten.
references:
  - https://attack.mitre.org/techniques/T1685/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685
logsource:
  product: windows
  category: registry_event
detection:
  selection:
    TargetObject|contains: '\SOFTWARE\Microsoft\AMSI\Providers'
  condition: selection
falsepositives:
  - Installation oder Update einer Antiviren-Loesung, die eigene AMSI-Provider registriert
level: high

3. amsi.dll aus ungewöhnlichem Pfad (T1685). Das Laden der DLL außerhalb der Systemordner deutet auf einen Hijack. level: medium, weil portable Anwendungen gelegentlich eigene Kopien mitbringen.

title: amsi.dll aus ungewoehnlichem Pfad geladen
id: c7e2f480-9a16-4b3d-8f05-6d4b1e2a7c59
status: experimental
description: |
  Erkennt das Laden von amsi.dll aus einem Verzeichnis ausserhalb der Windows-
  Systemordner. Beim DLL-Hijack legt ein Angreifer eine praeparierte amsi.dll neben
  die eigene Anwendung, damit statt der echten Bibliothek eine entschaerfte Variante
  geladen wird. Regulaer kommt amsi.dll nur aus System32 oder SysWOW64.
references:
  - https://attack.mitre.org/techniques/T1685/
author: blue-team.net
tags:
  - attack.defense-impairment
  - attack.t1685
logsource:
  product: windows
  category: image_load
detection:
  selection:
    ImageLoaded|endswith: '\amsi.dll'
  filter_system:
    ImageLoaded|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
  condition: selection and not filter_system
falsepositives:
  - Portable Anwendungen, die eine eigene amsi.dll mitbringen; bekannte Faelle je Pfad ausnehmen
level: medium

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

• PowerShell einschnüren. Script Block Logging erzwingen und den Constrained Language Mode einsetzen, wo es geht - er nimmt vielen Reflection-basierten Bypasses die Grundlage. Details in PowerShell für Verteidiger.
• Veraltete Hosts entfernen. PowerShell 2.0 kennt weder AMSI noch Script Block Logging. Die Engine deinstallieren, damit kein Downgrade auf die blinde Version möglich ist.
• Provider-Schlüssel schützen. Schreibzugriffe auf die AMSI-Registry überwachen und auf Administratoren beschränken, damit kein Dienst den Scanner lautlos abmeldet.
• Anwendungssteuerung. Mit WDAC oder AppLocker nur signierte Module zulassen - das erschwert den DLL-Hijack über eine untergeschobene amsi.dll erheblich.

Der Test

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

• Für Regel 1 ein harmloses Skript ausführen, das einen der bekannten Bezeichner enthält, ohne tatsächlich etwas abzuschalten. Event 4104 muss den Inhalt zeigen und die Regel auslösen.
• Für Regel 2 im Testsystem einen Wert unter dem AMSI-Provider-Schlüssel setzen oder löschen. Sysmon Event 13 muss den Zugriff protokollieren.
• Für Regel 3 eine beliebige, als amsi.dll benannte Datei aus einem Nutzerverzeichnis laden lassen. Sysmon Event 7 muss den abweichenden Pfad zeigen. Breiter wird der Test mit den passenden Fällen aus Atomic Red Team.

Fehlalarme und Tuning

• AV-Installationen. Antiviren-Produkte registrieren beim Einrichten eigene AMSI-Provider. Diese Wartungsfenster erzeugen in Regel 2 legitime Treffer - nach Host und Zeitpunkt ausnehmen.
• Sicherheitsforschung. Die Bezeichner aus Regel 1 tauchen in Schulungs- und Demo-Material auf. Übungssysteme und -fenster dokumentieren und filtern.
• Portable Software. Einzelne Anwendungen bringen eine eigene amsi.dll mit. Für Regel 3 die bekannten Pfade als Baseline aufnehmen, statt die Regel zu entschärfen.
• Korrelation schlägt Einzelregel. Ein AMSI-Bypass kommt selten allein. Wer den Treffer mit nachfolgender PowerShell-Aktivität verknüpft, trennt Umgehungsversuch und echten Angriff zuverlässiger.

Fazit

AMSI auszuhebeln ist für Angreifer der Türöffner zum dateilosen Arbeiten - aber kein leiser. Die PowerShell-Bezeichner im Script Block, die Griffe in die AMSI-Registry und das Laden einer fremden amsi.dll sind allesamt gut beobachtbare Stellen. Die wirksamste Härtung kombiniert erzwungenes Script Block Logging, Constrained Language Mode und das Entfernen von PowerShell 2.0. Als Nächstes folgt die ETW-Manipulation, die an einer tieferen Telemetriequelle ansetzt. Verwandt sind die EDR-Umgehung und die Event-Log-Löschung; auch der offizielle Weg, Defender abzuschalten zeigt, was ein SOC dabei im Log sieht. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Defense Impairment.