Windows Server Hardening: CIS Benchmarks, STIGs, and GPO Configuration That Actually Matters

Two authoritative hardening baselines dominate enterprise Windows Server hardening:

CIS Microsoft Windows Server Benchmark: Published by the Center for Internet Security. Organized into two profiles:

• Level 1: Practical hardening controls that improve security without significant operational impact. Suitable as a baseline for all Windows Servers.
• Level 2: More restrictive controls intended for high-security environments. Some controls will break standard enterprise software without testing.

CIS Benchmarks are free to download and widely adopted in commercial environments. They map to NIST 800-53, ISO 27001, and PCI DSS controls.

DISA STIG (Security Technical Implementation Guide): Published by the Defense Information Systems Agency. More prescriptive than CIS, mandatory for DoD environments, and referenced in many federal compliance frameworks (FedRAMP, FISMA). STIGs use Vulnerability IDs (V-IDs) and Severity Categories (CAT I = Critical, CAT II = High, CAT III = Medium).

Which to use:

• Commercial enterprise: Start with CIS Level 1 as your baseline. Evaluate Level 2 controls on a per-control basis.
• Federal/DoD contractors: STIG is required. Use SCAP tools (OpenSCAP, SCAP Compliance Checker) to automate compliance checking.
• Both frameworks complement each other — CIS Level 2 and STIG controls converge heavily on the same settings.

Microsoft publishes the Security Compliance Toolkit (SCT), which includes pre-built Group Policy Objects aligned to CIS and Microsoft's own security guidance. Download from the Microsoft Download Center — it includes GPO backups you can import directly into your domain.

Key baselines in the SCT:

• Windows Server 2022 Security Baseline
• Microsoft Defender Antivirus Security Baseline
• Microsoft Edge Security Baseline

Import process:

1. Download the SCT and extract the GPO backups
2. Use Group Policy Management Console > Import Settings to import into a test GPO
3. Run gpresult /H report.html on a test server after applying to verify settings landed
4. Test application functionality for 48-72 hours before promoting to production

Critical settings included in the Windows Server baseline:

• SMBv1 disabled (WannaCry/EternalBlue attack surface)
• LM and NTLMv1 authentication disabled
• Anonymous enumeration of accounts and shares blocked
• Null session access to named pipes and shares blocked
• Windows Firewall enabled on all profiles with deny-by-default inbound
• RDP Network Level Authentication (NLA) enforced
• Windows Defender enabled with real-time protection
• Audit policies set to log authentication, privilege use, and object access

Windows Server enables services that most production workloads do not need. Each enabled service is a potential attack vector.

Services safe to disable on most servers:

Services that require role-specific evaluation:

• IIS Admin Service: Disable if not a web server
• MSSQLSERVER: Disable if not a database server; harden if enabled (named pipes vs. TCP, minimal permissions)
• SNMP Service: Disable unless network management requires it; use SNMPv3 if kept

How to inventory and disable:

# List all running services and their start type
Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object Name, DisplayName, StartType

# Disable a service
Set-Service -Name "Spooler" -StartupType Disabled
Stop-Service -Name "Spooler"

Beyond the SCT baseline, these specific GPO settings address the most commonly exploited Windows Server configurations:

Authentication hardening:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

• Network security: LAN Manager authentication level → Send NTLMv2 response only. Refuse LM and NTLM
• Network security: Minimum session security for NTLM SSP based (including secure RPC) clients → Require NTLMv2 session security, Require 128-bit encryption
• Accounts: Guest account status → Disabled
• Network access: Do not allow anonymous enumeration of SAM accounts → Enabled
• Network access: Do not allow anonymous enumeration of SAM accounts and shares → Enabled

Credential protection:

• Credential Guard → Enable via Device Guard policy (requires UEFI, Secure Boot, virtualization-based security)
• WDigest Authentication → Disabled (prevents cleartext credential caching in LSASS)
• Protected Users security group → Add privileged accounts; prevents NTLM auth, credential delegation, and Kerberos RC4 for members

SMB hardening:

• Configure SMB v1 client driver → Disabled
• Configure SMB v1 server → Disabled
• Enable SMB signing: Microsoft network server: Digitally sign communications (always) → Enabled

RDP hardening:

• Set client connection encryption level → High Level
• Require use of specific security layer for remote (RDP) connections → SSL (TLS 1.0)
• Require NLA → Enabled
• Set time limit for disconnected sessions → 15 minutes

Windows Defender Antivirus on servers requires different configuration than endpoint workstations. Default settings are often insufficient for server threat coverage.

Key Defender settings for servers (via GPO or Intune):

# Enable cloud-delivered protection
Set-MpPreference -MAPSReporting Advanced
Set-MpPreference -SubmitSamplesConsent SendAllSamples

# Enable attack surface reduction rules (key rules for servers)
# Block process creations originating from PSExec and WMI commands
Add-MpPreference -AttackSurfaceReductionRules_Ids d1e49aac-8f56-4280-b9ba-993a6d77406c -AttackSurfaceReductionRules_Actions Enabled

# Block credential stealing from LSASS
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b3 -AttackSurfaceReductionRules_Actions Enabled

# Enable real-time protection
Set-MpPreference -DisableRealtimeMonitoring $false

# Set scan schedule
Set-MpPreference -ScanScheduleDay 1 -ScanScheduleTime 02:00:00

ASR rules particularly valuable on servers:

• Block LSASS credential dumping (catches Mimikatz and similar tools)
• Block process creations from PSExec/WMI (blocks lateral movement techniques)
• Block untrusted and unsigned processes from USB
• Block Office applications from creating child processes (relevant on RDS servers)

Exclusions discipline: Antivirus exclusions are a common attack vector. Limit exclusions to the minimum required by specific applications (e.g., database file extensions for SQL Server). Document every exclusion with a business justification and review quarterly.

If every Windows Server in your environment uses the same local administrator password — or if the built-in Administrator account has a predictable password — one compromised server gives an attacker lateral movement to every server with that password.

Microsoft LAPS (Local Administrator Password Solution) solves this by generating a unique, random password for each machine's local administrator account and storing it in Active Directory, where it is accessible only to authorized accounts.

Windows LAPS (built into Windows Server 2019+ and Windows 10 20H2+):

• No separate MSI required — enable via GPO
• Passwords stored in AD or Azure AD (Entra ID)
• Automatic rotation on schedule (recommended: 30 days) or after each use

Deployment via GPO:

1. Enable Computer Configuration > Administrative Templates > System > LAPS
2. Set Backup directory to Active Directory
3. Set Password Settings — minimum 15 characters, complexity required
4. Set Post-authentication actions — reset password after local admin account use
5. Extend the AD schema: Update-LapsADSchema
6. Grant read access to LAPS passwords to specific security groups only

Retrieving a LAPS password:

Get-LapsADPassword -Identity SERVER01 -AsPlainText

Do not grant helpdesk or broad IT staff access to LAPS passwords for all servers. Scope read access by OU.

Detection depends on logging. Default Windows Server audit policy logs far less than needed for effective threat detection.

Configure Advanced Audit Policy (not the legacy basic audit policy — they conflict):

Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration

Critical categories to enable:

Log size — defaults are dangerously small:

• Security log: Default 20 MB. Set to 1 GB minimum on servers.
• System log: Set to 512 MB minimum.
• Application log: Set to 512 MB minimum.

# Set Security log size to 1 GB
wevtutil sl Security /ms:1073741824

Forward logs to SIEM via Windows Event Forwarding (WEF) or a SIEM agent. Logs retained only on the source server are lost if the attacker clears the Security log — a standard post-exploitation step.