OPSEC for Physical Red Teams: Kill Switch, Self-Destruct, and Stealth Mode

Physical red team engagements carry a risk that remote pentests do not: someone can find your hardware. When a facilities manager discovers an unknown device plugged into a switch port behind the printer, the engagement is not just blown -- every credential, hash, and PCAP sitting on that device is now evidence. If the client's incident response team images the storage, they get a forensic record of every attack you ran, every network you mapped, and potentially every piece of client data you captured. That is not a failed engagement. That is a liability event.

OPSEC for drop boxes is not optional. It is the difference between a controlled engagement and a breach notification. The Phantom was designed from the ground up with five OPSEC controls that work together: a remote kill switch, cryptographic self-destruct, stealth mode, scheduled operations, and an independent 4G command channel.

How Does the Kill Switch Work?

The kill switch is a single command sent from the dashboard through the relay. When triggered, the Phantom immediately terminates all active attack modes -- Venom stops poisoning, Siren tears down rogue APs, Fang disconnects BLE sessions, and Scope stops capturing. The device goes radio-silent on every interface within seconds. No graceful shutdown negotiation, no finishing the current capture. Every process is killed, every socket is closed, and the network interfaces are brought down.

This matters in scenarios where you need instant cessation. A client calls and says their SOC flagged anomalous LLMNR traffic. You hit the kill switch from your phone, the Phantom goes dark, and the SOC sees the traffic stop. You buy time to coordinate with the client's engagement lead without the device continuing to generate alerts.

The kill switch is a stop, not a cleanup. The device retains its captured loot and configuration. You can re-activate it later if the engagement continues, or follow up with a self-destruct if you need to wipe it clean.

What Does Cryptographic Self-Destruct Actually Erase?

Self-destruct goes further than the kill switch. When triggered -- either remotely via the relay or physically using a button combination on the device -- the Phantom performs a cryptographic erasure sequence:

• All captured loot (credentials, hashes, PCAPs, scan results) is destroyed by overwriting the encryption keys that protect the loot partition. The data is AES-256 encrypted at rest; destroying the key renders the ciphertext unrecoverable.
• Playbook configurations, engagement settings, and operator-defined parameters are wiped.
• All log files -- system logs, attack logs, connection logs -- are destroyed.
• The device resets to a clean factory image. Post-destruct, it is indistinguishable from a device that was never configured for an engagement.

The key point is what a forensic examiner finds after self-destruct: nothing. No residual data in unallocated sectors because the data was encrypted and the keys are gone. No log fragments because the log partition is cryptographically erased with the same approach. The factory image is a stock Phantom image with no engagement artifacts. A competent forensic analyst can determine that the device is a Phantom, but they cannot determine what it was used for, what it captured, or who operated it.

The physical trigger exists for situations where you lose remote connectivity. If the 4G module is jammed or the device is in a Faraday cage, you can still trigger self-destruct during physical retrieval using the button sequence. The sequence is configurable per engagement so it cannot be guessed from documentation.

How Does Stealth Mode Prevent Detection?

Stealth mode is a master toggle that forces the Phantom into purely passive operation. When enabled, the device does not transmit a single packet on any target-facing interface. No ARP requests, no DHCP discovers, no DNS queries, no LLMNR responses. The Ethernet interfaces operate in promiscuous mode for passive capture only. The WiFi radio listens but does not probe or associate.

This is critical during the initial reconnaissance phase of an engagement. Before you decide which attack modes to run, you need to understand the target network -- what VLANs exist, what protocols are in use, how aggressive the SOC monitoring is. Stealth mode lets you answer those questions without generating a single alert. You observe the network for hours or days, build a picture of the environment through passive traffic analysis, and then make informed decisions about which active attacks to deploy.

Stealth mode is also your fallback if something goes wrong. If you suspect the SOC is investigating, you can switch to stealth mode remotely. The device continues to exist on the network physically, but it generates zero traffic. From the SOC's perspective, whatever was causing alerts has stopped, and there is no new traffic to investigate.

How Do Scheduled Operations Avoid Detection?

Running Venom mode credential harvesting at 3 AM on a Sunday is a red flag. LLMNR and NBT-NS poisoning responses when no employees are at their desks stands out in traffic analysis. Scheduled operations let you define time windows for each attack mode so the Phantom's activity coincides with normal business traffic.

A typical schedule might run Venom only during business hours (08:00-18:00 Monday through Friday) when legitimate name resolution traffic provides cover. Siren mode evil twin attacks might run during lunch hours (11:00-13:00) and end of day (16:00-18:00) when employees are most likely to connect to WiFi on personal devices. Scope mode runs continuously because passive capture generates no detectable activity.

The scheduler handles mode transitions automatically. You configure it once during playbook setup, and the Phantom activates and deactivates modes on schedule without operator intervention. This eliminates the risk of an operator forgetting to stop an attack mode outside business hours and generating anomalous off-hours traffic.

Why Does the Phantom Use a Separate 4G Command Channel?

Every command and every exfiltrated file travels over the Phantom's dedicated 4G LTE module. The device never touches the target's internet connection for command-and-control or data exfiltration. This is a fundamental architectural decision, not a convenience feature.

If the Phantom used the target network for C2, every relay connection would traverse the client's firewall, proxy, and IDS. The SOC would see outbound WebSocket connections to an unknown endpoint. DNS-based C2 would show up in DNS logs. Even encrypted traffic to an unusual destination is a signal. The independent 4G channel makes the Phantom's C2 traffic completely invisible to the target's security monitoring because it never enters the target's network infrastructure at all.

The 4G module also provides connectivity independence. If the target network goes down, or if the port the Phantom is connected to gets disabled, you still have full remote access to the device. You can trigger the kill switch, initiate self-destruct, or reconfigure the device regardless of the state of the target network.

How Does This Compare to Raspberry Pi OPSEC?

The short answer is that there is no Raspberry Pi OPSEC. A Raspberry Pi drop box has none of these controls. There is no kill switch -- you SSH in (if the tunnel is still up) and manually stop processes, hoping you remember every service you started. There is no self-destruct -- the SD card contains every tool you installed, every script you wrote, every credential you captured, and every log entry the OS generated. Whoever finds that Pi gets everything.

The SD card is a forensic goldmine. Even if you wrote a cleanup script, SD cards do not support TRIM, so deleted data remains in flash cells and is recoverable with standard forensic tools. There is no full-disk encryption by default, and even with LUKS the key management problem remains -- the key has to be stored somewhere the Pi can access it at boot, which means it is recoverable from the same SD card.

There is no stealth mode. The Pi's network stack sends ARP requests, DHCP discovers, and potentially NTP queries as soon as it boots. You can try to lock this down with iptables rules, but one misconfigured rule and the Pi is broadcasting its presence. There are no scheduled operations unless you write and debug cron jobs yourself. And there is no independent C2 channel -- your reverse SSH tunnel to a VPS means your engagement data transits a rented server you do not fully control.

Purpose-built OPSEC is not about adding features to consumer hardware. It is about designing hardware and software together so that operational security is the default state, not an afterthought bolted onto a hobbyist platform.