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:
- Authentication
- Message integrity, or message signing
- 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:
- NEGOTIATE_MESSAGE (Type 1 message)
- CHALLENGE_MESSAGE (Type 2 message)
- 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.
- The client authenticates to the server, but the server does not authenticate itself to the client.
- The client does not verify whether it is communicating with the legitimate server or a malicious one.
How does it work
Pretending to be a legitimate server
The attacker acts like a legitimate server that the client wants to authenticate with.
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.
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.
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
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.
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. Find machines having 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. |