Internal pentest of the financial organization, late 2024. Domain on Windows Server 2019, GPO Network security: LAN Manager authentication level put in the level of 5 - Send NTLMv2 response only. Refuse LM & NTLM. I lifted Responder to the VLAN server and got NetNTLMv1 hash from file server rights after twenty minutes.
The administrator was sure: NTLMv1 he turned off three years ago.
The hash flew from the legacy application on the old IIS, which requested NTLMv1 through its own NTLM flags in CHALLENGE. The domain controller shared this hash via MS-NRPC without looking at LmCompatibilityLevel. The Silverfort study, published in January 2025, confirmed that this is not a private bug, but an architectural problem of Active Directory, affecting any environment with on-prem applications. Below - analysis of the mechanism, practical audit and the scenario of operation.
The place of NTLMv1 in the attack chain on Active Directory
NTLMv1 is not an independent exploit. This is a weak link of authentication that the attacker pulls at several stages of kill chain. Understanding the position of NTLMv1 in the chain determines which tool to take and what to look for.
Credential Access - interception of NetNTLMv1-hesha. Responder responds to LLMNR/NBT-NS queries and collects hashes through Force Authentication (T1187) or Network Sniffing (T1040) NTLMv1 uses DES - overclocking challenge-response to GPU takes minutes.
Password Cracking (T1110.002) - NetNTLMv1-hash is converted to NT hash via rainbow tables. Services like crack.sh cope in time from minutes to 24 hours (DESspace is completely covered by rainbow tables). NTLMv2 does not break in this way - the difference is fundamental.
Lateral Movement Pass the Hash (T1550.002) The NT has received works for authentication on other servers without purchasing a password. CrackMapExec, impacket-psexec, impacket-wmiexec The choice depends on the target car.
NTLM Relay - Name Resolution Poisoning and SMB RelayT1557.001) NTLMv1-session is redirected to another server. NTLMv2 AV_PAIRS tie the response to a specific server, and relay becomes more complicated. In NTLMv1 there is no such binding - relay trivial.
Separate vector - Downgrade Attack (T1689, Defense Evasion): the attacker forcibly lowers the NTLM version, forcing the client to send NTLMv1. It is enough to control the server or raise a rogue service that in CHALLENGE will request NTLMv1.
Context of the threat: according to the CrowdStrike Global Threat Report 2025, 75% of the 2024 incursions used valid accounts. IBM X-Force records an increase in attacks on credentials by 71% year-on-year. NTLMv1 is one of the cheapest paths to credentials inside the network: you don’t need phishing, you don’t need 0-day. Raised Responder, wait.
Why GPO LmCompatibilityLevel = 5 does not disable NTLMv1
Politics Network security: LAN Manager authentication level manages the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. Levels of 0–3 determine that Sends a client (NEGOTIATE_MESSAGE). Levels 4-5 - what Accepts the server with direct authentication (CHALLENGE_MESSAGE). Level 5: The NTLMv2 client only refuses LM and NTLMv1 the server.
And now, where the logic breaks.
"Server" here is a Windows machine that processes the NTLM query directly. In real AD, authentication goes through an intermediary: client -> application server -> domain controller (via Netlogon/MS-NRPC). LmCompatibilityLevel manages the first arrow and server behavior as a direct participant. He does not manage that DC receives from the application server via MS-NRPC for validation.
The Silverfort study (January 2025) revealed the mechanism of bypass: on-prem applications are configured so that they ask NTLMv1 from customers through the NTLM flags at CHALLENGE, ignoring LmCompatibilityLevel on a client machine. The client obeys the application server: if CHALLENGE requests NTLMv1 - the client responds to NTLMv1. The server then forwards NTLMv1-response to the domain controller via MS-NPSC. DC performs validation and adopts NTLMv1, because LmCompatibilityLevel controls its behavior as a server in direct authentication rather than validated via Netlogon.
According to Silverfort, 64% of Active Directory accounts are regularly authenticated via NTLM. The share of NTLMv1 depends on a specific environment, but even one on-prem application with the wrong configuration turns LmCompatibilityLevel = 5 into a fiction.
MSRC, when responding to disclosure, pointed out that bypass is not a vulnerability, but the expected behavior. However, for two months, Microsoft announced the complete removal of NTLMv1 from Windows 11 24H2 and Windows Server 2025. Nuance: Server 2025 no longer supports Request NTLMv1, but domain controllers on Server 2025 still accept NTLMv1 Validation via MS-NRPC. If there is at least one server on the network not for 2025 with an legacy application or non-Windows client - the attack works.
Another vector that is often forgotten: the key LmCompatibilityLevel located outside the standard GPO path (HKLM\SOFTWARE\Policies) If the policy has been applied and then translated into “Not Defined” – the value in the registry remains (the so-called tattoo effect). The old GPO with LmCompatibilityLevel = 0 or 1 can live in the registry of machines that have long been removed from under this policy. According to Microsoft (Active Directory Hardening Series), the change in LmMPCAPibilityLevel comes into force immediately, without reboot - but only if the key is actually updated.
At risk:
• Organizations with self-written or third-party on-prem applications using NTLM
• Networks with non-Windows clients (macOS, GNU/Linux) connecting to Windows services
• Infrastructure with legacy devices: printers, NAS, industrial controllers
Detection of NTLMv1: NTLM authentication and network traffic
Windows Event ID 4624 and NTLM Operational Log
The main source for the detection of NTLMv1 - Event ID 4624 (An account was logged on) in Security Log. Field Package Name (NTLM only) contains the version: NTLM V1 or NTLM V2. Field Authentication Package - NTLM.
And here is the moment that almost everyone misses in practice: 4624 is logged by the car where the logon occurred, not on the domain controller. DC is logging Event ID 4776 (The etc. computer to validate the credentials for an account), but 4776 does not contain a version of NTLM. For a complete picture, you need to collect 4624 from all servers and workstations of the domain.
PowerShell to search for NTLMv1 authentications on domain controllers for the week:
Additional level: three NTLM-audit policies in Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options:
• Network Security: Restrict NTLM: Audit NTLM authentication in this domain-> Enable all
• Network Security: Restrict NTLM: Audit Incoming NTLM Traffic-> Enable auditing for domain accounts
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers-> Audit all
After the event is included, it is written in Applications and Services Logs -> Microsoft -> Windows -> NTLM -> Operational:
These events show where NTLM is used, but not the version (v1/v2). To determine the version, you still need 4624 on the final car.
Windows 11 24H2 and Server 2025 are changing the situation: new NTLM audit events have been added to determine the NTLM version (v1/v2) including at the DC level – before it was possible only through the parsing of the pcap. Specific Event ID - in the current Microsoft documentation (NTLM deprecation announcement series). Inverse compatibility is not planned - events are available only on new versions of the OS.
Wireshark: filters for NTLMv1 traffic on the network
Event Log shows the result. Wireshark shows the process - and does not depend on the OS version.
To filter the entire NTLM-traffic: display filter ntlmssp. To highlight AUTHENTICATE-messages (contained hash): ntlmssp.messagetype == 0x00000003.
How to determine the GUI version: expand NTLMSSP -> NTLM Response in the AUTHENTICATE package. Exactly 24 bytes - NTLMv1. More than 24 bytes (contains NTLMv2 blob with AV_PAIRS, timestamp, target info) - NTLMv2. Just count the length, and everything is clear.
For automation on a large pcap:
NTLM relay attack: from NTLMv1 interception to lateral movement
Adjustments to the environment
• Scenario : internal pentest, grey box (used low-privileged user data)
• Attacker OS : Kali Linux 2024.x+ or any GNU/Linux with Python 3.10+
• Tools : Responder (github.com/lgandx/Responder, actively supported), Impacket (github.com/fortra/impacket, actively supported), CrackMapExec/NetExex
• Network conditions : L2-access in target VLAN, no 802.1X on the connection port
• Target infra : Active Directory, at least one on-prem legacy service or non-Windows client
Checklist: elimination of legacy authentication in Active Directory
Checklist for inclusion in the pentest report or transfer to the administrator:
1. Insert NTLM audit via GPO: three Restrict NTLM (ATuide NTLM authentication, Audit Incoming NTLM, Traffic Outgoing NTLM) - collect at least 14 days
2. Collect Event ID 4624 from all servers and DC, filter by Package Name = NTLM V1- compile a full list of NTLMv1 sources (machine name + process + account)
3. Put LmCompatibilityLevel = 5 via GPO on DC and all type servers: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: LAN Manager authentication level -> «Send NTLMv2 response only. Refuse LM & NTLM»
4. Check the register for tattooed values : key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel- if not, the OS uses silence (level 3 for Win7+, level 0 for older OS); if the value < 5, GPO has not been applied or redefined by another policy; if the policy is deleted, but the value remains - manual cleaning on each machine
5. On-prem application audit: any application with its own NTLM settings can bypass GPO - check the configuration of IIS, legacy ERP, self-written services
6. Disable LLMNR (Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off Multicast Name Resolution) and NBT-NS (through network adapter settings) - eliminates the main interception vector
7. Insert SMB Signing on all servers - blocks NTLM relay
8. Insert Credential Guard: Isolate NTLM secrets in LSAiso and makes it difficult to extract NT-hshes from memory (mitigates Pass the Hash) but does not block NTLMv1 authentication over the network - Lmmcap Beficiuel and NTLM-blocking remain necessary
9. Identify Kerberos fallback: the reasons are the missing SPN, duplicate SPN, IP address instead of hostname. Event ID 4769 with failure code on DC will show unsuccessful Kerberos attempts
10. Plan for migration to Server 2025: the only version where NTLMv1 is not possible at the OS level (but DC validates NTLMv1 from old servers via MS-NRPC)
Conclusion
Most AD pentest reports contain a recommendation to “disable NTLMv1 via GPO.” Most customers are sure that they have done this for a long time. The problem is not GPO or administrators.
The problem in the mental model: LmCompatibilityLevel = 5 is perceived as a fence around the entire domain. In practice, this is a lock on one door, and application-level NTLM-configuration is an open window nearby. Silverfort has confirmed what we’ve seen on projects for years: no standard SIEM-dashboard will show that a specific on-prem application requests NTLMv1 from customers. Event ID 4624 with field NTLM V1 - the only reliable indicator, and it must be collected from ALL-sources, not just with DC. On my projects, none of the surveyed organizations did it systematically - only collected from domain controllers, where there is no information about the NTLM version.
Microsoft will remove NTLMv1 from Windows in the next couple of years. Legacy-device devices - printers, NAS, OT controllers - will generate NTLMv1 traffic for another five to seven years. Organizations that today are not invested in NTLM monitoring at the network level (not GPO ticks, but real pcap and collecting 4624 from all hosts) will find in a year that they have “protected” the protocol that continues to fly on their VLAN.
The administrator was sure: NTLMv1 he turned off three years ago.
The hash flew from the legacy application on the old IIS, which requested NTLMv1 through its own NTLM flags in CHALLENGE. The domain controller shared this hash via MS-NRPC without looking at LmCompatibilityLevel. The Silverfort study, published in January 2025, confirmed that this is not a private bug, but an architectural problem of Active Directory, affecting any environment with on-prem applications. Below - analysis of the mechanism, practical audit and the scenario of operation.
The place of NTLMv1 in the attack chain on Active Directory
NTLMv1 is not an independent exploit. This is a weak link of authentication that the attacker pulls at several stages of kill chain. Understanding the position of NTLMv1 in the chain determines which tool to take and what to look for.
Credential Access - interception of NetNTLMv1-hesha. Responder responds to LLMNR/NBT-NS queries and collects hashes through Force Authentication (T1187) or Network Sniffing (T1040) NTLMv1 uses DES - overclocking challenge-response to GPU takes minutes.
Password Cracking (T1110.002) - NetNTLMv1-hash is converted to NT hash via rainbow tables. Services like crack.sh cope in time from minutes to 24 hours (DESspace is completely covered by rainbow tables). NTLMv2 does not break in this way - the difference is fundamental.
Lateral Movement Pass the Hash (T1550.002) The NT has received works for authentication on other servers without purchasing a password. CrackMapExec, impacket-psexec, impacket-wmiexec The choice depends on the target car.
NTLM Relay - Name Resolution Poisoning and SMB RelayT1557.001) NTLMv1-session is redirected to another server. NTLMv2 AV_PAIRS tie the response to a specific server, and relay becomes more complicated. In NTLMv1 there is no such binding - relay trivial.
Separate vector - Downgrade Attack (T1689, Defense Evasion): the attacker forcibly lowers the NTLM version, forcing the client to send NTLMv1. It is enough to control the server or raise a rogue service that in CHALLENGE will request NTLMv1.
Context of the threat: according to the CrowdStrike Global Threat Report 2025, 75% of the 2024 incursions used valid accounts. IBM X-Force records an increase in attacks on credentials by 71% year-on-year. NTLMv1 is one of the cheapest paths to credentials inside the network: you don’t need phishing, you don’t need 0-day. Raised Responder, wait.
Why GPO LmCompatibilityLevel = 5 does not disable NTLMv1
Politics Network security: LAN Manager authentication level manages the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. Levels of 0–3 determine that Sends a client (NEGOTIATE_MESSAGE). Levels 4-5 - what Accepts the server with direct authentication (CHALLENGE_MESSAGE). Level 5: The NTLMv2 client only refuses LM and NTLMv1 the server.
And now, where the logic breaks.
"Server" here is a Windows machine that processes the NTLM query directly. In real AD, authentication goes through an intermediary: client -> application server -> domain controller (via Netlogon/MS-NRPC). LmCompatibilityLevel manages the first arrow and server behavior as a direct participant. He does not manage that DC receives from the application server via MS-NRPC for validation.
The Silverfort study (January 2025) revealed the mechanism of bypass: on-prem applications are configured so that they ask NTLMv1 from customers through the NTLM flags at CHALLENGE, ignoring LmCompatibilityLevel on a client machine. The client obeys the application server: if CHALLENGE requests NTLMv1 - the client responds to NTLMv1. The server then forwards NTLMv1-response to the domain controller via MS-NPSC. DC performs validation and adopts NTLMv1, because LmCompatibilityLevel controls its behavior as a server in direct authentication rather than validated via Netlogon.
According to Silverfort, 64% of Active Directory accounts are regularly authenticated via NTLM. The share of NTLMv1 depends on a specific environment, but even one on-prem application with the wrong configuration turns LmCompatibilityLevel = 5 into a fiction.
MSRC, when responding to disclosure, pointed out that bypass is not a vulnerability, but the expected behavior. However, for two months, Microsoft announced the complete removal of NTLMv1 from Windows 11 24H2 and Windows Server 2025. Nuance: Server 2025 no longer supports Request NTLMv1, but domain controllers on Server 2025 still accept NTLMv1 Validation via MS-NRPC. If there is at least one server on the network not for 2025 with an legacy application or non-Windows client - the attack works.
Another vector that is often forgotten: the key LmCompatibilityLevel located outside the standard GPO path (HKLM\SOFTWARE\Policies) If the policy has been applied and then translated into “Not Defined” – the value in the registry remains (the so-called tattoo effect). The old GPO with LmCompatibilityLevel = 0 or 1 can live in the registry of machines that have long been removed from under this policy. According to Microsoft (Active Directory Hardening Series), the change in LmMPCAPibilityLevel comes into force immediately, without reboot - but only if the key is actually updated.
At risk:
• Organizations with self-written or third-party on-prem applications using NTLM
• Networks with non-Windows clients (macOS, GNU/Linux) connecting to Windows services
• Infrastructure with legacy devices: printers, NAS, industrial controllers
Detection of NTLMv1: NTLM authentication and network traffic
Windows Event ID 4624 and NTLM Operational Log
The main source for the detection of NTLMv1 - Event ID 4624 (An account was logged on) in Security Log. Field Package Name (NTLM only) contains the version: NTLM V1 or NTLM V2. Field Authentication Package - NTLM.
And here is the moment that almost everyone misses in practice: 4624 is logged by the car where the logon occurred, not on the domain controller. DC is logging Event ID 4776 (The etc. computer to validate the credentials for an account), but 4776 does not contain a version of NTLM. For a complete picture, you need to collect 4624 from all servers and workstations of the domain.
PowerShell to search for NTLMv1 authentications on domain controllers for the week:
This script is looking for 4624 on DC only. For full coverage, you need to run a similar request on each type server - or centralize the collection through the SIEM. On my projects, it was the type servers that were the source of NTLMv1, not DC.
Additional level: three NTLM-audit policies in Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options:
• Network Security: Restrict NTLM: Audit NTLM authentication in this domain-> Enable all
• Network Security: Restrict NTLM: Audit Incoming NTLM Traffic-> Enable auditing for domain accounts
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers-> Audit all
After the event is included, it is written in Applications and Services Logs -> Microsoft -> Windows -> NTLM -> Operational:
These events show where NTLM is used, but not the version (v1/v2). To determine the version, you still need 4624 on the final car.
Windows 11 24H2 and Server 2025 are changing the situation: new NTLM audit events have been added to determine the NTLM version (v1/v2) including at the DC level – before it was possible only through the parsing of the pcap. Specific Event ID - in the current Microsoft documentation (NTLM deprecation announcement series). Inverse compatibility is not planned - events are available only on new versions of the OS.
Wireshark: filters for NTLMv1 traffic on the network
Event Log shows the result. Wireshark shows the process - and does not depend on the OS version.
To filter the entire NTLM-traffic: display filter ntlmssp. To highlight AUTHENTICATE-messages (contained hash): ntlmssp.messagetype == 0x00000003.
How to determine the GUI version: expand NTLMSSP -> NTLM Response in the AUTHENTICATE package. Exactly 24 bytes - NTLMv1. More than 24 bytes (contains NTLMv2 blob with AV_PAIRS, timestamp, target info) - NTLMv2. Just count the length, and everything is clear.
For automation on a large pcap:
Lines with an empty field ntlmssp.ntlmv2_response with non-empty auth - candidates for NTLMv1. Empty NTLMv2-field means that the client has sent NTLMv1-response.
NTLM relay attack: from NTLMv1 interception to lateral movement
Adjustments to the environment
• Scenario : internal pentest, grey box (used low-privileged user data)
• Attacker OS : Kali Linux 2024.x+ or any GNU/Linux with Python 3.10+
• Tools : Responder (github.com/lgandx/Responder, actively supported), Impacket (github.com/fortra/impacket, actively supported), CrackMapExec/NetExex
• Network conditions : L2-access in target VLAN, no 802.1X on the connection port
• Target infra : Active Directory, at least one on-prem legacy service or non-Windows client
Checklist: elimination of legacy authentication in Active Directory
Checklist for inclusion in the pentest report or transfer to the administrator:
1. Insert NTLM audit via GPO: three Restrict NTLM (ATuide NTLM authentication, Audit Incoming NTLM, Traffic Outgoing NTLM) - collect at least 14 days
2. Collect Event ID 4624 from all servers and DC, filter by Package Name = NTLM V1- compile a full list of NTLMv1 sources (machine name + process + account)
3. Put LmCompatibilityLevel = 5 via GPO on DC and all type servers: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: LAN Manager authentication level -> «Send NTLMv2 response only. Refuse LM & NTLM»
4. Check the register for tattooed values : key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel- if not, the OS uses silence (level 3 for Win7+, level 0 for older OS); if the value < 5, GPO has not been applied or redefined by another policy; if the policy is deleted, but the value remains - manual cleaning on each machine
5. On-prem application audit: any application with its own NTLM settings can bypass GPO - check the configuration of IIS, legacy ERP, self-written services
6. Disable LLMNR (Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off Multicast Name Resolution) and NBT-NS (through network adapter settings) - eliminates the main interception vector
7. Insert SMB Signing on all servers - blocks NTLM relay
8. Insert Credential Guard: Isolate NTLM secrets in LSAiso and makes it difficult to extract NT-hshes from memory (mitigates Pass the Hash) but does not block NTLMv1 authentication over the network - Lmmcap Beficiuel and NTLM-blocking remain necessary
9. Identify Kerberos fallback: the reasons are the missing SPN, duplicate SPN, IP address instead of hostname. Event ID 4769 with failure code on DC will show unsuccessful Kerberos attempts
10. Plan for migration to Server 2025: the only version where NTLMv1 is not possible at the OS level (but DC validates NTLMv1 from old servers via MS-NRPC)
Conclusion
Most AD pentest reports contain a recommendation to “disable NTLMv1 via GPO.” Most customers are sure that they have done this for a long time. The problem is not GPO or administrators.
The problem in the mental model: LmCompatibilityLevel = 5 is perceived as a fence around the entire domain. In practice, this is a lock on one door, and application-level NTLM-configuration is an open window nearby. Silverfort has confirmed what we’ve seen on projects for years: no standard SIEM-dashboard will show that a specific on-prem application requests NTLMv1 from customers. Event ID 4624 with field NTLM V1 - the only reliable indicator, and it must be collected from ALL-sources, not just with DC. On my projects, none of the surveyed organizations did it systematically - only collected from domain controllers, where there is no information about the NTLM version.
Microsoft will remove NTLMv1 from Windows in the next couple of years. Legacy-device devices - printers, NAS, OT controllers - will generate NTLMv1 traffic for another five to seven years. Organizations that today are not invested in NTLM monitoring at the network level (not GPO ticks, but real pcap and collecting 4624 from all hosts) will find in a year that they have “protected” the protocol that continues to fly on their VLAN.
