Kali Forensic WiFi Capture Toolkit

Download Kali 2025.4 Live ISO

Get the official live ISO via torrent for integrity verification.

https://cdimage.kali.org/kali-2025.4/kali-linux-2025.4-live-amd64.iso.torrent

Verify the SHA256 checksum after download against the value published on kali.org/get-kali.

Flash with Rufus

1. Download and open Rufus (rufus.ie)
2. Select the SSK 256GB SSD as the target device
3. Select the Kali ISO
4. When prompted, select "Write in DD Image mode" (not ISO mode)
5. Create a persistence partition -- set to ~100GB
6. Click Start and wait for completion

BIOS Setup (Acer Nitro ANV16-72)

1. Power on the laptop, press F2 repeatedly to enter BIOS
2. Navigate to Security tab -- set Secure Boot to Disabled
3. Navigate to Boot tab -- set the SSK SSD as first boot priority
4. Save and exit (F10)

First Boot

1. At the GRUB menu, select "Live system (persistence, check kali-runp)" or "Live (persistence)"
2. Wait for Kali desktop to load
3. Open a terminal

Change Default Password

Default credentials are kali / kali. Change immediately.

$ passwd

Update System

$ sudo apt update && sudo apt upgrade -y

This ensures aircrack-ng, wireshark, and drivers are at their latest versions.

You need two WiFi adapters working simultaneously: the internal Intel adapter (wlan0) connects to your phone hotspot for internet access, and the ALFA AWUS036AXM (wlan1) goes into monitor mode for passive capture. They operate independently.

Connect Internal WiFi to Phone Hotspot

First, set up your phone as a WiFi hotspot. Then connect the laptop's internal adapter:

# List available WiFi networks
$ nmcli dev wifi list

# Connect to your phone hotspot
$ nmcli dev wifi connect "YourHotspotName" password "YourPassword"

# Verify connection
$ nmcli con show --active

# Test internet
$ ping -c 3 1.1.1.1

Install and Connect ProtonVPN

Route your internet traffic through a VPN so your ISP and anyone monitoring the hotspot can't see what you're doing.

# Install ProtonVPN CLI
$ sudo apt install protonvpn-cli -y

# Login (will prompt for credentials)
$ protonvpn-cli login

# Connect to fastest available server
$ protonvpn-cli connect --fastest

# Verify VPN is active
$ protonvpn-cli status

# Check your external IP has changed
$ curl ifconfig.me

Plug In ALFA Adapter

With the internal WiFi connected to the hotspot, plug in the ALFA via the USB 3.0 extension cable.

# Check USB device is recognized
$ lsusb | grep -i mediatek

# Check wireless interfaces -- should see both wlan0 and wlan1
$ iwconfig

# Detailed interface info
$ iw dev

# Check link state
$ ip link show

Troubleshooting -- Not Detected

# Check kernel messages for driver loading
$ dmesg | grep mt7921

# Manually load the driver module
$ sudo modprobe mt7921u

# Full USB device listing (look for MediaTek or 0e8d vendor ID)
$ lsusb

Verify Both Adapters Working Simultaneously

After putting the ALFA into monitor mode (Section 4), verify both are operational:

$ iwconfig

Expected output should show both adapters:

wlan0     IEEE 802.11  ESSID:"YourHotspotName"
          Mode:Managed  Frequency:2.437 GHz  Access Point: AA:BB:CC:DD:EE:FF
          Bit Rate=72.2 Mb/s   Tx-Power=20 dBm
          Link Quality=70/70  Signal level=-38 dBm

wlan1mon  IEEE 802.11  Mode:Monitor  Frequency:5.785 GHz
          Tx-Power=20 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off

wlan0 = internal adapter, Managed mode, connected to hotspot. wlan1mon = ALFA, Monitor mode, capturing. Both working independently.

Pre-installed on Kali (verify with which)

Install Additional Tools

Run these while connected to internet via hotspot:

# mdk4 -- Attack signature analysis tool (understand what attack looks like, NOT for attacking)
$ sudo apt install mdk4 -y

# hcxdumptool -- Alternative capture tool, good for PMKID capture and extended frame analysis
$ sudo apt install hcxdumptool -y

# kismet -- Wireless IDS / network detector, can run as daemon for continuous monitoring
$ sudo apt install kismet -y

# wifite2 -- Automated wireless auditing tool
$ sudo apt install wifite -y

# horst -- Lightweight wireless scanner, great for signal strength histograms
$ sudo apt install horst -y

# wavemon -- Terminal-based WiFi signal monitor with real-time visualization
$ sudo apt install wavemon -y

# linssid -- Graphical WiFi scanner with signal strength graphs over time
$ sudo apt install linssid -y

Or install all at once:

$ sudo apt install mdk4 hcxdumptool kismet wifite horst wavemon linssid -y

Monitor mode puts the adapter into a state where it captures all wireless frames on a channel -- not just traffic addressed to it. This is how you'll see the attacker's frames.

Enable Monitor Mode (ALFA Only) -- Preserving Internet

Method 1: Manual (RECOMMENDED -- keeps internet alive)

# Put ONLY the ALFA adapter into monitor mode
# This does NOT touch wlan0 or NetworkManager
$ sudo ip link set wlan1 down
$ sudo iw dev wlan1 set type monitor
$ sudo ip link set wlan1 up

The interface stays named wlan1 (does NOT become wlan1mon). Use wlan1 in all subsequent commands.

# Verify monitor mode is active
$ iwconfig wlan1

Confirm: Mode:Monitor in the output. Your internet on wlan0 should still be working.

# Start capturing on channel 157
$ sudo airodump-ng wlan1 --channel 157 -w evidence_ch157

Method 2: airmon-ng (if Method 1 doesn't work)

Only use this if the manual method above fails. It WILL kill your internet temporarily.

# This kills NetworkManager -- your internet WILL drop
$ sudo airmon-ng check kill
$ sudo airmon-ng start wlan1

This creates wlan1mon. Then immediately restore internet:

# Restart NetworkManager to get internet back on wlan0
$ sudo systemctl start NetworkManager

# Wait a few seconds for it to initialize, then reconnect
$ sleep 3
$ nmcli device wifi connect "Praxis" password "YOUR_HOTSPOT_PASSWORD" ifname wlan0

# Check both adapters
$ iwconfig

# You should see:
# wlan0     Mode:Managed  ESSID:"Praxis"   (internet, connected)
# wlan1     Mode:Monitor                    (capture, listening)
# -- OR if using Method 2 --
# wlan0     Mode:Managed  ESSID:"Praxis"   (internet, connected)
# wlan1mon  Mode:Monitor                    (capture, listening)

Stop Monitor Mode (When Done)

If using Method 1:

$ sudo ip link set wlan1 down
$ sudo iw dev wlan1 set type managed
$ sudo ip link set wlan1 up

If using Method 2:

$ sudo airmon-ng stop wlan1mon

This is where you'll spend most of your time. airodump-ng passively listens and displays all APs and clients it can see.

Scan All Channels

# See everything -- all APs, all clients, all channels
$ sudo airodump-ng wlan1mon

Use this first to get a lay of the land. Look for the CTS-A SSID on both channel 149 (legitimate) and channel 157 (attacker).

Lock to Attack Channel

# Focus on channel 157 only -- the attack channel
$ sudo airodump-ng wlan1mon --channel 157

Capture Everything on Channel 157

# Capture to file on channel 157 (all BSSIDs -- don't filter yet)
$ sudo airodump-ng wlan1mon --channel 157 -w capture_157

# Or filter to AP BSSID on channel 157
$ sudo airodump-ng wlan1mon --channel 157 --bssid 19:33:CE:D0:A2:9F -w capture_157

This writes capture files to capture_157-01.cap, capture_157-01.csv, etc. These are your forensic evidence files.

Reading the airodump-ng Output

Top section -- Access Points:

Bottom section -- Clients:

Example airodump-ng Output

All-channel scan (what you might see initially):

 CH  9 ][ Elapsed: 30 s ][ 2026-03-22 14:30

 BSSID              PWR  Beacons  #Data  #/s  CH   MB   ENC   CIPHER  AUTH  ESSID

 19:33:CE:D0:A2:9F  -42      245     18    0  149  540  WPA2  CCMP    PSK   CTS-A
 AA:BB:CC:DD:EE:FF  -58      198      0    0  157  270  WPA2  CCMP    PSK   CTS-A
 00:1A:2B:3C:4D:5E  -71       82      3    0   36  130  WPA2  CCMP    PSK   Neighbor_WiFi
 11:22:33:44:55:66  -85       31      0    0    6   54  WPA2  CCMP    PSK   DIRECT-tv

 BSSID              STATION            PWR   Rate  Lost  Frames  Probe

 19:33:CE:D0:A2:9F  C0:A8:10:42:67:7E  -38   54e-24e    0     124  CTS-A
 19:33:CE:D0:A2:9F  50:2E:91:48:F6:4A  -45   54e-24e    0      87  CTS-A
 (not associated)   B0:68:E6:B2:19:7B  -32    0 - 1     0       3  CTS-A

In this example, the highlighted line shows a SECOND AP broadcasting "CTS-A" on channel 157 with a DIFFERENT BSSID. That's the rogue device. Note the BSSID AA:BB:CC:DD:EE:FF (placeholder -- yours will be different).

Locked to channel 157 (what the attack channel looks like):

 CH 157 ][ Elapsed: 2 mins ][ 2026-03-22 14:35

 BSSID              PWR  Beacons  #Data  #/s  CH   MB   ENC   CIPHER  AUTH  ESSID

 AA:BB:CC:DD:EE:FF  -52     1247      0    0  157  270  WPA2  CCMP    PSK   CTS-A

 BSSID              STATION            PWR   Rate  Lost  Frames  Probe

 (no clients -- everyone has moved to channel 149)

A lone AP on channel 157 still broadcasting CTS-A -- that's the planted device. High beacon count, zero data frames (no clients are connecting), signal strength tells you how close you are.

What Is an Evil Twin?

An evil twin is a rogue access point broadcasting the same SSID (CTS-A) on the same or nearby channel, potentially with a stronger signal than the real AP. It creates a cycle:

1. Client sees two APs advertising "CTS-A" -- one is the real Peplink, one is the rogue
2. Client tries to roam to the rogue (especially if it has stronger signal)
3. Client fails WPA2 authentication (wrong PSK or no PSK on the rogue)
4. Client falls back to the real AP
5. Client sees the rogue again, tries again -- cycle repeats
6. Result: constant disconnects, reconnects, degraded performance

How to Detect an Evil Twin

Step 1: airodump-ng -- look for two BSSIDs with the same ESSID

# Scan all channels -- look for TWO entries for "CTS-A" with different BSSIDs
$ sudo airodump-ng wlan1mon

What to look for:

• Two BSSIDs for "CTS-A" -- the real one (19:33:CE:D0:A2:9F) and an unknown one
• Different channels -- real AP on 149, rogue potentially on 157 (or any channel)
• Different encryption level -- rogue may show OPN (open) or lower encryption
• Different signal strength -- rogue may be stronger if it's closer to the building
• Different MB (speed) rating -- rogue hardware may support different max speeds

Step 2: Wireshark -- compare beacon frame details between the two BSSIDs

# Filter beacons from the suspected rogue BSSID
wlan.fc.type_subtype == 0x0008 && wlan.bssid == AA:BB:CC:DD:EE:FF

# Compare with beacons from the real AP
wlan.fc.type_subtype == 0x0008 && wlan.bssid == 19:33:CE:D0:A2:9F

Compare these details between the two BSSIDs:

• Vendor-specific IEs (Information Elements) -- real Peplink will have Peplink vendor IEs; a Raspberry Pi or Pineapple won't
• Supported rates -- different hardware = different rate sets
• HT/VHT capabilities -- hardware capability differences will show here
• Beacon interval -- default is 100 TU; attack tools sometimes use different values
• RSN (Robust Security Network) IE -- differences in cipher suites or AKM suites

Confirmation Steps

# Lock to channel 157 and look for ANY AP broadcasting "CTS-A"
# that ISN'T the real Peplink BSSID
$ sudo airodump-ng wlan1mon --channel 157

# If you find one, capture its traffic specifically
$ sudo airodump-ng wlan1mon --channel 157 --bssid AA:BB:CC:DD:EE:FF -w evil_twin_capture

How CSA Works

Channel Switch Announcement is a legitimate 802.11 mechanism designed to let an AP tell clients "I'm moving to a new channel -- follow me." It's embedded as an Information Element (IE) inside beacon frames and probe responses.

In a CSA injection attack:

1. The attacker sends fake beacon frames with the real AP's BSSID (spoofed)
2. These beacons contain a CSA IE that says "AP is moving to channel X"
3. Clients receive the beacon, see the CSA, and obey -- they switch to channel X
4. On channel X, the real AP isn't there. Clients lose connectivity.
5. Clients eventually scan back, find the real AP, reconnect -- then get hit again

Why PMF Does NOT Protect Against CSA

This is the critical distinction: deauth attacks send forged unicast management frames (which PMF can verify). CSA attacks modify broadcast beacons (which PMF cannot verify). The 802.11 specification has no protection for broadcast management frames.

Detection in Your Captures

Wireshark filters for CSA:

# CSA Information Element (tag number 37)
wlan.tag.number == 37

# Extended CSA (tag number 60, extension 33)
wlan.ext_tag.number == 33

# CSA channel switch mode field
wlan.csa.channel_switch_mode

# Beacons containing CSA on channel 157
wlan.fc.type_subtype == 0x0008 && wlan.tag.number == 37

# Action frames with Spectrum Management category (includes CSA)
wlan.fixed.category_code == 0

# Combine: any CSA activity on the CTS-A BSSID
wlan.tag.number == 37 && wlan.bssid == 19:33:CE:D0:A2:9F

tshark one-liner to detect CSA in a capture file:

$ tshark -r capture_157-01.cap -Y "wlan.tag.number == 37" -T fields -e frame.time -e wlan.bssid -e wlan.csa.channel_switch.new_channel_number

mdk4 CSA signature (what the attack tool generates):

# This is what an attacker WOULD run (DO NOT EXECUTE -- reference only)
# mdk4 wlan0mon d -c 157
# This generates fake beacons with CSA IE on channel 157

What the Captured Frame Looks Like

In Wireshark, expand a beacon frame containing CSA. You'll see:

IEEE 802.11 Beacon frame
  Tagged parameters:
    ...
    Tag: Channel Switch Announcement (37)
      Tag Number: Channel Switch Announcement (37)
      Tag length: 3
      Channel Switch Mode: 1       <-- 1 = clients must stop transmitting
      New Channel Number: 36       <-- channel the attacker wants clients to go to
      Channel Switch Count: 1      <-- switch after 1 more beacon interval

Key fields to examine:

• Channel Switch Mode: 1 -- tells clients to stop transmitting immediately (more disruptive)
• New Channel Number -- where clients are being told to go. If this is a channel the real AP isn't on, it's an attack
• Channel Switch Count -- how many beacon intervals before the switch. Low values (1-3) cause immediate disruption

For each model below: what it looks like in airodump-ng, what to filter for in Wireshark, whether PMF blocks it, and how to remediate.

Management Frame Types

# All management frames
wlan.fc.type == 0

# All control frames
wlan.fc.type == 1

# All data frames
wlan.fc.type == 2

# --- Specific management frame subtypes ---

# Association request
wlan.fc.type_subtype == 0x0000

# Association response
wlan.fc.type_subtype == 0x0001

# Reassociation request
wlan.fc.type_subtype == 0x0002

# Probe request
wlan.fc.type_subtype == 0x0004

# Probe response
wlan.fc.type_subtype == 0x0005

# Beacon frames
wlan.fc.type_subtype == 0x0008

# Disassociation
wlan.fc.type_subtype == 0x000a

# Authentication
wlan.fc.type_subtype == 0x000b

# Deauthentication
wlan.fc.type_subtype == 0x000c

# Action frames
wlan.fc.type_subtype == 0x000d

Reason Codes (Deauth/Disassoc)

# Reason code 1 -- Unspecified reason
wlan.fixed.reason_code == 1

# Reason code 7 -- Class 3 frame from nonassociated STA (most common in attacks)
wlan.fixed.reason_code == 7

# Reason code 6 -- Class 2 frame from nonauthenticated STA
wlan.fixed.reason_code == 6

Address-based Filters

# Frames from specific BSSID
wlan.bssid == XX:XX:XX:XX:XX:XX

# Frames TO a specific client (destination address)
wlan.da == XX:XX:XX:XX:XX:XX

# Frames FROM a specific client (source address)
wlan.sa == XX:XX:XX:XX:XX:XX

# Any frame involving a specific MAC (source, dest, or BSSID)
wlan.addr == XX:XX:XX:XX:XX:XX

# Broadcast frames (sent to all clients)
wlan.da == ff:ff:ff:ff:ff:ff

Other Useful Filters

# Retransmissions (high count = interference or jamming)
wlan.fc.retry == 1

# FCS (Frame Check Sequence) errors -- corrupted frames
frame.checksum_bad == 1

# CSA Information Element
wlan.tag.number == 37

# Extended CSA
wlan.ext_tag.number == 33

# Specific SSID in beacons/probes
wlan.ssid == "CTS-A"

# Beacons claiming to be CTS-A (spot the rogue)
wlan.fc.type_subtype == 0x0008 && wlan.ssid == "CTS-A"

Combined Filter Examples

# All deauth AND disassoc frames from the CTS-A BSSID
(wlan.fc.type_subtype == 0x000c || wlan.fc.type_subtype == 0x000a) && wlan.bssid == 19:33:CE:D0:A2:9F

# Deauth frames targeting Jonathan's desktop
wlan.fc.type_subtype == 0x000c && wlan.da == C0:A8:10:42:67:7E

# All management frames from an unknown/rogue BSSID
wlan.fc.type == 0 && wlan.bssid == AA:BB:CC:DD:EE:FF

# Beacons with CSA from CTS-A (the attack signature)
wlan.fc.type_subtype == 0x0008 && wlan.ssid == "CTS-A" && wlan.tag.number == 37

# Everything NOT from the real AP (find the rogue)
wlan.ssid == "CTS-A" && !(wlan.bssid == 19:33:CE:D0:A2:9F)

Wireshark Deauth Frame Details (What You'll See)

Frame 1247: 26 bytes on wire, 26 bytes captured
IEEE 802.11 Deauthentication, Flags: ........
    Type/Subtype: Deauthentication (0x000c)
    Frame Control Field: 0x00c0
    Duration: 314 microseconds
    Receiver address: C0:A8:10:42:67:7E (CTRS-JONATHAN-DESK)
    Transmitter address: 19:33:CE:D0:A2:9F (CTS-A AP -- likely spoofed)
    BSS Id: 19:33:CE:D0:A2:9F
    Fragment number: 0
    Sequence number: 0        <-- Sequence 0 is suspicious (attackers often use 0)
  IEEE 802.11 wireless LAN management frame
    Fixed parameters:
      Reason code: Class 3 frame received from nonassociated STA (0x0007)

tshark is Wireshark's CLI counterpart. Use it when you want to capture or analyze without the GUI -- useful for headless operation, scripted analysis, or when the GUI is too resource-heavy.

Basic Capture to File

# Capture on channel 157, write to file
$ sudo tshark -i wlan1mon -w capture_157.pcap

# Capture with a packet count limit (stop after 10000 frames)
$ sudo tshark -i wlan1mon -c 10000 -w capture_157.pcap

# Capture with a time limit (stop after 300 seconds / 5 minutes)
$ sudo tshark -i wlan1mon -a duration:300 -w capture_157.pcap

Live Display with Filter

# Show only deauth frames in real-time
$ sudo tshark -i wlan1mon -Y "wlan.fc.type_subtype == 0x000c"

# Show only CSA frames in real-time
$ sudo tshark -i wlan1mon -Y "wlan.tag.number == 37"

# Show deauth + disassoc with details
$ sudo tshark -i wlan1mon -Y "wlan.fc.type_subtype == 0x000c || wlan.fc.type_subtype == 0x000a" -T fields -e frame.time -e wlan.sa -e wlan.da -e wlan.fixed.reason_code

Count, Export, and Analyze

# Count deauth frames in real time -- grouped by source and destination
$ sudo tshark -i wlan1mon -Y "wlan.fc.type_subtype == 0x000c" -T fields -e wlan.sa -e wlan.da | sort | uniq -c | sort -rn

# Export only deauth frames from a capture file to a new file
$ tshark -r capture_157.pcap -Y "wlan.fc.type_subtype == 0x000c" -w deauth_only.pcap

# Export CSA frames from a capture file
$ tshark -r capture_157.pcap -Y "wlan.tag.number == 37" -w csa_only.pcap

# Count all unique BSSIDs advertising "CTS-A" in a capture
$ tshark -r capture_157.pcap -Y "wlan.fc.type_subtype == 0x0008 && wlan.ssid == \"CTS-A\"" -T fields -e wlan.bssid | sort -u

# Summary statistics from a capture file
$ tshark -r capture_157.pcap -z io,stat,0,"wlan.fc.type_subtype == 0x000c","wlan.fc.type_subtype == 0x000a","wlan.tag.number == 37"

Example tshark Deauth Count Output

   1247 19:33:CE:D0:A2:9F	C0:A8:10:42:67:7E
    893 19:33:CE:D0:A2:9F	50:2E:91:48:F6:4A
    456 19:33:CE:D0:A2:9F	B0:3C:DC:3A:B8:FD
    312 19:33:CE:D0:A2:9F	ff:ff:ff:ff:ff:ff
     89 19:33:CE:D0:A2:9F	2C:0D:A7:9C:63:D2

Left column = count, middle = source (spoofed AP BSSID), right = target. Jonathan's desktop was hit hardest (1247 deauths), followed by Nick's laptop (893).

Before walking the building (Section 12), understand the tools available for signal strength monitoring. Each gives you a different view of RF activity.

Monitoring Tools

airodump-ng PWR column -- simplest, already running

# The PWR column in airodump-ng updates in real-time
$ sudo airodump-ng wlan1mon --channel 157

wavemon -- terminal-based real-time signal visualization

# Launch wavemon on the monitor interface
$ sudo wavemon -i wlan1mon

wavemon - wlan1mon
Levels:
  link quality:  ||||||||||||||||||||||||----  70/100
  signal level:  |||||||||||||||-----------   -52 dBm
  noise level:   ||||-----------------------  -95 dBm
  SNR:           ||||||||||||||||-----------   43 dB

Statistics:
  RX: 12847 packets  TX: 0 packets  (monitor mode)

Interface: wlan1mon  Mode: Monitor  Channel: 157 (5785 MHz)

horst -- histogram view of signal strength

# horst with channel lock
$ sudo horst -i wlan1mon -C 157

linssid -- graphical scanner with signal strength over time (requires X display)

$ sudo linssid

Systematic Sweep Procedure

1. Start at the AP location -- this gives you a known reference point for signal baseline
2. Open airodump-ng --channel 157 and note the rogue device's PWR at the AP location
3. Walk a grid pattern through the building -- hallway first, then each room
4. At each location, pause for 5 seconds and note the PWR value
5. Record observations as you go: "Loading dock: PWR -45 from rogue on ch157"
6. Move toward stronger signal (closer to 0 = closer to device)
7. Draw a rough signal heat map as you go -- even on paper

Signal Strength Reference:

Your goal is to use signal strength (PWR) to physically walk toward the planted device. This is RF direction-finding on foot.

Walk-Down Procedure

# Lock to channel 157 and watch signal strength
$ sudo airodump-ng wlan1mon --channel 157

1. Start at the AP location -- this gives you a known reference point
2. Note the PWR value of the suspicious BSSID on channel 157
3. Walk slowly through the building, watching the PWR column on your laptop screen
4. Move in the direction where PWR gets closer to 0 (stronger signal)
5. When PWR is around -30 to -20 dBm, you are within a few feet of the device
6. Use the USB extension cable to position the adapter like a wand -- move it around to pinpoint the exact spot

Common Hiding Spots

• Server closets, network cabinets, patch panel areas
• Behind or under desks, especially in unused workstations
• Ceiling tiles (dropped ceiling) -- check above the grid
• Electrical outlets with USB ports -- could be a tiny device plugged directly in
• Behind furniture, shelving, filing cabinets
• Vehicles in the parking lot (if signal is strongest near exterior wall)
• Powered USB hubs behind monitors or under desks

Common Device Form Factors

• Raspberry Pi in a small case (credit-card sized computer, usually black, with a USB WiFi adapter plugged in)
• USB WiFi adapter plugged into a powered USB hub or wall-wart USB charger behind furniture
• Old laptop left running in a bag or backpack, possibly under a desk or in a closet
• WiFi Pineapple or similar purpose-built attack device (small box, usually with multiple antennas)
• Modified router running OpenWrt or similar custom firmware

When You Find It: DO NOT TOUCH IT

The .cap / .pcap files generated by airodump-ng and tshark are your primary forensic evidence. They are timestamped, contain every raw 802.11 frame captured, and are admissible as network forensic evidence.

File Handling

• Capture files are written to the current directory with the prefix you specified in -w
• Multiple file types are created: .cap (packet capture), .csv (summary), .kismet.csv, .kismet.netxml
• The .cap file is the important one -- it contains the raw frames

Backup Immediately

# Create an evidence directory with today's date
$ mkdir -p ~/evidence/$(date +%Y%m%d)

# Copy all capture files
$ cp capture_157* ~/evidence/$(date +%Y%m%d)/

# Also copy to a separate USB drive if available
$ cp capture_157* /media/kali/BACKUP_USB/

# Generate SHA256 checksums for integrity verification
$ sha256sum ~/evidence/$(date +%Y%m%d)/*.cap > ~/evidence/$(date +%Y%m%d)/checksums.sha256

Documentation Checklist

For every capture session, record:

• Date and time (start and stop of capture)
• Channel monitored
• Physical location of the laptop/adapter during capture
• What you observed -- BSSIDs seen, signal strengths, unusual activity
• File names of all captures generated
• SHA256 checksums of all evidence files

Screenshots

# Take a screenshot of the current screen
$ scrot ~/evidence/screenshot_$(date +%Y%m%d_%H%M%S).png

Screenshot airodump-ng output at key moments -- when you first see the rogue device, when signal strength peaks (closest approach), etc.

For each attack type, what to do to stop it. The definitive fix for ALL of these is finding and removing the planted device.

What You're Doing Is Legal

Passive monitoring of your own network is legal. You own the network infrastructure, you are authorized to manage it, and you are operating in a purely passive (receive-only) mode. Your adapter never transmits. You are a listener.

Key Legal Points

• Passive monitoring (what you're doing) is legal -- you own the network, you're an authorized administrator, you are a listener only
• Active attacks (deauth, injection, etc.) are illegal under the Computer Fraud and Abuse Act (CFAA, 18 U.S.C. § 1030) even on your own network IF they affect other people's devices -- but that's not what you're doing
• WiFi jamming is illegal under FCC regulations (47 U.S.C. § 333) -- if the planted device is jamming, it's the attacker who is breaking the law
• Evidence from passive capture is admissible in employment proceedings, civil litigation, and criminal investigations

Evidence Handling Best Practices

• Photograph everything before touching it -- multiple angles, context shots showing location
• Chain of custody: maintain a written log of who touched the evidence, when, where, and what was done
• Don't modify captures -- work with copies, keep originals pristine
• Hash everything -- SHA256 checksums on all evidence files, generated immediately after capture
• Timestamps are critical -- note your system clock accuracy, use NTP if internet is available
• Witness -- if possible, have a second person present when you find the device