Windows installs with a lot of legacy protocols still enabled. SMBv1, LLMNR, NetBIOS, RC4 encryption for Kerberos, NTLMv1 authentication - features that made sense in the 1990s and early 2000s but which attackers now exploit routinely. The CIS Benchmarks for Windows document runs to over a thousand pages because there are hundreds of settings that need attention. For someone learning security, that is an overwhelming place to start.
This guide takes a different approach. Rather than a compliance checklist, it walks through hardening in a logical sequence: understand the attack surface, apply the highest-impact controls, enable the logging that lets defenders see what is happening, and verify the changes actually worked. Each step includes the relevant commands and Group Policy paths, plus a TryHackMe room to practise in a safe environment before touching production systems.
The steps below are ordered from highest-impact to more advanced. If you only complete the first four, you will have addressed the majority of the attack chains covered in most real-world Windows penetration tests.
Step 1 - Audit what is running before you harden anything
Hardening without understanding what is on the system is how you break things. The first step is always reconnaissance on your own environment: what services are running, which protocols are active, and what the current patch state looks like.
Run these in an elevated PowerShell session:
Step 2 - Disable legacy protocols: SMBv1, LLMNR, and NetBIOS
These three protocols are responsible for a disproportionate share of real-world Windows attacks. SMBv1 was the attack vector for WannaCry and NotPetya. LLMNR and NetBIOS enable Responder-style credential poisoning attacks that require no prior access. All three should be disabled in any environment that does not have a specific legacy dependency on them.
The Group Policy path for LLMNR is: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution. Set it to Enabled.
Step 3 Enforce NTLMv2 only and enable SMB signing
NTLM is a legacy authentication protocol that supports multiple versions. NTLMv1 is trivially crackable and should never be used. NTLMv2 is significantly stronger but still vulnerable to relay attacks without SMB signing. The combination of enforcing NTLMv2-only and requiring SMB signing closes both gaps.
The Group Policy path for LAN Manager authentication level is: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level. Set to 'Send NTLMv2 response only. Refuse LM and NTLM'.
Step 4 - Enable Credential Guard and protect LSASS
Credential Guard uses hardware-backed virtualisation (VBS) to protect credential material in memory. Without it, tools like Mimikatz can extract NTLM hashes and plaintext credentials from LSASS memory. Enabling it requires a machine with Secure Boot and TPM 2.0 enabled, which covers most hardware from 2016 onwards. The Microsoft Credential Guard documentation covers prerequisites in detail.
In Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Enable it with the Secure Boot and DMA Protection platform settings.
Step 5 - Deploy LAPS for unique local administrator passwords
By default, Windows machines often have the same local administrator password across the entire fleet, set during imaging and never changed. If an attacker compromises one machine and dumps the local admin hash, they can authenticate to every other machine on the network using Pass-the-Hash. Microsoft LAPS (Local Administrator Password Solution) solves this by generating a unique, automatically rotated password for the local administrator account on each machine, storing it in Active Directory where only authorised users can retrieve it.
LAPS is now built into Windows since the April 2023 cumulative updates (replacing the legacy standalone LAPS client). To enable it:
Step 6 - Configure Attack Surface Reduction rules in Defender
Windows Defender includes 17 Attack Surface Reduction (ASR) rules that block specific attack behaviours: Office macros spawning child processes, script interpreters running executable content, credential dumping from LSASS, and more. Most are not enabled by default. The recommended approach is to deploy them in Audit mode first to see what would be blocked, then switch to Block mode once you have confirmed no legitimate applications are affected.
Step 7 - Enable PowerShell logging and Windows Event auditing
Hardening reduces the attack surface, but no configuration is impenetrable. The controls that give defenders visibility into what is happening on a system are just as important as the controls that block attacks. PowerShell script block logging captures every script that runs, even if it is obfuscated. Windows Event ID 4688 with command line auditing records every process that starts, including its full command line arguments.
The Group Policy paths are: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell for logging, and Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies for process creation. The full Advanced Audit Policy reference is on Microsoft Learn.
Step 8 - Verify your hardening actually worked
The final step is verification. Configuration drift is real: updates can re-enable settings, new software installs can add services, and Group Policy can conflict in unexpected ways. Checking that the controls you applied are still in effect should be a regular practice, not a one-time event.
For a more structured approach, Microsoft Security Baselines provide a policy package you can deploy via Group Policy that applies Microsoft's recommended settings across all the categories above, with documentation for each choice. The CIS Benchmarks cover the same ground but are more conservative and compliance-focused.
What this sequence covers
Working through these eight steps addresses the most commonly exploited Windows configuration weaknesses: the legacy protocols that enable credential harvesting, the default settings that allow Pass-the-Hash lateral movement, the missing controls that let attackers dump credentials from memory, and the absence of logging that lets attacks go undetected.
None of these steps require a security product purchase. Everything above uses native Windows functionality, Group Policy, and built-in Defender features. The gap between a default Windows installation and a reasonably hardened one is almost entirely a configuration gap, not a technology gap.
Practise these skills on TryHackMe's Windows Fundamentals module builds the foundation needed to understand the controls above, and the rooms linked throughout this guide put them into practice in a browser-based lab environment.
Nick O'Grady