J. Perez Duertojperezduerto.info
← all walkthroughs

Wifinetic

Linux· Easy
owned
2026-07-06
time to own
10m42s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I found an FTP server accepting anonymous logins that exposed an OpenWrt router configuration backup. Extracting the archive revealed a plaintext WiFi pre-shared key inside the wireless configuration file; the same password had been reused as the SSH login for the 'netadmin' system account, giving an immediate shell and the user flag.

Once inside, I discovered that the 'reaver' WPS-attack binary had the CAP_NET_RAW Linux capability set, allowing a non-root user to send raw wireless frames without sudo. Reaver brute-forced the local access point's WPS PIN and recovered the WPA passphrase — which had been reused, again, as the root SSH password — completing full system compromise.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export PASSWORD="<the-password-you-recovered, for root>"
export PASSWORD2="<the-password-you-recovered, for netadmin>"

Attack path — how the box was taken

1ReconnaissanceNetwork port and service enumeration (T1046)
Scanned open ports and identified exposed services
A full TCP scan of $TARGET revealed three ports: FTP on 21 (vsftpd 3.0.3), SSH on 22 (OpenSSH 8.2p1 on Ubuntu), and a tcpwrapped port on 53. The presence of an FTP server alongside SSH — with no web surface — made FTP the natural first target, since vsftpd 3.x commonly ships with anonymous access enabled.
Nmap: 21/open/tcp ftp vsftpd 3.0.3; 22/open/tcp ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.9
Exact commands 1
shell

Full TCP scan with version detection and default scripts.

$ nmap -sV -sC -p- --min-rate 5000 -oN nmap_full.txt $TARGET
2EnumerationAnonymous FTP access (T1078.001)
Logged into FTP anonymously and retrieved a sensitive router backup archive
The FTP service accepted anonymous / anonymous with no password. The share contained an OpenWrt router backup dated 2023-07-26 alongside internal project documents (MigrateOpenWrt.txt, ProjectGreatMigration.pdf, ProjectOpenWRT.pdf, employees_wellness.pdf). The backup archive was the highest-value file: tar archives of OpenWrt systems routinely contain raw /etc configuration including network credentials in cleartext.
-rw-r--r-- 1 ftp ftp 40960 Sep 11 2023 backup-OpenWrt-2023-07-26.tar confirmed in directory listing
Exact commands 3
shell

Connect; at the Name prompt type 'anonymous' and press Enter for the password.

$ ftp $TARGET
shell

List all files in the FTP root to confirm what is exposed.

$ ftp> ls -la
shell

Download the backup for local extraction.

$ ftp> get backup-OpenWrt-2023-07-26.tar /tmp/backup-OpenWrt-2023-07-26.tar
FixDisable anonymous FTP accessCritical
WeaknessThe FTP server accepted unauthenticated (anonymous) logins, allowing any internet-connected client to browse and download files — including a router backup containing live network credentials — without supplying a password.
FixDisable anonymous FTP in vsftpd by setting 'anonymous_enable=NO' in /etc/vsftpd.conf and restarting the service ('sudo systemctl restart vsftpd'). If file sharing is genuinely needed, require named user accounts, confine them to a purpose-built directory that holds no credentials or internal documents, and enable TLS (ssl_enable=YES) so credentials in transit are encrypted.
3Credential AccessCredentials from configuration files (T1552.001)
Extracted a plaintext WiFi password and a username from the backup
The archive contained a full dump of the OpenWrt /etc directory. The file ./etc/config/wireless held the WPA pre-shared key in its 'option key' field in plaintext. The file ./etc/passwd confirmed a 'netadmin' account on the target system, strongly suggesting that whoever set up the box had also set the same passphrase as the system account password.
Tar listing confirms ./etc/config/wireless and ./etc/passwd present in backup-OpenWrt-2023-07-26.tar
Exact commands 2
shell

Stream wireless config to stdout; look for 'option key' lines containing the WPA PSK.

$ tar -xOf /tmp/backup-OpenWrt-2023-07-26.tar ./etc/config/wireless
shell

Extract passwd to identify account names — confirms 'netadmin' exists on the live host.

$ tar -xOf /tmp/backup-OpenWrt-2023-07-26.tar ./etc/passwd
FixPurge plaintext credentials from backup archives before storing or transferring themHigh
WeaknessThe OpenWrt backup placed on the FTP share included ./etc/config/wireless with the WPA pre-shared key stored in cleartext inside an 'option key' field. Anyone who downloaded the archive could read the live network password with a single tar command.
FixBefore archiving OpenWrt configuration for storage or transfer, redact all credential fields ('option key', 'option password') and replace them with placeholders, or encrypt the entire archive with GPG before placing it on any shared medium ('tar czf - /etc | gpg --symmetric -o backup.tar.gz.gpg'). Immediately delete the existing unredacted archive from the FTP share and audit all other shared locations for similar credential-bearing files.
4Initial AccessValid accounts — credential reuse (T1078)
Reused the WiFi password to log in over SSH as netadmin and captured the user flag
The WPA pre-shared key found in the wireless config was tried as the SSH password for the 'netadmin' account. It succeeded immediately. I now had an interactive shell on the Ubuntu host and could read the user flag from /home/netadmin/user.txt.
Sshpass -p <withheld> ssh netadmin@$TARGET returned uid=1000(netadmin) and located user.txt
Exact commands 2
shell

Verify the login and confirm running as netadmin.

$ sshpass -p "$PASSWORD2" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null netadmin@$TARGET 'id; hostname; pwd'
uid=1000(netadmin)
shell

Read the user flag -> <user.txt>

$ sshpass -p "$PASSWORD2" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null netadmin@$TARGET 'cat /home/netadmin/user.txt'
FixEnforce unique passwords — never reuse a network passphrase as a system account passwordCritical
WeaknessThe WPA pre-shared key in the backup was identical to the netadmin SSH login password, and the WPA passphrase recovered by Reaver was identical to the root SSH password. Recovering any single credential automatically unlocked corresponding system access.
FixGenerate unique, randomly created passwords for every system account and every wireless network — they must never overlap. Store them in a password manager or secrets vault (e.g., HashiCorp Vault, Bitwarden Teams). Immediately rotate all four compromised credentials: the netadmin SSH password, the root SSH password, and both wireless PSKs. Where possible, replace password-based SSH authentication with public-key authentication and disable PasswordAuthentication in sshd_config.
5Post-ExploitationWireless interface enumeration; Linux capability discovery (T1548)
Enumerated wireless interfaces and discovered Reaver with a raw-packet capability
From the netadmin shell, I listed wireless interfaces and found two — wlan0 (the host's AP interface broadcasting the local SSID) and wlan1 (a secondary interface usable for frame injection). Checking installed tooling revealed that the 'reaver' WPS-attack binary had the CAP_NET_RAW Linux capability set on its filesystem entry, meaning any local user could invoke it to send raw 802.11 frames without needing sudo.
Exact commands 3
shell

Run from the netadmin SSH session to list wireless interfaces and their operating mode (managed / AP).

$ iw dev
shell

Confirm CAP_NET_RAW is set on the reaver binary (output: reaver = cap_net_raw+ep).

$ getcap $(which reaver)
shell

Retrieve the BSSID (MAC address) of the AP interface — needed as the reaver target in the next step.

$ iw dev wlan0 info
FixRemove CAP_NET_RAW from Reaver and uninstall offensive wireless tools from production systemsHigh
WeaknessThe 'reaver' WPS brute-force tool was installed system-wide with the CAP_NET_RAW Linux capability set on the binary, allowing any local user account — including the low-privilege 'netadmin' — to send raw 802.11 frames and attack the wireless access point without any sudo or root privilege.
FixRemove the capability immediately: 'sudo setcap -r /usr/bin/reaver'. Then uninstall reaver and related offensive wireless tools (wash, pixiewps, aircrack-ng) from production systems entirely — they serve no legitimate operational purpose on a server. Audit all binaries for unnecessary capabilities with 'getcap -r / 2>/dev/null' and strip any that are not explicitly required. If wireless diagnostics are ever genuinely needed, confine them to named administrators via sudo command whitelisting and log all invocations.
6Privilege EscalationWPS PIN brute-force / WPA-PSK recovery (T1110.001)
Ran Reaver to brute-force the WPS PIN and recover the WPA passphrase
With CAP_NET_RAW set on the reaver binary, I launched a WPS PIN brute-force against the local AP (wlan0) from the wlan1 interface, running entirely as the unprivileged netadmin user. Reaver cycled through WPS PIN candidates and eventually returned the WPA pre-shared key. That passphrase had been set as the root account's SSH password — another credential reuse mistake, this time at the administrator level.
Sshpass -p <withheld> ssh root@$TARGET succeeded; this password matches the PSK Reaver recovers from the WPS attack
Exact commands 1
shell

Run from the netadmin SSH session. Replace <AP_BSSID> with the BSSID from 'iw dev wlan0 info'. Reaver prints the recovered WPA-PSK on success. Add -K 1 to attempt Pixie-Dust first for faster recovery if the AP is vulnerable.

$ reaver -i wlan1 -b <AP_BSSID> -vv
7Full CompromiseValid accounts — credential reuse for root access (T1078.003)
Logged in as root using the recovered passphrase and captured the root flag
The WPA passphrase returned by Reaver was tried directly as the root account's SSH password. It succeeded on the first attempt, delivering a root shell. I read /root/root.txt, completing full system compromise from an unauthenticated starting position.
Sshpass -p <withheld> ssh root@$TARGET returned uid=0(root) and root.txt
Exact commands 1
shell

Root SSH login; output is uid=0(root) and the root flag <root.txt>.

$ sshpass -p "$PASSWORD" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@$TARGET 'id; cat /root/root.txt'
uid=0(root)

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

Exposed services

21/tcp
22/tcp
53/tcp

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.