Potential NetNTLMv1 Downgrade Attack
Identifies registry modification to force the system to fall back to NTLMv1 for authentication. This modification is
possible with local administrator privileges and is commonly referred to as a NetNTLMv1 downgrade attack
.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/04/14"
3integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows", "crowdstrike"]
4maturity = "production"
5updated_date = "2025/08/26"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies registry modification to force the system to fall back to NTLMv1 for authentication. This modification is
11possible with local administrator privileges and is commonly referred to as a `NetNTLMv1 downgrade attack`.
12"""
13from = "now-9m"
14index = [
15 "logs-endpoint.events.registry-*",
16 "endgame-*",
17 "logs-m365_defender.event-*",
18 "logs-sentinel_one_cloud_funnel.*",
19 "logs-windows.sysmon_operational-*",
20 "logs-crowdstrike.fdr*",
21]
22language = "eql"
23license = "Elastic License v2"
24name = "Potential NetNTLMv1 Downgrade Attack"
25note = """## Triage and analysis
26
27### Investigating Potential NetNTLMv1 Downgrade Attack
28
29
30### Possible investigation steps
31
32- Review the registry event logs to confirm the modification of the LmCompatibilityLevel value in the specified registry paths, ensuring the change was not part of a legitimate administrative action.
33- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information.
34- Check for any recent remote authentication attempts or sessions on the affected host to determine if unauthorized access was achieved.
35- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections.
36- Evaluate the security posture of the affected system, including patch levels and existing security controls, to identify potential vulnerabilities that could have been exploited.
37
38### False positive analysis
39
40- Administrative changes to LmCompatibilityLevel settings can trigger false positives when IT personnel intentionally modify registry settings for legitimate purposes. To handle this, create exceptions for known administrative activities by documenting and excluding these specific registry changes from alerts.
41- Software updates or installations that modify NTLM settings might be flagged as false positives. To mitigate this, maintain a list of trusted software and their expected registry changes, and configure the detection system to ignore these during update windows.
42- Automated scripts or management tools that adjust NTLM configurations for compliance or performance reasons can also cause false positives. Identify these tools and their expected behavior, then set up exclusions for their registry modifications to prevent unnecessary alerts.
43
44### Response and remediation
45
46- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
47- Re-enable NTLMv2 on the affected system by modifying the registry value back to its secure state.
48- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled.
49- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise.
50- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
51- Implement enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities.
52"""
53references = [
54 "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level",
55]
56risk_score = 47
57rule_id = "4d169db7-0323-4157-9ad3-ea5ece9019c9"
58severity = "medium"
59tags = [
60 "Domain: Endpoint",
61 "OS: Windows",
62 "Use Case: Threat Detection",
63 "Tactic: Defense Evasion",
64 "Data Source: Elastic Defend",
65 "Data Source: Elastic Endgame",
66 "Data Source: Microsoft Defender for Endpoint",
67 "Data Source: SentinelOne",
68 "Data Source: Sysmon",
69 "Data Source: Crowdstrike",
70 "Resources: Investigation Guide",
71]
72timestamp_override = "event.ingested"
73type = "eql"
74
75query = '''
76registry where host.os.type == "windows" and event.action != "deletion" and
77 registry.value == "LmCompatibilityLevel" and registry.data.strings in ("2", "1", "0", "0x00000002", "0x00000001", "0x00000000")
78'''
79
80
81[[rule.threat]]
82framework = "MITRE ATT&CK"
83[[rule.threat.technique]]
84id = "T1112"
85name = "Modify Registry"
86reference = "https://attack.mitre.org/techniques/T1112/"
87
88[[rule.threat.technique]]
89id = "T1562"
90name = "Impair Defenses"
91reference = "https://attack.mitre.org/techniques/T1562/"
92[[rule.threat.technique.subtechnique]]
93id = "T1562.010"
94name = "Downgrade Attack"
95reference = "https://attack.mitre.org/techniques/T1562/010/"
96
97
98
99[rule.threat.tactic]
100id = "TA0005"
101name = "Defense Evasion"
102reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating Potential NetNTLMv1 Downgrade Attack
Possible investigation steps
- Review the registry event logs to confirm the modification of the LmCompatibilityLevel value in the specified registry paths, ensuring the change was not part of a legitimate administrative action.
- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information.
- Check for any recent remote authentication attempts or sessions on the affected host to determine if unauthorized access was achieved.
- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections.
- Evaluate the security posture of the affected system, including patch levels and existing security controls, to identify potential vulnerabilities that could have been exploited.
False positive analysis
- Administrative changes to LmCompatibilityLevel settings can trigger false positives when IT personnel intentionally modify registry settings for legitimate purposes. To handle this, create exceptions for known administrative activities by documenting and excluding these specific registry changes from alerts.
- Software updates or installations that modify NTLM settings might be flagged as false positives. To mitigate this, maintain a list of trusted software and their expected registry changes, and configure the detection system to ignore these during update windows.
- Automated scripts or management tools that adjust NTLM configurations for compliance or performance reasons can also cause false positives. Identify these tools and their expected behavior, then set up exclusions for their registry modifications to prevent unnecessary alerts.
Response and remediation
- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Re-enable NTLMv2 on the affected system by modifying the registry value back to its secure state.
- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled.
- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities.
References
Related rules
- Disabling Lsa Protection via Registry Modification
- Microsoft Windows Defender Tampering
- Encoded Executable Stored in the Registry
- Executable File Creation with Multiple Extensions
- Code Signing Policy Modification Through Registry