NTLM Relay

Authentication | Protocol | LM | NTLMv1 | NTLMv2

Beside Kerberos there is another difference authentication protocol used in AD networks. NT Lan Manager (NTLM/MS-NLMP) is the name of a family of security protocols.

  • LM

  • NTLMv1

  • NTLMv2

NTLM security protocols are embedded meaning it doesn't have its own way of sending and receiving messages across a network. therefore NTLM allows or uses any protocol with a defined layer in the network stack like SMB or HTTS.

NTLM provides three operations:

  1. Authentication

  2. Message integrity, or message signing

  3. Message confidentiality, or message sealing.

NTLM is a challenge-response protocl meaning it back-and-forth steps between user and server to confirm a user's identity. It generates unique, one-time numbers called nonces to prevent attackers from reusing old messages.

Authentication Workflow

NTLM authentication workflow for domain joined computers begins with the client and server exchanging application protocol messages, where the client signals to wanting to authenticate. The client and server exchange 3 NLTM messages:

  1. NEGOTIATE_MESSAGE (Type 1 message)

  2. CHALLENGE_MESSAGE (Type 2 message)

  3. AUTHENTICATE_MESSAGE (Type 3 message)

NTLM Message

An NTLM message has variable length with a fixed-length header and variable-size message payload. Header begins with signature and messagetype fields.

NEGOTIATE_MESSAGE

This message indicates the client wants to authenticate and specifies the NTLM options it supports/requests. In the NEGOTIATIE_MESSAGE there is the NegotiateFlags field which 4 bytes long present in all messages. Those flags indicate which NLTM capabilities are supported or request by sender.

CHALLENGE_MESSAGE

This message can support and challenge a client to prove its identity. It has 6 fixed length fields, with NegotiateFlags and ServerChallenge. ServerChallenge is a 64-bit nonce which holds the NTLM challenge generated by the server.

Get info within CHALLENGE_MESSAGE

python3 examples/DumpNTLMInfo.py 172.16.117.3

AUTHENTICATE_MESSAGE

Sent by the client to the server to prove its possession of the shared secret key. It contains LmChallengeResponseFields and NtChallengeResponseFields.

Message Signing and Sealing

Message signing helps against relay attacks by negotiating a session key to sign all messages exchanged. The session key is generated based on client/server challenge messages and users's password hash. Once session key is established all messages are signed using a MAC.

Message sealing provided message confidentiality by using a symmetric-key encrption mechanism. This way attackers cannot read or tamper with it. Every sealed message is also signed.

NTLM Relay Attack

The NTLM Relay attack is an Man-in-the-Middle attack. Microsoft chooses in many cases for Kerberos authentication as its better and more secure.

Situation in which Kerberos cannot be used:

  • Compatibility with older systems

  • Kerberos configuration not setup correctly

  • Non-domain joined server

  • Protoco that chooses not to support Kerberos but NLMP only.

NLTM is vulnerable to Relay Attacks because of lack of mutual authentication.

  1. The client authenticates to the server, but the server does not authenticate itself to the client.

  2. The client does not verify whether it is communicating with the legitimate server or a malicious one.

How does it work

1

Pretending to be a legitimate server

The attacker acts like a legitimate server that the client wants to authenticate with.

2

Pretending to be a legitimate client

At the same time, the attacker also impersonates the legitimate client to the actual server that offers the service.

3

Relaying messages

The attacker intercepts and forwards messages between the client and the server. They pass authentication messages back and forth until the server thinks the client is authenticated.

4

Establishing an authenticated session

Once the attacker has relayed the authentication messages and established a session with the server, the attacker now has access to the server as if they were the legitimate client

5

Abusing the session

With the authenticated session in place, the attacker can perform actions on the server that the legitimate client is authorized to do. These actions could include accessing sensitive data or carrying out other privileged tasks.

6

Disrupting the client

After the attacker has used the session, they may send an application message to the client saying that authentication failed or simply disconnect the client, making it unaware of the attack.

Pre-relay

Pre-relay is a technique where a client is coerced into NTLM authentication for a service on a server. Techniques like poisoning and spoofing are used for this.

LLMNR, NBT-NS, and mDNS Poisoning

In enterprise networks DNS is used a lot however when DNS is not properfly configured it happens clients using name resolution that standard DNS servers do not resolve, caused by incomplete DNS records or unavailable servers. To solve this alternative name resolution protocols are used.

  • LLMNR (Link-Local Multicast Name Resolution): A protocol for resolving names in local networks when DNS isn't available.

  • NBT-NS (NetBIOS Name Service): An older protocol used for resolving NetBIOS names in a local network.

DNS is unicast meaning a client asks directly for a name resolution while multicast means it will broadcast the network if anyone knows the name.

Relay

Relaying the NTLM authentication of the client to a relay target. Therefore find machines with SMB have SMB signing disabled. 

# Check if SMB signing is disabled
python3 RunFinger.py -i 172.16.117.0/

# With nxc
smb 172.16.117.0/24 --gen-relay-list relayTargets.txt

Post Relay

Having a authenticated session by relaying the victims NTLM authentication there are many post-relay attacks that can be done.

Component
Explanation

Coercion method

Coerce client into performing authentication like MiTM.

Incoming NTLM auth over

Protocols client uses to perform NTLM authentication with HTTP(1), SMB(2).

Client-Side mitigation

Client-Side mitigations clients have to protect against NTLM relay attacks.

Server-Side mitigation

Server-Side mitigations servers have to protect against NLTM relay attacks.

Relayed NTLM auth over

Protocols that we can relay NLTM authentication received from client, like HTTP, HTTS, SMB, LDAP and LDAPS

Post-relay attack

These are the post-relay attacks that we can carry out depending on the protocol of the Relayed NTLM auth over component.

Last updated

Was this helpful?