Windows Server 2012 R2 — Common Findings (Detect / Confirm / Remediate)
Reference for assessing Windows Server 2012 R2 hosts. WS2012R2 is end-of-life (October 2023; ESU through October 2026), so any deployment carries structural risk — but “well-maintained” legacy VMs in the wild are typically domain members with a small set of recurring misconfigurations rather than exotic CVEs. The dominant theme is the ntlm-relay-attacks kill chain: coercion → relay → lateral movement, enabled by signing and name-resolution defaults. 1
Baseline authority: CIS Microsoft Windows Server 2012 R2 Benchmark and DISA STIG (Ver 3) — both enumerate these settings as Level 1 scored items.
The big five
1. SMB signing not required
- Detect: Nmap shows 445 open.
nxc smb <target>(netexec) reportssigning:False. On host:Get-SmbServerConfiguration | Select RequireSecuritySignature. - Confirm:
RequireSecuritySignature=False→ host accepts unsigned SMB sessions and is a viable relay target. Default on member servers and workstations; DCs require signing by default. - Remediate: GPO → Security Options → ‘Microsoft network server: Digitally sign
communications (always)’ = Enabled (plus client-side equivalents). Breakage risk:
SMBv1-only NAS/printers — audit first with
Get-SmbConnection | ? Dialect -eq '1.0'. Overhead <1% CPU on AES-NI hardware.
2. LDAP signing and channel binding not enforced (DCs)
- Detect:
nxc ldap <dc>highlights(signing:None)and weak channel binding. A DC with SMB signing required but LDAP signing disabled is still a relay target (relay-to-LDAP → RBCD, shadow credentials, AD object modification). - Confirm: GPO ‘Domain controller: LDAP server signing requirements’ ≠ Require
signing;
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding≠ 2. - Remediate: LDAP signing = Require signing (GPO on Domain Controllers OU); channel binding = 2 via registry (no GPO exists). Note the StartTLS bypass: plain LDAP relay auto-upgrades to TLS and non-enforcing DCs ignore the token mismatch.
3. LLMNR / NBT-NS enabled
- Detect: on the segment, run Responder in analyze mode (
responder -I eth0 -A); LLMNR/NBT-NS queries confirm broadcasts are answered. From a scan: UDP 5355 (LLMNR) and UDP 137 (NBT-NS) listening. - Confirm: GPO ‘Turn off multicast name resolution’ not Enabled; per-interface
NetbiosOptions≠ 2. - Remediate: LLMNR via GPO (DNS Client → Turn off multicast name resolution =
Enabled); NBT-NS via registry
NetbiosOptions=2 per interface or DHCP option 001. Kills passive coercion — lowest breakage, deploy first.
4. SMBv1 enabled
- Detect:
nmap --script smb-protocols <target>lists SMBv1; on hostGet-SmbServerConfiguration | Select EnableSMB1Protocol. - Confirm:
EnableSMB1Protocol=True. EternalBlue (MS17-010, CVE-2017-0144) applies if unpatched — WS2012R2 shipped SMBv1-capable; check KB4012598. - Remediate:
Set-SmbServerConfiguration -EnableSMB1Protocol $false(and remove the SMB 1.0/CIFS feature). Audit dialect usage first; Server 2003/XP and some NAS need it. See Microsoft’s AD Hardening series part 2 for the audit-then-remove rollout.
5. Weak NTLM authentication level / LM hash storage
- Detect: on host, check
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. - Confirm: value < 5 means the host accepts LM/NTLMv1. Also check
NoLMHash— if 0/absent, LAN Manager hashes are stored on next password change. - Remediate: ‘Network security: LAN Manager authentication level’ = ‘Send NTLMv2 response only. Refuse LM & NTLM’ (LmCompatibilityLevel=5); ‘Do not store LAN Manager hash value on next password change’ = Enabled. Both are CIS L1 items. Test legacy app compatibility (very old NAS, third-party SMB clients).
Other frequent findings
- TLS 1.0/1.1 and weak ciphers (3DES/SWEET32, RC4) enabled on IIS/services — detect
with
nmap --script ssl-enum-ciphers -p 443,3389 <target>; remediate via SCHANNEL registry keys (Enabled=0 for TLS 1.0/1.1, 3DES, RC4). When your modern OpenSSL/Python client cannot speak those suites, see legacy-tls-assessment-friction before concluding the service is unreachable. - MSSQL mixed-mode / empty or weak
sa+xp_cmdshell— if SQL Server is present (often 1433), treat blank-password SQL auth as a host-to-OS bridge; full detect/confirm/remediate playbook on mssql-empty-sa-xp-cmdshell. - Kerberos RC4_HMAC_MD5 allowed — ‘Network security: Configure encryption types allowed for Kerberos’ should be AES128/AES256 only; RC4 enables AS-REP roasting and easier ticket cracking.
- Print spooler running on DCs — enables PrinterBug coercion; disable Spooler service where printing isn’t needed.
- AD CS web enrollment without EPA (if CA present) — ESC8 relay target; see ntlm-relay-attacks.
- Unsupported OS itself — CVSS-10.0-class structural finding in scanner reports; remediation is migration (Server 2022+) or ESU + network isolation.
Detection cheat sheet (blue-side)
| Signal | Event | Meaning |
|---|---|---|
| 4624 type 3, unexpected source IP | Security | Possible Responder relay |
| 5145, IPC$ on DC from workstation | Security | Coercion attempt |
| 31017 | SMBServer/Security | Signing failure post-enforcement (legacy device or relay attempt) |
| 4741 + 4728 | Security | Computer account created + group-added (relay outcome) |
| 4776 | Security (DC) | NTLM validation; correlate for lateral movement |
Cross-references
- ntlm-relay-attacks — the kill chain these misconfigurations enable
- mssql-empty-sa-xp-cmdshell — SQL auth bridge to OS command execution on legacy boxes
- legacy-tls-assessment-friction — when modern assessor TLS stacks cannot reach the app layer
- opc-ua-security — same “secure by design, insecure by default/config” pattern in ICS
- institutionally-constrained-technology-adoption — why organizations keep inferior legacy systems: adoption decisions are constrained by internal factors, not technical merit
Sources
- Eric Bang (Decryption Digest) — SMB Signing Enforcement: How to Stop NTLM Relay Attacks
- SecureAuth — We Love Relaying Credentials: A Technical Guide to Relaying Credentials Everywhere