Microsoft Windows LM / NTLMv1 Authentication Enabled

This Nessus finding is not a single CVE; it is a Windows authentication *configuration weakness*. Tenable plugin 63478 fires when the host is configured to attempt LM and/or NTLMv1 for outbound authentication, typically where HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel is below 3. In practice that means legacy challenge-response can still be negotiated from affected Windows hosts, exposing LM/NetNTLMv1 material that is far weaker than NTLMv2 and far easier to abuse if captured on the wire.

Tenable's MEDIUM label is fair only for a lone workstation viewed in isolation. In a real enterprise, this setting is an *amplifier* for common internal attack paths: name-resolution poisoning, coerced authentication, NTLM relay into unsigned services, or offline cracking with commodity tooling. The decisive reality check is role blast radius: if the same weak auth posture exists on systems participating in AD, trusts, certificate enrollment, or admin workflows, the chain can end in tenant-wide or domain-wide compromise. That pushes this out of backlog hygiene and into HIGH.

Why this verdict

• Attacker position downgrade: exploitation normally requires internal network access or a prior foothold, which implies the attacker is already past initial access. That is real downward pressure versus an unauthenticated internet RCE, but it does *not* make the finding harmless.
• Compounding friction: the chain narrows further because many environments prefer Kerberos, and capture/relay success often depends on legacy name resolution, NTLM fallback, or a second misconfiguration on the destination service such as missing signing or EPA. Those prerequisites are why this is not CRITICAL.
• Role multiplier: on a low-value role like a workstation or isolated member host, the documented chain usually ends at single-host or single-user impact unless the captured credential is privileged. On a typical member server, success can mean host compromise or lateral movement. On high-value roles adjacent to identity — especially DC-admin workflows, AD CS, or trust paths documented by Microsoft — the same chain can end in domain or fleet compromise. That keeps the verdict floored at HIGH even though the opening step is post-initial-access.

Why not higher?

This is not a one-packet takeover. The attacker generally needs internal positioning, a way to induce NTLM, and either weak passwords or a second service-side weakness to relay into meaningful privilege. Those compounding prerequisites keep it below CRITICAL for the average host.

Why not lower?

Calling this MEDIUM ignores enterprise reality. Public, mature tooling exists; Microsoft still documents NTLM relay risk today; and the same setting becomes an identity-scale problem when it touches admin workflows, AD CS, or trust boundaries. For a 10,000-host shop, that is too much blast radius to treat as routine hygiene.

1. Enforce NTLMv2-only — Set Network security: LAN Manager authentication level to at least Send NTLMv2 response only (LmCompatibilityLevel=3) and, where compatibility allows, to Refuse LM & NTLM (5). For a HIGH verdict, deploy this control within 30 days on exposed tiers first: admin workstations, management servers, jump hosts, DC-adjacent systems, and anything talking to AD CS.
2. Turn on NTLM auditing — Enable Microsoft NTLM auditing on domain controllers and review the Microsoft-Windows-NTLM/Operational and Netlogon/LSA events to find the last legacy dependencies before enforcement. Do this within 30 days so you can break the weakest paths before full rollout.
3. Require signing and EPA where NTLM still exists — Enable SMB signing and, for HTTP/AD CS-style endpoints, Extended Protection for Authentication and related binding protections. This matters because even if a source host still emits NTLM, relay success drops sharply when the destination service enforces modern channel protections; deploy within 30 days on certificate, identity, and admin-facing services.
4. Kill easy capture paths — Disable LLMNR/NBNS/WPAD where operationally possible and remove workflows that force NTLM by IP address or legacy naming. This does not fix the root setting, but it cuts the most common Responder-style capture path and should be in place within 30 days for user and server segments.
5. Harden privileged identities — Move admins to tiered accounts, reduce standing local admin, and keep privileged users off ordinary workstations and member servers. This does not remove NTLMv1, but it limits what a captured or relayed credential can buy while you complete remediation within the 180-day window.

Run this on the target Windows host or through your remote management plane with local administrator rights so the registry and OS role can be read reliably. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-ntlmv1.ps1; it prints VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.

# check-ntlmv1.ps1

# Verifies whether a Windows host is configured to allow LM/NTLMv1 outbound auth

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'Stop'

function Write-Result {
    param(
        [string]$State,
        [int]$Code,
        [string]$Message
    )
    Write-Output ("{0} - {1}" -f $State, $Message)
    exit $Code
}

try {
    $regPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
    $propName = 'LmCompatibilityLevel'
    $os = Get-CimInstance Win32_OperatingSystem
    $cs = Get-CimInstance Win32_ComputerSystem

    $caption = $os.Caption
    $version = $os.Version
    $role = switch ($cs.DomainRole) {
        0 { 'Standalone Workstation' }
        1 { 'Member Workstation' }
        2 { 'Standalone Server' }
        3 { 'Member Server' }
        4 { 'Backup Domain Controller' }
        5 { 'Primary Domain Controller' }
        default { 'Unknown' }
    }

    $item = Get-ItemProperty -Path $regPath -Name $propName -ErrorAction SilentlyContinue

    if ($null -eq $item) {
        Write-Result 'UNKNOWN' 2 ("{0} ({1}); role={2}; registry value {3} is not explicitly set. Check resultant GPO / local security policy." -f $caption, $version, $role, $propName)
    }

    $level = [int]$item.$propName

    switch ($level) {
        0 {
            Write-Result 'VULNERABLE' 1 ("{0} ({1}); role={2}; LmCompatibilityLevel=0 (Send LM & NTLM responses)." -f $caption, $version, $role)
        }
        1 {
            Write-Result 'VULNERABLE' 1 ("{0} ({1}); role={2}; LmCompatibilityLevel=1 (Send LM & NTLM; NTLMv2 session security if negotiated)." -f $caption, $version, $role)
        }
        2 {
            Write-Result 'VULNERABLE' 1 ("{0} ({1}); role={2}; LmCompatibilityLevel=2 (Send NTLM responses only / NTLMv1)." -f $caption, $version, $role)
        }
        3 {
            Write-Result 'PATCHED' 0 ("{0} ({1}); role={2}; LmCompatibilityLevel=3 (Send NTLMv2 response only)." -f $caption, $version, $role)
        }
        4 {
            Write-Result 'PATCHED' 0 ("{0} ({1}); role={2}; LmCompatibilityLevel=4 (Send NTLMv2 only; refuse LM)." -f $caption, $version, $role)
        }
        5 {
            Write-Result 'PATCHED' 0 ("{0} ({1}); role={2}; LmCompatibilityLevel=5 (Send NTLMv2 only; refuse LM & NTLM)." -f $caption, $version, $role)
        }
        default {
            Write-Result 'UNKNOWN' 2 ("{0} ({1}); role={2}; unexpected LmCompatibilityLevel={3}." -f $caption, $version, $role, $level)
        }
    }
}
catch {
    Write-Result 'UNKNOWN' 2 $_.Exception.Message
}

Sources

1. Tenable Nessus Plugin 63478
2. Microsoft security guidance for NTLMv1 and LM
3. Microsoft Learn: LAN Manager authentication level
4. Microsoft Learn: audit NTLMv1 on domain controllers
5. Microsoft Support: mitigations for NTLM relay on AD CS
6. Microsoft Learn: NTLM overview
7. Hashcat wiki modes including NetNTLMv1
8. Fortra Impacket NTLM implementation