First-Time WiFi Pentest — Real-World Findings
I work at an IT security consulting company that provides penetration testing services. I am a penetration tester there and often get pentest projects, especially for web applications and infrastructure. However, a few days ago, the pentester coordinator gave me a job to pentest WiFi—I immediately felt nervous because I had never done it before. But I was curious and wanted to learn, so I accepted the project. There were two man-days allocated for WiFi and another two man-days for the Bypass EDR project.
WiFi Penetration testing
WiFi penetration testing is a penetration testing process where a pentester simulates attacks on a WiFi network, such as Evil Twin, Deauthenticate, and so on. WiFi Pentest itself uses many tools such as airgeddon, wireshark, and requires a WiFi adapter that supports Monitor mode. In this case, I used Tp Link Wn722n V1, yes, version 1 HAHAHA. Alright, let's move on to the discussion.
I got several Wi-Fi scopes, namely Internal Wi-Fi, Guest Wi-Fi, and Wi-Fi for Customer Service, which I decided to start with Guest Wi-Fi first.
WiFi Guest
I tried monitoring using aircrack-ng (airodump-ng) to see POWER, CHANNEL, SSID, BSSID, and others. For this first test case, I tried capturing the handshake, which I could later crack using the available wordlist or create my own WiFi.
The command I ran on my Kali Linux, which was already connected to a WiFi adapter, was something like this:
sudo airmon-ng start wlan0
sudo airodump-ng wlan0mon
In this case, I used VirtualBox with a KALI LINUX virtual machine (because it has all the necessary tools).
Okay, let's move on to how I obtained the handshake from this guest WiFi and what I found.
First, from the initial analysis using airodump-ng, I obtained the BSSID of my target WiFi, as well as its channel. From there, I tried capturing it using airodump-ng and saved the capture output as a .cap file.
The command is simple, and you can copy it:
sudo airodump-ng --bssid 'BSSID' -w 'NAMA FILE OUTPUT' <interface>
After capturing, we need to perform a deauth attack to disrupt the connection of people using that WiFi, so that they reconnect to the WiFi. Then we can get the Handshake from WPA2. The deauth command is very simple:
sudo aireplay-ng --deauth 0 -a 'BSSID' <interface>
And sure enough, I got a handshake from WiFi Guest. I tried cracking the password using aircrack-ng. The command was like this
sudo aircrack-ng -w /usr/share/wordlists/seclists/rockyou.txt output-02.cap
After cracking using aircrack-ng, I didn't get the password at all. I decided to do a little recon on my client's website, starting with the domain name, company name, director's name, and when the company was founded. I tried making several password combinations using cewl and some that I made myself.
And sure enough, I managed to guess the WiFi password because the WiFi used a weak password policy with no numbers or symbols in the password. Let's just say the password was “WellecometoRedacted.”
Yep, that's right. This was discovered because the WiFi used a Weak Password Policy where the password could be guessed.
Therefore, I tried to continue the recon after connecting to the WiFi. I tried to perform Host Discovery to identify the router (gateway). There were several arubaOS devices that were turned on when I performed host discovery. Let's say the IP addresses of the arubaOS devices were 192.168.0.1, 192.168.0.5, and 192.168.0.9.
Since it uses Aruba, I researched online whether there was a default login password for Aruba, and it turns out there is: the username is admin and the password is blank. Therefore, this is a finding where the router is not configured correctly or has no hardening at all.
This is clearly a finding of Default ArubaOS-CX Password.
Since the internal WiFi and CS use WPA2 Enterprise, I could only perform a few tests. There were no findings on the internal WiFi and CS WiFi. Moving on to the Guest WiFi, I tried several attacks, such as whether the Guest WiFi could communicate with the internal WiFi/CS, as well as ARP spoofing tests, and finally DHCP starvation tests. However, all of them failed.
That's all for this article. It's just for sharing experiences. Maybe some of you have encountered the same project. As I mentioned earlier, there's a Bypass EDR project. Maybe we'll discuss it in the next article. Thank you all :>