HTB | Cascade CTF Write-up
Good morning all,
I present to you today a post relating to the "Cascade" machine, created by @VbScrub and available on the HackTheBox platform.
Hack The BoxAccessible since March 28 as a replacement for "Sniper", it is a Windows machine of Intermediate difficulty (MEDIUM).
Without further ado, let's start our investigations!
Enumeration
My first enumeration phase will begin, once is not custom, with a port scan carried out using the nmap tool .
nmap -sC -sV -p- 10.10.10.182
This first analysis will thus reveal the presence of several accessible services such as DNS, LDAP, SMB, WINRM, RPC or even Kerberos… A set of services traditionally observed on Active Directory domain controllers.
In order to quickly list the main information accessible from the LDAP directory, I used the enum4linux tool allowing me to retrieve the list of users, groups or even the password policy applied to domain users:
enum4linux -a 10.10.10.182
In addition to the traditional “ Builtin Groups ”, we will note the presence of groups such as IT , Production , Factory , Finance , HR , Time , Audit Share or even Data Share ; these last two groups may imply the presence of dedicated shares on the network.
However, querying the available shares from a "Null Session" will be unsuccessful.
Having a list of users present on CASC-DC1, including several accounts resembling service accounts ( ArkSv c, BackupSvc and util ), I then wanted to control the vulnerability of these latter to an AS- type attack. REP Roast .
For those wishing to deepen all notions relating to attacks on Active Directory, I can only recommend the excellent site of Sean Metcalf ( @ PyroTek3 ): https://adsecurity.org/
A good description of the functioning mechanism of the AS-REP Roast attack, rather educational, is also available in French (Cocorico!) On the Pixis website ( @HackAndDo )
Pixis
In order to carry out this operation, I therefore relied on the GetNPUsers.py script present on the Impacket suite: a must for operating Windows systems. Unfortunately, none of the accounts on this machine were vulnerable to this attack.
python3 ./GetNPUsers.py cascade.local / -request -dc-ip 10.10.10.182 -no-pass -usersfile users.txt
A quick attempt to bruteforce accounts, carried out using the CrackMapExec tool and relying on a list made up of the main information collected during our investigations (login, name, first name, etc.), will also prove to be unsuccessful ...
SMB and Kerberos seeming unusable for the moment, I decided afterwards to carry out a manual enumeration of the LDAP service.
Note that the LDAP directory was searchable from an anonymous connection on TCP port 389, which is not always the case!
When checking user input, a particular attribute was identifiable on the user r.thompson : attribute cascadeLegacyPwd whose value clk0bjVldmE=
The sign "=" present at the end of our character string is often the sign of an encoding in Base64, we proceed to a decryption test… confirming our hypothesis!
echo "clk0bjVldmE =" | base64 -d (Result = rY4n5eva)
Initial access
Study of accessible shares
The new identifiers obtained now allow us to perform a new enumeration with the rights of the user r.thompson
Note that attempting to connect remotely from the WinRM protocol will be unnecessary at this time; the r.thompson user who is not part of the " Remote Management Users" group
The initial enumeration of users and groups revealed that our user r.thompson belonged to the "Data Share " and " IT " groups. Also, I carried out a new analysis of the shares accessible from this new user… This is how we can see the presence of the " Data" share , accessible in read only:
Without further ado, let's access this sharing!
smbclient -U r.thompson% rY4n5eva //10.10.10.182/DataWe are now accessing a new data tree… However, our user being a member of the " IT " group, we can easily imagine that he only has access to the corresponding folder!
Within the IT file, we will find several documents:
- A " Meetings_Notes_June_2018.html " file , present in the IT \ Email Archives folder: this is a memo informing us of the production of a new network and also indicating the use of an account from temporary administration for this operation. The temporary administration account was “ TempAdmin ” and had the same password as the company administration account … Some interesting information for the rest!
- The " dcdiag.log " file , found under \ IT \ Logs \ DCs \… without much interest;
- The " ArkAdRecycleBin.log " file , found under \ IT \ Logs \ Ark AD Recycle Bin \: this file will give us an idea of the usefulness of the ArkSvc service account, which seems to be used in order to perform restore operations on the 'Active Directory;
- The " VNC install.reg " file found under \ IT \ Temp \ s.smith \: this file, found in the user's s.smith folder , contains the password used by the VNC service… Rather interesting!
System access as s.smith
We now have sufficient elements to continue our access to the IS.
The VNC password, present in the register in hexadecimal format, can be recovered in clear. For this purpose several publicly available tools can be used. For my part, I opted for the latter:
trinitronx
After installing the prerequisites, using the tool will provide us with the VNC password in clear as desired:
./vncpasswd.py -d -H 6bcf2a4b6e5aca0f
Now, having previously observed that s.smith was part of the " Remote Management Users " group, we can make a remote connection, via the WinRM protocol, using the credentials obtained… And voila!
evil-winrm -i 10.10.10.182 -u s.smith -p sT333ve2
Now, let's get our user flag ...
Privilege escalation
Access to the system as ArkSvc
Like the operations carried out with the r.thompson account , we must now perform a new enumeration with the rights of our new user.
A new analysis of the accessible shares will then tell us that s.smith has access to the Audit $ hidden share.
Let's go see what it contains!
smbclient -U s.smith% sT333ve2 //10.10.10.182/Audit$
Among these files, we can retain:
- The RunAudit.bat file: the latter provides us with information on the launch of the executable file CascAudit.exe which is based on the Audit.db database ;
The Audit.db file , found under \ DB: this SQLite database contains the password of the ArkSvc user in the Ldap table . It also refers to the deleted temporary administration account, namely TempAdmin. We will also note that the password seems to be encoded in Base64. However, a simple decryption operation will not provide any usable password ... Therefore, we can assume that a processing of the latter, before its insertion in the database, is carried out by the program CascAudit.exe ;
The CascAudit.exe file: program used with the Audit.db database ;
- The CascCrypto.dll file: DLL used by the CascAudit.exe program , probably containing the latter's encryption / decryption functions… and at the same time supporting the hypothesis formulated as to the password present in the Audit database . db .
For the rest of the investigations, I had to use a disassembler in order to read the source code of the CascAudit.exe and CascCrypto.dll files . The "JetBrains DotPeek" software (freeware) will have been used to meet this need.
JetBrains
We can now observe that the CascAudit.exe file refers to the CascCrypto library and that its main program tells us about the key used for decryption of passwords: c4scadek3y654321
Regarding the CascCrypto DLL, the analysis of the DecryptString method will reveal the encryption algorithm used, namely AES in CBC mode , as well as the value of the Initialization Vector (IV): 1tdyjCbY1Ix49842 . We will also have confirmation that the final string is encoded in Base64 format.
We now have all the information we need to decrypt our password:
- Password (AES + Base64): BQO5l5Kj9MdErXx6Q6AGOw ==
- Key: c4scadek3y654321
- IV: 1tdyjCbY1Ix49842
In order to simply perform this decryption operation, I advise you to use the excellent CyberChef site.
And here is the result!
To conclude, an authentication test will confirm the validity of this password for the ArkSvc user:
All we have to do is log in with our new login details on the server!
evil-winrm -i 10.10.10.182 -u ArkSvc -p w3lc0meFr31nd
Access to the system as Administrator
This last phase of operation turned out to be rather rapid, given the information revealed during our successive analyzes. The author took great care to leave us several clues during each of the enumeration phases… which was really pleasant and reinforced the readability of the expected final exploitation!
To summarize the useful information in our possession:
- The TempAdmin administration account was created temporarily for a network migration operation;
- This user has the same password as the company's administrator account;
- The logs mentioning the ArkSvc user refer to the "ARK AD RECYCLE BIN MANAGER" program, used for restoring objects in the Active Directory ;
- The ArkSvc user belongs to the " AD Recycle Bin " group.
From these elements, it was easy to imagine that the TempAdmin user had been deleted and that we had to try to restore it ... The first hypothesis will have been confirmed by requesting the objects deleted from the directory from our PowerShell console:
Get-ADObject -IncludeDeletedObjects -Filter {objectClass -eq "user" -and IsDeleted -eq $ True}
However, the second hypothesis relating to the restoration of this account will prove to be unsuccessful; the ArkSvc account not having sufficient rights to perform this operation:
Get-ADObject -Filter {SamAccountName -eq 'TempAdmin'} -IncludeDeletedObjects | Restore-ADObject
To finish, I was thus inspired by the method of elevation of the user r.thompson … Wouldn't sensitive information be present in the LDAP entry of the TempAdmin user ?
All I had to do was verify this hypothesis by requesting our deleted user to display its properties. Thus we will see again the presence of the attribute cascadeLegacyPwd whose value YmFDVDNyMWFOMDBkbGVz
Get-ADObject -Filter {SamAccountName -eq 'TempAdmin'} -IncludeDeletedObjects -Properties *
A Base64 decryption of the observed value will provide us with the clear password of the TempAdmin user : baCT3r1aN00dles
echo " YmFDVDNyMWFOMDBkbGVz" | base64 -d (baCT3r1aN00dles)An attempt to authenticate as Administrator with the username obtained will confirm that the passwords for the TempAdmin and Administrator accounts were indeed identical!
A last connection will finally be made as Administrator ...
evil-winrm -i 10.10.10.182 -u Administrator -p baCT3r1aN00dlesIn order to retrieve our last root.txt flag!
Conclusion
This is where my presentation of the "Cascade" machine ends. I particularly appreciated the program analysis phase (similar to the "Nest" machine by the same author) as well as the general coherence of this challenge, delivering several clues as the privilege escalation phases progress. to orient the attacker on the final method of exploitation… A very beautiful machine in my opinion, giving pride of place to the enumeration!
Regarding the elevation through the cascadeLegacyPwd attribute , I am not sure that this is the most realistic on an Active Directory but hey ... this remains a detail knowing that many sensitive information is often present in the within LDAP user entries. I would also give an opinion concerning the difficulty of this machine which seems to me to have been evaluated on the rise. But here again, this assessment will be really subjective since it is highly dependent on the areas of predilection of each.
I warmly thank @VbScrub for their contribution! And you for reading my write-up, Until next time!
Your friendly neighborhood Hacker