Windows environments continue to be vulnerable to a range of weaknesses related to NTLM. NTLM is a common authentication feature in Windows systems. This article provides an overview of how recent vulnerabilities are exploited, why they are so serious, and how to respond.
I will explain what makes these weaknesses so attractive to attackers, how the attacks are carried out, and what measures and logging mechanisms are necessary to protect the business.
CVE-2025-24054, CVE-2025-21377, CVE-2025-21308, CVE-2024-43451, CVE-2024-21320
These require minimal or no specific action from the user to be exploited.
What is needed to activate these vulnerabilities is to get the Windows machine to look at the file's content or metadata. The user only needs to see that the file exists in File Explorer.
Since it requires almost no action from users, these are attractive weaknesses for attackers. Some of the vulnerabilities are listed in the CISA KEV (Known Exploited Vulnerabilities) database.
Windows handles NTLM authentication regardless of zone definitions (Intranet/Trusted/Public). It also does not distinguish whether the IP is within or outside the private IP-ranges (RFC1918).
This also works when the attacker is outside the private network. As long as SMB traffic reaches the attacker's system, there is an opportunity to exploit this.
The attacker can also use an "internal" compromised system with an SMB service that receives NTLM hash from a user. As an attacker, you want a user with more permission and access.
For the system to use NTLM as the authentication method, the connection link must contain an IP address. If the connection link has an FQDN (for example, FILE-SERVER.COMPANY.COM), the system will use Kerberos as the authentication method.
The image above shows a tool that can be used to receive SMB connection and then extract NTLM hash.
Disable NTLM authentication on systems that do not have a direct need for that authentication method. This can be done via Group Policy (GPO).
Limit SMB traffic to server groups such as Domain Controllers, File Servers, and Print Servers. These services can use Kerberos as the authentication method, so there is an opportunity to limit NTLM authentication to these services.
Verify that SMB signing is enabled. This can be done via Group Policy (GPO).
Update systems continuously according to routine.
Enable NTLM audit. In the standard setup, this is not enabled. The reason this should be turned on is because authentication logs (Event ID: 4624) – where NTLM is the authentication method – do not contain information about the client connecting to the system.
Verify that NTLM logs are collected to SIEM or by the SOC service. Important Event ID is 8004, and the logs are located in: Applications and Services Logs >> Microsoft >> Windows >> NTLM >> Operational
Since NTLM log events do not exist in the security log, extra configuration is often required to collect these log data.
Learn more about our security monitoring and incident response (SOC) services here >