Controlling the domain controller (Part 1) - LLMNR poisoning with Responder.py and cracking NTLMv2 tokens
This is a long article, so if you want to go to the attacking part, navigate here
Notice that the attack could be exploited when a user or a service fails to navigate to a resource. A bad configured service/script/program or a bad access for a current user, could give an attacker the possibility to extract a domain password.
All Controlling the Domain Controller articles could be found here:
What is an Active Directory
An Active Directory is the most common infrastructure in corporate networks. It permits centralize and share information like user accounts, shared folders, printers in a usefull administrative way. When you form part of a domain, you account use the domain identifier to authenticate and see what permissions you have (jlajara@domain.com or DOMAIN\jlajara), so it is easy to log in a computer of the domain, connect to the company mail, use the enterprise printer and access to shared folders.
Based on Microsoft description:
A directory service, such as Active Directory Domain Services (AD DS), provides the methods for storing directory data and making this data available to network users and administrators. For example, AD DS stores information about user accounts, such as names, passwords, phone numbers, and so on, and enables other authorized users on the same network to access this information.
Active Directory stores information about objects on the network and makes this information easy for administrators and users to find and use. Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information.
What is a Domain Controller and why is juicy for us?
In an Active Directory infraestructure, there must be a brain that centralices the activity of the users, resources and permissions. So a Domain Controller is this critical part. A good defintion from techopedia could be:
A domain controller (DC) is a server that responds to security authentication requests within a Windows Server domain. It is a server on a Microsoft Windows or Windows NT network that is responsible for allowing host access to Windows domain resources.
A domain controller is the centerpiece of the Windows Active Directory service. It authenticates users, stores user account information and enforces security policy for a Windows domain.
And… the DC stores all the users credentials to handle authentication
A computer with all the users in the domain = GOLD
How Windows stores credentials?
A Windows computer stores credentials in a hashed (LM hash or as a NTLM hash) format within files in the C:/Windows/System32/Config directory or HKEY_LOCAL_MACHINESAM registry. SAM(Security Account Manager) contains the hashed passwords, however they are encrypted using the boot key within the SYSTEM file
Theorically, SAM files can not be accessed or copied while the system is running. But there are techniques to extract the SAM database. We will discuss in further articles.
Has a Domain Controller a SAM?
A Domain Controller use NTDS.dit instead of a SAM. The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain. It uses Extensible Storage Engine (ESE) as engine.
Attacking: LLMNR Poisoning with Responder.py and NTLMv2 cracking
What is LLMNR?
The Link-Local Multicast Name Resolution (LLMNR) is a protocol based on the Domain Name System (DNS) packet format that allows both IPv4 and IPv6 hosts to perform name resolution for hosts on the same local link.
A normal workflow is the following:
Therefore, when a user/service try to connect to a resource or host (ex. \jlajarashared), the following steps are used to determine the IP:
- 1 Search in host file C:/Windows/System32/Drivers/etc/hosts
- 2 Do a DNS request
- 3 Broadcast a LLMNR package waiting the response from the network.
This last step, has security implications. What would happend when a malicious user replies to that request saying that he knows the resource?
Therefore, when a user/service tries to access to a unknown host, all 3 steps to search the resolutions are followed, if not, the following error is thrown:
LLMNR Poisoning with Responder.py
Responder.py is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication.
A LLMNR poiser, just what we need to intercept LLMNR packages and see its content. But how it works?
Let’s set up an Active Directory environment to test this attack. It will consist in the following:
- 1 Domain Controller (192.168.56.99)
- 2 Windows 7 machines (192.168.56.10-20)
- 1 Attacker (192.168.56.1)
The following steps are going to be followed by the attacker:
- 1 Configure Responder.py to poison LLMNR events (turning on SMB and HTTP server)
- 2 Start listening to LLMNR events in the network interface (
vboxnet0in this case) - 3 Automatically poison LLMNR events to extract hashes.
NTLMv2 hashes
At the end of the previous Proof of Concept, a NTLMv2-SSP is retrieved… but what is this kind of hash?
NTLM (NT Lan Manager), is a suite of Microsoft security protocols based on challenge-response that provides authentication, integrity, and confidentiality to users. Can be obtained by MiTM techniques, by dumping the SAM or memory database (Mimikatz) or by extracting the contents of NTDS.dict file in the Domain Controller. There are two types of NTLM packages:
- NTLMv2 has the same concept as NTLMv1 but with a stronger algorithm.
- NTLMv2 does not allow Pass-the-hash attacks.
How a Domain Controller checks authentication with a NTLM package?
- 1 A user tries to access a shared directory.
- 2 The client machine sends the user name of the server in plain text.
- 3 The server generates a 16-byte random number (challenge) and is sent by the client computer.
- 4 The client encrypts the challenge with his password hash and sends it to the server (reply)
- 5 The server sends the following objects to the domain controller.
- Username
- Challenge sent to customer.
- Response received from the client.
- 6 The domain controller uses the user to obtain the hash of your password stored in NTDS.
- 7 The domain controller compares the response and if identical authorizes access.
That is the NTLMv2 package explained:
So… if by encrypting the challenge we get the answer… can the algorithm be cracked?
Cracking NTLMv2 hashes
NTLMv2 could be cracked if the challenge produces the same response after is encrypted using the correct user password. We could speed it up with John or Hashcat
john --format=netntlmv2 hash.txt
hashcat -m 5600 -a 3 hash.txt
In the next Proof of Concept, a dictionary is used to speed up the cracking proccess:
But, what would happen if the password is not in a dictionary or has a minimum security requirements, we will see in the next Controlling the Domain article.