Bruno
A "medium" difficulty AD box about AS-REPRoasting for credentials. A zip slip vulnerability in a file scanner delivers a DLL hijack payload, leading to a KrbRelay RBCD attack for full
Target IP: 10.129.238.9
Domain: bruno.vl | DC: brunodc.bruno.vl
OS: Windows Server 2022 (Build 20348)
Attack Path: Anonymous FTP → ASREPRoast → Zip Slip + DLL Hijack → RBCD via KrbRelay → Domain Admin
Phase 1: Reconnaissance & Enumeration
1.1 Nmap Port Scan
The engagement starts with a comprehensive Nmap service/version scan. The -sCV flags combine default scripts (-sC) and version detection (-sV), giving a clear picture of the attack surface in a single pass.
1.2 Anonymous FTP Enumeration
Nmap's FTP script flags anonymous login as permitted (FTP code 230). Anonymous FTP is a significant misconfiguration — anyone can browse and download files with no credentials. We connect immediately:
the file "changelog" said
The changelog leaks the internal service account name svc_scan. Service accounts are prime ASREPRoasting targets because they are frequently misconfigured with Kerberos pre-authentication disabled. The mention of "EICAR string" also tells us this is an antivirus/malware scanning application — important context for how it behaves.
Phase 2: Initial Access — ASREPRoasting
2.1 What Is ASREPRoasting?
Normally when a user requests a Kerberos TGT, they must first prove knowledge of their password by encrypting a timestamp — this is Kerberos pre-authentication. If the Do not require Kerberos preauthentication flag is set on an account, the KDC will hand back an AS-REP (Authentication Service Reply) encrypted with the user's password hash — without requiring any proof of identity.
This AS-REP blob can be captured by any network participant and cracked offline, since the ciphertext is derived directly from the user's password.
Attack flow:
Identify accounts with pre-auth disabled (via LDAP or Impacket)
Request an AS-REP — the KDC sends back encrypted data without authentication
Crack the hash offline with hashcat or john
2.2 Requesting the AS-REP Hash
Using Impacket's GetNPUsers.py (No Pre-auth Users), we target the svc_scan account:
The KDC returns a hash in Kerberos 5 etype 23 (RC4-HMAC) format — hashcat mode 18200. RC4 is an older, weaker cipher, which means offline cracking is significantly faster than against AES-based hashes (etype 17/18).
2.3 Cracking the Hash
Credentials obtained: bruno.vl\svc_scan : Sunshine1
Phase 3: Post-Credential Enumeration
3.1 SMB Share Enumeration
With valid credentials, we use NetExec (nxc) — the maintained successor to CrackMapExec — to enumerate accessible SMB shares:
3.2 Browsing CertEnroll
The share contains CRL files and CA certificates, confirming:
CA Name:
bruno-BRUNODC-CACA Server:
BRUNODCNo sensitive credentials here, but the presence of AD CS warrants a deeper scan.
this doesnt have any sensitive file that we can abuse, but it does disclose some info about the domain
CA Name:
BRUNODC-CACA Server:
BRUNODC
since there is a lot of AD CS mentioned, lets run a quick Certipy scan to check for AD CS vulnerabilities
the result exposed
ESC8 (discovered by SpecterOps) is an AD CS misconfiguration where the Web Enrollment endpoint (/certsrv/) accepts HTTP-based certificate requests. When combined with the ability to coerce NTLM authentication from the DC (or relay Kerberos via KrbRelay), an attacker can obtain a certificate for the DC's machine account — usable to request a TGT and perform a DCSync. This is noted and becomes relevant in Phase 5.
Phase 4: Code Execution via DLL Hijacking (Zip Slip)
4.1 Analyzing SampleScanner.exe Locally
We download SampleScanner.exe and its supporting files from FTP and run it on a local Windows machine. After installing .NET 3.1.0 x64 (as specified in runtimeconfig.json), the first run fails:
when we try to run the samplescanner.exe on our system we get the following error (telling us to download the right .NET)
After installing the required .NET, if we try to run the Samplescanner.exe again we see this
that means we dont have the correct environement setup (i.e C:\samples\queue), after fulfilling this requirement as well we can see, that the app ran successfully
After creating C:\samples\queue\, the application runs successfully — confirming it monitors that directory for incoming zip files.
4.2 Process Monitor Analysis
With Procmon (Sysinternals) filtering on Process Name is samplescanner.exe, we watch every file system operation during execution. The key observation: when processing a zip file, SampleScanner.exe attempts to load several DLLs using relative paths — specifically:
Microsoft.DiaSymReader.Native.amd64.dll— sought in the application directoryhostfxr.dll— the .NET host framework resolver, loaded relatively on startup
This is a DLL Search Order Hijacking opportunity. Windows loads DLLs by searching a predictable sequence of directories. If we can plant a DLL with the right name in a searched directory before the legitimate one, our malicious version loads instead — executing arbitrary code in the application's security context.
4.3 Confirming Zip Slip
Zip Slip is a path traversal vulnerability where a zip archive contains filenames with directory traversal sequences (../). A vulnerable extractor writes these files outside the intended destination directory.
We test with a benign file first: Now we create a text file to test the theory
create a python script to zip the text file
then run this script and unzip the result to see the final txt file with absolute path in it
Now that we have the final malicious txt file, we'll move it to our local windows system
and run SampleScanner.exe
And on our desktop we can see that the file has been created
Now we know that svc_scan has WRITE privileges on queue share, and source code we also know that queue, is in C:\app\, so we need to create our malicious DLL like C:\samples\app\Microsoft.DiaSymReader.Native.amd64.dll
so this is what our python script will look like
Now we will put our zip file in the queue share, and will start a reverse shell listener on metasploit
Microsoft.DiaSymReader.Native.amd64.dll didn't work for me, so now I'm trying hostfxr.dll, with relative path traversal, instead of absolute.
4.4 Generating the Malicious DLL
We use msfvenom to generate a reverse shell DLL. We initially try Microsoft.DiaSymReader.Native.amd64.dll but it doesn't execute. Reviewing Procmon output more carefully, hostfxr.dll is the better target — .NET loads it from a relative path at startup, and Procmon confirms it's searched in the app directory:
So the new MSFvenom payload will be this
4.5 Weaponizing the Zip Archive
From Procmon, we know SampleScanner.exe lives at C:\app\ (or E:\app\ on the target). The scanner's queue directory is at C:\samples\queue\. Using path traversal in the zip entry name, we can write our DLL to C:\app\hostfxr.dll — one level up from queue, then into app:
The traversal ../app/hostfxr.dll resolves as: C:\samples\queue\ → ../ → C:\samples\ → app/hostfxr.dll → C:\samples\app\hostfxr.dll
When SampleScanner.exe next starts and .NET initializes, it finds our hostfxr.dll first and loads it.
4.6 Uploading and Catching the Shell
Now we will upload it on the queue share
and start a netcat listener
And soon enough we got a connection back from the target system
We have a shell as svc_scan. User flag retrieved
Phase 5: Privilege Escalation — RBCD via KrbRelay
5.1 Enumeration as svc_scan
Now for privilege escalation for root flag I first enumerated groups, our user beloonged to
there's nothing much here, except the DCOM group, but let's keep looking further, and enumerate privileges
Here it says that we can have SeMachineAccountPrivilege, but it is disabled, researching about it tells us that it, looks that way because of the type of reverse-shell we are in, so lets check this out in LDAP
LDAP enumeration tells us that we (svc_scan) have the machine account quota of 10
So now we can try RBCD, using krbrelay, we'll first setup the following
Now we get the user flag
Last updated