Microsoft Windows LM / NTLMv1 Authentication Enabled

Tenable plugin 63478 is a local hardening finding, not a remotely exploitable software bug. It fires when a Windows host is configured to *send* LM and/or NTLMv1 for outbound authentication, typically via LmCompatibilityLevel values 0-2; Tenable recommends 3 or higher. Microsoft says older platforms such as Windows XP and Windows Server 2003 were affected by default, while modern Windows can still be dragged back into this state by policy, legacy compatibility, or special auth paths.

Vendor MEDIUM is defensible in a vacuum, but for enterprise patch priority this is really a LOW. The decisive friction is attacker position: the adversary usually needs to already be on the internal network or on-path, then induce or observe a victim NTLMv1 exchange, then either crack the captured challenge-response or find a relayable target. That's a real post-compromise amplifier, especially around privileged endpoints, but it is not a direct internet-facing initial-access issue.

Why this verdict

• Downgrade for attacker position: exploitation usually requires *internal network* or *on-path* access first, which implies the attacker is already past your perimeter.
• Downgrade for population reach: the finding is local and not directly internet-addressable; only hosts that both allow NTLMv1 and actually attempt a matching auth flow are exposed at the moment of use.
• Downgrade for chain dependency: capture alone is not impact. The attacker still needs a victim auth event, then either a crackable password or a relayable target lacking signing/channel protections.
• Keep it above IGNORE: if the exposed credential belongs to an admin or service account, the blast radius jumps quickly from one workstation setting to domain-wide consequences.

Why not higher?

This is not unauthenticated remote code execution, not wormable, and not an edge-service exposure. Most modern environments prefer Kerberos or NTLMv2, so the vulnerable state often needs legacy compatibility plus a successful internal interception path before anything bad happens.

Why not lower?

It still weakens real credential protection and plugs directly into well-known offensive tooling. In environments with legacy auth, poor segmentation, or privileged users browsing around from general-purpose endpoints, NTLMv1 is exactly the kind of small weakness attackers chain into meaningful lateral movement.

1. Raise LmCompatibilityLevel — Set clients and member servers to at least 3 and domain controllers to 5 where compatibility allows. Because this is a LOW reassessment, there is no SLA; fold it into baseline hardening, but prioritize Tier 0 assets, admin workstations, and systems that regularly handle privileged credentials.
2. Enable Credential Guard on supported clients — Credential Guard blocks NTLMv1 use for signed-in credentials on supported Windows clients and removes a chunk of the practical attack surface. There is no LOW mitigation deadline, so deploy through normal endpoint-hardening waves after application compatibility review.
3. Kill relay paths — Require SMB signing, enforce LDAP signing / channel binding / EPA where applicable, and harden AD CS web enrollment if present. This does not remove the weak auth setting itself, but it cuts the payoff attackers get after capture; for a LOW item, handle during your next identity and protocol-hardening cycle.
4. Suppress name-resolution abuse — Disable LLMNR where feasible, reduce NBT-NS dependence, and watch for WPAD abuse so tools like Responder have fewer opportunities to collect challenge-response material. Again, no SLA here, but this is worth bundling with workstation baseline work.
5. Audit before you enforce — Use Microsoft NTLM auditing and server log review to identify which apps, devices, VPN/Wi-Fi stacks, or legacy appliances still trigger NTLMv1. That keeps you from breaking brittle dependencies while still driving the fleet toward NTLMv2 only.

Run this on the target Windows host or through your software deployment / RMM channel. Invoke it with powershell.exe -ExecutionPolicy Bypass -File .\Test-LmCompatibilityLevel.ps1; standard user rights are usually enough to read the registry, but run elevated if your endpoint controls restrict HKLM access. It checks the local effective registry value Tenable keys on and returns VULNERABLE, PATCHED, or UNKNOWN.

# Test-LmCompatibilityLevel.ps1
# Checks whether the local host allows LM/NTLMv1 outbound authentication
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

$ErrorActionPreference = 'Stop'
$regPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
$valueName = 'LmCompatibilityLevel'

try {
    $item = Get-ItemProperty -Path $regPath -Name $valueName -ErrorAction Stop
    $level = [int]$item.$valueName

    switch ($level) {
        { $_ -lt 3 } {
            Write-Output "VULNERABLE - $valueName=$level (host may send LM/NTLMv1 outbound)"
            exit 1
        }
        default {
            Write-Output "PATCHED - $valueName=$level (host sends NTLMv2 only or stricter)"
            exit 0
        }
    }
}
catch [System.Management.Automation.ItemNotFoundException] {
    Write-Output "UNKNOWN - $valueName is not explicitly set in $regPath; verify effective policy with RSOP/GPO because defaults vary by role and OS generation"
    exit 2
}
catch {
    Write-Output "UNKNOWN - failed to read registry: $($_.Exception.Message)"
    exit 2
}

Sources

1. Tenable Nessus Plugin 63478
2. Microsoft security guidance for NTLMv1 and LM
3. Microsoft Learn: LAN Manager authentication level policy
4. Microsoft Learn: audit use of NTLMv1 on a domain controller
5. Microsoft Learn: Credential Guard overview
6. GitHub: Responder
7. GitHub: Impacket ntlmrelayx
8. Hashcat example hashes wiki