Blackfield 10.10.10.192

I know the sky is not the limit because there are footprints on the Moon — and I made some of them! #Buzz Aldrin

Completed at 23 Sep 2020

Background

Blackfield is a Windows machine from HackTheBox, that is focusing on the enumeration technique, for training your ethical hacking skills and penetration testing skills.

After basic enumeration, this Windows server was a Domain Controller (DC) in the blackfield.local domain. After reconnaissance, a set of user's account was publicly available to view. This DC used Kerberos service. With this user list, I got a non-preauth AS_REP response. Finally, I got the access of a user 'support' account.

Using this support account, I reset the password of a user "Audit2020" and got access to this account. This account has the access rights on the ‘forensic’ shared folder and through this shared folder I could download several files, among others lass.dmp. Decode this file, I got the NTLM hash of the user account svc_backup.

This svc_backup account is the service account for system backup that is a member of the Security Group ‘Backup Operators’. This account has rights to back the critical file, NTDS.dit , and also has permission to execute the program DiskShadow.exe.

After retrieved the NTDS file and decoded it, I go the NTLM hash of the administrative account. 130n@calvinlai.com

Target Machine: 10.10.10.192

Attacker Machine: 10.10.14.8

Knowledge

  • Windows

  • Active Directory

  • Powershell

  • Account Misconfiguration

  • Kerberoasting

  • File System Forensics

Hacking Process Part 0 – Service Scanning

Quick Pre-searching

nmap -p- -T5 --min-rate=1000 10.10.10.192 -oG fkclai.nmap

Details Analysis

nmap -p $(grep -Eo '[0-9]{1,5}/open' fkclai.nmap | cut -d '/' -f 1 | tr -s '\n' ',') -sC -sV 10.10.10.192 -o nmap-result.txt

Enumeration strategies According to the nmap result, the target machine is a Domain Controller in the backfield.local , this server has the hostname DC01, the interesting ports are tcp/445 for SMB, 88/tcp for Kerberos, and 389/tcp for LDAP.

  1. Check SMB (445)

  2. Check kerberos-sec (88)

  3. Check LDAP (339)

Hacking Process Part 1 – Enumeration

SMB Enumeration

Started with the enumeration of the SMB protocol by checking the default account access, but nothing information returned. After that, using enum4linux gethered the SMB service of target machine and didn't have any usful information.

smbmap -u "guest" -p "" -H 10.10.10.192
enum4linux 10.10.10.192

Two shared folders (forensic, profiles$) are found using the smbclient and a list of user profile folder list is found at the //10.10.10.192/profiles$. It may be useful, let check this user list using

Hacking Process Part 2 – Initial Low Privilege Access

Enumeration through RPC

As the target provides the AD service, let use the folder name to create a user list file and check with GetNPUsers.py program to find out the "real" user account actually present in the Active Directory and try to capture the NTLM hash. Exported the shares to a file named ‘userlist.txt’, and check of the usernames are existing and if they have Kerberos pre-authentication enabled, using the parament -format john that sent founded captured Ticket-Gain-Tickets to john for cracking. Finally, the following three accounts existed at the Active Directory and the password of "support was found. 1. audit2020 2. support 3. svc_backup

python /root/Documents/ctf/tools/win/impacket-0.9.20/examples/GetNPUsers.py blackfield.local/ -usersfile userlist.txt -outputfile hash.txt -dc-ip 10.10.10.192 -format john
Password of the user account support@BLACKFIELD.LOCAL was found #00^BlackKnight

Initial access with the account "support"

Login the "blackfield.local/support" account with the password ":#00^BlackKnight". It was confirmed that the user list and user gourp of the AD service. After futher recon, this account cannot access other SMB share folder and no other information can be found under this . Before swithing to other strategy, if it is a "support" account, can I do some support service, such as create account, reset account password...etc.

Googled an article explains how to change a password via rpcclient. Finally, I was able to change the password of the account audit2020 to ‘abcd@1234’.

Jump to account "audit2020"

This user account can access the share folder "forensic". Jumped to this user "aduit2020", however, no luck to get the user flag. It is not the target user account. I downloaded all the files at this forensic account and found a interesting file lass.DMP under memory_analysis folder.

memory_analysis\lsass.DMP

There is a program "volatility" under tool folder which can be used for analyzing memory dumps. This lasass.DMP may be the dump result from lsass.exe, which contains the password hash.

Tried read out the lsass.dmp using different method, first I tried with volatility to read out the DMP file, but couldn’t get it to work on my Kali machine. Finally, used the Python version of Mimikatz, pypykatz. Lucky, another user account "svc_backup" was found with a NTLM hash.

Using the Evil-WinRM I can just pass the hash to login

This account "svc_backup" have the user flag at the Desktop folder. Let's go for Privilege Escalation.

Hacking Process Part 3 – Privilege Escalation

The support account has the support fuction, audit account can access the backup file, will this svc_backup account has system backup function?

Starting check who am i and what access rights I have, A quick check on the privileges of this account that this user is member of the group "Backup Operations" and it have two ‘extra’ privileges, i.e. SeBackupPrivilege and SeRestorePrivilege which are able to back-up critical system files on this Domain Controller.

My target is to get the NTDS.dit file by creating a Volume Shadow Copy which the files are being locked. In addition, I need the SYSTEM hive from the registry which is containing the boot key, which is used to decrypt the NTDS.dit. Googled, diskshadow.exe is the program to use to create Volume Shadow Snapshots (VSS) of disks and expose them as a folder or as a Driveletter.

Get the NTDS.dit

Even the SeBackupPrivilege is enable, but the system security still not allow me to dump the ntds.dit file. First we need to get the permissions in the file NTDS.dit by following the instruction of this https://github.com/giuliano108/SeBackupPrivilege

Once I have the privileges, next steps, execute the program DiskShadow.exe with the scripts (DiskShadow.exe /s ), which is creating a Volume Shadow Copy and expose the VSS with the Driveletter Z:.

Using the Copy-FileSeBackupPrivilege to get the ntds.dit file and the system.bak (the key of this ntds) that get from the registry

With the secretsdump.py to extract the NTDS.dit and read the hashes.

Dumping to the Administrator account

With the administrator's NTML hash using the Evil-WinRM to create a session with the Administrator-account.

Got the root key

Post Exploitation

Recommendation

This Lab is a sample of Kerberoasting attack, how to prevent it....

Mitigating the brute-forcing aspect of the attack, using the offline brute-force attack the hash dump file to get the initial access acount. Choosing a strong complex password for system account.

SMB Sharing, becareful what kinds of information be shared that may be used to exploitation. If I cannot get the potential user account list, the brute-force attack cannot be success.

Think about what your service accounts have access to, special privilege account can be a risk vectors for unauthorized access.

Reference Link

https://decoder.cloud/2018/02/12/the-power-of-backup-operatos/ https://serverfault.com/questions/990231/windows-backup-operators-and-network-access https://github.com/giuliano108/SeBackupPrivilege/tree/master/SeBackupPrivilegeCmdLets/bin/Debug https://github.com/giuliano108/SeBackupPrivilege https://pure.security/dumping-windows-credentials/ https://pentestlab.blog/tag/ntds-dit/

PreviousLove 10.10.10.239NextRemote 10.10.10.180

Last updated

Was this helpful?