AMSI- und ETW-Bypass fuer Defensive Forschung: Was Blue Teams Wissen Sollten

Ein Operator wirft Invoke-Mimikatz ohne jede Obfuskation in eine PowerShell 5.1 und es passiert nichts. Defender schreit nicht, das SOC bekommt keinen Alert, und das Ticket bleibt still, waehrend der lsass-Speicher laengst gelesen wurde. Das ist keine Magie: das ist ein Einzeiler-Patch in amsi.dll, der AmsiScanBuffer mit zwei Instruktionen nullt. Im Jahr 2026 sind AMSI und ETW immer noch das Skelett der Windows-Telemetrie und werden immer noch von vierzeiligen Skripten neutralisiert, die seit 2016 auf GitHub kursieren. Dieser Text zerlegt Schicht fuer Schicht, warum diese Bypasses weiter funktionieren, wie man sie im Labor sauber reproduziert und was auf der blauen Seite tatsaechlich etwas bewegt, ohne dass man den naechsten teuren EDR kaufen muss.

Was AMSI wirklich ist und warum es im Prozess des Opfers lebt

AMSI (Antimalware Scan Interface) ist eine Bruecke, keine Mauer. PowerShell, VBScript, JScript, WMI und sogar Office-Makros rufen AmsiScanBuffer auf, um den registrierten Antivirus zu fragen, ob der gerade im Speicher liegende Inhalt boesartig ist. Das entscheidende Detail: dieser Aufruf laeuft im Zielprozess selbst, mit dessen Rechten und in dessen Adressraum. Wenn der Angreifer bereits Code innerhalb von powershell.exe ausfuehrt, sitzt er auf derselben Seite des Vertrauensgrabens wie die Pruefroutine. Er kann in den .text-Bereich von amsi.dll schreiben, das Prolog von AmsiScanBuffer durch mov eax, 0x80070057; ret ersetzen (E_INVALIDARG, was als "sauber" interpretiert wird) und das Licht ausschalten. Matt Graeber veroeffentlichte die klassische Reflection-Variante 2016, und seitdem tauchen Abwandlungen mit Hardware-Breakpoints, AmsiOpenSession-Patching und amsiContext-Korruption unermuedlich auf.

Der Grund fuer die Langlebigkeit ist strukturell, nicht nachlaessig. Solange die Instrumentierung im User-Mode und im selben Prozess liegt, ist sie per Definition manipulierbar durch jeden, der in diesem Prozess Code ausfuehrt. Wer mit EDR-Umgehung fur Forschung: Direct Syscalls Erklart ohne Romantik arbeitet, kennt das Muster: User-Mode-Instrumentation ist immer Soft Power. Microsoft haertet die Oberflaeche (z. B. Signaturen fuer bekannte Patch-Bytes, AMSI in PowerShell 7 mit strengerer Integritaet), aber das Grundprinzip bleibt: der Verteidiger stellt seinen Sensor in das Wohnzimmer des Angreifers.

ETW als tiefere Schicht mit derselben Achillesferse

ETW (Event Tracing for Windows) liegt tiefer im System, teilt aber die Schwaeche. Provider wie Microsoft-Windows-Threat-Intelligence emittieren Events zu NtAllocateVirtualMemory, lsass-Handle-Oeffnungen und Remote-Thread-Injection und speisen damit praktisch jeden kommerziellen EDR. Der kanonische Bypass patcht EtwEventWrite in ntdll.dll mit einem simplen xor eax,eax; ret, und das war's: der Provider bleibt registriert, aber nichts verlaesst den Prozess. Moderne Varianten greifen EtwpEventWriteFull an, entfernen den Provider aus TRACE_ENABLE_INFO oder senken die Trace-Level pro Thread. Da diese Bypasses lokal und leise sind, wird Hunting auf Basis fehlender erwarteter Events wertvoller als signaturbasiertes Hunting.

Wer bereits ein Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel aufbaut, weiss, dass Regeln fuer "abnormale Stille" muehsam zu tunen sind, aber genau das fangen, was positive Regeln nicht erwischen. Der Kernwert von ETW-TI liegt darin, dass es im Kernel entsteht; der Bypass findet aber im User-Mode statt, bevor das Event den Prozess verlaesst. Verlagert man das Sammeln naeher an den Kernel oder off-host, verliert der User-Mode-Patch seine Wirkung.

Der klassische AMSI-Patch Schritt fuer Schritt

Konzeptuell laeuft der Reflection-Bypass so: man beschafft ueber [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') das Feld amsiInitFailed und setzt es auf true — PowerShell ueberspringt dann den Scan. Der robustere Speicher-Patch loest die Adresse von AmsiScanBuffer via GetProcAddress(LoadLibrary("amsi.dll"), "AmsiScanBuffer") auf, ruft VirtualProtect mit PAGE_EXECUTE_READWRITE, schreibt die Rueckgabe-Stub-Bytes und stellt den Schutz wieder her. Die Hardware-Breakpoint-Variante ist eleganter: sie beruehrt .text nicht, sondern setzt via SetThreadContext Debug-Register (Dr0-Dr7) auf AmsiScanBuffer und faelscht im Exception-Handler den Rueckgabewert. Weil sie keinen Code veraendert, gleitet sie an schwachen Integritaets-Checks vorbei, die nur auf gepatchte Bytes achten.

Wichtig fuer die defensive Analyse: der Reflection-Patch hinterlaesst eine sehr charakteristische Spur in PowerShell ScriptBlockLogging (Event ID 4104), weil der String AmsiUtils und amsiInitFailed geloggt wird, bevor AMSI selbst deaktiviert ist. Der Speicher-Patch dagegen ist ueber NtProtectVirtualMemory auf amsi.dll sichtbar. Jede Technik tauscht Tarnung gegen Komplexitaet, und keine ist unsichtbar, wenn man an der richtigen Stelle schaut.

Lab-Aufbau, um zu sehen, was Blue wirklich mitbekommt

Aus ethisch-offensiver Sicht ist das Reproduzieren dieser Bypasses im Labor Pflicht, wenn man verstehen will, was das Blue Team wirklich sieht. Minimales Setup: Windows 11 23H2 mit aktivem Defender, Sysmon 15 mit Olaf Hartongs Config, und Elastic Agent, der an einen Testcluster sendet. Fuehre den klassischen reflection-basierten AMSI-Patch aus, danach die Hardware-Breakpoint-Variante, und vergleiche, was Defender und Sysmon jeweils protokollieren. Haeufige Ueberraschung: PowerShell Event ID 4104 erfasst den boesartigen Script-Block weiterhin, weil ScriptBlockLogging unabhaengig von AMSI arbeitet. Solche Uebungen passen sehr gut in einen Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus und lehren mehr als jedes Whitepaper.

Isolation ist Teil der Uebung: kein Domaenen-Join des Labors mit Produktion, kein Internet-Egress, der die getesteten Payloads exfiltrieren koennte, und Snapshots vor jedem Lauf, damit die Baseline reproduzierbar bleibt. Miss immer zuerst den "Null-Zustand" (was wird ohne Bypass geloggt?), dann den Bypass-Zustand. Die Differenz ist deine Detektionschance.

Echte Haertung: was den Angreifer wirklich Geld kostet

Echte Haertung beginnt mit der Akzeptanz, dass User-Mode-Bypass billig ist. Aktiviere PowerShell Constrained Language Mode via WDAC fuer Standardnutzer, schalte ScriptBlockLogging und Module Logging mit Weiterleitung raus aus der Maschine ein (lokale Logs loescht der Angreifer), und erzwinge PowerShell 7+ mit verifizierter AMSI-Integration. Aktiviere Protected Process Light fuer Defender, schalte LSA Protection (RunAsPPL) ein und ziehe Credential Guard in Betracht, um die Kosten fuer jeden zu erhoehen, der bis lsass kommt. Auf ETW-Ebene aendert es das Spiel, die Erkennung vom Host wegzuziehen: Sysmon plus WEF auf einen dedizierten Collector, und wo moeglich Kernel-Callbacks ueber den eigenen Treiber des EDR, den der Angreifer nur per BYOVD plattmacht.

Wer bereits Windows 11 Hardening fuer Hochrisiko Arbeitsplaetze umsetzt, hat einen Grossteil des Wegs hinter sich. Die Priorisierung ist wichtig: WDAC/Constrained Language Mode und weitergeleitetes ScriptBlockLogging bringen mehr pro investierter Stunde als eine weitere EDR-Lizenz. Das Ziel ist nicht, den Bypass unmoeglich zu machen (das geht im selben Prozess nicht), sondern ihn teuer, laut und nachvollziehbar zu machen.

Erkennung: konkrete Muster und IOCs

Bypass-Erkennung hat klare, billig umsetzbare Muster. Suche nach NtProtectVirtualMemory, das Permissions an amsi.dll oder ntdll.dll in Prozessen aendert, die keine Installer sind (Sysmon Event ID 10 plus Filter auf das Zielimage). Achte auf PowerShell, das System.Management.Automation.AmsiUtils per Reflection laedt (Event 4104 mit "amsiInitFailed" ist quasi ein wortwoertlicher IOC). Beobachte die Divergenz zwischen erwarteten ETW-TI-Events und dem, was pro Host im SIEM ankommt: wenn ein Endpunkt ploetzlich 70 Prozent weniger Events emittiert ohne Lastaenderung, hat etwas EtwEventWrite gepatcht.

Diese Per-Host-Baseline-Logik verbindet sich mit Hunting von Living-off-the-Land-Binaries unter Windows mit KQL und mit Windows-Persistenz: 10 Dokumentierte Techniken und ihre Gegenmassnahmen, wo Stille ebenfalls ein Signal ist. Ergaenze verhaltensbasierte Regeln: ein PowerShell-Prozess, der amsi.dll laedt und kurz darauf einen RWX-Bereich alloziert, ist verdaechtiger als jeder einzelne Indikator fuer sich.

Haeufige Fehler auf beiden Seiten

Auf der blauen Seite ist der haeufigste Fehler, AMSI 4104 zu vertrauen, ohne die Weiterleitung abzusichern: wenn der Angreifer lokale Logs loeschen kann, ist dein IOC weg. Ein zweiter Fehler ist, nur nach Byte-Signaturen des klassischen Patches zu suchen und die Hardware-Breakpoint-Variante komplett zu verpassen. Auf der offensiven (Lab-)Seite ist der haeufigste Fehler, Bypasses auf Produktions-Assets zu testen oder PoCs ohne defensiven Kontext zu veroeffentlichen. Ein dritter, oft uebersehener Punkt: viele nehmen an, ein AMSI-Bypass deaktiviere auch ETW — das stimmt nicht, es sind getrennte Mechanismen und muessen getrennt umgangen und getrennt detektiert werden.

Checkliste fuer Blue Teams

Kurz und umsetzbar: (1) ScriptBlockLogging und Module Logging aktivieren und per WEF off-host weiterleiten. (2) Constrained Language Mode via WDAC fuer Standardnutzer erzwingen. (3) RunAsPPL und Credential Guard aktivieren. (4) Sysmon 15 mit kuratierter Config plus Event ID 10 auf amsi.dll/ntdll.dll. (5) Pro-Endpoint-Baseline des ETW-TI-Event-Volumens und Alarm bei Einbruch. (6) 4104-Suche nach "amsiInitFailed"/"AmsiUtils". (7) Detektionsregeln mit der Sigma-Regel dokumentieren, nicht mit dem Mimikatz-Screenshot. (8) Alle Kontrollen im Purple-Team-Zyklus gegen echte Bypasses validieren, nicht nur auf dem Papier.

FAQ: Reicht ein moderner EDR gegen AMSI/ETW-Bypass?

Nein, nicht allein. Ein guter EDR erschwert und detektiert Bypasses ueber Kernel-Callbacks und Verhaltensanalyse, aber sobald der Angreifer im Prozess ist, kann er User-Mode-Sensoren manipulieren, und mit BYOVD auch Kernel-Komponenten angreifen. Der Mehrwert liegt in Defense-in-Depth: EDR plus weitergeleitetes ScriptBlockLogging plus WDAC plus off-host-Telemetrie. Kein einzelnes Produkt schliesst die Luecke, weil die Luecke architektonisch und nicht produktbezogen ist.

FAQ: Ist es legal, diese Bypasses zu erforschen und zu veroeffentlichen?

Das Reproduzieren im eigenen, isolierten Labor ist legitime Verteidigungsforschung. Veroeffentlichen erfordert ethische Sorgfalt. Ein AMSI/ETW-Bypass ist kein Zero-Day, aber eine PoC ohne defensiven Fokus zu veroeffentlichen, hilft vor allem denen, die keine Hilfe brauchen. Gesunder Standard: im isolierten Lab reproduzieren, den defensiven IOC vor dem Exploit dokumentieren, und beim Publizieren mit der Sigma-Regel fuehren. Wenn deine Arbeit Kunden beruehrt, fixiere den Scope schriftlich; wenn sie deine eigene Infra beruehrt, praktiziere OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell.

Fazit

Praktischer Takeaway: gehe davon aus, dass AMSI und ETW auf dem kompromittierten Host umgangen werden, und investiere in weitergeleitetes ScriptBlockLogging, eine kuratierte Sysmon-Config und ein Event-Volumen-Baseline pro Endpoint. Diese drei Kontrollen alleine fangen die meisten oeffentlich bekannten Bypasses aus 2025-2026, ohne dass ein bestimmter Vendor noetig waere. Der rote Faden ist immer derselbe: der Verteidiger, der davon ausgeht, dass sein Host-Sensor manipuliert werden kann, und die Erkennung deshalb off-host und verhaltensbasiert aufstellt, gewinnt gegen einen Bypass, der auf die Bequemlichkeit des Verteidigers setzt.