Windows 11 Hardening fuer Hochrisiko Arbeitsplaetze

Eine kompromittierte Pentester-Workstation ist ein regulatorischer Albtraum: Kunden-SSH-Schluessel, abgefangene Credentials, signierte Payloads und Berichte unter NDA teilen sich dieselbe Platte. Bei Basilisk OffSec behandeln wir jedes Windows-11-Laptop bis zum Beweis des Gegenteils als feindlichen Endpunkt und haerten es so, als wuerde der Operator in derselben Woche gephisht, ueberfallen und auditiert. Diese Notiz dokumentiert das Baseline, das wir seit Maerz 2026 auf 47 Maschinen produktiv fahren: ASR-Regeln im Block-Modus, Credential Guard mit verstaerktem VBS, AppLocker fuer den User-Mode-Perimeter und WDAC fuer den Kernel. Die Konfiguration ist kein Vergnuegen, hat aber die Angriffsflaeche, die wir in AMSI- und ETW-Bypass fuer Defensive Forschung: Was Blue Teams Wissen Sollten kartiert haben, messbar reduziert. Diese erweiterte Fassung geht die gesamte Kette Schicht fuer Schicht durch, mit exakten Einstellungen, Zielkonflikten und der Reihenfolge, die verhindert, dass Sie die eigene Flotte lahmlegen.

Das Bedrohungsmodell: warum das Operator-Laptop das Kronjuwel ist

Bevor Sie ein einziges Group Policy Object anfassen, schreiben Sie auf, gegen wen Sie verteidigen. Ein Offensive-Security-Laptop ist kein normaler Firmenendpunkt: Es haelt entschluesselte Kundengeheimnisse, C2-Profile und Berichte, die beschreiben, wie man in andere Firmen einbricht. Die realistischen Gegner sind drei: ein Phishing-Operator, der ein Makro oder ein bosartiges LNK landet, ein Dieb, der das Geraet am Flughafen greift, und ein entschlossener Angreifer, der gezielt die Kundendaten will. Jeder verlangt eine andere Kontrolle. Phishing beantwortet Ausfuehrungskontrolle (ASR, AppLocker, WDAC); Diebstahl beantwortet Pre-Boot-Verschluesselung und TPM-Bindung; gezielte Kompromittierung beantwortet Credential-Isolation und Telemetrie. Das Modell zu ueberspringen und einfach alles zu aktivieren ist der Weg, auf dem Teams Caldera-Labore zerlegen und dann frustriert die ganze Policy abschalten. Kartieren Sie die Assets, priorisieren Sie sie, und lassen Sie diese Rangfolge entscheiden, welchen Schalter Sie zuerst umlegen.

Hardware-Fundament: TPM, Secure Boot, DMA und Firmware

Jede Softwarekontrolle darunter ruht auf vertrauenswuerdiger Hardware, also beginnen wir dort. Wir verlangen aktives TPM 2.0, Secure Boot mit eigenen eingespielten Schluesseln, aktivierten Kernel-DMA-Schutz und Firmware mit Intel Boot Guard oder AMD Platform Secure Boot je nach Hersteller. Ohne diesen Vertrauensanker ist jede Policy Theater: ein DMA-Angriff ueber Thunderbolt oder ein manipulierter Bootloader haengt alles in Minuten aus. Standard-Laptop ist ein ThinkPad P14s Gen 5 oder ein Surface Laptop 7. Wir deaktivieren Legacy-CSM, sperren die Firmware mit Supervisor-Passwort und schalten Boot von USB und Netzwerk fuer die allgemeine Flotte ab. In der Firmware deaktivieren wir zudem ungenutzte Funkmodule und den Fingerabdruckleser, wenn das Modell PIN-only-Pre-Boot verlangt. Wer denselben Betriebsstandard auf Server anwenden will, findet Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen mit identischer Philosophie.

Full-Disk-Verschluesselung: BitLocker mit Pre-Boot-PIN

BitLocker ist nicht verhandelbar und muss an TPM plus Pre-Boot-PIN gebunden sein, nicht nur an TPM. TPM-only entsperrt die Platte automatisch beim Boot, das heisst ein gestohlenes ausgeschaltetes Laptop ist einen Cold-Boot- oder DMA-Trick von Klartext entfernt. Wir erzwingen XTS-AES 256, verlangen eine numerische PIN von mindestens acht Stellen (ueber die Policy zur zusaetzlichen Authentifizierung beim Start) und legen den 48-stelligen Recovery-Key in einem offline Team-Tresor ab, niemals im Microsoft-Konto und nie im fuer den Helpdesk lesbaren Active Directory. Wir aktivieren BitLocker auch fuer feste und Wechseldatentraeger, sodass die Reports-Partition und jede USB-Scratch-Disk abgedeckt sind. Schutz-Suspendierung fuer beilaeufige Firmware-Updates ist deaktiviert; jede Entsperrung wird geloggt. Ergebnis: ein verlorenes Geraet ist ein Hardwareverlust, keine Meldepflicht.

Credential Guard, VBS, Secure Launch und HVCI

Die erste Softwareschicht ist virtualisierungsbasierte Sicherheit. Ueber Group Policy machen wir Device Guard, Virtualization Based Security, Secure Launch und HVCI (Hypervisor-Enforced Code Integrity) zur Pflicht. Credential Guard verschiebt NTLM-Hashes und Kerberos-Tickets in einen VTL1-isolierten Prozess, den das normale OS nicht lesen kann, sodass ein Fuss in der User-Session nicht einfach Domaenen-Credentials aus dem Speicher schaben kann. HVCI erzwingt, dass nur signierter, verifizierter Code im Kernel laeuft, und schliesst die Tuer fuer unsignierte Rootkits und viele BYOVD-Ketten. Secure Launch nutzt den CPU-DRTM, um nach der Firmware Vertrauen neu aufzubauen, und verkleinert das Early-Boot-Fenster. Es gibt einen realen Preis: HVCI blockiert einige alte Treiber und kostet ein paar Prozent Overhead bei schweren Builds, gemessen an unserer Sliver-Custom-Build-Pipeline. Dieser Preis kauft eine Operator-Session, die weit weniger leckt, wenn sie unvermeidlich angestochen wird.

LSASS-Schutz: RunAsPPL und Zugriffsaudit

Auch mit Credential Guard bleibt LSASS ein Ziel fuer Handle-basiertes Dumping, also fahren wir es als Protected Process Light. Wir setzen RunAsPPL=1 in HKLM\SYSTEM\CurrentControlSet\Control\Lsa (UEFI-gesperrte Variante, wo unterstuetzt) und aktivieren das LSASS-Zugriffsaudit. In internen Tests hat das gewoehnliches mimikatz, comsvcs.dll-MiniDump-Missbrauch und mehrere Handle-Duplication-Tricks gebrochen, ganz ohne EDR, und die LSA-Protection blockierte jeden Injection-Versuch, den wir aus Windows-Persistenz: 10 Dokumentierte Techniken und ihre Gegenmassnahmen reproduziert haben. Die ergaenzende Kontrolle ist eine Detektionsregel auf Prozess-Handle-Zugriff auf lsass.exe mit gewuenschter Zugriffsmaske 0x1010 oder 0x1410, dem verraeterischen Zeichen eines Dump-Versuchs. Kosten: etwa vier Prozent CPU-Overhead bei schweren Rust-Builds, gemessen an unserer Sliver-Custom-Build-Pipeline. Das ist ein guenstiger Preis fuer den meistmissbrauchten Credential-Theft-Pfad unter Windows.

Attack-Surface-Reduction-Regeln im Block-Modus

ASR folgt als naechstes und genau hier verlieren die meisten Teams die Nerven. Wir aktivieren alle sechzehn Regeln im Block, nicht im Audit. Ja, das bricht Office-Child-Prozesse, obfuskierte Skriptausfuehrung, WMI-erzeugte Prozesse und nicht vertrauenswuerdige USB-Executables. Wir halten eine separate OU namens "OffSec-Tools", in der einige Regeln im Audit bleiben fuer die Laborkiste des Forschers, der Caldera braucht, wie in Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab beschrieben. Fuer den Rest der Flotte hat allein die Regel D4F940AB-401B-4EFC-AADC-AD5F3C50688A (Office-Child-Prozesse blockieren) 73 Prozent der Initial-Access-Vektoren aus Initial Access Simuliert: Makros, LNK und ISO im Isolierten Windows-11-Lab eliminiert. Kombinieren Sie sie mit dem Blockieren von Credential-Diebstahl aus LSASS, ausfuehrbarem Inhalt aus E-Mail und Win32-API-Aufrufen aus Office-Makros fuer den hoechsten Ertrag pro Regel.

AppLocker fuer den User-Mode-Perimeter

AppLocker und WDAC leben in verschiedenen Schichten und Sie wollen beide. AppLocker steuert den User-Mode mit Publisher- und Pfad-Allowlists und eignet sich ideal, das verdaechtige ZIP zu stoppen, das ein Nutzer gerade in Downloads abgelegt hat, oder ein Skript unter einem Nutzerprofil. Wir verweigern standardmaessig Ausfuehrung aus schreibbaren Orten (Downloads, Temp, AppData) und erlauben nur signierte Binaries plus einen kuratierten Tools-Pfad unter einem admin-eigenen Verzeichnis. Regeln decken EXE, DLL, MSI, Script und Packaged Apps ab; DLL-Regeln sind trotz ihrer Kosten aktiv, weil DLL-Side-Loading eine beliebte Loader-Technik ist. AppLocker laeuft ueber den Application-Identity-Dienst und wird zuerst auditiert: zwei Wochen "Nur Audit", die 8003- und 8004-Events geerntet, dann auf Enforce. Fuer sich allein keine harte Grenze, aber als aeusseres Sieb vor WDAC entfernt es eine riesige Klasse nutzergestarteten Muells.

WDAC fuer Kernel- und Treiberschicht

WDAC (Windows Defender Application Control) ist die eigentliche Code-Integritaetsgrenze und umfasst Kernel und Treiber ueber eine signierte Policy, gebunden an unser EV-Zertifikat, mit den im Januar 2026 importierten Microsoft Recommended Driver Block Rules. Die Basis-Policy generieren wir mit New-CIPolicy, fahren sie 30 Tage im Audit, sammeln Event-IDs 3076 und 3077, verfeinern und gehen erst dann in Enforce. Der Ertrag: verwundbare Treiber aus loldrivers.io, inklusive jener aus den Evasion-Routinen in EDR-Umgehung fuer Forschung: Direct Syscalls Erklaert ohne Romantik, laden schlicht nicht mehr. Nur Binaries, signiert von Microsoft, vom OEM (Lenovo, Microsoft Surface) oder passend zu unseren internen Hashes, laufen. Wir deployen die Policy als signierte, UEFI-gesperrte Datei, sodass ein Angreifer mit Admin sie nicht heimlich tauschen kann, und alarmieren auf jedes Policy-Aenderungs-Event als hochsignifikantes Signal.

Microsoft Defender als letzte Schicht und seine Telemetrie

Defender kommt zuletzt mit aktiver Tamper Protection, Cloud Block Level hoch, PUA auf Block, aktivem Network Protection und Controlled Folder Access ueber Dokumente, Desktop und das Reports-Verzeichnis. Der Punkt ist nicht, dass Defender alles faengt; es ist, dass jede Schicht darueber das Feld bereits verengt hat, sodass Defender jetzt ein hochsignifikanter Sensor statt eines lauten Torwaechters ist. Wir leiten die Events in die Sigma-plus-Elastic-Pipeline aus Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel, mit Fokus auf WDAC-Policy-Aenderungen, Service-Anlage via sc.exe, Scheduled-Task-Persistenz und LSASS-Handle-Zugriffe mit Maske 0x1010. In 90 Tagen auf 47 Workstations hatten wir null bestaetigte Kompromittierungen und zwolf hochsignifikante Alerts, zwei davon echte Drive-By-Versuche waehrend Bug-Bounty-Engagements. Telemetrie ohne Review-Rota ist Deko, also hat jede Alert-Klasse einen benannten Owner und ein Runbook.

Rollout-Methodik und Governance der Ausnahmen

Der groesste Fehlermodus ist, alle Schalter auf einmal umzulegen, jemanden mitten im Engagement lahmzulegen und die ganze Policy bis zum Mittag im Zorn deaktiviert zu bekommen. Tun Sie das nicht. Fahren Sie 30 Tage Audit, schicken Sie die Logs in ein SIEM, tunen Sie die minimal noetigen Ausnahmen und gehen Sie erst dann auf Block. Jede Ausnahme bekommt ein Jira-Ticket, einen benannten Owner und ein quartalsweises Review-Datum, denn Hardening, das niemand pflegt, verrottet in sechs Monaten, wenn neue Tools und Treiberversionen kommen. Versionieren Sie die Policies als Code in einem Git-Repo, signieren Sie sie in der CI und deployen ueber Intune oder Ihr Config-Management, sodass das Baseline reproduzierbar und diffbar ist. Behandeln Sie die OffSec-Tools-OU als dokumentierte, ueberwachte Ausnahme, nicht als dauerhafte Hintertuer, und baselinen Sie sie jedes Quartal neu.

FAQ: bricht das die taegliche Pentest-Toolkette?

Meistens nein, und wo doch, ist der Bruch beabsichtigt und begrenzt. WDAC im Enforce blockiert unsigniertes Custom-Tooling, weshalb das Forscherlabor in einer eigenen OU mit gelockerter Policy und ohne Kundendaten liegt. Fuer die Produktionsflotte signieren wir unsere internen Binaries und fuegen ihre Hashes der WDAC-Policy hinzu, sodass hausgemachte Rust- und Go-Tools laufen, zufaellige unsignierte Executables aber nicht. ASR im Block stoppt, dass Office cmd.exe oder PowerShell startet, was in legitimer Operator-Arbeit fast nie passiert; die wenigen makrolastigen Reporting-Templates wurden von VBA weg migriert. Braucht ein Tool wirklich eine Ausnahme, laeuft das ueber den ticketbasierten Ausnahmeprozess statt ueber eine pauschale Policy-Lockerung, sodass der Blast-Radius jeder einzelnen Erlaubnis klein und auditierbar bleibt.

FAQ: wie starte ich bei null ohne Ausfall?

Aktivieren Sie Kontrollen in Abhaengigkeitsreihenfolge, sodass jeder Schritt eigenstaendig wertvoll und umkehrbar ist. Die empfohlene Sequenz: zuerst BitLocker mit Pre-Boot-PIN, dann Credential Guard und VBS, dann LSA PPL, dann ASR im Audit gefolgt von Block, dann AppLocker im Audit gefolgt von Enforce, dann WDAC im Audit gefolgt von Enforce. Jede Stufe laeuft mindestens eine Woche mit Logs ins SIEM, bevor die naechste kommt, sodass eine Regression gegen eine Variable statt gegen zehn geprueft wird. Halten Sie fuer jedes GPO einen dokumentierten Rollback und einen offline abgelegten Break-Glass-Local-Admin. Niemand sollte auf eine einzelne Aenderung zeigen und sagen koennen "wir wissen nicht, ob das die Sache war, die es zerbrach", weil Sie genau eine Sache auf einmal geaendert haben.

Fazit: ein Baseline, das den Kontakt ueberlebt

Hardening von Hochrisiko-Workstations ist kein heroisches Eintagesprojekt; es ist ein geschichtetes Baseline, das echte Engagements, echte Diebstahlszenarien und echte Audits ueberleben muss. Hardware-Vertrauensanker, BitLocker mit PIN, Credential Guard, LSA PPL, ASR im Block, AppLocker, WDAC und ein Defender-Sensor, der eine ueberwachte Pipeline fuettert, machen aus dem Operator-Laptop gemeinsam einen wirklich feindlichen Landeplatz. Die Reihenfolge zaehlt so sehr wie die Einstellungen: Audit vor Block, eine Variable auf einmal, jede Ausnahme ticketiert und reviewt. Machen Sie es in dieser Sequenz, halten Sie die Policies in Git, und Sie fahren offensive Operationen auf Maschinen, die Sie tatsaechlich verteidigen, einem Auditor uebergeben und am Flughafen verlieren koennen, ohne eine Meldung schreiben zu muessen.