Researchers discovered a new NTLM vulnerability exploited by Russian threat actors that allows attackers to leverage weaknesses in NTLM authentication to deliver the Spark RAT malware.Â
NTLM’s outdated cryptography and lack of modern security features make it susceptible to attacks that include credential theft and relay attacks and pose a significant security risk to organizations still relying on this protocol.
Despite organizations enforcing Group Policy to disable NTLMv1, misconfigured on-premises applications can still utilize this insecure protocol that effectively bypasses the security measure.
A move toward authentication protocols that are more secure is indicated by Microsoft’s decision to deprecate the NTLM active development protocol.
Even though this step improves security by discouraging the use of the vulnerable NTLMv1, it is still difficult to completely remove it because of the dependencies that are built into legacy systems.
The push for organizations to modernize their authentication infrastructure and adopt security measures that are stronger and more resilient is strengthened.
NTLM authenticates users in Windows by exchanging messages where the client initiates with Negotiate, the server responds with a Challenge, the client submits hashed credentials in an Authenticate message, and the server verifies the hash and grants access if valid.
NTLMv1 is lacking strong encryption, which is a robust challenge and source/destination verification was susceptible to brute-force attacks and relay attacks.
NTLMv2 addressed these issues by implementing RC4 encryption by introducing a client challenge and incorporating AV_PAIRS for enhanced session key uniqueness that significantly improved security.
The application server lacks user credentials and leverages the RPC Netlogon interface to remotely evaluate the NTLM message on the Domain controller, then the server submits the NTLM message and challenges NetrLogonSamLogonEx.
The Domain Controller validates the message using stored credentials by generating a success response and PAC for authorization and session key establishment if successful. Otherwise, it returns an error.
Disabling NTLMv1 through Group Policy by setting the LMCompatibilityLevel registry key on Domain Controllers prevents them from processing NTLMv1 authentication messages that effectively force clients to use NTLMv2 for authentication.
This mechanism does not completely eliminate NTLMv1, as it only prevents Domain Controllers from handling NTLMv1 requests. Clients might still attempt NTLMv1 authentication with other servers that are not configured with the same Group Policy restriction.
The MS-NRPC specification allows applications to bypass Group Policy restrictions on NTLMv1 authentication by setting the “Allow NTLMv1 authentication (MS-NLMP) when only NTLMv2 (NTLM) is allowed” flag in the NETLOGON_LOGON_IDENTITY_INFO structure that enables the use of the less secure NTLMv1 protocol even when explicitly disabled.
According to Silver Fort, the use of NTLM should be audited and applications that use NTLMv1 should be identified, while NTLM should be replaced with more modern authentication methods such as single sign-on or Kerberos instead.Â
