> For the complete documentation index, see [llms.txt](https://docs.0xrushi.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.0xrushi.xyz/protocols/ntlm.md).
# NTLM
### What is NTLM?
NTLM (New Technology LAN Manager) is a suite of authentication protocols developed by Microsoft to confirm the identity of users and protect the integrity and confidentiality of their activities on a network.
How does NTLM Authentication Work?
There are two possible scenarios:
* Either the user uses the credentials of a local account of the server, in which case the server has the user’s secret in its local database and will be able to authenticate the user;
* Or in an Active Directory environment, the user uses a domain account during authentication, in which case the server will have to ask the domain controller to verify the information provided by the user.
In both cases, authentication begins with a **challenge and response** between the client and the server.
Ntlm works on challange - response mechanism
The challenge/response principle is used so that the server verifies that the user knows the secret of the account he is authenticating with, without passing the password through the network. There are three steps in this exchange:
**Negotiation** : The client tells the server that it wants to authenticate to it
**Challenge** : The server sends a challenge to the client. This is nothing more than a 64-bit random value that changes with each authentication request
**Response** : The client encrypts the previously received challenge using a hashed version of its password as the key, and returns this encrypted version to the server, along with its username and possibly its domain
### Authentication
As explained earlier, there are two different scenarios. The first is that the account used for authentication is a local account, so the server has knowledge of this account, and it has a copy of the account’s secret. The second is that a domain account is used, in which case the server has no knowledge of this account or its secret. It will have to delegate authentication to the domain controller.
#### SAM (Security Accounts Manager)
the server needs to store the local users and the hash of their password. The name of this database is the **SAM** (Security Accounts Manager). The SAM can be found in the registry
A copy is also on disk in `C:\Windows\System32\SAM`.
so it contains the list of local users and their hashed password, as well as the list of local groups. Well, to be more precise, it contains an encrypted version of the hashes. But as all the information needed to decrypt them is also in the registry (SAM and SYSTEM), we can safely say that their hashed version is stored there. If you want to see how the decryption mechanism works, you can go check [secretsdump.py code](https://github.com/SecureAuthCorp/impacket/blob/master/impacket/examples/secretsdump.py#L1124) or [Mimikatz code](https://github.com/gentilkiwi/mimikatz/blob/master/mimikatz/modules/kuhl_m_lsadump.c).
#### So to summarize, here’s the verification process.
Since the server sends a challenge (**1**) and the client encrypts this challenge with the hash of its secret and then sends it back to the server with its username (**2**), the server will look for the hash of the user’s password in its SAM database (**3**). Once it has it, it will also encrypt the challenge previously sent with this hash (**4**), and compare its result with the one returned by the user. If it is the same (**5**) then the user is authenticated! Otherwise, the user has not provided the correct secret.
### Domain account
When a **domain account** authenticates using NTLM, the user’s password hash (NT hash) is not stored on the local server but on the **Domain Controller (DC)** inside the `NTDS.DIT` database. The process begins when the **server** sends a random challenge to the **client**. The client then encrypts this challenge with its NT hash (derived from the user’s password) and sends the result, along with its username and domain name, back to the server. Since the server doesn’t have the user’s NT hash, it can’t verify the response itself. Instead, it uses the **Netlogon service** to establish a **Secure Channel** with the Domain Controller a trusted, encrypted connection based on the server’s own machine account password. Through this channel, the server sends the user’s name, the original challenge, and the client’s response to the DC. The Domain Controller retrieves the user’s NT hash from the `NTDS.DIT` file, uses it to compute what the correct response should be, and compares it to the one received from the client. If they match, the DC confirms the user is authenticated and notifies the server through the secure channel, sending back additional user information like groups and privileges. If they don’t match, authentication fails. In short, for **local accounts**, verification is done by the local server using the SAM database; for **domain accounts**, it’s done by the Domain Controller via the Netlogon secure channel.
Same as before, the server sends a challenge (**1**) and the client **jsnow** encrypts this challenge with the hash of its secret and sends it back to the server along with its username and the domain name (**2**). This time the server will send this information to the domain controller in a **Secure Channel** using the **Netlogon** service (**3**). Once in possession of this information, the domain controller will also encrypt the challenge using the user’s hash, found in its NTDS.DIT database (**4**), and will then be able to compare its result with the one returned by the user. If it is the same (**5**) then the user is authenticated. Otherwise, the user has not provided the right secret. In both cases, the domain controller transmits the information to the server (**6**).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.0xrushi.xyz/protocols/ntlm.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.