Security Assessment Methodology and Operational Pitfalls

Authorization Framework: Rules of Engagement

Wireless assessments collapse faster than wired ones when scope boundaries are vague. RF does not respect network diagrams. A tester transmitting deauth frames on channel 6 will hit every 2.4 GHz network in a three-floor radius, not just the target SSID. Your rules of engagement must explicitly define: frequency bands permitted for testing, maximum EIRP (not just "use reasonable power"), prohibited attack types (e.g., jamming vs. association testing), and physical boundaries—parking lot testing is legally and operationally distinct from lobby testing.

PTES structures engagement phases as baseline guidance requiring organizational customization. For wireless, that customization is non-optional. Jurisdiction matters acutely: U.S. assessments fall under 47 CFR Part 15 Subpart E (U-NII) and §15.247 (2.4 GHz spread spectrum), while European engagements face ETSI EN 301 893/EN 300 328. These frameworks diverge on power limits and DFS requirements. A test plan valid in Frankfurt may violate FCC rules in New York if you fail to recalculate EIRP ceilings. Document which regulatory framework governs each test environment; do not assume your home jurisdiction transfers.

Practical note: PTES does not contain a dedicated RF annex. Adapt its pre-engagement phase by adding RF-specific scope controls: channel exclusion lists for operational safety systems, coordination with facility management for transmitter activation windows, and explicit written authorization for any frame injection activity.

Pre-Engagement Verification Checklist

Item	Verification Method	Failure Consequence
Written authorization specifies frequency bands, channels, and max TX power	Legal review against test plan	Unlicensed transmission becomes willful interference
Facility/facilities notified of testing window and expected RF signatures	Email confirmation + on-site briefing	Guard response or employee panic call to law enforcement
Channel scan completed for safety-of-life systems (medical telemetry, industrial control)	Spectrum analyzer sweep 30 min pre-test	Harmful interference with protected operations
Test equipment firmware verified, driver versions documented	`iw list` / `airmon-ng` driver check	Reproducibility failure; evidence challenged in court
GPS/location logging enabled for all captures	`gpsd` + Kismet geolocation tag	Inability to prove test occurred at authorized location
Backup NIC available	Spare hardware in kit	Single point of failure mid-engagement

Operational Security: RF Leakage and Attribution

Your test traffic is indistinguishable from malicious traffic without proper operational controls. Three vectors expose you: RF leakage beyond the target perimeter, persistent MAC addresses linking to your organization, and temporal patterns (nightly deauth bursts at 02:00 are memorable to SOC analysts).

MAC rotation is table stakes, but implement it correctly. Randomized MACs in probe requests still leak chipset fingerprints through IE fields. For sensitive engagements, use dedicated test hardware never connected to your production identity.

# Verify current MAC and set monitor-mode interface to randomized
ip link show wlan0 | grep ether
sudo ip link set wlan0 down
sudo macchanger -r wlan0
sudo ip link set wlan0 up
sudo airmon-ng start wlan0 6

What it does: macchanger -r assigns a random locally-administered MAC, preserving the U/L bit to indicate non-global uniqueness. When to use it: Before every new test session; rotate between sessions, not mid-session (temporal churn itself becomes detectable). Risks: Some drivers ignore MAC changes in monitor mode; verify with iw dev post-change. Expected output: ether 02:xx:xx:xx:xx:xx (02 prefix confirms local bit set).

Timing discipline: Avoid predictable intervals. Automated deauth tools default to aggressive rates that trigger WIDS signatures and attract investigator attention. Space transmissions with jitter, and cease all activity outside authorized windows—"the test script was still running" is not a defensible explanation for 3 AM transmissions.

Equipment Failure Modes

Wireless NICs are the most fragile component in your kit. Driver instability under monitor mode, firmware crashes during frame injection, and antenna mismatch destroy test continuity and corrupt evidence integrity.

Failure	Symptom	Diagnostic
Driver injection incompatibility	`aireplay-ng -9` returns "No answer..." despite target present	Check `iw list` for "Supported interface modes: monitor" and "Supported commands: injection"
Firmware crash under load	Interface disappears from `ip link`; `dmesg` shows USB disconnect	Thermal throttling on compact adapters; add passive heatsink or reduce duty cycle
Antenna mismatch	Strong nearby signals, weak target at 20m	Verify connector type (RP-SMA vs. SMA); check VSWR if equipment available
USB bus power collapse	Multiple adapters drop simultaneously	Use powered hub; single bus ports deliver 500mA, insufficient for high-TX adapters

Lab (aggressive validation):

# Stress-test injection capability against known test AP
sudo aireplay-ng -9 -e TestLab -a 02:00:00:00:00:01 wlan0mon

Production (conservative verification):

# Validate monitor mode without transmitting test frames
sudo airmon-ng check wlan0
sudo iw dev wlan0 interface add wlan0mon type monitor
sudo iw dev wlan0mon set channel 6 NOHT
# Verify with passive-only capture
sudo tcpdump -i wlan0mon -c 100 -e -n | head -5

What it does: Production variant creates monitor interface without injection, using tcpdump to confirm frame reception. When to use it: In operational environments where any transmission risks interference. Risks: Passive-only mode cannot validate injection capability; pair with controlled lab test pre-engagement. Expected output: Radiotap headers with signal strength and data rates, confirming functional monitoring without TX validation.

False Positive Management

Your authorized deauth flood will trigger every wireless IDS in the enterprise. Coordinate with the blue team beforehand, but also build distinguishability into your test activity. Structured test signatures allow defenders to separate your work from genuine attacks:

Predictable sequence numbers in your test frames (e.g., fixed 4-byte payload prefix) for SOC correlation
Documented BSSID/MAC ranges reserved for test equipment
Real-time communication channel (out-of-band) for activity notifications

Without these controls, your test becomes an unscheduled incident. Worse, a genuine concurrent attack hides in your noise. Maintain a test activity log with 1-second granularity, share it with the SOC, and cross-correlate against their alert timeline post-test.

Physical Safety and Regulatory Hard Limits

FCC Part 15 sets absolute ceilings: 100W maximum output for spread spectrum systems, with SN-ratio-based reduction above 1W. ETSI limits are stricter and vary by sub-band. Exceeding these is not a compliance fine risk—it is a spectrum enforcement action with equipment seizure precedent.

More immediate is interference risk to safety systems. Industrial environments use 2.4 GHz for wireless sensor networks; medical facilities for telemetry. Your 30dBm amplifier can crash both. The checklist above mandates pre-test spectrum sweep; execute it with a portable analyzer or even a second NIC in wide scan mode:

# Rapid channel occupancy survey before active testing
sudo iw dev wlan0mon set channel 1
sudo iw dev wlan0mon scan passive | grep -E "(SSID|signal|freq)" | head -20
# Repeat for 6, 11, 36, 40, 44, 48, 149, 153, 157, 161

What it does: Passive scan on representative channels detects operating networks without transmitting. When to use it: Mandatory pre-test on all channels in scope. Risks: Passive scan misses non-WiFi emitters (cordless phones, proprietary telemetry); supplement with spectrum analyzer if safety systems are plausible. Expected output: SSID list with signal strengths; absence of expected medical/industrial SSID names does not guarantee channel safety.

Documentation Rigor and Report Structure

PTES emphasizes reproducibility. For wireless, that means: exact hardware (NIC chipset, antenna model, firmware version), driver and tool versions, channel and power settings, GPS coordinates, and complete packet captures (not just summaries). Aircrack-ng .cap files are standard; annotate with kismetdb or equivalent for geolocation correlation.

Report structure for wireless assessments should include:

Executive summary: Scope boundaries, test window, authorization reference
Methodology: PTES-adapted phase description with wireless-specific controls
Findings per SSID/BSSID: Signal plots, encryption state, authentication weaknesses, capture evidence
Operational notes: Deviations from plan, equipment failures, false positive resolution
Remediation timeline: Prioritized by exploitability from RF-accessible perimeter

A finding without a timestamped capture is an anecdote. A capture without a verification hash is unverifiable. Generate SHA-256 at capture time:

sha256sum capture_2024-06-15_site-alpha.cap >> capture_manifest.sha256

Hard-won insight: The most professionally damaging wireless assessment failure is not a missed vulnerability—it is an unprovable negative. "We found nothing" requires the same evidentiary standard as "We found WPA2-PSK cracked in four hours." Incomplete documentation transforms a clean result into an inconclusive one, and inconclusive results do not survive peer review or litigation discovery.