Project 61: Wi-Fi Pineapple Awareness Lab

Module: Module 7: Wireless, Systems & Mobile Security  |  Level: Intermediate  | 
Primary tool: Wireshark (analysis-only, no rogue-AP hardware required)  |  Estimated time: 75–120 minutes

Objective: Understand rogue access point / evil-twin attack indicators without deploying attacker hardware.

Free lab environment

Your own isolated access point + Aircrack-ng test lab — https://www.aircrack-ng.org/doku.php?id=newbie_guide

Wireless attack/defense techniques must only be run against a Wi-Fi network and access point you personally own and control, e.g. a spare router configured in an isolated room, or a virtual AP built with `hostapd` on a Linux VM. Do not test against your ISP-issued home router if it is shared with neighbors’ devices, and never test networks you do not own or have explicit written permission to test.

Lab workflow

  1. Before anything else, confirm in writing that the wireless network in scope is one you personally own or have explicit permission to test — this is non-negotiable for every wireless project.
  2. Put your wireless adapter into monitor mode and confirm it with Wireshark (analysis-only, no rogue-AP hardware required) before attempting any capture.
  3. Run your capture/test against a sample public capture illustrating probe-request/beacon behavior (Wireshark Sample Captures wiki) and record the raw output.
  4. Focus specifically on how to understand rogue access point / evil-twin attack indicators without deploying attacker hardware — annotate exactly which field or packet told you this.
  5. Change one variable (e.g. passphrase strength, encryption type) and re-run the same test so you have a direct before/after comparison.
  6. Document your isolation setup (which proves the test stayed inside your own authorized lab) alongside your findings.

Evidence & screenshot requirements

Submit the following with your report (see this module’s practical assignment for exact upload details):

  • your annotated Wireshark filter isolating suspicious beacon/probe patterns
  • your written checklist of 3 things a user’s device should check before auto-joining a ‘known’ network

Expected deliverable

A concise lab-report entry containing: scope/target, exact commands or payloads used, your key
observation, the required screenshots above, and — where applicable — the specific remediation for what
you found. Vague answers (“sanitize input”, “use a firewall”) without naming the exact mechanism will not
receive full credit.

Safety & authorization

Only test the specific free lab target named above, or infrastructure you personally own. Do not target
third-party systems, real user accounts, or production services without explicit written authorization.
Never deploy anything from this project outside an isolated lab environment.