Evil Portal

Evil Portal

Create an access point that serves a captive web page to connected clients. Use it to host single-file portals or small portal packages stored on the device.

Quick Overview

• Purpose: show a captive page, capture form submissions, and log each interaction.
• Prep: copy your portal files to /portals, keep the SD card mounted, and (optionally) connect the ATK STA to upstream Wi‑Fi beforehand.

Features

• Portal selection – pick any uploaded portal package or single HTML file under portals and refresh the list when you add new content.
• Hit counter – watch the total requests the portal endpoint receives while it is running.
• Log path indicator – see exactly where the current session is writing (for example /portals/logs/portal_001.log).
• SSID & security – set SSID, password (leave blank for open), channel, and decide whether to hide the SSID.
• Fake Internet Connection – after a submission, optionally respond to OS captive probes with success and show a “Connection Successful” page instead of reloading the portal.
• SD/portal badges – the card warns you if the SD card or portals directory is unavailable, preventing a failed launch.

How to Use

1. Open the card – Web UI → Wi‑Fi Attacks → Evil Portal.
2. Load your portal – upload a package through File Manager, click Refresh, and select it from the dropdown.
3. Configure options – use the table below for quick reference.

Tip: While the portal is active, the File Manager cannot access the SD card. Stop the portal before browsing or downloading files.

4. Start the portal – click Start Portal to display the status, log path, and hit counter.
5. (Optional) Enable upstream Internet – connect the ATK STA Bridge (Settings → Connect) before starting for seamless Internet passthrough once a client completes the captive flow.
6. Stop when finished – click Stop Portal; when the confirmation appears, SD access and other Wi‑Fi attacks resume immediately.

Real Internet Connection Sharing (ATK Network Sharing)

1. Connect first for seamless browsing – pair the ATK STA (Settings → Connect) before launching the portal. After any GET/POST submission, NAT + DNS passthrough flip on and clients immediately reach the real Internet.
2. Connecting later still works – if you link the STA after the portal is already running, complete the captive flow again; as soon as the STA reports connected, the bridge comes online without a restart.
3. If upstream drops – captive content keeps working locally, but Internet passthrough pauses until the STA reconnects. Fake Internet mode still delivers the success page for testing-only scenarios.

Portal Files

Upload portal files to the mounted storage under portals/. The Web UI treats the directory like this:

• Folders with index.html – serve the whole folder (e.g., portals/myportal/index.html).
• Single HTML files – serve the lone file at the root (e.g., portals/landing.html).

The UI assumes index.html for directories, and every run writes logs under /portals/logs.

Notes & Limitations

• The portal serves the selected web page to clients that join the AP; some client OSes may behave differently — reconnecting the client can help trigger the captive-page prompt.
• The Fake Internet Connection option affects how the portal responds to OS captive-portal probes after the portal flow completes (it does not alter how the portal serves pages before submission). When disabled, form submissions will not mark the session complete and will instead reload the portal page.
• The portal tracks “hits” (client interactions sent to the portal log endpoint). The Web UI displays the hit count in the status row while the portal is running.
• Some client devices (or apps) use Private DNS / DNS over TLS which can bypass or interfere with captive-portal detection. If clients do not show the captive page or the OS probe does not trigger, ask the user to temporarily disable Private DNS or open a browser and navigate to a non-HTTPS site to trigger the portal.
• If you want an open network, leave the password field empty; no additional setting is required.
• If a portal does not appear for a client, try disabling and re-enabling Wi‑Fi on the client or reconnecting to the portal SSID.

Hit Counter Details

• Each hit represents a grouped interaction that successfully reached the portal logging endpoints (form submits, injected script events, etc.).
• Events are debounced in ~2-second windows so rapid successive requests from the same client only increment the counter once, aligning the number with meaningful credential entries or portal interactions.

Safety & Responsible Use

Use this feature only on networks and devices you own or are explicitly authorized to test. Intercepting credentials or other private information without consent is illegal and unethical.