HTB: Blackfield

Target Experience:

My observations while working this target:

· Enumeration: Life-like

· Vulnerabilities: Life-like

· Exploitation: Life-like

· Foothold Difficulty: Hard

· Privilege Escalation Difficulty: Medium

Tools:

The recommended tools for this lab were:

· Nmap

· CrackmapExec

· SMBClient

· GetNPUsers

· Hashcat

· PowerView (Windows)

· RPCClient

· Pypykatz

· Evil-WinRM

· Diskshadow (Windows)

· Secretsdump

Vulnerabilities:

· Exposed Usernames

· Kerberos Pre-Authentication not requried

· ACE Privilege Abuse

· Sensitive File Information

· Backup Privilege Abuse

Information Gathering:

Using Nmap, I saved the output while scanning for service version detection, OS detection, script scanning, and verbose mode of the target system.

Figure 1: Nmap Scan

Since the target was identified as a Windows system, and most likely a domain controller, I decided to use CrackMapExec to further enumerate SMB.

Figure 2: CME Enumeration

After discovering a few shares, I enumerated the profiles$ share and found what appeared to be user account names.

Figure 3: Share Enumeration

Foothold:

Part 1:

After identifying that the enumerated share was more than likely valid user accounts, I created a user list in preparation for password spraying.

Figure 4: Users.lst

I tried a few different spraying techniques, but none of them were successful. So, I used the user list with the Impacket GetNPUsers to identify if I could ASREPRoast any of the accounts.

Figure 5: ASREPRoast

Reviewing the output of the ASREPRoast, I was able to obtain the Kerberos hash for the support account.

Figure 6: ASREP Hash

A quick trip to my cracking machine, I was able to use Hashcat to crack the hash.

Figure 7: Cracked Hash

Next, I returned back to my Attacker system and validated that the credentials were valid. However, the credentials did not have remote access privileges.

Figure 8: Validated Credentials

Part 2:

I’ll have to admit that I had issues with trying to figure this part out. And by far, this was the most difficult part for me. I would usually execute a SharpHound collector, but those attempts returned with no visible results within BloodHound. I attempted a few other enumeration attempts, but was not having any luck. I turned to the forums and folks commented “what can a support account due?”

I had my suspicion that an ACL/ACE was enabled on the audit2020 account for the support account. However, I was just not finding a tool nor did I have the knowledge of a tool on my Attacker system to prove my suspicion. So, I blindly moved on and eventually pwn3d the target.

I came back to this point and continued to rework this step until I was able to come up with proof. Doing so, forced me to use my Windows system to load the PowerView module. Since my Windows system was not on the Blackfield Domain, I used a runas /netonly command to load a new PowerShell window as the blackfield.local\support user.

Figure 9: PowerShell RunAs

Once the new window launched, I loaded PowerView and then executed the Invoke-ACLScanner function to only scan the audit2020 account. After a few errors regarding the current domain, the returned results indicated that the audit2020 account had an ACL/ACE applied.

Figure 10: Invoke-ACLScanner Results (audit2020)

At this point, I returned to my Attacker system and launched a RPCClient session as the support account. Once connected, I performed a lookupsids to view the ObjectSID and IdentitySID.

Figure 11: SID Identification

With the above enumeration results, I was confident that the support account had AD Rights over the audit2020 account based on the AccessControlType. Although, I did not know the exact rights. It was not until after I obtained Administrator privileges that I was able to definitely identify that the ACEType was a User-Force-Change-Password as well as User-Change-Password.

In performing an Internet search, I was able to find an example of how to change a user password. However, I needed to identify the current password policy that was being utilized first.

Figure 12: Domain Password Policy

Knowing that the domain credentials had to be a minimum of eight characters, with complexity, I used RPCClient to change the password for the audit2020 account. I then validated the password change with CME. However, I still was not able to obtain PS-Remote access.

Figure 13: Password Change and Validation

Part 3:

Using the audit2020 account, I enumerated the shares with CME. I noted that the audit2020 account had read access to the forensics folder.

Figure 14: Enumerated Shares

After connecting to the forensics share with SMBClient, I started reviewing the data to find anything that would be interesting. I ended up discovering a lsass.zip file within the memory_analysis directory and downloaded it to my Attacker system.

Figure 15: Discovered lsass.zip

Once the lsass.zip file download completed, I extracted the zip and then launched pypykatz to view the contents of the file; which contained the svc_backup account NTLM hash.

Figure 16: Extracted Hash

Next, I launched CME to validate the credentials and validated remote access privileges.

Figure 17: CME Credential Validation

Privilege Escalation:

With validated credentials, I launched Evil-WinRM to connect to the target and enumerated privileges.

Figure 18: SeBackupPrivilege

Once again, I used an Internet search to research how to privilege escalate with the SeBackupPrivilege. I found a couple of articles that explained how to use diskshadow to make a shadow copy of the Active Directory database. Since the file was backed up with SeBackupPrivileges, it could only be copied by the svc_backup account using Robocopy or Copy-FileSeBackupPrivilege to a writable location.

To prepare for compromising the target, I created a CMD file (shadowcopy.cmd) and a text file script (shadow.txt) that executed commands within the binary of diskshadow. These commands would create a shadow copy of ntds.dit, and save it to a mapped drive. Then the script would call the CMD file to copy the file to a World-Writable location of C:\Window\System32\spool\drivers\color.

Figure 19: shadowcopy.cmd & shadow.txt

With the files uploaded, I executed diskshadow with the /s flag to use the script of shadow.txt. In addition, I used the /l flag to log the output to log.txt. As a side, it was not required to create the log file.

Figure 20: Diskshadow Execution

As an alternate copy method, I found two special .dll’s for the SeBackupPrivilege copy process. The first validated the SeBackupPrivilege settings and the second enabled copying files with SeBackupPrivilege. Both of these files needed to be uploaded onto the target. If the .dll’s were flagged by AV, the author had provided raw code for obfuscation and re-compiling.

Figure 21: Copy-FileSeBackupPrivilege (ntds.dit)

Next, I extracted the SYSTEM key from the registry and then downloaded the Active Directory database and the SYSTEM key. Once the files downloaded successfully, I cleaned up by deleting the files, scripts, and any logs that I used.

Figure 22: Extract Key & Download Files

With ntds.dit and system.hive successfully downloaded to my Attacker system, I used Impacket secretsdump to extract the hashes from the Active Directory database.

Figure 23: Extracted Hashes

Using the extracted contents of the Active Directory database, I used Evil-WinRM to connect to the target as the Domain Administrator.

Figure 24: Escalated Privileges (DA)

References:

https://malicious.link/post/2017/reset-ad-user-password-with-linux/

https://assets.contentstack.io/v3/assets/blt36c2e63521272fdc/blta6a2ae64ec0ed535/5eb08aaeead3926127b4df44/SMB-Access-from-Linux.pdf

https://medium.com/@ali.bawazeeer/using-mimikatz-to-get-cleartext-password-from-offline-memory-dump-76ed09fd3330

https://github.com/giuliano108/SeBackupPrivilege

https://ethicalhackersacademy.com/blogs/ethical-hackers-academy/active-directory

https://bohops.com/2018/03/26/diskshadow-the-return-of-vss-evasion-persistence-and-active-directory-database-extraction/

Disclaimer:

This article is made available for educational purposes only!!! In addition, this article provides general information on cyber security topics used for “Ethical Hacking”.

Persons accessing this information assume full responsibility for the use and agree to not use this content for any illegal purpose. Furthermore, the author is not liable for any direct or indirect damages or expense incurred which may result from the use of the information covered within this article.

Information within this article is “as is”, without warranty of any sort.