Hack The Box: Cascade
What will you learn? This is a medium rated Windows machine configured as a Domain Controller. It includes opportunities to enumerate LDAP and SMB leading to an initial foothold. It includes the decomposition and source code analysis of binaries using DNSPYx64 to retrieve important artifacts leading to further escalation. Taking advantage of overly permissive permissions in Active Directory in order to escalate privileges to the primary domain administrator.
Let’s begin enumerating the box:
We can see that there are many ports open on the target. Ports of interest: 88 (Kerberos), 135 (RPC), 389 (LDAP), 445 (SMB), and 5985 (WinRM)
We should further enumerate the LDAP service for potentially visible information which is a common issue with this service. This could include visible LAPs (Windows Local Administrator Password Solution) passwords, cleartext user passwords, a list of users, or more pertinent information to an attacker.
We can do this with NMAP scripts and avoiding brute forcing with `nmap -sV --script "ldap* and not brute" 10.10.10.182`
What stands out?
We are able to take out the parameters for the domain naming convention for DC=cascade,DC=local
and use this in a second command to retrieve potentially sensitive data from an unencrypted LDAP service.
Run the following command configured with the above information: ldapsearch -x -H ldap://10.10.10.182 -b "dc=cascade,DC=local"
This will generate a massive output of information to sift through that will include usernames and passwords, we can filter for usernames first then attack passwords next- see what we find.
We can find a cleartext password by sifting through the data manually (awful), or filter on terms like: pwd, pass, and password. We should also filter on description fields too. Now that we have at least one password, we can use all of the usernames we acquired. We should cut out all of the other stuff and create only a list of users
The password we acquired had an equal sign at the end. We can infer that this may be a base64 encoded string. Doing so gives us another string to attempt using with crackmapexec (netxec in my case) for a brute force attempt. Spraying this password against all users we have:
We have a couple immediate things to do. Try to use the credentials with SMBCLIENT to see if we can view shares and obtain information from them. Then we also could attempt to login using SMB or WINRM (evil-winrm) as well. This is not an administrator user (no pwn3ed!) as we can see from the output.
SMBCLIENT outputs from authenticating as the user r.thompson
The data share stands out the most to me. We should try to connect to this and look into the others if required. Trying to connect with evil-winrm did not work for me in the background.
We are able to connect to the Data share. There are many files and folders. We should enter in the necessary steps to recursively get all of the contents of the directory in smbclient then view all the contents offline (make sure to create a folder to pull this all into)
Looking through the directory structure we can see that we have some information to comb through. We should look for any usernames, passwords, or anything else vital to our investigation into this box that may lead to a foothold on the network itself. See below for the first artifact which we can open using firefox Meeting_Notes_June_2018.html
This is a great source of information. We could potentially get in with this user account with the password from before. I did try using evil-winrm again with the pair of TempAdmin:rY4n5eva
and it did not work (sidenote). We can see that the ArkSvc user is doing something, moving an object to the recycle bin on the next one.
The next file dcdiag.log
does not show anything interesting to me other than successfully connecting some things. The VNC log shows something intriguing in a “password” field.
This is a Tight VNC registry file. Looking that up with ‘how to decrypt its password’ on google returns: https://github.com/frizb/PasswordDecrypts . Taking what we found below in the “Password” field we can follow the instructions for Metasploit to decrypt it.
Now that we have the credentials from below we can test this with our userlist back on crackmapexec (netexec).
We are able to get access as the s.smith
user account from our userlist and then attempt successfully to authenticate with evil-winrm, landing us the foothold
We can now enumerate for privileges, look for files and folders throughout the user profiles / C:\ drive, but let’s skip some of that and look at our user account over the domain we’re apart of:
We are able to reach another share, the Audit share, so we should take advantage of the spider_plus module with crackmapexec (netexec) to see what is inside
There is a file that is viewable from the output of the scan that shows us all the contents of the shares we have access to. In the Audit share the CascAudit.exe is interesting and so is the DLL. We can pull these down by mounting the share on our attacker system.
We should continue to look through the other directories. There is an SQLite database in the DB directory. We can identify that by running file
against the file and we can interact with and dump the database file accordingly using sqlite3 filename .dump
. There is a hard-coded credential in BASE64 for the ArkSvc
user account.
We can attempt to decode that hard-coded credential. Then we can try to test the somewhat obfuscated credential against the arksvc
credential, it fails.
Going back to the executable for CascAudit.exe
we can try to use DNSPYx64 against it and examine the source code for anything interesting. You can reach DNSPYx64 here for a Windows machine: https://github.com/dnSpy/dnSpy/releases . I am going to be using a secondary virtual machine for Windows where I will run this. You can serve the binary up in whatever your favorite way is.. Python HTTP server, SMBServer, etc.
I am using the same method to get the binary from DNSPY over as well, with my alternative VM being disconnected from the internet. Once you have the DNSPYx64 release downloaded, unzip it, and you’ll be able to just drag the CascAudit
or CascCrypto.dll
file onto the DNSPYx64 executable to open it (or you can do it normally, open it and click file to open something else- whatever works).
Below we have the DLL open first. You can see that we’re able to now inspect what is contained within using DNSPY. For context, this is what Google returns about DNSPY: “dnSpy is a free, open-source debugger and .NET assembly editor that allows users to modify, debug, and decompile .NET programs. It's often used by cybersecurity researchers to inspect .NET malware and by DataMiner Automation script and connector developers to debug assemblies without the matching code. dnSpy can also be used to edit and debug assemblies without source code”
Clicking through the components of this program we’re able to find a piece that represents a string encryption function. That tells us more about what its doing such as using AES, a block/keysize of 128, and the Initialization Vector (IV), and CBC. This could be helpful if your intention is to manually write C code to decrypt this- or to understand the context of how to reverse engineer something or how it works.
Now open the executable CascAudit.exe
and open the main module, we will see some more information referencing the encrypted / decrypted strings.
Cover the text where we want to set a breakpoint. This is where the password is decrypted. Highlight the text, right click, and select ‘Set Breakpoint’ (It says delete on mine because I did it in advance). After setting a breakpoint we want to click on ‘Start’, then set an argument pointing towards the Database file at Executable\DB\Audit.db
.
After running the program it will hit the breakpoint. Then we can press the key for ‘stepping over’ (runs the previous instruction and stops at the next one as we proceed line by line of program execution, letting you examine outputs), and we will obtain the password decrypted in cleartext.
So we have the password we can now use against a local administrator user, other user accounts we have, and it has some null bytes at the end to remove. The password itself is 'w3lc0meFr31nd
. Null bytes, also known as null characters, are a type of byte with a value of zero (0x00
in hexadecimal). In programming, particularly in C and C-derived languages, a null byte is used to signify the end of a string. This is known as null-terminated strings.
Attempting this with crackmapexec (netexec), we find we can login. I would imagine this will work the same with winrm if we test it so we just proceed to testing evil-winrm to acquire a command line session on the host too:
We can see however there are no “quick wins” here so we will need to further enumerate for a method to escalate our privileges here.
We can review this user accounts standing in the domain once more and see that it has a local membership to AD Recycle Bin
. We need to see what this is exactly, I believe I recall seeing a mention of that earlier in the shared files we had reviewed.
That group probably has a capability to review deleted items from the recycle bin. There may be a query for that in powershell. This was cool especially considering I had no idea you could do that with PowerShell previous to this. This is the command string to use: Get-ADObject -SearchBase "CN=Deleted Objects,DC=Cascade,DC=local" -Filter {ObjectClass -eq "user"} -IncludeDeletedObjects -Properties * | ft
If we remove the last part | ft
then we actually get a more complete output in a better format, that shows us a new password encoded in Base64.
Armed with this new cleartext password we can log into the local administrator account. If you recall the email we received earlier in the process, it mentioned the TempAdmin password is the same as the local administrator account. So now we should be able to attempt using winrm as it has worked previously for all others, but with these credentials: Administrator:baCT3r1aN00dles
We can become the local administrator user and acquire the root.txt flag. Thank you for joining me in this writeup, and I’m looking forward to the next one.