Evil Portal vs Captive Portal: What's the Difference?
People use these terms interchangeably, and they shouldn't. A captive portal and an evil portal share one thing: both serve a web page over a locally hosted access point. Beyond that, the intent, the mechanics, and the security implications are meaningfully different. If you're doing authorized security testing, you need to understand exactly which tool you're reaching for and why.
What a Captive Portal Actually Is
A captive portal is a web page that intercepts all HTTP traffic on a network and forces the user to interact with it before granting internet access. You've hit one at every hotel, airport, coffee shop, and conference you've ever attended. The basic flow is:
- Client connects to the AP and gets a DHCP lease.
- Client makes a DNS query. The portal's DNS server returns the portal IP for every query, regardless of what was requested.
- Client makes an HTTP request. The AP's firewall drops it (or the portal web server responds with a 302 redirect to the portal URL).
- Client browser loads the portal page. The portal might ask for a room number, an agreement to terms of service, or an email address.
- After the user completes the interaction, the AP opens access to the internet.
The purpose is access control - not credential theft. A legitimate captive portal from a hotel or coffee shop is designed to gate internet access, log usage, or collect marketing data. It's not trying to impersonate anything. It shows a generic landing page that's clearly associated with the venue.
On the BLEShark Nano, the captive portal feature lets you host a fully custom HTML page over a locally broadcast AP. You can upload any HTML file via the File Portal, set a custom SSID, and choose what data (if any) the form collects. Submissions are written to a JSON file you can review later. The device doesn't forward that traffic anywhere - it's a closed loop on the device itself. The use case in authorized testing is demonstrating what a real captive portal looks like on a target network, or running a security awareness exercise where you want to show employees what a suspicious portal looks like.
What an Evil Portal Is
An evil portal does everything a captive portal does at the network layer - it hosts an AP, hijacks DNS, and serves a web page. The difference is the page itself. An evil portal is designed to mimic a real, recognized login page. Instead of "Welcome to The Grand Hotel - accept our terms," the user sees what looks like a Marriott login page, or a corporate SSO screen, or their home router admin panel.
The attack goal is credential harvesting. A user who doesn't scrutinize the URL and is already expecting to authenticate somewhere will type their password into what looks like a familiar form. The attacker captures the submitted credentials.
Evil portals are a standard tool in physical red team assessments. The scenario: an attacker sets up a fake access point with an SSID that matches or closely resembles the target organization's corporate WiFi. When users connect (sometimes because the fake AP has stronger signal than the real one, sometimes because they're looking for guest access, sometimes because of auto-connect behavior), they're served what looks like the corporate login page. Credentials submitted go to the attacker.
This is a social engineering attack. It doesn't break any encryption. It doesn't exploit any software vulnerability. It relies entirely on the user trusting what they see on screen.
sequenceDiagram
participant V as Victim Device
participant RAP as Rogue AP
(Evil Portal)
participant DNS as DNS Server
(Attacker-controlled)
participant WEB as Fake Login Page
participant ATK as Attacker
Note over V,ATK: Evil Portal Attack Flow
V->>RAP: Connect to open WiFi
RAP->>V: DHCP: IP + DNS=attacker
V->>DNS: Resolve any domain
DNS->>V: Redirect to captive IP
V->>WEB: HTTP request triggers portal
WEB->>V: Fake login page
(Google, Facebook, ISP)
V->>WEB: Enter credentials
WEB->>ATK: Credentials captured
ATK->>V: Redirect to real site
(victim unaware)
Note over V,ATK: Legitimate Captive Portal Flow
V->>RAP: Connect to hotel/cafe WiFi
RAP->>V: DHCP with captive flag
V->>DNS: OS detects captive portal
DNS->>V: Redirect to auth page
V->>WEB: Shown terms/payment page
WEB->>V: Accept terms or pay
V->>RAP: Full internet access granted
Side-by-side comparison - evil portals mimic the same captive portal mechanism but serve fake login pages to harvest credentials instead of legitimate authentication.
How the BLEShark Nano Handles Evil Portal
The BLEShark Nano includes an evil portal feature. A few things to understand about how it's implemented:
The portal page is served from custom HTML you upload to the device. The BLEShark doesn't come with pre-built fake login pages for real services - you provide the HTML. This keeps the responsibility where it belongs: with the person using the device.
Inputs are handled carefully. The device collects form submissions and writes them to a JSON file accessible via the File Portal. There is no outbound transmission - no exfiltration to an external server, no live relay to an attacker's backend. The data sits on the device until the tester retrieves it during an authorized assessment review.
Credential fields are treated with care. The UI on the device and the documentation are explicit about the fact that this is a testing tool. The standard disclaimer applies: you should only deploy this against a network and users for whom you have explicit written authorization.
Evil portal testing involves capturing user credentials, even in a controlled test environment. Never deploy an evil portal on any network without explicit written authorization from the network owner and the organization responsible for the users who might connect. Unauthorized evil portal deployment can constitute fraud and computer misuse under laws in most jurisdictions.
The Technical Overlap
At the network layer, a captive portal and an evil portal are identical. Both:
graph LR
subgraph "Shared Infrastructure"
DHCP["DHCP Server
Assigns IP + DNS"]
DNS["DNS Hijacking
Redirects all queries"]
HTTP["HTTP Redirect
302 to portal page"]
DETECT["Captive Portal Detection
OS probes connectivity URL"]
end
subgraph "Captive Portal (Legitimate)"
CP_AP["Authenticated AP
Known SSID"]
CP_PAGE["Terms/Payment Page
Valid HTTPS cert"]
CP_AUTH["RADIUS or
voucher auth"]
CP_RESULT["Internet access
after auth"]
end
subgraph "Evil Portal (Malicious)"
EP_AP["Rogue AP
Cloned SSID"]
EP_PAGE["Phishing Page
No valid cert"]
EP_CRED["Credential
harvesting"]
EP_RESULT["Credentials exfiltrated
Optional internet relay"]
end
DHCP --> DNS --> HTTP --> DETECT
CP_AP --> DHCP
EP_AP --> DHCP
DETECT --> CP_PAGE --> CP_AUTH --> CP_RESULT
DETECT --> EP_PAGE --> EP_CRED --> EP_RESULT
Both evil portals and captive portals use identical network plumbing - DHCP, DNS hijacking, and HTTP redirects - but diverge at the portal page intent: authentication vs. credential theft.
- Broadcast a custom SSID from the device's hosted AP
- Assign DHCP leases to connecting clients
- Intercept DNS queries and return the device's IP
- Respond to all HTTP requests with the portal page (302 redirect or direct serve)
The only difference is the HTML content served. This is why the BLEShark treats them as variants of the same feature rather than separate modules. The portal system is one thing. What you put in the HTML file determines whether it's a generic landing page (captive portal behavior) or a mimicked login page (evil portal behavior).
HTTPS is a blocker for both. Any site that enforces HSTS will fail to load through either portal type, and most browsers now show a warning when a connection is intercepted. This is intentional from a security standpoint - HTTPS with HSTS is specifically designed to prevent the kind of interception that captive portals rely on. In practice, the portal page itself loads fine (it's served over HTTP from the device), but if the user tries to load a specific HTTPS site, the browser will block it.
How Red Teams Actually Use These
In an authorized physical penetration test, the evil portal is typically used to test one specific control: do employees recognize a fake login page?
graph TD
START["Red Team WiFi Assessment"] --> RECON["Recon: Identify
target network"]
RECON --> CLONE["Clone target SSID
+ BSSID (optional)"]
CLONE --> PORTAL_TYPE{"Choose portal
template"}
PORTAL_TYPE -->|"Corporate"| CORP["Corporate SSO page
AD/LDAP login clone"]
PORTAL_TYPE -->|"ISP/Hotel"| ISP["ISP terms page
WiFi access portal"]
PORTAL_TYPE -->|"Social"| SOCIAL["Google/Microsoft
OAuth login page"]
CORP --> DEPLOY["Deploy on
BLEShark Nano"]
ISP --> DEPLOY
SOCIAL --> DEPLOY
DEPLOY --> DEAUTH{"Deauth
target clients?
(if authorized)"}
DEAUTH -->|"Yes (non-EU)"| FORCE["Force reconnection
to rogue AP"]
DEAUTH -->|"No / EU mode"| WAIT["Wait for voluntary
connection"]
FORCE --> CAPTURE["Capture credentials
on portal submission"]
WAIT --> CAPTURE
CAPTURE --> VALIDATE["Validate captured
credentials"]
VALIDATE --> REPORT["Document in
pentest report"]
subgraph "Detection Indicators"
DET1["BSSID mismatch"]
DET2["Certificate warning"]
DET3["HTTP instead of HTTPS"]
DET4["WIDS alert"]
end
Red team evil portal workflow - from network reconnaissance through portal deployment to credential capture, with common detection indicators that defenders should monitor.
The test is set up with full scope documentation. The red team is authorized to deploy a fake AP in a specified physical area. They broadcast an SSID that resembles the target's corporate network. They serve a page that looks like the corporate SSO. They record how many people connect and submit credentials. The output of the test isn't the credentials themselves - it's the percentage of users who fell for it and the demographic or location data about who's most vulnerable.
This is the same category of test as a phishing simulation email. The goal is measurement, not exploitation. The credentials captured during an authorized test are disclosed to the security team, used to demonstrate the gap, and then discarded.
Captive portals serve a slightly different red team purpose. They're useful for demonstrating what happens when a corporate network lacks proper network segmentation, or for showing how easily a convincing "guest network" can be stood up in a physical space. A captive portal that collects email addresses can be used to demonstrate data exposure risk - users typing their corporate email into an unverified form - without crossing into full credential theft territory.
Detection and Defense
Both attack types share the same detection signature: a new AP appears with a familiar or suspicious SSID, and DNS stops resolving normally. Enterprise wireless intrusion detection systems watch for rogue APs by cross-referencing the authorized AP inventory. Any AP broadcasting in the RF environment that isn't on the approved list generates an alert.
For individual users, the defense is simpler to describe than to practice. Check the URL bar before submitting credentials. If you're connecting to corporate WiFi and the login page URL is something other than your company's known SSO domain, don't submit anything. A VPN that establishes immediately on connection provides a layer of protection because it routes all traffic through an encrypted tunnel before hitting any local DNS hijacking.
802.1X enterprise WiFi is significantly harder to fake. Because authentication involves a RADIUS server and certificate-based EAP methods, a rogue AP can't present the right certificate for your organization's domain. The client rejects the connection. This is one of the strongest arguments for migrating corporate WiFi to 802.1X if it isn't already.
The BLEShark Nano's Role
The BLEShark Nano at $36.99 gives a security tester both portal types in one device. The captive portal feature uses your uploaded HTML as a generic landing page. The evil portal feature uses whatever HTML you've crafted to mimic a specific login interface. The hardware is the same - the 2.4GHz AP capability, the DNS hijacking, the form collection - the difference is entirely in the content you deploy.
For people doing authorized physical security assessments, the BLEShark's form submission logging is genuinely useful. You run the test, connect clients, collect submissions to the JSON file, download it via File Portal after the engagement, and include the data in your report. No external infrastructure needed, no cloud credentials to manage, no per-test costs.
The Shiver mesh capability adds a dimension here: up to 16 BLEShark Nanos can be networked via ESP-NOW, each hosting a different portal variant on a different SSID and channel. This allows A/B testing of portal designs across physical locations during a large-scale authorized assessment - which landing page gets more connects, which SSID name draws more attention. Results aggregate to the master node in real time.
Whether you're running a captive portal to demonstrate access control gaps or an evil portal to test employee credential hygiene, the device handles both. The technical capability is neutral. The ethical weight is entirely on the authorization behind the test.