Die frühere MITRE-Taktik Defense Evasion ist mit ATT&CK v19 (2026) in zwei Taktiken aufgeteilt: Stealth (TA0005) - sich verbergen und wie normales Verhalten aussehen - und Defense Impairment (TA0112) - Schutzmechanismen aktiv schwächen. Dieser Hub erklärt den Split und konzentriert sich auf Stealth: Obfuscation, Masquerading, Living off the Land und das Entfernen von Spuren, dazu die Mechanik der Beobachtungsflächen (AMSI, ETW, Hooking) und vor allem, wie ein Red Teamer über Tarnung entscheidet. Die aktive Schwester-Taktik behandelt der eigene Hub Defense Impairment. Funktionsfähige Bypässe liefert er bewusst nicht - der Fokus liegt auf Entscheidung, Mechanik und Footprint.
Defense Evasion heute: der v19-Split in Stealth und Defense Impairment
Mit ATT&CK v19 hat MITRE die lange sehr breite Taktik Defense Evasion getrennt. Der Grund: Sich zu verbergen und Schutz aktiv zu sabotieren sind unterschiedliche Ziele mit unterschiedlichem Footprint. Seitdem gilt:
| Taktik | ID | Ziel | Beispiele |
|---|---|---|---|
| Stealth | TA0005 | Verbergen und tarnen, wie normales Verhalten aussehen | Obfuscation, Masquerading, LOLBins, Indicator Removal |
| Defense Impairment | TA0112 | Sicherheitsmechanismen, Pipelines und Werkzeuge aktiv schwächen | Impair Defenses, Logging deaktivieren, AMSI-/ETW-Manipulation, EDR-Unhooking |
Die URL dieses Hubs bleibt aus Bestands- und SEO-Gründen /defense-evasion/, inhaltlich deckt er aber beide neuen Taktiken ab. Ein eigener, vertiefter Defense-Impairment-Hub ist sinnvoll und kann folgen.
Das operative Ziel
Aus Operator-Sicht hat Evasion nie einen Selbstzweck. Sie dient genau zwei Zielen: unentdeckt bleiben (Stealth) oder dem Verteidiger die Sicht nehmen (Defense Impairment). Jede Evasion kostet aber etwas - Zeit, Komplexität und oft einen eigenen, neuen Footprint. Deshalb ist die erste Frage eines erfahrenen Red Teamers nicht "wie umgehe ich die Kontrolle", sondern "muss ich sie hier überhaupt umgehen".
Wie ein Red Teamer Evasion plant
Evasion ist eine Entscheidung, keine Reflexhandlung. Der folgende Denkprozess läuft vor fast jeder potenziell auffälligen Aktion ab:
Die wichtigste Einsicht aus diesem Prozess: Die leiseste Aktion ist oft die, die am wenigsten vom erwarteten Normalverhalten abweicht - nicht die mit der meisten Verschleierung.
Beispielszenario: Codeausführung auf einer Windows-Workstation
Ein Operator hat auf einer Standard-Workstation Codeausführung erreicht und will eine zweite Stufe nachladen. Die Umgebung hat Defender mit aktiviertem Script Block Logging und ein EDR mit Userland-Hooks. Vier Wege stehen zur Wahl, jeder mit anderem Footprint:
| Weg | Vorteil | Footprint / Risiko |
|---|---|---|
| PowerShell Download Cradle | Schnell, dateilos | Script Block Logging (4104) sieht den deobfuskierten Code; powershell.exe mit Netzwerkverbindung ist ein klassischer Alarm |
| Eigenes Binary ablegen | Umgeht Skript-Logging | Neue, unsignierte Datei mit schlechter Reputation - AV und EDR schlagen hier oft an |
| LOLBin zum Nachladen | Keine neue Datei, signierter Prozess | Die bekannten LOLBin-Muster sind gut überwacht |
| Vorhandenes Admin-Tool nutzen | Geht am ehesten im Normalverhalten unter | Erfordert Aufklärung, was in dieser Umgebung "normal" ist |
Die naheliegende Reaktion - "PowerShell nehmen und einen AMSI-Patch davorsetzen" - ist oft die schlechteste. Der Patch löst das Logging-Problem, erzeugt aber ein neues, auffälliges Artefakt: einen Schreibzugriff eines Prozesses auf seinen eigenen Code. Der erfahrene Operator fragt stattdessen, ob er PowerShell überhaupt braucht, oder ob ein ohnehin genutztes Werkzeug die zweite Stufe unauffälliger holt. Evasion ist hier eine Abwägung, kein Automatismus.
Evasion Decision Matrix
Dasselbe Prinzip, verdichtet. Die naive Lösung greift fast immer zu mehr Verschleierung; die bessere Operator-Frage prüft zuerst, ob das nötig ist.
| Ausgangslage | Naive Lösung | Bessere Operator-Frage |
|---|---|---|
| Skript wird vom AV erkannt | Payload stärker verschleiern | Brauche ich das Skript überhaupt, oder reicht ein Bordmittel ohne Signatur-Trigger? |
| Script Block Logging ist aktiv | AMSI und Logging patchen | Ist der Patch nicht auffälliger als der geloggte Befehl? Geht es ganz ohne PowerShell? |
| EDR hookt ntdll | Unhooking oder Direct Syscalls einbauen | Ist diese Aktion überhaupt hook-relevant, oder erzeuge ich das Signal erst durch das Unhooking? |
| Neue Datei löst Reputation-Alarm | Datei packen oder verschlüsseln | Muss überhaupt etwas auf die Platte, oder geht es dateilos über vorhandene Werkzeuge? |
Was moderne Abwehr sieht: AMSI, ETW und Hooking
Um diese Entscheidungen treffen zu können, muss man die Beobachtungsflächen kennen. Vier tragen den Großteil der Windows-seitigen Erkennung - wie stark ein konkretes EDR-Produkt auf welche davon setzt, unterscheidet sich jedoch erheblich. Pauschale Aussagen über "das EDR" führen in die Irre:
| Beobachtungsfläche | Was sie liefert | Warum Angreifer sie ins Visier nehmen |
|---|---|---|
| AMSI | Übergibt Skript- und .NET-Inhalte zur Laufzeit an die registrierte Schutzlösung, nach dem Entschlüsseln oder Dekodieren | Weil AMSI auch verschleierten Code zur Ausführungszeit sieht, zielt Evasion darauf, diese Prüfung im eigenen Prozess zu neutralisieren (Defense Impairment) |
| ETW | Windows-weites Tracing, aus dem viele EDR und Defender einen großen Teil ihrer Telemetrie ziehen | Wer ETW im eigenen Prozess stört, erzeugt blinde Flecken in der Telemetriekette |
| Userland-Hooking | Viele EDR-Produkte setzen Hooks in Systemmodulen wie ntdll.dll im Benutzerprozess; wie stark, variiert je Produkt | Das erklärt, warum es Klassen wie Unhooking und Direct Syscalls gibt: Sie umgehen die beobachtende Schicht |
| Kernel-Callbacks | Der Kernel meldet Prozess-, Thread- und Image-Load-Ereignisse über Callback-Routinen an registrierte Treiber | Diese Ebene ist aus dem User-Mode schwer zu manipulieren und bei vielen Produkten ein wichtiger Telemetrie-Anker - ein Grund, warum rein nutzerseitige Evasion selten vollständig blind macht |
Welche Flächen eine Umgebung tatsächlich auswertet, ist die eigentliche Aufklärungsaufgabe. Ein Logging, das aktiv ist, aber nie ausgewertet wird, ist operativ etwas anderes als eine scharfe, alarmierende Erkennung.
Stealth-Techniken (TA0005)
Stealth zielt darauf, nicht aufzufallen - ohne Schutzmechanismen aktiv anzugreifen. Die vier wichtigsten Kategorien:
Obfuscation (T1027)
Verschleierung umgeht statische Signaturen: kodierte Kommandozeilen, verpackte Payloads, zur Laufzeit zusammengesetzte Strings, bei .NET das Nachladen von Assemblies im Speicher. Wann sinnvoll: gegen signaturbasierte Erkennung. Grenze: AMSI sieht den Code nach dem Entschleiern, Verhaltenserkennung bleibt unberührt.
Script Block Logging protokolliert den deobfuskierten Code, hohe Entropie und ungewöhnlich lange base64-Strings fallen auf. Footprint also hoch, sobald Verhaltens- statt reiner Signaturerkennung läuft. Die Erkennungslogik steht auf blue-team.net.
Masquerading (T1036)
Tarnung lässt Schadcode harmlos aussehen: ein svchost.exe-Name aus dem falschen Verzeichnis, doppelte Dateiendungen, gefälschte Icons. Wann sinnvoll: gegen oberflächliche, namensbasierte Prüfung. Grenze: der Abgleich von Name, Pfad und Signatur entlarvt sie.
Ein Systemprozessname aus falschem Pfad, fehlende Signatur und eine untypische Eltern-Kind-Beziehung sind der Widerspruch, den Sysmon über Image, OriginalFileName und Hashes sichtbar macht. Details auf blue-team.net.
Living off the Land und LOLBins (T1218)
Signierte, vorinstallierte Windows-Programme werden zweckentfremdet - sie sind legitim und damit unverdächtig. Wann sinnvoll: um keine eigene, verdächtige Datei einzubringen. Grenze: die bekannten Missbrauchsmuster sind gut dokumentiert (LOLBAS) und überwacht.
| Binary | Legitimer Zweck | Auffälliges Muster |
|---|---|---|
| rundll32.exe | DLL-Funktionen aufrufen | Aufruf mit netzwerkbezogenen oder ungewöhnlichen Argumenten |
| regsvr32.exe | COM-Komponenten registrieren | Laden entfernter Scriptlets |
| mshta.exe | HTA-Anwendungen ausführen | Ausführung entfernter HTA oder Skripte |
| certutil.exe | Zertifikate verwalten | Herunterladen oder Dekodieren von Dateien |
Entscheidend ist der Kontext: Kommandozeile, Elternprozess und Netzwerkaktivität. certutil, das lädt, oder regsvr32, das ein entferntes Scriptlet aufruft, sind klassische Alarme. LOLBAS katalogisiert die Muster, die Regeln dazu stehen auf blue-team.net.
Indicator Removal (T1070)
Spuren beseitigen: Ereignisprotokolle leeren, Dateien löschen, Zeitstempel manipulieren (Timestomping). Wann sinnvoll: nach einer Aktion, deren Spuren lokal liegen. Grenze: zentrale Log-Weiterleitung macht lokales Löschen wirkungslos, und das Löschen selbst ist ein Alarm.
Das Leeren des Sicherheitsprotokolls erzeugt Event ID 1102 - eines der höchstpriorisierten Signale überhaupt. Gegen Timestomping hilft der Vergleich der Zeitstempel im Dateisystem, und weitergeleitete Logs liegen längst auf dem SIEM. Mehr auf blue-team.net.
Defense Impairment (TA0112) - die aktive Schwester-Taktik
Mit dem v19-Split ist das aktive Schwächen von Schutzmechanismen - ein EDR stoppen, Logging abschalten, AMSI oder ETW im Prozess neutralisieren - eine eigene Taktik: Defense Impairment (TA0112). Sie verfolgt das gegenteilige Prinzip von Stealth: Statt sich zu verbergen, greift sie in die Kontrolle selbst ein und erzeugt damit einen ganz anderen, meist lauteren Footprint. Mechanik, Technikklassen, Voraussetzungen und die Operator-Entscheidung dazu stehen im eigenen Hub Defense Impairment.
Einordnung und Grenze
Dieser Hub ist der konzeptionellste der Sammlung - und das mit Absicht. Funktionsfähige AMSI- und ETW-Umgehungen, EDR-Unhooking, Process-Injection-Bausteine oder einsatzbereite Log-Cleaner liefern Angreifern direkten Mehrwert und tragen nichts zum Verständnis bei, das dieses Portal vermitteln will. Wer sie für legitime Forschung oder autorisierte Tests braucht, findet sie bei MITRE, im Unprotect Project und in Konferenzbeiträgen. Hier stehen die Entscheidung, die Mechanik und der Footprint im Vordergrund.
Verschleierung und das Schwächen von Schutzmaßnahmen gehören ausschließlich in autorisierte Tests mit wirksamer Erlaubnis des Berechtigten. Der Einsatz gegen fremde Systeme ohne Berechtigung kann abhängig vom Einzelfall strafrechtlich relevant sein. Dieser Beitrag dient der Information und der Absicherung legitimer Sicherheitsarbeit und ist keine Rechtsberatung.
Einordnung in die Angriffskette
Stealth und Defense Impairment sind keine einzelnen Schritte, sondern begleiten fast alle anderen: von Execution über Persistence und Credential Access bis zur Kommunikation über Command & Control. Einen Überblick über alle Taktiken gibt die Payload-Sammlung.
Häufige Fragen
Warum heißt die Taktik jetzt Stealth statt Defense Evasion?
Mit ATT&CK v19 (2026) hat MITRE die sehr breite Defense-Evasion-Taktik geteilt: TA0005 Stealth für das Verbergen und Tarnen, TA0112 Defense Impairment für das aktive Schwächen von Schutzmechanismen. Die Trennung macht den unterschiedlichen Zweck und Footprint sichtbar. Die URL dieses Hubs bleibt aus Bestandsgründen /defense-evasion/.
Macht Evasion einen Angreifer wirklich unsichtbar?
Nein. Nutzerseitige Evasion kann AMSI, ETW und Userland-Hooks im eigenen Prozess schwächen, aber kernelnahe Callbacks und die Netzwerksicht bleiben bei vielen Produkten. Verteidigung, die sich nicht auf eine Fläche verlässt, sieht die Aktivität trotzdem.
Ist maximaler Stealth immer das Ziel?
Nein. Das Ziel ist, die Operation zu erreichen, ohne vorzeitig entdeckt zu werden - nicht, jede denkbare Spur zu tilgen. Zusätzliche Evasion kostet Zeit und erzeugt eigenen Footprint. Oft ist die Aktion mit der geringsten Abweichung vom Normalverhalten die bessere Wahl.