Captive Portal A/B Testing With BLEShark Shiver Mesh

Social engineering assessments have a measurement problem. You deploy a captive portal, people either connect to it or they don't, you collect whatever submissions come in. But you rarely know: would a different page design have worked better? A different network name? A different physical location in the building?

With one device, you can test one variant at a time. With a Shiver mesh, you can test multiple variants simultaneously across different locations, and results sync to a single display in real time. This is captive portal A/B testing at the scale an authorized red team operation actually needs.

This article covers how it works technically, what the use cases are, and what the hardcoded safety restrictions mean for how results are handled.

Table of Contents

• How Portal Sync Works
• Deploying Different Variants Across Nodes
• Result Aggregation
• SSID Strategy
• Physical Placement
• Safety Restrictions
• What the Data Tells You
• EU Note

How Portal Sync Works

When a BLEShark Nano running a captive portal receives a form submission, the portal sync system kicks in. The submission JSON is broadcast across the Shiver mesh using the EVENT_CREDENTIAL event type. Every online node in the mesh receives the event. If a node has the captive portal screen active, it stores the credential in SPIFFS (flash memory) and displays it.

The event delivery uses Shiver's fragmented reliable transport. Credential JSON can be arbitrarily long depending on what fields your custom portal page includes. The fragmentation layer splits large payloads into 198-byte chunks, each delivered reliably with ACK/retry. For a typical form submission (email, name, maybe a password field), the whole thing fits in one or two fragments and arrives at the master node within seconds of the original submission.

From the operator's perspective: you're watching the captive portal screen on Node 1 (your command node), and when someone connects to Node 3's portal three rooms away and submits the form, you see the result appear on your screen within a few window cycles.

Deploying Different Variants Across Nodes

Each BLEShark Nano runs its own captive portal independently. The portal page is a custom HTML file uploaded to the device via the file portal. From the Execute menu on any paired node, you can send CMD_PORTAL to any specific target node or to all nodes simultaneously.

For A/B testing, the workflow is:

1. Upload different HTML files to different nodes before deployment. Node A gets variant-1.html (minimalist design, one field), Node B gets variant-2.html (detailed branding, multiple fields), Node C gets variant-3.html (urgency framing, "your connection requires verification").
2. Position nodes in different target areas.
3. Send CMD_PORTAL to each node via the Execute menu.
4. Monitor results from a single command node.

The portal HTML is fully custom. You upload any HTML file you want - the device serves it over HTTP from a local access point. Form submissions are collected as JSON entries, stored locally on the device, and synced across the mesh via the EVENT_CREDENTIAL system.

Each submission is tagged with the source node's eFuse ID, so you know which node (and therefore which variant and physical location) generated each result.

graph TD
    subgraph "A/B Testing with Shiver"
        N1["Node 1
Portal: WiFi Login"] -->|"Results"| CTRL["Controller"]
        N2["Node 2
Portal: Guest Network"] -->|"Results"| CTRL
        N3["Node 3
Portal: Building WiFi"] -->|"Results"| CTRL
        CTRL --> COMPARE["Compare submission
rates per variant"]
    end

Result Aggregation

The credential sync system sends results in one direction by default: from the node that collected them to any other node watching the portal screen. If you have three portal nodes running and you want centralized monitoring, put the captive portal screen up on your command node and all three remote nodes will sync their results to you.

Results are stored persistently in SPIFFS on each node. If the mesh loses connectivity briefly, buffered submissions aren't lost - they're stored locally and synced when the connection restores. The sync system processes one pending delivery per tick, so large backlogs drain gradually without flooding the mesh with traffic.

In the scenario where you have 5 portal nodes running simultaneously and all of them start getting submissions at the same time (say, a large group enters the building), the staggered sync means results may arrive at the command node with a few seconds of delay. But none are lost.

SSID Strategy

A/B testing isn't only about the portal page content. The SSID name is arguably more important - it's what gets people to connect in the first place.

Common approaches in authorized assessments:

• Mimicry: Use SSIDs that closely resemble the legitimate corporate network name. Tests whether employees verify they're on the correct network before connecting.
• Authority framing: "IT-Guest-Secure", "CorpNet-Visitor", "Guest-WiFi-Authorized". Tests whether official-sounding names increase trust.
• Incentive framing: "Free-Printer-Access", "Conference-Room-B-WiFi". Tests whether functional names get more connects in specific areas.
• Generic: "Free WiFi", "Guest", "Public-WiFi". Baseline control group.

Different nodes in different parts of a building can test different SSID strategies simultaneously. Meeting room wing vs. lobby vs. cafeteria vs. parking level - each location may respond differently to different framings. One assessment run gives you data across all variants rather than requiring multiple separate visits.

Physical Placement

Portal effectiveness is partly a function of location. A node tucked in a corner has fewer potential victims than one near a high-traffic area. Shiver mesh deployment lets you place nodes strategically without needing to be physically present at each one during the assessment.

Placement considerations for portal testing:

• Entrance and lobby areas: High foot traffic, people pulling out phones on arrival. New arrivals may connect to anything labeled "Guest" or "Visitor".
• Conference rooms: Visitors brought in for meetings. Often on unfamiliar networks, looking for guest access.
• Break rooms and cafeterias: People on personal devices during breaks. Less vigilant about network verification.
• Parking areas: People connecting before entering the building. Range permitting.

The RSSI triangulation capability of the Shiver mesh is useful here too - if you've placed nodes at known positions, you can roughly localize where submissions are coming from even within the building. A submission from a node whose nearest mesh neighbor is Node 3 (positioned in the north wing) tells you something about the physical origin of that submission.

Safety Restrictions

BLEShark Nano's captive portal has hardcoded safety features that exist regardless of what HTML you upload:

Credentials collected by the portal are never transmitted off-device by the firmware. The EVENT_CREDENTIAL sync sends collected submissions to other Shiver nodes you control, but the device never initiates outbound connections to external servers or APIs. What you collect stays within your mesh.

The portal page you upload can include any fields you want, but the device only stores and forwards the form submission JSON - it doesn't execute any scripts in the submission context or perform any actions based on submitted credentials.

These restrictions exist so the tool can be used for authorized security assessments without creating an accidental data exfiltration mechanism. You are responsible for what you do with collected submissions under your authorized testing agreement. The device enforces that collected data stays local to your mesh.

What the Data Tells You

A well-designed captive portal A/B test gives a security team actionable data:

Connection rate by SSID: How many devices connected to each node's access point vs. passed by without connecting. Higher connection rates indicate more convincing SSID framing for that location and audience.

Submission rate of connected devices: What fraction of devices that connected to the portal actually submitted the form? Low submission rate = the portal page was not convincing, or users were suspicious. High submission rate = the portal framing was effective.

Credential type patterns: Did users submit corporate email addresses? Personal emails? Fake data? This tells you about user security awareness training effectiveness.

Location variation: Did one area of the building show dramatically higher susceptibility? That's where security awareness training is most needed, or where physical controls need improvement.

Time distribution: Did most submissions come in during morning arrival, lunch, end of day? Understanding when people are most susceptible helps a security team prioritize monitoring and training timing.

None of this data is actionable from a one-node, one-location test. The multi-node, multi-variant simultaneous approach is what produces statistically meaningful results within a single authorized assessment window.

EU Note

Captive portal functionality operates normally under EU firmware. The EU restrictions apply to deauth and handshake capture features. Deploying a captive portal, collecting custom form submissions, and syncing results across the Shiver mesh are all available in EU builds.

Authorized Use

Everything in this article is framed for authorized security assessments - red team engagements conducted with explicit written authorization from the organization being tested. Deploying captive portals to collect credentials from people who have not consented is illegal in virtually every jurisdiction.

BLEShark Nano's multi-node portal capability is a professional tool for professional assessments. The data it produces helps organizations understand their actual human-factor vulnerability to social engineering attacks, which is information they need to improve their defenses.

Get BLEShark Nano