1. Introduction
NTLM Authentication Detected indicates a web page is using NTLM for authentication. This older protocol has known security weaknesses and is vulnerable to various attacks, including pass-the-hash. Systems usually affected are Windows servers and workstations offering web applications or file shares. A successful attack could compromise confidentiality, integrity, and availability of data accessed through the protected resource.
2. Technical Explanation
The scanner detected a webpage configured to use NTLM authentication. Attackers can exploit this by intercepting NTLM traffic using tools like Responder or Ntlmrelayx. Preconditions include network access to the affected system and successful credential harvesting.
- Root cause: The web application is configured to accept NTLM authentication, which relies on a challenge-response mechanism susceptible to relay attacks.
- Exploit mechanism: An attacker intercepts an NTLM negotiation between a client and server, then relays the credentials to another service for authentication. This allows access without knowing the actual password.
- Scope: Windows servers and workstations running web applications configured with NTLM authentication are affected.
3. Detection and Assessment
Confirming NTLM usage involves checking network traffic or application configurations. A quick check is to examine browser prompts for NTLM credentials. Thorough assessment requires a network scan.
- Quick checks: Check if your web browser prompts for username and password when accessing the affected resource, indicating NTLM authentication.
- Scanning: Nessus plugin ID 34861 can identify systems using NTLM authentication. This is an example only.
- Logs and evidence: Windows Security Event Logs may show NTLM authentication events (Event ID 4624). Look for ‘Authentication Package’ equal to ‘NTLM’.
net session | find "NTLM"4. Solution / Remediation Steps
The primary solution is to disable NTLM authentication and migrate to more secure protocols like Kerberos or modern alternatives.
4.1 Preparation
- Ensure Kerberos is functioning correctly as an alternative. Roll back by re-enabling NTLM in application configuration.
- A change window may be required, with approval from the IT security team.
4.2 Implementation
- Step 1: Disable NTLM authentication within your web server configuration (e.g., IIS).
- Step 2: Configure Kerberos authentication if not already enabled.
- Step 3: Test access to the web application using Kerberos credentials.
4.3 Config or Code Example
Before
<authentication mode="NTLM" />After
<authentication mode="Windows" />4.4 Security Practices Relevant to This Vulnerability
List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.
- Practice 1: Least privilege can limit the impact if NTLM is compromised by restricting access to sensitive resources.
- Practice 2: Regularly review and update authentication protocols to use stronger methods like Kerberos or multi-factor authentication.
4.5 Automation (Optional)
# PowerShell example to check NTLM usage on a server
Get-WmiObject Win32_WinNTAuthenticationDefault | Select AuthenticationPackage5. Verification / Validation
Confirm the fix by verifying that NTLM authentication is no longer used and Kerberos is functioning correctly.
- Post-fix check: Run `net session` again; NTLM should not appear in the output.
- Re-test: Re-run the Nessus scan (plugin ID 34861); it should no longer report NTLM authentication.
- Smoke test: Verify users can still access the web application using their standard credentials via Kerberos.
- Monitoring: Monitor Windows Security Event Logs for successful Kerberos authentications (Event ID 4768).
net session6. Preventive Measures and Monitoring
Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.
- Baselines: Update your security baseline or group policy to disable NTLM authentication by default.
- Pipelines: Implement configuration management tools to enforce secure authentication settings across servers.
- Asset and patch process: Regularly review server configurations for outdated protocols like NTLM during routine maintenance.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 2: Kerberos configuration errors can cause authentication failures. Ensure proper DNS and SPN settings.
- Roll back: Re-enable NTLM authentication in your web server configuration to restore previous functionality.
8. References and Resources
- Vendor advisory or bulletin: https://docs.microsoft.com/en-us/windows-server/security/ntlm-authentication/ntlm-authentication-schemes
- NVD or CVE entry: No specific CVE for NTLM detection, but related attacks exist (e.g., CVE-2019-0780).
- Product or platform documentation relevant to the fix: https://docs.microsoft.com/en-us/iis/config/authentication/configure-ntlm-authentication