ADDOM-016: NTLMv1 Usage Detection

Platform: Active Directory
Category: AD Domain & Forest Configuration
Severity: Critical
Zero Trust pillar: Governance (weight 2)
Golden fixtures: 3
Branch coverage: Observed: fixtures prove the verdicts they exercise
Provenance: baseline

What it checks

The check evaluates three independent surfaces. First, it reads the effective LAN Manager authentication level on every domain controller and on a representative sample of member servers by querying HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel via remote registry, and by parsing the resolved RSoP GPO setting "Network security: LAN Manager authentication level" (security option SeNetworkLogonRight chain). Values 0 through 4 all permit the server to accept or send NTLMv1 or LM responses; only value 5 ("Send NTLMv2 response only. Refuse LM and NTLM") refuses NTLMv1 entirely. Second, the check reads the NTLM restriction and auditing values: RestrictSendingNTLMTraffic, RestrictReceivingNTLMTraffic, AuditReceivingNTLMTraffic, and ClientAllowedNTLMServers under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Third, on each domain controller it queries the Microsoft-Windows-NTLM/Operational event log for event IDs 8001 (outgoing NTLM authentication), 8002 (incoming NTLM authentication), 8003 (NTLM blocked by policy), and 8004 (NTLM authentication on a DC), and for Security log event 4624 with LmPackageName equal to NTLM V1 or LM. Any non-zero count of NTLMv1 or LM handshakes inside the configured audit window (default 30 days) is reported with the source workstation, the target server, and the authenticating user. The check also enumerates Group Policy preferences and computer-startup scripts for occurrences of NET USE, NET VIEW, or net.exe with the /USER switch pointing at NetBIOS-style names that would force NTLM rather than Kerberos.

Why it matters

NTLMv1 derives its response from three DES encryptions of the 8-byte server challenge using a key schedule built from the 16-byte NT hash padded with five null bytes. The third DES key has only 16 bits of entropy because of the five-null pad, which collapses the search space for that block to 2^16. The first two DES blocks each use 56 bits of key, but because both encrypt the same 8-byte challenge, a precomputed rainbow table across all 2^56 DES keys (built by Marsh Ray and Moxie Marlinspike, hosted at crack.sh) can recover the full NT hash from any captured NTLMv1 response in approximately 24 hours, often within minutes for cached lookups. Recovery of the NT hash is functionally equivalent to recovery of the password for all NTLM, NTLMv2, Pass-the-Hash, and silver-ticket use cases. An attacker on the same broadcast domain or on a position to coerce authentication (PetitPotam, PrinterBug, DFSCoerce, WebClient via WebDAV) can capture an NTLMv1 handshake from a privileged account in seconds, recover the NT hash within hours, and then authenticate as that account anywhere NTLM is accepted. If the captured account is a domain controller machine account or a service account with Tier 0 reach, the entire forest is compromised. NTLMv1 is also commonly used by legacy appliances (storage arrays, MFPs, backup proxies, NAS devices, ESXi hosts joined via Likewise), and these devices are frequently the unmonitored entry point for ransomware affiliates. Microsoft has formally deprecated NTLM and is removing it from future Windows releases.

Attack path

Step 1: Position. The attacker gains a foothold on a workstation or a coercion-capable position on the network. Common entry: phishing payload, exposed RDP, unauthenticated SMB, or a compromised vendor VPN account. Step 2: Force a downgrade. The attacker uses Responder (Laurent Gaffie) with the --lm flag, or Inveigh with -ConsoleOutput Y -LM Y, to advertise an LLMNR, NBT-NS, or mDNS poisoning service that offers only LM and NTLMv1 in the NTLM negotiate message. Victims whose LmCompatibilityLevel is 2 or lower (default on Server 2003 and many appliances) will respond with NTLMv1. The attacker can also coerce authentication directly from a server using PetitPotam (MS-EFSRPC), PrinterBug (MS-RPRN EfsRpcOpenFileRaw), DFSCoerce (MS-DFSNM NetrDfsRemoveStdRoot), or ShadowCoerce, then downgrade the negotiate phase by responding from a SMB server that advertises only LM and NTLMv1. Step 3: Capture. The attacker logs the captured NTLMv1 response. The format is USER::DOMAIN:LMRESP:NTRESP:SERVERCHALLENGE. Step 4: Crack. The attacker submits the captured response to crack.sh, which returns the NT hash via the full 2^56 DES rainbow table (24-hour SLA, often minutes). Alternatively, the attacker uses hashcat mode 5500 on local GPUs. Step 5: Replay. The recovered NT hash is used with impacket-psexec, impacket-wmiexec, Invoke-TheHash, evil-winrm, or CrackMapExec to authenticate to any NTLM-accepting service as the victim. If the victim is a server machine account or a domain admin, the attacker pivots to a DC. With the NT hash of a DC machine account, the attacker can perform Silver Ticket forgery against the DC computer services and against the krbtgt service, or run secretsdump.py to extract ntds.dit. Step 6: Persistence. Pass-the-Hash to additional hosts, lateral movement via WMI and SMB, and finally DCSync to dump every account hash in the domain.

How Guerrilla assesses it

Guerrilla enumerates every domain controller via Get-ADDomainController and every member server via the Domain Computers group filtered by operatingSystem. For each target it opens a remote registry handle via winreg RPC and reads HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel, HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\RestrictSendingNTLMTraffic, HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\RestrictReceivingNTLMTraffic, and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\AuditReceivingNTLMTraffic. Effective policy is reconciled with Get-GPResultantSetOfPolicy to detect cases where the registry value is set locally but a higher-precedence GPO overrides it. The check then opens the Microsoft-Windows-NTLM/Operational and Security event logs on every DC using Get-WinEvent with an XPath filter for EventID=8001 or 8002 or 8004, and for Security EventID=4624 with EventData/Data[@Name="LmPackageName"]="NTLM V1" or "LM" within the configured lookback window. Each NTLMv1 hit is enriched with the source workstation name, target server, authenticating user, and authentication time. A finding is raised when any server reports LmCompatibilityLevel less than 5, when AuditReceivingNTLMTraffic is 0 on any DC (auditing is disabled and the environment is blind), when RestrictReceivingNTLMTraffic is 0 or 1 on a DC (DC accepts NTLMv1 inbound), or when any captured event in the lookback window matches NTLMv1 or LM. The check also queries the krbtgt and DC machine accounts for "Do not require Kerberos preauthentication" (userAccountControl bit 0x400000) because this attribute combined with NTLMv1 acceptance enables AS-REP roasting plus NTLMv1 crack chains.

Recommended value

Zero NTLMv1 authentication events detected; LAN Manager authentication level set to refuse NTLMv1

Remediation

Enable NTLM auditing via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > 'Network security: Restrict NTLM' settings. Review event logs for NTLMv1 usage and remediate applications, then set 'Network security: LAN Manager authentication level' to 'Send NTLMv2 response only. Refuse LM & NTLM'

Fixture-proven verdicts

Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.

Verdict scenarios for ADDOM-016
Scenario	Expected verdict
clean	PASS
known-bad	FAIL
throttled	Not Assessed

Framework mappings

NIST SP 800-53: IA-5(2), SC-8
CIS Benchmark: 2.3.8.4
ANSSI: R27
NSA / ASD: NTLM-1
CIS AD Benchmark: 2.3.1
MITRE ATT&CK: T1557, T1003