Custom ruged infra for WIFI assessments

7/1/2025

Effective Wi-Fi auditing in complex environments requires a strategic infrastructure that prioritizes stealth, data integrity, and remote management. This article details the construction of such a system, leveraging a distributed model for maximum flexibility and power. The field unit consists of a Raspberry Pi paired with a high-sensitivity Alfa Network adapter, chosen for its superior range and packet injection capabilities.

To achieve secure remote access, we will architect a private network using WireGuard. A central Virtual Private Server (VPS) will act as the hub, with both our Raspberry Pi and our management workstation connecting as clients. This creates a secure “VPN pool,” allowing us to manage the Pi and access its data from anywhere, simply by connecting to the same private network.

The core of our software stack is Kismet, deployed for passive reconnaissance. We will demonstrate a key technique: parsing Kismet’s output to dynamically generate a context-aware wordlist from captured SSIDs. This custom wordlist provides a significant advantage over generic dictionaries for subsequent WPA/WPA2 handshake cracking, forming the cornerstone of an intelligent and targeted assessment methodology. Follow along as we configure the hardware, establish the secure network, and automate the intelligence gathering.

Bill of Materials: What You’ll Need

Before we dive in, let’s outline the necessary components for this project.

Hardware

• Raspberry Pi: A Raspberry Pi 4 Model B is recommended for its performance and USB 3.0 ports, but a Pi 3B+ will also work.
• Alfa Network Wi-Fi Adapter: A high-gain adapter capable of monitor mode and packet injection. Models like the AWUS036ACH or AWUS036AXML are excellent choices.
• MicroSD Card: A high-speed, high-endurance card (32GB or larger is recommended) to host the operating system and store captured data.
• Portable Power Source: A quality USB-C power bank to keep the Raspberry Pi running in the field for extended periods.
• Optional: A case for the Raspberry Pi to provide physical protection.

Services

• Virtual Private Server (VPS): A basic VPS from a provider like DigitalOcean, Linode, Vultr, or Hetzner. A minimal instance with 1 CPU and 1GB of RAM running a modern Linux distribution (e.g., Debian 11/12 or Ubuntu 22.04) is sufficient.

Software

• Raspberry Pi OS Lite: The headless version of the Raspberry Pi operating system to minimize resource usage.
• WireGuard: The modern, fast, and secure VPN software we will use to build our private network.
• Kismet: The powerful wireless network detector, sniffer, and intrusion detection system.
• Linux Command-Line Tools: Standard utilities like grep, awk, sort, and uniq for processing Kismet’s output into a custom wordlist.
• SSH Client: Your preferred SSH client (e.g., OpenSSH on Linux/macOS, PuTTY on Windows) for connecting to the VPS and Raspberry Pi.

Part 1: Building the Secure Network Hub – The WireGuard VPS

The foundation of our distributed infrastructure is a secure and reliable network hub. This hub, running on our VPS, will act as the central point of contact for all our devices. By using WireGuard, we establish a private, encrypted network layer, ensuring that all communications between our management station and the remote Raspberry Pi are shielded from interception.

This section details the configuration of the WireGuard server on the VPS.

1.1 Initial Server Provisioning and Access

First, we must connect to our newly deployed VPS and prepare the system. After deployment, locate the static public IP address assigned to your server.

Open a terminal or PowerShell and establish an SSH connection. You will use the username and SSH key you configured during the VPS setup.

# Replace <your-vps-public-ip> with the server's public IP
# Replace <your-vps-user> with your configured username (e.g., ubuntu, debian)
ssh -i ~/.ssh/id_rsa <your-vps-user>@<your-vps-public-ip>

Once connected, perform a full system update and install the WireGuard package and its associated tools.

sudo apt update
sudo apt upgrade -y
sudo apt install wireguard -y

1.2 Generating Server Cryptographic Keys

WireGuard’s security model is built on modern cryptography. Each peer in the network has its own private and public key pair. We will now generate these for our server.

sudo -i
cd /etc/wireguard/
umask 077

Now, generate the key pair using WireGuard’s utility. This command pipeline generates a private key, saves it to a file named privatekey, and simultaneously pipes it to the wg pubkey command to generate the corresponding public key, which is saved to publickey.

wg genkey | tee privatekey | wg pubkey > publickey

1.3 Configuring the Server Interface

With our keys generated, we can create the WireGuard server configuration file, wg0.conf. This file defines the behavior of the wg0 virtual network interface.

nano /etc/wireguard/wg0.conf

Paste the following configuration into the editor. You must replace the PrivateKey value with the contents of the privatekey file you just created.

[Interface]
# The private IP address for the VPN server itself within our private network
Address = 10.10.0.1/24

# Automatically save peer configurations added via 'wg set' to this file on shutdown
SaveConfig = true

# The UDP port WireGuard will listen on for incoming connections
ListenPort = 51820

# Paste your server's private key here. (Run 'cat /etc/wireguard/privatekey' to view it)
PrivateKey = PASTE_YOUR_SERVER_PRIVATE_KEY_HERE

# These firewall rules enable Network Address Translation (NAT).
# They allow clients (like the Pi) to route their internet traffic through the VPS.
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostDown = ufw route delete allow in on wg0 out on eth0
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Note: The network interface eth0 is common but may differ depending on your VPS provider. You can find your primary interface name by running ip a.

To get your private key while editing, you can open a second SSH session to the server and run sudo cat /etc/wireguard/privatekey. Copy the output and paste it into the wg0.conf file, then save and exit the editor.

1.4 Enabling Packet Forwarding and Firewall Rules

For our VPS to act as a router for the VPN clients, we must enable IP forwarding at the kernel level.

# Edit the system control configuration file
nano /etc/sysctl.conf

Find the line #net.ipv4.ip_forward=1 and uncomment it by removing the #. Save the file, then apply the change immediately without rebooting:

sysctl -p

Next, we configure the ufw (Uncomplicated Firewall) to permit traffic on our WireGuard port (UDP 51820) and our SSH port (TCP 22) to ensure we don’t lock ourselves out.

ufw allow 51820/udp
ufw allow 22/tcp
ufw enable

Press y and Enter to confirm and activate the firewall.

1.5 Activating the WireGuard Service

Finally, we enable and start the WireGuard service. The --now flag starts it immediately, and enable ensures it will launch automatically on boot.

systemctl enable --now wg-quick@wg0

Verify that the service is running and the wg0 interface is active.

wg show

The output should display the wg0 interface, its public key, and the listening port. At this stage, it will show zero peers. You can now type exit to return to your regular user shell.

1.6 Configuring the Management Workstation Client

Before we configure the Raspberry Pi, we must first connect our own management workstation to the VPN. This allows us to test the connection and manage the server from within the private network.

On your local machine (your laptop or desktop), install the appropriate WireGuard client for your operating system. Use the client’s interface to generate a new key pair for this machine.

Create a configuration file (e.g., management-station.conf) with the following template:

[Interface]
# Assign a unique private IP for this client within the VPN
Address = 10.10.0.2/32
PrivateKey = PASTE_YOUR_CLIENTS_PRIVATE_KEY_HERE
# Optional but recommended: Set a DNS server for the client
DNS = 1.1.1.1, 1.0.0.1

[Peer]
# The public key of the VPS server
PublicKey = PASTE_THE_SERVERS_PUBLIC_KEY_HERE

# Route all traffic through the VPN. This is useful for hiding your real IP.
AllowedIPs = 0.0.0.0/0

# The public endpoint of your VPS server
Endpoint = <your-vps-public-ip>:51820

• To get the server’s public key, run sudo cat /etc/wireguard/publickey on your VPS.
• Import this file into your local WireGuard client.

1.7 Authorizing the Client Peer on the Server

The final step is to create the trust relationship. SSH back into your VPS and tell the WireGuard server about your management client’s public key and its assigned private IP address.

# Replace <CLIENT_PUBLIC_KEY> with the public key from your management workstation
sudo wg set wg0 peer <CLIENT_PUBLIC_KEY> allowed-ips 10.10.0.2/32

Because we set SaveConfig = true in our wg0.conf, this new peer configuration will be saved automatically.

Activate the tunnel on your management workstation. You can verify a successful connection by checking the output of wg show on the server, which should now list your workstation as a peer. You can also visit a “what is my IP” website, which should now display the public IP address of your VPS.

With our secure network hub operational, the next step is to configure our field unit: the Raspberry Pi.

Part 2: Integrating the Raspberry Pi Field Unit

With the secure network hub operational, the next phase is to configure and integrate our Raspberry Pi field unit. This device will perform the on-site wireless reconnaissance. The objective is to make it a trusted peer within our WireGuard network, allowing for secure remote management and data access from our workstation.

2.1 Prerequisites: Gathering Server Information

Before configuring the Raspberry Pi, we require two key pieces of information from the VPS server. Ensure you have these readily available:

1. Server’s Public IP Address: The static IP of your VPS.
2. Server’s Public Key: The cryptographic identifier for the server.

You can retrieve the server’s public key by logging into your VPS via SSH and executing the following command:

sudo wg show wg0 public-key

2.2 Field Unit Key Generation

First, we must establish a new cryptographic identity for the Raspberry Pi. On the Pi itself, open a terminal and ensure the wireguard-tools package is installed (sudo apt install wireguard-tools).

Execute the following command to generate a new private key and derive its corresponding public key.

wg genkey | tee pi_private.key | wg pubkey > pi_public.key

This process creates two files in your current directory:

• pi_private.key: The secret key for the Raspberry Pi. This file must be protected and never shared.
• pi_public.key: The public key for the Pi. This key will be shared with the server to authorize the device.

View the contents of the public key file and copy the entire string. This will be used in the next step.

Generated bash

cat pi_public.key

2.3 Server-Side Peer Authorization

The server must be explicitly configured to trust connection attempts from our new Raspberry Pi. To do this, we will add the Pi’s public key to the server’s peer list.

SSH into your VPS server from your management workstation and open the WireGuard configuration file with a text editor.

sudo nano /etc/wireguard/wg0.conf

Append a new [Peer] block to the end of the file to define the Raspberry Pi. We will also add a new iptables rule to the PostUp and PostDown sections to explicitly allow traffic forwarding between VPN clients. This is essential for enabling your management station (10.10.0.2) to communicate directly with the Pi (10.10.0.3).

Your updated wg0.conf should look like this:

[Interface]
Address = 10.10.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = <YOUR_SERVER_PRIVATE_KEY_IS_ALREADY_HERE>
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -I FORWARD -i wg0 -o wg0 -j ACCEPT # Add this line
PostDown = ufw route delete allow in on wg0 out on eth0
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -o wg0 -j ACCEPT # Add this line

# --- Peer #1 (Management Workstation) ---
[Peer]
PublicKey = <PUBLIC_KEY_OF_YOUR_FIRST_CLIENT>
AllowedIPs = 10.10.0.2/32

# --- Peer #2 (Raspberry Pi Field Unit) --- ADD THIS BLOCK ---
[Peer]
# The public key copied from the Raspberry Pi
PublicKey = PASTE_THE_RASPBERRY_PI_PUBLIC_KEY_HERE

# The unique private IP address assigned to the Pi
AllowedIPs = 10.10.0.3/32

Save the file and exit the editor. To apply the changes, the wg0 interface must be restarted. This forces it to re-read the modified configuration file.

sudo wg-quick down wg0 && sudo wg-quick up wg0

Verify that the server now recognizes both peers by running sudo wg show. The output should now list two distinct peers.

2.4 Final Field Unit Configuration and Connection

The final stage is to create the client configuration file on the Raspberry Pi so it knows how to connect to the server.

On the Raspberry Pi, create a new configuration file.

nano pi.conf

Paste the following template into the file, populating the placeholder values with your specific information:

[Interface]
# The private key for THIS Raspberry Pi (from pi_private.key)
PrivateKey = PASTE_THE_RASPBERRY_PI_PRIVATE_KEY_HERE

# The Pi's assigned private IP address inside the VPN
Address = 10.10.0.3/32

# Use a reliable DNS resolver when connected
DNS = 1.1.1.1

[Peer]
# The public key of your VPS server
PublicKey = PASTE_THE_SERVER_PUBLIC_KEY_HERE

# Routes all network traffic from the Pi through the VPN tunnel.
# This ensures both management and internet-bound traffic are secured.
AllowedIPs = 0.0.0.0/0

# Your server's public IP address and listening port
Endpoint = <YOUR_VPS_PUBLIC_IP>:51820

# Maintains the connection through NAT and restrictive firewalls by sending periodic keepalive packets.
PersistentKeepalive = 25

Save and exit the editor. Now, move this configuration to the standard WireGuard directory and set strict file permissions to protect the private key.

sudo mv pi.conf /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

Activate the tunnel using wg-quick.

sudo wg-quick up wg0

To ensure the connection persists after a reboot, enable the service:

sudo systemctl enable wg-quick@wg0

2.5 System Verification

The infrastructure is now complete. From your management station (connected to the VPN at 10.10.0.2), you should be able to ping and SSH directly into the Raspberry Pi using its private VPN address.

# From your management station
ping 10.10.0.3
ssh <pi-user>@10.10.0.3

The Raspberry Pi is now a securely connected, remote-access field unit, ready for the deployment of our wireless assessment software.

Part 3: Deploying the Kismet Wireless Reconnaissance Engine

With our secure, distributed network fully operational, we can now deploy the core software for our intelligence-gathering mission: Kismet. Kismet is a sophisticated wireless network detector, sniffer, and intrusion detection system. We will run it headless on the Raspberry Pi field unit and access its powerful web-based user interface remotely and securely from our management workstation.

This operational model allows the Pi to be deployed discreetly in a target environment while we monitor and manage the data collection from any location, all tunneled through our private WireGuard network.

3.1 Kismet Installation on the Field Unit

First, we must install the Kismet package and its dependencies on the Raspberry Pi. Connect to the Pi over the VPN using its private IP address.

# Connect from your management workstation
ssh <pi-user>@10.10.0.3

Once connected, update the package list and install Kismet.

sudo apt update
sudo apt install kismet -y

During installation, you may be prompted to allow the Kismet service to be run by a non-root user. For our purposes, select Yes and add your current user (e.g., pi) to the kismet group. This simplifies permissions, though we will still launch it with sudo for direct hardware control.

sudo usermod -aG kismet $USER

You may need to log out and log back in for this group change to take effect.

3.2 Launching and Accessing the Kismet Server

Kismet requires elevated privileges to put the wireless hardware into monitor mode and capture raw packets. Therefore, it must be launched with sudo.

On the Raspberry Pi’s terminal, start the Kismet server:

# This will launch the Kismet server and start the first-time setup wizard
sudo kismet

On its initial run, Kismet will prompt you to set up an administrator account. Follow the on-screen instructions to create a username and a strong password.

Once the server is running, it will listen for connections on port 2501 on the Pi’s localhost interface. To access this securely from our management workstation, we will create an SSH local port forward.

# This forwards local port 2501 to port 2501 on the Pi (10.10.0.3)
ssh -L 2501:localhost:2501 <pi-user>@10.10.0.3

http://localhost:2501

You will be presented with the Kismet login screen. Enter the administrator credentials you created earlier.

3.3 Configuring the Alfa Network Adapter as a Data Source

Upon successful login, you will be in the Kismet web UI. Before Kismet can begin collecting data, you must tell it which hardware interface to use.

1. From the main menu (hamburger icon ☰ in the top left), navigate to Data Sources.
2. Your Alfa Network adapter should be listed (e.g., wlan1, wlan2). Kismet will show it as an available but inactive source.
3. Click the Enable button next to the interface. Kismet will automatically handle the process of putting the adapter into RF Monitor mode.
4. Once enabled, the interface status will change, and Kismet will immediately begin capturing packets.

For a true “set-it-and-forget-it” deployment, running sudo kismet in a standard SSH session is not ideal, as it will terminate when you disconnect. It is highly recommended to use a terminal multiplexer like tmux or screen.

Example with tmux:

1. Install tmux on the Pi: sudo apt install tmux
2. Start a new session: tmux new -s kismet
3. Start the server: sudo kismet
4. You can now safely detach from the session by pressing Ctrl+b then d. Kismet will continue running in the background.
5. To re-attach later, SSH back into the Pi and run: tmux attach -t kismet

3.4 Passive Intelligence Gathering

With the data source active, Kismet is now performing its primary function: passively listening to the wireless spectrum. The Raspberry Pi and Alfa adapter are now a silent, remote sensor. You can close the browser tab and even terminate the SSH port-forwarding tunnel; the Kismet server will continue running on the Pi, collecting data.

Leave the unit running for an extended period to maximize data collection. It will log:

• Access Points (BSSIDs) and their advertised names (SSIDs).
• Client Devices and the networks they are probing for.
• Device relationships, signal strengths, and much more.

This captured data forms the raw intelligence for our next step. In the following section, we will extract the collected SSIDs from Kismet’s logs to construct a highly targeted, custom wordlist for our continued assessment.

Part 4: From Reconnaissance to Attack – Rogue AP Implementation

With a rich dataset of wireless networks harvested by Kismet and stored on our Raspberry Pi, our operational focus now shifts frm passive listening to active measures. The objective of this phase is to leverage our intelligence to capture authentication handshakes or credentials from unsuspecting client devices.

The primary methodology is the “Rogue Access Point” or “Evil Twin” attack. This technique exploits the inherent trust that wireless devices place in familiar network names (SSIDs). By broadcasting an SSID that a device has previously connected to, we can entice it to auto-connect to our malicious hardware, allowing us to intercept authentication traffic. We will explore two distinct methods for executing this attack.

4.1 Preparing the Attack Data

Before launching any attacks, we must process the data gathered by Kismet into a clean, usable format. SSH into the Raspberry Pi and use command-line tools to parse the Kismet logs (kismetdb) or its plain-text output to extract the SSIDs and their corresponding authentication methods.

The goal is to create a simple CSV file named networks.csv. Each line should contain the SSID and its primary encryption type.

Example networks.csv content:

CorporateGuest,WPA2
Free-Airport-WiFi,Open
MainOffice,WPA3-SAE
CoffeeShop-Net,WPA2/WPA3

This file will serve as the input for both of our attack methodologies.

4.2 Method 1: High-Efficiency Handshake and PMKID Capture with hcxdumptool

For rapid and broad-spectrum attacks, the most effective tool is hcxdumptool. This specialized utility is designed for maximum efficiency in capturing credentials. It actively probes for clients and can capture the Pairwise Master Key Identifier (PMKID) from the initial association frame of a WPA/WPA2/WPA3 connection. Capturing a PMKID is often faster and more reliable than waiting for a full four-way handshake.

• Project Repository: https://github.com/ZerBea/hcxdumptool

Step-by-Step hcxdumptool Execution:

1. Install Dependencies and Tool: On the Raspberry Pi, install the necessary libraries and clone the repository.

   sudo apt-get install libpcap-dev libssl-dev
   git clone <https://github.com/ZerBea/hcxdumptool.git>
   cd hcxdumptool
   make
   sudo make install
   
       ```

2. Prepare the Interface:hcxdumptool requires exclusive control of the wireless adapter. It is critical to stop any services that might interfere, such as NetworkManager.

   sudo systemctl stop NetworkManager
   # Use 'ip' or 'iw' to ensure the interface is down before starting
   sudo ip link set <your-wifi-interface> down

3. Launch the Attack: Execute hcxdumptool with your Alfa adapter as the interface and specify an output file for the captured hashes. The -enable_status=1 option provides real-time on-screen feedback.

   sudo hcxdumptool -i wlan1 -o captured_hashes.pcapng --enable_status=1
   
       ```

4. Convert Captured Data: After letting the tool run, stop it with Ctrl+C. The output file (captured_hashes.pcapng) is not yet in a format suitable for cracking. Use the companion hcxpcapngtool to convert it.

   hcxpcapngtool -o hashcat_ready.hc22000 captured_hashes.pcapng
   
       ```
   
       The resulting `.hc22000` file contains the extracted hashes, ready for an offline cracking attempt with Hashcat.

4.3 Method 2: Sequential Targeted Broadcasting with a Custom Script

This method offers a more controlled, one-by-one approach. Instead of attacking all networks simultaneously, an automation script iterates through our networks.csv file, broadcasting each SSID as an open network for a set duration. This is particularly useful for live monitoring to see if a specific device connects, confirming it has a target SSID in its preferred network list.

Acquiring the Automation Script

For this method, we will use a purpose-built automation script. The script is maintained in a public GitHub repository to facilitate easy access and updates. You can acquire it by cloning the repository directly onto your Raspberry Pi.

# Example repository - replace with the actual URL
git clone <https://github.com/ExampleUser/Smart-Evil-Twin-Script.git>
cd Smart-Evil-Twin-Script

Step-by-Step Script Execution:

1. Install Prerequisites: The script relies on hostapd for creating the access point, dnsmasq for DHCP services, and the aircrack-ng suite for interface management.

   sudo apt-get install hostapd dnsmasq aircrack-ng
   
       ```

2. Prepare the Target File: Create your networks1.csv file as described in section 4.1. Place this file inside the Smart-Evil-Twin-Script directory you just cloned. The script is designed to look for it in its local directory.

3. Launch the Script: Navigate into the repository directory and execute the script with sudo. It will read the CSV, put the specified interface into monitor mode, and begin broadcasting each SSID sequentially.

   sudo ./smart_twin.sh
   
       ```
   
       Monitor the terminal output for live status updates. All detailed events, including DHCP requests from connecting clients, are automatically appended to the `smart_evil_twin_log.txt` file for later, in-depth analysis.

With these active measures, we have successfully captured raw handshake data. The final step in our assessment is to take these captured hashes offline and attempt to crack them to recover the original pre-shared keys.