WiFiPumpkin3 is a rogue access point (fake AP) attack framework written in Python 3, developed by the P0cL4bs team (mh4x0f / Marcos Bomfim). It is the successor to the older WiFi-Pumpkin / 3vilTwinAttacker, and for red teams and network assessments it bundles into one tool everything needed to "stand up a fake Wi-Fi, lure victim devices in, then observe or tamper with their traffic as a man-in-the-middle (MITM)." What it does is simple: broadcast an AP that looks like the real thing, then pass connected devices through modules for captive-portal phishing, credential sniffing, DNS spoofing, and HTTP injection. Its hallmark is an interactive console plus a plugin/extension system: instead of hand-rolling hostapd + dnsmasq + a phishing page, you assemble a full Evil Twin attack from the console with just set and start.
What WiFiPumpkin3 is — a rogue AP framework #
A rogue AP (fake access point) is a "Wi-Fi that looks real" set up by the attacker. When a victim device connects to it, the attacker sits right in the middle of the traffic path as a man-in-the-middle, able to read HTTP contents, present fake login screens, or rewrite DNS responses. WiFiPumpkin3 packages this whole chain into a single framework.
| Component | Role |
|---|---|
| The fake AP itself | Broadcasts the SSID named via set ssid to lure devices in |
| Proxy / modules | Process the passing traffic (captive-portal phishing, HTTP injection, sslstrip, etc.) |
| Plugins / extensions | Enable sniffing, DNS, deauth, and more via plugins |
| Interactive console | Controls the whole thing from a wp3 > prompt with set / start |
WiFiPumpkin3 itself doesn't "understand" the attack — it is just a base that combines parts: a fake AP plus the modules you pick. What you actually do depends on the modules selected with set proxy or plugins.
Attacks that "stand up a fake AP identical to a legitimate one and steal devices" are collectively called Evil Twin. WiFiPumpkin3 is one of its representative implementations, in the same lineage as airgeddon, Fluxion, and eaphammer. The difference is that those are shell-script-centric, whereas WiFiPumpkin3 is built as a Python framework with an interactive console and plugins.
Legal and ethical considerations #
What WiFiPumpkin3 does is pull unrelated people's devices into your fake AP and observe or tamper with their traffic. This is not a harmless technical game. Running a rogue AP / MITM / phishing portal against others without permission is an illegal act that clearly violates Japan's Radio Act (電波法) and Unauthorised Computer Access Act (不正アクセス禁止法), and their equivalents elsewhere.
- Only your own kit and your own devices — a closed test using your own Wi-Fi adapter with a phone/PC you own as the "victim."
- Engagements with explicit written permission — a red-team / pentest contract where the target (SSID, location, devices, period) is documented as scope.
- An isolated learning lab — an experiment environment physically/logically isolated so that no one else's radio or devices get mixed in.
A fake AP can sweep in nearby strangers' devices the moment it starts transmitting. Carelessly running start in a public space — a café, an airport, an office — means intercepting unrelated third parties' communications, and can simultaneously constitute violations of the Radio Act, the secrecy of communications, and unauthorized access. Always confirm first: is it your own kit, do you have authorization, and will it avoid catching others?
How it works and how it's built — fake AP plus modules #
A WiFiPumpkin3 attack is easiest to reason about in two stages: "lure devices in with a fake AP" → "process the passing traffic with modules." What you insert in the second stage decides the character of the attack.
set ssid from an AP-mode-capable adapter. A deauth module may kick devices off the legitimate AP so they switch to the fake one.set proxy captiveflask presents a fake login screen first; pumpkinproxy inspects/rewrites HTTP.sniffkin3 harvests credentials, and dnsspoof redirects specific domains to a spoofed site.In other words, the combination of "the fake-AP base" + "what the proxy does" + "what the plugins extract" is your attack scenario. The set commands in the following sections are the operations that assemble this layout.
You need a Wi-Fi adapter that supports AP / master mode (some chipsets can't). If you want to forward the victim's traffic to the real internet so things look natural, you'll also want a second interface for the upstream link. It runs on Linux as root.
Basic usage — the interactive console #
WiFiPumpkin3 is used primarily as an interactive console. Launched as root, it drops you at a wp3 > style prompt where you configure with set and fire with start. Rather than stringing together long flags, the tool's style is to build up state with commands inside the console.
$ sudo wifipumpkin3
# launched as root, it enters the wp3 > prompt
wp3 > set interface wlan0
# choose the wireless interface that will host the fake AP (AP-mode capable)
wp3 > set ssid FreeWiFi
# set the broadcast network name (the lure)
wp3 > set proxy captiveflask
# module the traffic passes through: captiveflask = captive-portal phishing
wp3 > start
# launch the fake AP and the selected modules
wp3 > stop
# stop itCheck what's available with the console's listing commands: proxys for proxy modules, plugins for plugins, and help for the full command set.
wp3 > proxys
# list of available proxy modules (captiveflask, etc.)
wp3 > plugins
# list of available plugins (sniffkin3 / dns, etc.)
wp3 > help
# list of console commandsWhen typing the same steps every time gets tedious, pass a .pulp script — a list of console commands — with --pulp, and they run in sequence at startup. Good for reproducing test procedures and automating labs.
$ sudo wifipumpkin3 --pulp myscript.pulp
# a .pulp is a list of set interface / set ssid / start … commands
# they run in order at startup, reproducing the same attack layoutThe main modules #
The core of WiFiPumpkin3 is a thin base; the actual offensive power lives in the modules. Rather than specifying things in fine-grained flags, think of it as choosing "which module to enable" with set proxy or plugins. Know the representative ones.
| Module | Type | Role |
|---|---|---|
captiveflask | proxy | Captive-portal phishing. Presents a fake login on connect and harvests Wi-Fi / email credentials via a selectable template |
pumpkinproxy | proxy | Inspect / inject HTTP. Used to examine traffic contents or rewrite content |
sslstrip2 | proxy | Strips the redirect to HTTPS and downgrades to HTTP (sslstrip family), aiming to keep traffic plaintext |
sniffkin3 | plugin | Sniffs credentials from the traffic (FTP / HTTP, etc.) |
deauth | plugin | Sends deauth at the legitimate AP to disconnect devices and make them switch to the fake AP |
DNS / dnsspoof | plugin | Replaces the fake AP's DNS responses to redirect specific domains to the attacker's site |
For example, to steal credentials with a fake login, select set proxy captiveflask and have the victim enter a Wi-Fi password or email credentials into a login template under captiveflask. To inspect and tamper with HTTP, use set proxy pumpkinproxy; to passively harvest credentials, enable sniffkin3 from plugins.
WiFiPumpkin3 is not a tool whose behavior you set with long flag chains like ffuf or wfuzz. Which proxy you set and which plugins you enable determine the substance of the attack. So rather than "memorizing commands," the fastest path to mastery is understanding the role of each module that appears under proxys / plugins.
Defenses and where it sits #
Because WiFiPumpkin3 is one implementation of the Evil Twin attack, its defenses belong to the same family as Evil Twin in general. The crux of the attack is "connecting to a fake AP without noticing" and "entering data into a fake page without noticing," so the countermeasures close those gaps.
| Defense | Effect |
|---|---|
| WPA3 / 802.11w (PMF) | Management-frame protection makes forced disconnects via deauth harder to land |
| Never enter a Wi-Fi password into a web page | Breaks the premise of captive-portal phishing — a legitimate AP doesn't ask for the password on a web screen |
| Server-cert validation for enterprise (802.1X) | Rejects a fake RADIUS / fake AP on certificate mismatch |
| VPN on untrusted networks | Even with a MITM present, traffic stays encrypted, neutralizing eavesdropping and tampering |
| WIDS / WIPS rogue-AP detection | Detects and reports suspicious APs or radio on the same SSID |
| Tool | Implementation | Characteristics |
|---|---|---|
WiFiPumpkin3 | Python framework | Assembles a fake AP via an interactive console plus plugins. Rich set of modules like captiveflask |
airgeddon | Bash script | Menu-driven. Broad coverage from Evil Twin to WPA handshake capture |
Fluxion | Bash script | Specializes in phishing Wi-Fi passwords via Evil Twin + a captive portal |
eaphammer | Python | Strong at evil-twin attacks aimed at enterprise (WPA-Enterprise / 802.1X) |
WiFiPumpkin3's value is that, instead of hand-rolling hostapd + dnsmasq + a phishing page, you can assemble a fake AP together with captive-portal phishing, sniffing, and DNS spoofing from a single console. Where airgeddon / Fluxion are menu-driven, this is a Python framework with plugins that's easy to extend. The point of learning it is that knowing the "attack steps" makes the defenses (WPA3, VPN, never entering a password into a web page, WIPS) click into place. Always run it only on your own kit, within an authorized scope, or in an isolated lab.
