Windows 11 Hardening for High-Risk Offensive Security Workstations

A compromised pentester workstation is a regulatory nightmare: client SSH keys, captured credentials, signed payloads and NDA-bound reports all share the same disk. At Basilisk OffSec we treat every Windows 11 laptop as a hostile endpoint until proven otherwise, and we harden it as if the operator will be phished, physically robbed and audited in the same week. This note documents the baseline we have run in production since March 2026 across 47 machines: ASR rules in block mode, Credential Guard with reinforced VBS, AppLocker for the user-mode perimeter and WDAC for the kernel. It is not pretty to configure, but it measurably shrank the attack surface we mapped in AMSI and ETW Bypass for Defensive Research: What Blue Teams Should Know. This expanded version walks the full stack layer by layer, with the exact settings, the trade-offs, and the rollout order that keeps you from bricking your own fleet.

The threat model: why the operator laptop is the crown jewel#

Before touching a single Group Policy Object, write down who you are defending against. An offensive-security laptop is not a normal corporate endpoint: it holds decrypted client secrets, C2 profiles, and reports that describe how to break into other companies. The realistic adversaries are three: a phishing operator who lands a macro or a malicious LNK, a thief who grabs the device at an airport, and a determined attacker who wants the client data specifically. Each demands a different control. Phishing is answered by execution control (ASR, AppLocker, WDAC); theft is answered by pre-boot encryption and TPM binding; targeted compromise is answered by credential isolation and telemetry. Skipping the model and jumping to "enable everything" is how teams break Caldera labs and then disable the whole policy in frustration. Map the assets, rank them, and let the ranking drive which switch you flip first.

Hardware foundation: TPM, Secure Boot, DMA and firmware#

Every software control below rests on trusted hardware, so we start there. We require an active TPM 2.0, Secure Boot with our own enrolled keys, Kernel DMA Protection enabled, and firmware running Intel Boot Guard or AMD Platform Secure Boot depending on the vendor. Without that root of trust, any policy is theater: a DMA attack over Thunderbolt or a rogue boot loader unwinds everything in minutes. The standard laptop is a ThinkPad P14s Gen 5 or a Surface Laptop 7. We disable legacy CSM, lock the firmware with a supervisor password, and turn off boot from USB and network for the general fleet. In firmware we also disable unused radios and the built-in fingerprint reader when the threat model calls for PIN-only pre-boot. If you want the same operational bar applied to servers, we wrote Linux Server Hardening: Applying CIS Benchmark Without Breaking Production on the identical philosophy.

Full-disk encryption: BitLocker with a pre-boot PIN#

BitLocker is non-negotiable and it must be bound to the TPM plus a pre-boot PIN, not TPM-only. TPM-only unlocks the disk automatically at boot, which means a stolen powered-off laptop is one cold-boot or DMA trick away from plaintext. We enforce XTS-AES 256, require a numeric PIN of at least eight digits (enabled through the "Require additional authentication at startup" policy), and store the 48-digit recovery key in an offline team vault, never in a Microsoft account and never in Active Directory readable by helpdesk. We also enable BitLocker for fixed and removable data drives, so the reports partition and any USB scratch disk are covered. Suspend protection is disabled for casual firmware updates; each unlock is logged. The net effect: a lost device is a hardware loss, not a breach notification.

Credential Guard, VBS, Secure Launch and HVCI#

The first software layer is virtualization-based security. Through Group Policy we make Device Guard, Virtualization Based Security, Secure Launch and HVCI (Hypervisor-Enforced Code Integrity) mandatory. Credential Guard moves NTLM hashes and Kerberos tickets into a VTL1 isolated process that the normal OS cannot read, so a foothold in the user session cannot simply scrape domain credentials from memory. HVCI enforces that only signed, verified code runs in the kernel, closing the door on unsigned rootkits and many BYOVD chains. Secure Launch uses the CPU DRTM to re-establish trust after firmware, shrinking the early-boot attack window. There is a real cost here: HVCI blocks some old drivers and adds a few percent of overhead on heavy compile workloads, which we measure against our custom Sliver build pipeline. That cost buys you an operator session that leaks far less when it is inevitably poked.

LSASS protection: RunAsPPL and access auditing#

Even with Credential Guard, LSASS remains a target for handle-based dumping, so we run it as a Protected Process Light. We set RunAsPPL=1 in HKLM\SYSTEM\CurrentControlSet\Control\Lsa (UEFI-locked variant where supported) and turn on LSASS access auditing. In internal testing this broke vanilla mimikatz, comsvcs.dll MiniDump abuse and several handle-duplication tricks without even needing an EDR, and LSA Protection blocked every injection attempt we replayed from Windows Persistence: 10 Documented Techniques and Their Countermeasures. The complementary control is a detection rule on process handle access to lsass.exe with a desired access mask of 0x1010 or 0x1410, which is the tell of a dump attempt. The cost is roughly four percent CPU overhead on heavy Rust compiles, measured against our custom Sliver build pipeline. That is a cheap price for closing the single most abused credential-theft path on Windows.

Attack Surface Reduction rules in block mode#

ASR comes next and it is exactly where most teams lose their nerve. We enable all sixteen rules in block, not audit. Yes, this breaks Office child processes, obfuscated script execution, WMI-spawned processes and untrusted USB executables. We keep one separate OU named "OffSec-Tools" where a handful of rules stay in audit for the researcher lab box running Caldera, as described in Adversary Emulation with Caldera and MITRE ATT&CK in a Corporate Lab. For the rest of the fleet, rule D4F940AB-401B-4EFC-AADC-AD5F3C50688A (block all Office applications from creating child processes) alone killed 73 percent of the initial-access vectors we simulated in Simulated Initial Access: Macros, LNK and ISO in an Isolated Windows 11 Lab. Pair it with block credential stealing from LSASS, block executable content from email and webmail, and block Win32 API calls from Office macros for the highest return per rule.

AppLocker for the user-mode perimeter#

AppLocker and WDAC live in different layers and you want both. AppLocker governs user-mode with publisher and path allowlists and is ideal for stopping the suspicious ZIP a user just dropped into Downloads or a script under a per-user profile. We deny execution from writable locations (Downloads, Temp, AppData) by default and allow only signed binaries plus a curated tools path under an admin-owned directory. Rules cover EXE, DLL, MSI, Script and Packaged apps; DLL rules are on despite their cost because DLL side-loading is a favorite loader technique. AppLocker is enforced through the Application Identity service and audited first: we run it in "Audit only" for a fortnight, harvest the 8003 and 8004 events, then flip to enforce. It is not a hard security boundary on its own, but as the outer sieve in front of WDAC it removes a huge class of user-launched junk.

WDAC for the kernel and driver layer#

WDAC (Windows Defender Application Control) is the real code-integrity boundary, covering kernel and drivers through a signed policy tied to our EV certificate, with the Microsoft Recommended Driver Block Rules imported in January 2026. We generate the base policy with New-CIPolicy, run it in audit for 30 days, collect event IDs 3076 and 3077, refine, and only then promote to enforce. The payoff: vulnerable drivers cataloged on loldrivers.io, including those used in the evasion routines we covered in EDR Evasion for Research: Direct Syscalls Explained Without the Hype, simply refuse to load. Only binaries signed by Microsoft, by the OEM (Lenovo, Microsoft Surface) or matching our internal hashes execute. We deploy the policy as a signed, UEFI-locked file so an attacker with admin cannot silently swap it, and we alert on any policy-modification event as a high-severity signal.

Microsoft Defender as the last layer and its telemetry#

Defender goes in last with Tamper Protection on, Cloud Block Level set to High, PUA set to block, Network Protection enabled and Controlled Folder Access covering Documents, Desktop and the reports directory. The point is not that Defender catches everything; it is that every layer above already narrowed the field, so Defender is now a high-signal sensor rather than a noisy gatekeeper. We pipe the events into the Sigma-plus-Elastic pipeline described in Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule, focused on WDAC policy modification, service creation via sc.exe, scheduled-task persistence, and LSASS handle access with mask 0x1010. Over 90 days on 47 workstations we recorded zero confirmed compromises and twelve high-signal alerts, two of which were genuine drive-by attempts during bug-bounty engagements. Telemetry without a review rota is decoration, so each alert class has a named owner and a runbook.

Rollout methodology and exclusion governance#

The single biggest failure mode is flipping every switch at once, breaking someone mid-engagement, and having the whole policy disabled in anger by lunchtime. Do not do that. Run 30 days in audit, ship the logs to a SIEM, tune the minimum viable set of exclusions, and only then move to block. Every exclusion gets a Jira ticket, a named owner and a quarterly review date, because hardening that nobody revisits rots within six months as new tools and driver versions arrive. Version the policies as code in a git repo, sign them in CI, and deploy through Intune or your config-management tool so the baseline is reproducible and diffable. Treat the OffSec-Tools OU as a documented, monitored exception, not a permanent escape hatch, and re-baseline it every quarter against what the researchers actually still need.

FAQ: does this break day-to-day pentest tooling?#

Mostly no, and where it does the breakage is intentional and scoped. WDAC in enforce will block unsigned custom tooling, which is why the researcher lab lives in its own OU with a relaxed policy and no client data. For the production fleet, we sign our internal binaries and add their hashes to the WDAC policy, so home-grown Rust and Go tools run while random unsigned executables do not. ASR block mode will stop Office spawning cmd.exe or PowerShell, which almost never happens in legitimate operator work; the handful of macro-heavy reporting templates were migrated off VBA. If a tool genuinely needs an exception, it goes through the ticketed exclusion process rather than a blanket policy relaxation, so the blast radius of any single allowance stays small and auditable.

FAQ: how do I start from zero without downtime?#

Enable controls in dependency order so each step is independently valuable and reversible. The sequence we recommend is: BitLocker with a pre-boot PIN first, then Credential Guard and VBS, then LSA PPL, then ASR in audit followed by block, then AppLocker in audit followed by enforce, then WDAC in audit followed by enforce. Each stage runs for at least a week with logs flowing to the SIEM before the next one lands, so a regression is caught against one variable rather than ten. Keep a documented rollback for every GPO and a break-glass local admin stored offline. Nobody should be able to point at a single change and say "we do not know if that was the thing that broke it," because you changed exactly one thing at a time.

Conclusion: a baseline that survives contact#

High-risk workstation hardening is not a heroic one-day project; it is a layered baseline that has to survive real engagements, real theft scenarios and real audits. Hardware root of trust, BitLocker with a PIN, Credential Guard, LSA PPL, ASR in block, AppLocker, WDAC and a Defender sensor feeding a monitored pipeline together turn the operator laptop from a soft target into a genuinely hostile place to land. The order matters as much as the settings: audit before block, one variable at a time, every exception ticketed and reviewed. Do it in that sequence, keep the policies in git, and you will run offensive operations on machines you can actually defend, hand to an auditor, and lose at an airport without writing a breach notification.