NTLM - New Technology LAN Manager & the attack possibilities

Table of Contents

Background knowledge. What is NTLM?

The abbreviation NTLM stands for New Technology LAN Manager, which is an authentication method developed and provided by Microsoft based on a challenge-response mechanism.

The first NTLM version, which was first released in 1993, is now known as NTLMv1. This version should no longer be used. Just five years later, in 1998, Microsoft released the NTLMv2 version that is commonly used today.

You are hacked, what to do?
If you have been the victim of a successful hacker attack,
read our post.
Go to Article

Differences between NTLMv1 and NTLMv2

  • The client adds a timestamp when submitting the username to the server.
  • The length of the "Challenge" used is variable and therefore more difficult to crack.
  • The weak DES algorithm was replaced by the HMAC_MD5 algorithm as part of the challenge-response protocol. (Not to be confused with creating the nt hash using md4). The “newer” MD5 algorithm is no longer part of the state of the art and should no longer be used because it is vulnerable to attacks.

 

NTLMv2 is still widely used in networks, especially since older services and protocols are not deactivated. This is why it is used. If the network infrastructure and the systems used allow it, this should be replaced by newer protocols such as Kerberos!

Difference between NT hash, NTLM and NetNTLMv1/v2

In the context of the topic of NTLM, there is always confusion in the distinction between terminology.

NT hash: The NT hash (Windows NT) can be found together with the LM hash (LAN Manager) in the SAM database (Security Accounts Manager). Attacks can be run against this to crack the hash or it can be used for pass-the-hash attacks.

NTLM: Authentication protocol provided by Microsoft. This has since been replaced by Kerberos. NTLM exists in two versions, the older NTLMv1 also known as Net-NTLMv1 and the version NTLMv2 or Net-NTLMv2. The newer version can no longer be viewed as state of the art and should be replaced where possible by successor solutions such as Kerberos.

How does NTLMv2 work?

NTLMv2 uses a challenge-response procedure to authenticate the requesting network participant. The following communication takes place between client and server:

  • The client sends a username to the host.
  • In response, the server sends a random number (challenge).
  • From this, the client calculates a hash value in conjunction with the NT hash and sends it back (response).
  • Since the server knows the user's NT hash, it also calculates this hash value for comparison.
    • If both values ​​match, the authenticity of the client could be confirmed (confirmation).
    • If the two hash values ​​differ from each other, the request is rejected (denial).
NTLM Authentication

Attack: Attack options using man-in-the-middle

It should be one  If an attacker manages to obtain an NTLMv2 hash, he can try to crack it and obtain the password or “interpose” himself between the communication between client and server and intercept information about (changed) requests. We have explained how this is possible in the articles LLMNO, NetBIOS or IPv6 described. 

To illustrate the attack options, a laboratory environment was set up containing:

  • Windows Server 2016 as domain controller
  • Windows 10 as a client
  • Kali Linux as an attacker, with the tools
    • reply
    • mitm6
    • ntlmrelayx (impacket)

To carry out the scenarios described below, the network must be configured so that IPv6 is active and there is no automatic filtering of packets (in virtual environments this may have to be set actively).

In addition, it was shown that in this laboratory environment the Active Directory certificate services must be installed and set up on the domain controller to recreate the relay on LDAPS. 

NTLM relay to SMB

In the first attack scenario, the NTLM authentication is relayed to SMB. To do this, we use the Windows behavior for name resolution. If the client is looking for a release that the known DNS cannot resolve, the query is made using alternative (predecessor) protocols, e.g. LLMNR.

This query can be intercepted by the attacker, who poses as a corresponding server and passes on the query in a modified form. Because an NTLM hash does not contain any information about the destination or sender. In our case, the security account management (SAM – Security Account Manager) is queried to output all password hashes of the existing users stored locally on the system:

Commands to start responder and ntlmrelayx

Before starting the responder, the SMB and http options must be deactivated in the configuration. The responder listens on the interface eth0.

Ntlmrelayx should forward to the IP 192.168.5.5, in this case the local Windows 10 client. Dumping the SAM data is standard behavior of the tool for SMB.

Display of results after searching for the share \\my on the DomainController

The output shows the corresponding LM or NT password hashes of the users, including, for example, Administrator and myUser. These hashes can now be used for offline attacks on the passwords using brute force  or used for authentication in Windows domains. 

NTLM relay to LDAP

In the next example, forwarding takes place using IPv6 to LDAP. This means that an unauthorized user without permissions in AD can query domain information. The attack is carried out using mitm6 and ntlmrelayx. 

Commands to start mitm6 and ntlmrelayx

It is then sufficient for a user to open the browser on the Windows 10 client. The standard behavior is that it first searches for provided proxy configurations, which the attacker intercepts using mitm6. The default behavior of ntlmrelayx when redirecting to ldap is to query domain information, which is stored in the local directory.

Successful request for domain information
Results of the query

NTLM relay to LDAPS

Finally, the request is forwarded using LDAPS. The experimental setup is the same as in the last scenario, but ntlmrelayx should now establish a connection to LDAPS and create a PC. We could then use this for further attacks. 

Commands to start mitm6 and ntlmrelayx
Creation of “AttackerPC” using mitm6; Control in the DomainController

Prevention: Ways to prevent attacks using NTLM relay

The best approach to prevent the attacks mentioned is to configure the network or the components involved accordingly and securely. Some options that also protect against the attacks described have already been presented in our previous articles, including “IPv6—Man in the Middle"Or"LLMNR poisoning“. In addition, the following measures prevent the possibility of successfully executing the attacks shown above.

How does package signing work?

With package signing, every package sent is given a signature, which enables the client and server to determine that it has not been changed. However, it does not protect against packets being read. Signing should not be confused with encryption here.

With SMBv2, for example, a corresponding hash is calculated using HMAC-SHA256, taking the entire message into account. 

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/a3e9ea1e-53c8-4cff-94bd-d98fb20417c0

For example: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/8b80e60b-7514-442b-baf4-eb785d0b0e2c

SMB signing

SMB signing serves as an authenticity and integrity feature for SMB packages used when accessing resources within the Active Directory. The client and server sign the SMB packets during communication, so that SMB packets can be prevented from being changed or forwarded. (Details at https://www.prosec-networks.com/blog/smb-server-message-block-protocol/)

Corresponding signing is only recommended from version SMBv2 onwards, as the packet size with SMBv1 is so small that performance problems can arise here. Furthermore, when configuring, it is important to ensure that signing is required and not just desired or enabled.

SMB signing can be configured through GPOs on servers and clients. As always, we advise you to check this in appropriate test settings before implementation!

Recommended settings:

Microsoft network (client): Digitally sign communication (always) Enabled

Microsoft network (client): Digitally sign communication (if server agrees) Disabled

Microsoft network (server): Digitally sign communications (always) Enabled

Microsoft network (server): Digitally sign communication (if client agrees) Disabled

LDAP signature request for the client, using DC Group Policy (GPO)

LDAP signing

Similar to signing using SMB, signing can also be set for LDAP. LDAP signing provides the LDAP connection with a digital signature.

The setting is also done using GPO on the domain controller for server and client:

LDAP Server Signature Request (GPO):

Desktop -> Guidelines ->  Windows settings -> security settings ->  local guidelines -> Security options -> Enable “Domain Controller: Server Signature Requirements for LDAP Servers”.

LDAP signature request for the server (GPO)

LDAP signature request for the client, using DC Group Policy (GPO):

Desktop -> Guidelines ->  Windows settings -> security settings ->  local guidelines -> Security options -> "Network Security: LDAP Client Signing Requirements -" Enable

LDAP channel binding

A missing channel binding allows authentications to be forwarded to LDAPS. 

With channel binding, a hash of the certificate (of the server) is created and appended to the normal packet. The server performs the same step and then checks the hash of its certificate against the hash value that was appended to the LDAPS packet.

In March 2020, Microsoft released updates to use channel binding.

Note: In the test environment mentioned above, the updates must be installed accordingly, otherwise channel binding is not available.

– Channel binding can be configured on domain controllers by enabling the “Domain controller: LDAP server channel binding token requirements” group policy. This is located in Group Policy Management under the path Computer > Policies > Windows Settings > Security Settings > Local Policies > Security Options

– The policy must be configured to the “Always” option and the policy must be enabled.

Note: Whether LDAP signing and channel binding are active can easily be checked using LdapRelayScan https://github.com/zyn3rgy/LdapRelayScan.git be checked. A valid domain user must be used to verify LDAP signing.

LDAP signing and channel binding disabled
LDAP signing and channel binding activated

Detection: How attacks can be detected in the network

The direct attack is difficult to detect because the use of the protocols described is standard behavior in the network. One way of detection is to monitor the devices in the network for the protocols underlying the attack (e.g. LLMNR). Answers to these inquiries usually do not come from the systems available on the internet; details can be found at: https://www.prosec-networks.com/blog/llmnr-poisoning/

This detection can also be configured in the firewall. The responses that the attacker sends in the scenarios presented above should only come from known and authorized systems (LLMNR, wpad). If there is a response in the network from an IP that is not defined, the attacker can be identified.

React: React to detected attacks

If an attack is detected using the methods described in the last section, you should obtain as much information about it as possible. The device in question should then be blocked.

Additionally, all existing logs should be searched for activity from this IP. In addition to the logs from the firewalls and network devices, this also includes the event logs from the domain controllers.

ISMS controls:

IT-Grundschutz Compendium:

OPS.1.1.3: Patch and change management

NET.1.2: Network Management

ISO27001:

A.12.4.1 Event logging

A.13.1 Network security management

Increase the security of your IT system now!
You will receive detailed advice from us!
Contact us now
Newsletter form (#7)

Become a Cyber ​​Security Insider

Get early access and exclusive content!


By signing up, you agree to receive occasional marketing emails from us.
OTHER CONTRIBUTIONS

Table of Contents

PSN_KU_Cover
NewsLetter Form Pop Up New

Become a Cyber ​​Security Insider

Subscribe to our knowledge base and get:

Early access to new blog posts
Exclusive content
Regular updates on industry trends and best practices


By signing up, you agree to receive occasional marketing emails from us.