Initial Access Simuliert: Makros, LNK und ISO im Isolierten Windows-11-Lab

Initial Access ist der Punkt, an dem die meisten echten Einbrueche beginnen, und die Phase, die Verteidiger am schlechtesten verstehen, weil sie sie selten gefahrlos beobachten koennen. Die Antwort ist ein vollstaendig isoliertes Labor, in dem du die Zustelltechniken nachspielst, die Angreifer wirklich nutzen, Makros, LNK-Verknuepfungen und ISO-Container, gegen eine instrumentierte Windows-11-Maschine, die dir gehoert, damit du die Telemetrie jeder Technik siehst und die Detektionen schreibst, die sie fangen. Dieser Leitfaden des Basilisk-Teams ist defensiv angelegt: jeder Payload hier ist ein harmloser Ausfuehrungsbeweis (er startet calc oder schreibt eine Markierungsdatei) und alles laeuft air-gapped. Es geht nicht darum, Malware zu bauen, sondern die Zustellkette gut genug zu verstehen, um sie zu brechen. Der Denkfehler, den wir am haeufigsten sehen, ist, Zustellung mit dem eigentlichen Schadcode zu verwechseln: der Payload ist austauschbar, der interessante Teil ist der Moment, in dem ein Benutzer eine Datei oeffnet und Code startet. Genau dieser Uebergang erzeugt die Telemetrie, die du fangen willst, und genau er laesst sich mit einem harmlosen Marker exakt so studieren wie mit echter Malware, nur ohne jedes Risiko.

Warum Initial Access ueberhaupt simulieren

Du kannst keine gute Detektion fuer eine Technik schreiben, die du nie hast ausloesen sehen. Hersteller liefern generische Regeln, aber deine Umgebung hat ihre eigene Baseline normaler Office-Aktivitaet, ihr eigenes EDR, ihre eigenen Logging-Luecken. Das Nachspielen der Technik im Labor beantwortet die einzigen Fragen, die zaehlen: welchen Prozessbaum sie erzeugt, welche Kommandozeile, welche Dateischreibvorgaenge, welchen Netzwerk-Callback und welche davon deine Sensoren tatsaechlich aufzeichnen. Das ist Standard-Red-Team- und Purple-Team-Praxis, es bildet direkt MITRE-ATT&CK-Techniken unter Initial Access (T1566 Phishing) und Execution (T1204 User Execution) ab und ist der schnellste Weg, eine vage Angst in eine konkrete, testbare Regel zu verwandeln.

Das isolierte Windows-11-Labor bauen

Stelle eine Windows-11-VM in VirtualBox oder Hyper-V mit einem einzigen Host-Only-Adapter und ohne Internetroute auf; Zustellsimulationen duerfen nie einen echten Command-and-Control-Host erreichen. Installiere Sysmon mit gut abgestimmter Konfiguration (die Base-Configs von SwiftOnSecurity oder Olaf Hartong sind der Standard-Startpunkt), aktiviere PowerShell-Script-Block- und Module-Logging per Gruppenrichtlinie und schalte Windows Defender in den Audit-Modus, damit du siehst, was er blockiert haette, ohne deine Telemetrie zu stoeren. Snapshotte den sauberen Zustand vor jedem Lauf. Eine zweite kleine Linux-VM im selben Host-Only-Netz dient als gefaelschter Payload-Host und als Sysmon-zu-Sigma-Sammelpunkt, sodass nichts das Labor verlaesst.

Vektor eins: VBA-Makros

Das klassische Office-Dokument-Makro lehrt am meisten. Baue ein Dokument, dessen Document_Open- oder Workbook_Open-Handler schlicht calc.exe startet oder %TEMP%\marker.txt schreibt. Das Interessante ist nicht das Makro, sondern die Telemetrie: Sysmon Event ID 1 zeigt winword.exe, das einen Kindprozess erzeugt, das zuverlaessigste Makro-Ausfuehrungssignal, denn Office, das cmd, powershell oder wscript startet, ist fast nie legitim. Da Microsoft Makros in Dateien mit Internetzonen-Markierung inzwischen standardmaessig blockiert, beachte, wie das Mark-of-the-Web auf der heruntergeladenen Datei das Verhalten aendert, was genau der Grund ist, warum Angreifer auf Container umgestiegen sind, weiter unten behandelt.

Vektor zwei: LNK-Verknuepfungsdateien

Eine Windows-Verknuepfung kann ein beliebiges Ziel und Argumente tragen und dabei ein unschuldiges Icon zeigen, was sie zum beliebten modernen Zustell-Wrapper macht. Erstelle im Labor eine .lnk, deren Ziel powershell.exe mit einem harmlosen Argument ist, das deine Markierungsdatei schreibt, und beobachte den Prozessbaum: explorer.exe, das powershell.exe mit verdaechtiger Kommandozeile startet, ist der Detektionsanker. Beachte die Felder, die eine bewaffnete Verknuepfung von einer normalen unterscheiden, eine ueberlange Kommandozeile, ein Ziel, das nicht zum Icon passt, Argumente mit kodierten oder download-aehnlichen Strings, und notiere, welche davon deine Sysmon-Konfiguration erfasst, damit du eine Sigma-Regel um die zuverlaessigen herum baust.

Vektor drei: ISO- und IMG-Container

Angreifer sind zu ISO-, IMG- und VHD-Containern gewechselt, gerade weil das Mounten und Ausfuehren einer Datei darin das Mark-of-the-Web historisch nicht an den Inhalt weitergab und so die Makro- und SmartScreen-Schutzmechanismen umging. Verpacke im Labor eine harmlose LNK oder ein Skript in einer ISO, mounte sie und beobachte, wie die Ausfuehrung von einem gemounteten Volume-Laufwerksbuchstaben statt aus dem Downloads-Ordner ausgeht. Die Detektionen sind hier container-bewusst: ein Prozess, der von einer frisch gemounteten ISO startet, oder ein explorer.exe-Kind, das von einem Sekunden zuvor erschienenen Laufwerk stammt, sind starke Signale. Neuere Windows-Builds propagieren das Mark-of-the-Web in Container, also teste auch das gepatchte Verhalten und stelle sicher, dass deine Abwehr beides annimmt.

Detection Engineering mit Sysmon und Sigma

Verwandle jedes beobachtete Verhalten in eine Regel. Die wertvollsten Detektionen aus diesen drei Vektoren sind: Office-Anwendungen (winword, excel, powerpnt), die eine Shell oder einen Skript-Host starten; explorer.exe, das powershell/wscript mit kodierter oder download-artiger Kommandozeile startet; und Prozessausfuehrung, deren Image-Pfad ein Wechseldatentraeger oder gemountetes Container-Volume ist. Schreibe diese als Sigma-Regeln gegen Sysmon Event ID 1, deploye sie in dein SIEM und wiederhole die Simulationen, um zu bestaetigen, dass jede ausloest und eine niedrige False-Positive-Rate gegen deine Normalaktivitaets-Baseline erzeugt. Eine Detektion, die du im Labor nicht ausgeloest hast, ist eine Hypothese, keine Kontrolle.

Mitigation: die Zustellkette schliessen

Detektion ist die halbe Arbeit; die andere Haelfte ist, die Technik scheitern zu lassen. Aktiviere Microsofts Attack-Surface-Reduction-Regeln, besonders das Blockieren aller Office-Anwendungen beim Erzeugen von Kindprozessen und das Blockieren ausfuehrbaren Inhalts aus E-Mail und Webmail, was den Makro-Vektor direkt neutralisiert. Halte Makros aus Internetzonen-Dateien per Richtlinie blockiert und nutze das neuere Windows-Verhalten, das Mark-of-the-Web in gemountete Container propagiert. Beschraenke oder logge .lnk- und Skript-Host-Ausfuehrung, setze Application Control (WDAC oder AppLocker) ein, damit unsignierte Skripte und Binaries aus benutzerschreibbaren Pfaden nicht laufen, und bestaetige jede Mitigation im Labor, indem du die passende Simulation erneut faehrst und sie blockiert siehst.

Haeufige Fallstricke in einem Zustell-Labor

Die wiederkehrenden Fehler: der Windows-VM irgendeinen echten Netzwerkpfad geben, sodass ein vertippter Payload tatsaechlich nach draussen greifen koennte; mit voll aktiviertem Defender testen, sodass er das Sample blockiert, bevor du seine Telemetrie studieren kannst (nutze stattdessen den Audit-Modus); das Snapshotten vergessen und die instrumentierte Baseline verlieren; und aus einem einzigen Lauf Schluesse ziehen, statt zu bestaetigen, dass die Detektion ueber Reboots und Benutzerkontexte zuverlaessig ausloest. Die subtilste Falle ist, nur das ungepatchte Verhalten zu testen: ist dein Windows-Build alt, siehst du Mark-of-the-Web-Luecken, die moderne Endpunkte nicht mehr haben, und deine Regeln sind auf ein ueberholtes Bedrohungsmodell abgestimmt.

Labor-Checkliste

Bevor du die Uebung als erledigt bezeichnest, verifiziere: die Windows-11-VM ist Host-Only ohne Internetroute; Sysmon, Script-Block-Logging und Defender-Audit-Modus sind an; ein sauberer Snapshot existiert; alle drei Vektoren (Makro, LNK, ISO) wurden gefahren und ihre Prozessbaeume erfasst; mindestens drei Sigma-Regeln sind geschrieben, deployt und als ausloesend bestaetigt; ASR-Regeln und Application Control sind aktiviert und jede Mitigation durch einen blockierten Wiederholungslauf verifiziert; und jeder verwendete Payload war harmlos. Produzierte ein Vektor keine Telemetrie, ist deine Instrumentierung der Befund, behebe ihn, bevor du weitergehst.

FAQ: Ist das Ausfuehren dieser Simulationen legal und sicher?

Ja, wenn es vollstaendig in einem Labor stattfindet, das dir gehoert, mit harmlosen Payloads und ohne echtes Command-and-Control. Die Techniken sind in MITRE ATT&CK dokumentiert und werden taeglich von Verteidigungsteams genutzt. Die Grenze wird ueberschritten, wenn du irgendetwas davon an eine Person oder ein System zustellst, das du nicht testen darfst, oder einen Live-Payload nutzt, der nach Hause telefoniert. Halte es air-gapped, halte die Payloads harmlos und halte schriftlichen Scope, falls du das je in ein genehmigtes Engagement gegen eine echte Umgebung ueberfuehrst.

FAQ: Brauche ich ein echtes EDR, um das zu lernen?

Nein. Sysmon plus PowerShell-Logging plus Defender im Audit-Modus liefert dir die Kern-Telemetrie kostenlos, und Sigma-Regeln uebersetzen sich spaeter in die meisten SIEMs und EDRs. Ein kommerzielles EDR ergaenzt reichere Prozess-Lineage- und Memory-Signale, was sich lohnt, sobald du die Grundlagen verstehst, aber der Start mit dem kostenlosen Stack zwingt dich, genau zu verstehen, welches Event welches Verhalten beweist, und dieses Verstaendnis uebertraegt sich auf jedes Werkzeug.

Es als Purple-Team-Uebung fahren

Das Labor erreicht seinen vollen Wert, wenn du es nicht mehr als Einzelpraxis behandelst, sondern als Purple-Team-Uebung faehrst, bei der jemand Angreifer und jemand Verteidiger gegen dieselbe Telemetrie spielt. Bilde jeden der drei Vektoren auf seine MITRE-ATT&CK-Technik ab, damit beide Seiten eine Sprache sprechen: T1566.001 fuer den makrotragenden Anhang, T1204.002 fuer den Benutzer, der eine schaedliche Datei doppelklickt, und T1027 fuer die Verschleierung, die der Container hinzufuegt. Der Angreifer faehrt einen Vektor ohne Vorwarnung; der Verteidiger arbeitet nur aus dem SIEM und versucht zu rekonstruieren, was passiert ist, dann vergleichen beide ihre Notizen mit der von dir erfassten Grundwahrheit. Diese Uebung legt die Luecken offen, die keine Checkliste findet: ein Alert, der ausloeste, aber den niemand triagierte, ein Prozessbaum-Feld, das dein Dashboard verbirgt, eine Detektion, die auf dem harmlosen Test ausloest, aber im grossen Massstab in False Positives ertraenke. Verfolge jede Luecke als Ticket mit Verantwortlichem, faehre nach dem Fix erneut, und du hast eine messbare Feedbackschleife statt einer einmaligen Demo. Ueber ein paar Zyklen bewegt sich ein Team so vom Reagieren auf Alerts hin zum echten Verstaendnis seiner eigenen Angriffsflaeche, was der ganze Sinn des Simulierens von Initial Access ist.

Praktisches Take-away: baue das isolierte Windows-11-Labor, fahre Makro-, LNK- und ISO-Zustellung mit harmlosen Payloads, erfasse die Prozessbaeume und verwandle jeden in eine Sigma-Detektion, die du als tatsaechlich ausloesend bestaetigst. Aktiviere dann ASR und Application Control und beweise, dass jeder Vektor blockiert ist. Mach das quartalsweise, waehrend sich die Plattform aendert, denn Mark-of-the-Web-Propagierung und Standard-Makroblockierung verschieben staendig den Boden. Simulierter Initial Access geht nicht um bessere Koeder, sondern darum, deine Zustellkette so gut zu kennen, dass keine echte ungesehen an deinen Sensoren vorbeikommt.