• 6 hours
  • Medium

Free online content available in this course.

course.header.alt.is_certifying

Got it!

Last updated on 10/31/24

Exploit the NTLM Protocol to Perform a Lateral Movement

You have your first network login credentials or your first access to a workstation or server in the domain. Now you need to continue with your attack plan and compromise other users or machines in an attempt to gain further access.

Exploit the NTLM Protocol

The NTLM protocol is one of two authentication protocols used in Microsoft environments. It allows users to prove who they are to a server.

Let’s look at several ways we can move laterally with the NTLM protocol.

NTLM Authentication

Authentication involves a challenge-response phase between the client and server.

This technique is used so the server can check that the user knows the password of the account they are using for authentication, without actually sending the password over the network.

This authentication process consists of three steps. First, the client indicates that it wants to authenticate. The server then sends it a challenge. This is just a random value that changes with each authentication request. The server saves this value. The client receives this challenge and encrypts it using the password hash as a key. It sends this encrypted version back to the server with its username.

Diagram of the three-step NTLM protocol: Negotiate, Challenge, and Authenticate
The Three Steps of the NTLM Protocol

Once this exchange has taken place, the server is in possession of two things:

  • The challenge it sent to the client

  • The client’s response, encrypted with the password hash

To finalize the authentication, the server simply checks if the response sent by the client is valid. To do this, the server has a local user database called SAM (Security Accounts Manager). This database contains a list of usernames and their password hash, called an NT hash. This eliminates the need to store plaintext passwords on the machine. When the server receives the response from the client trying to be authenticated, it receives the challenge message encrypted with this hash. The server runs the same operation to look for the user’s hash in its table, and it will use this hash to encrypt the challenge message it sends.

If the response matches what the client sent, this means that the client has used the same password and is therefore authenticated.

Diagram of NTLM response validation with the SAM database
Validating the NTLM Response

1. Receive the challenge.

2. Send the response.

3. Search for the NT hash in the SAM database.

4. Calculate the expected response using the NT hash from the SAM and the challenge.

5. Compare it with the client’s response.

For your information, this process is also possible with a domain account. Because the server doesn’t know the secret of the domain account that wants to authenticate itself, it is going to delegate the verification phase to a domain controller.

Pass-the-Hash

If you’ve managed to keep up with all this, you’ll have noticed that the user is always authenticated using the NT hash of their password only. They are never sent their password in plaintext.

Hold on a minute. What you’re telling me is that it’s the password hash that’s stored on the server to avoid storing the password in plaintext, but in the end, this same hash is enough to be authenticated?

Yes, exactly! With the NTLM protocol, whether you steal the plaintext password or the NT hash, you still have everything you need to be authenticated. In the end, we can even say that having the NT hash is the same as having the password in plaintext in the majority of cases.

During the compromise phase of the first account, if you have exploited a vulnerability on a workstation allowing you to take control of it, you may have sufficient privileges to find the local administrator’s password hash for that workstation.

However, a company’s employee workstations are often copies of the same workstation that has been configured once and reused for every other workstation, which is much simpler. This means that local users are the same everywhere, including the local admin account.

I think I see what you’re getting at…

That’s right, if you’ve compromised just one of these workstations and found the admin account’s hash, there’s a good chance that the same hash is valid on all the other workstations! This is known as pass-the-hash.

Diagram representing Pass-the-Hash: four computers locked with a password, and one machine, using the same password, that is compromised.
Pass-the-Hash

In practical terms, if you’ve stolen the hash of the local administrator’s workstation, you can try to pass the hash to other workstations using CrackMapExec. It’s a useful tool for attacking several machines at the same time by using only the hash of a compromised user.

This is how I compromised the domain during my first audit! I was able to compromise the server by using default login credentials on an application server. I then retrieved the hash of the local administrator account and used it on all the other workstations, which allowed me to find the password of a domain admin. You’ll find out what happens next with this attack in upcoming chapters!

To extract the NT hashes from the machines of local users, the  --sam  parameter must be provided to CrackMapExec, along with the login credentials of an administrator account.

$ cme smb 10.10.10.0/24 -u pixis -p P4ssw0rd -d medic.ex --sam

To authenticate using a user’s NT hash, you can use CrackMapExec’s  -H  parameter. You also need to add the  --local-auth  parameter if you’re authenticating with a local account and not a domain account.

cme smb 10.10.10.0/24 -u Administrator -H aad3b435b51404eeaad3b435b51404ee:01a27c88a6c1bd0ab0944599129c58a6 --local-auth

You can also use the  -hashes  parameter for all the Impacket tools. This includes the psexec.py tool, for example.

psexec.py Administrator@dc01.medic.ex -hashes aad3b435b51404eeaad3b435b51404ee:01a27c88a6c1bd0ab0944599129c58a6

NTLM Relay

The NTLM protocol enables a client to be authenticated on a server. As you’ve already seen, authentication takes place in three steps. But what happens if an attacker has managed to get into a man-in-the-middle position? Well, they can pretend to be the client to the server and carry out actions on the server by impersonating a client. This is known as the NTLM relay.

Diagram representing NTLM relay.
NTLM Relay

To find out more about the details of this attack, watch the following video:

There is a very powerful tool called ntlmrelayx.py, from the Impacket collection, that allows you to use the NTLM relay technique.

Relay of a Connection From
Relay of a Connection From MEDIC.EX\Administrator to 10.10.10.2

In this example, the tool has been launched to relay authentications to the 10.10.10.2 server with the  -t option. The authentication of the MEDIC.EX\Administrator user is received by the tool and relayed to the server. Once authentication has been completed through the relay, ntlmrelayx automatically extracts the local user’s login credentials from the workstation. 

Let’s Recap!

One of the options to perform lateral movement within an Active Directory is to:

  • compromise machines with the pass-the-hash technique. 

  • pretend to be a victim with the NTLM relay technique.

In the next chapter, we’ll look at other lateral movement techniques using Kerberos and other protocols.

Example of certificate of achievement
Example of certificate of achievement