Evil portal and misleading wireless onboarding
V04 · reusable vector · version 1.0HIGH · proposed test impact
A false access point or captive portal imitates trusted onboarding. It can be combined with social engineering but requires its own radio/network permission.
Attacker tools and payload types
A convincing portal page or onboarding instruction. The assessment fixture has no password or MFA-code collection and uses only test identities.
The entries below are tools that can support assessment or emulate aspects of this vector in an authorised fixture. They are not claims that these exact products were used in every linked incident. Native platform availability and Armory installation are different from tested capability.
- Wireshark · Armory · Existing local tool notes · Maintained official user guide
- Wifiphisher · Armory · Existing local tool notes · Upstream project / documentation
- Owned lab access point and inert portal · client/operator supplied
Setoolkit/Wifiphisher are candidate Armory mappings where shown, not the default execution route. Their capabilities may exceed the agreed simulation. Select and review a harmless lab profile; the inert fixture/manual method is sufficient for the initial assessment.
Repository and operating guides
canary.txt · RES-022 · published synthetic fixture in the assessment collection linked from the Repository.
Read the selected tool’s guide for installation and operation rather than recreating it here. Pin the deployed version and reviewed configuration in the task record. Some local guides are autogenerated inventory notes and contain stale commands or broad prerequisite lists; they require validation before use. The official manuals linked above were checked during this review.
Reusable controlled test
Use a separate owned lab SSID and consented test devices/users. Check network selection, trust warnings and access boundaries; never involve nearby third parties or production radio disruption.
- Required permission
- Specific SSID/location, radio environment, test devices, people and channel. Physical location access and wireless manipulation require separate approvals.
- Parent supplies
- Scenario/risk ID; business question; exact targets; named permitted people; channel; current policy revision; tool/resource versions; limits; expected result and reviewer.
- Output
- One result per approved case, with run and target IDs, permission decision, evidence, actual outcome and coverage limits.
- Measure
- Correct trust decisions / executed approved cases; prohibited network flows blocked; reporting events. No client result has been collected here.
- Failure handling
- Blocked, not authorised, failed, inconclusive and not tested remain visible. A refused route cannot be replaced by another agent, channel or target without fresh applicable approval.
What the vector returns to the scenario
| Result | What it means |
|---|---|
| Control held | The evidenced attempted action was prevented under the tested conditions. This is not a universal security guarantee. |
| Control failed | Describe the exact observed boundary failure and its business consequence, without inflating it into a wider compromise. |
| Unknown / not tested | Record the missing capability, evidence, permission or coverage. Do not invent a score. |
Mitigation recommendations
Reduce likelihood: Improve secure onboarding, certificate validation and user verification routes.
Reduce impact: Isolate guest networks and constrain the access gained even if onboarding is misunderstood.
Define how a later retest would verify the recommendation; implementation assignments, scheduling and pricing are Part 2.