In the modern Microsoft environment, NTLM (“NT Lan Manager”) is a security threat you should keep an eye on. Especially when it’s about the cloud environment, Microsoft warns you to deny it before accessing Azure resources.
However, things have not always been that way.
If you have been involved in Microsoft IT Systems for a long time, you will be familiar with the NTLM authentication protocol. In fact, NT LAN Manager was first introduced as far back as 1993 with the introduction of Windows NT 3.1. In 1994, it was updated to NTLM v2 as part of the NT 4.0 service pack 4 release with some security improvements to prevent replay style attacks.
Given that NTLM is a legacy protocol, Microsoft does not recommend it to be used in applications. Kerboros protocol should be used instead. Still, Gytpol’s findings show that in 2020, NTLM is still widely used within enterprises. The main reason? Backwards compatibility with older applications.
That’s a bad excuse of course. Sometimes you need to open a window, but don’t make a hole in the wall.
The good news is that with some knowledge of Group Policy, you can get a good control over it. The bad news is that it’s not so obvious: different versions of Windows have different behaviors about the protocol.
So what’s so dangerous about NTLM anyway?
A protocol of this age will have a number of security risks. For example:
NTLM v1 uses the DES block cipher algorithm using an MD4 hash. In 2012, it was proven it can be broken by brute force mainly due to the fact that a full 128-bit key is not used.
NTLM v2 uses a stronger hash algorithm and encryption than v1. Still, it can be easily exploited using either Pass The Hash (see our article on this) or Man in the Middle hacking technique.
These NTLM weaknesses are used by hackers to breach Windows machines, both as the entry point and for making a lateral movement.
Usage of NTLM in an organization could have a major impact. You should strive to block NTLM completely – and until you achieve that, you must monitor its usage on all your servers and endpoints, all the time.
This is where Gytpol’s Endpoint Configuration Security (ECS) solution can help. Our solution monitors all endpoints and servers in an organization, and detects misconfigurations.
This includes NTLM misconfiguration such as:
Detecting and alerting which endpoints and servers are configured to use NTLM
Alerting when an endpoint has made a configuration changes from Kerboros to NTLM (often the sign of a suspicious attack vector)
Validating that usage of NTLM via Group Policy has been applied correct for all different Windows OS versions
Monitoring the network traffic to assure that NTLM is not used for accessing Azure resources from the on-prem network
SecOps and IT Admins now have total visibility of configuration security risks in their organization. Also, with the help of the Gytpol remediation, the misconfiguration can be fixed immediately without any interruption to the employee whether they are connected to the network or working from home remotely.
If you are interested in getting visibility of your Endpoint Configuration Security risk posture on all endpoints in your organization please contact us for a demo and free trial.
