Building Testing Dropboxes

## Overview

Chris Kalles, a career penetration tester and red teamer, presents a practical guide to building and deploying "dropboxes"—customized physical computers placed on target networks to facilitate temporary remote access during security testing. Rather than prescribing exact configurations, Kalles emphasizes the decision-making process and lessons learned from years of field deployments and numerous mistakes.

## What Are Dropboxes?

Dropboxes are small, temporary computing devices deployed on networks for penetration testing and red teaming. While virtual machines and C2 agents have become more common, physical dropboxes remain useful for scenarios requiring isolated, persistent network presence. Unlike purchasing pre-built solutions like Hak5 devices (Packet Squirrel, LAN Turtle, WiFi Pineapple), custom-built dropboxes can be tailored to specific operational needs and goals.

## Testing Goals Drive Design

Kalles emphasizes the distinction between penetration testing and red teaming—two fundamentally different engagements. Penetration tests focus on identifying security control weaknesses with limited stealth requirements, while red team engagements simulate attacks to test defenders' detection and response capabilities, requiring significant operational security. A box built for penetration testing (like Secure Yeti's "Beast," designed to support multiple testers simultaneously) will likely compromise a red team operation through excessive noise and visibility. Conversely, a stealthy red team box may lack the throughput and capabilities needed for intensive penetration testing.

## Hardware Considerations

Kalles discusses multiple hardware platforms: Raspberry Pi and clones (Orange Pi, Banana Pi) offer affordability and popularity; Pi Compute Modules provide compact form factors with dual Ethernet ports critical for physical man-in-the-middle attacks against 802.1X networks; and Intel-based alternatives like fitlet and Zima Board provide stronger processing power without ARM limitations. Key hardware decisions involve size (stealth), cooling (fanless vs. noisy), port availability (particularly dual Ethernet for NAC bypass), and upgrade potential. Recent options like Zima Board are noted as functional but require consideration of thermal management when enclosed in confined spaces.

## Software Stack and Challenges

The software layer typically runs Linux (Windows requires significantly more effort) and must balance flexibility with complexity. Essential components include operating systems, persistence mechanisms, encryption (with projects like Crypt My Pi enabling passwordless boots via SSH key authentication), potential hypervisors for running testing VMs, and remote access solutions (SSH tunnels, OpenVPN, WireGuard, or Tailscale). Kalles stresses that 90% of hacking involves getting tools to work properly—a reality he illustrates through repeated failures during field deployments.

## Communication Options

Connectivity methods range from wired (SSH through existing network infrastructure) to wireless (WiFi, cellular, Bluetooth) and experimental approaches (drone radios in 900 MHz band, powerline Ethernet, Meshtastic mesh networks, MoCA over coaxial cables, and Starlink satellite). Each option presents trade-offs: wired connections offer reliability but visibility; WiFi provides range but can be detected; cellular offers stealth but requires SIM cards and service plans; newer protocols like WiFi hello (900 MHz band) offer interesting range/throughput combinations but limited current ecosystem.

## Operational Security Failures and Lessons

Kalles recounts multiple self-inflicted errors: deploying Raspberry Pis with unchanged default credentials (easily discovered by defenders), using obvious hostnames like "Kali," inadvertently disrupting networks by running Responder on physically MITM'd systems (causing help desk calls), and selecting hostnames containing initials matching "Red Team." More recent lessons involve encryption requiring wireless network discovery and SSH key verification before boot completion, avoiding elaborate naming schemes, and prepositioning equipment (cables, monitors, adapters) to prevent field equipment failures. A memorable incident involved accidentally triggering a building's emergency phone while installing a box in a parking garage.

## Legal and Ethical Boundaries

Kalles addresses serious considerations often overlooked: recording audio constitutes wiretapping (illegal); video without audio exists in a legal gray area; attacking wireless devices (mice, keyboards) or causing denial of service crosses into crime; and understanding actual versus assumed authorization matters critically. Shared tenants, cloud provider networks, and building ownership create legal complexities that require explicit written authorization and legal review before testing.

## Key Takeaways

Dropbox deployment requires thoughtful decisions about testing goals, budget constraints, hardware platform selection, software requirements, communication methods, and operational security posture. Extensive field testing is essential before operational deployment. Documentation and team support determine whether a dropbox becomes a valuable tool or an unsupported burden. Kalles emphasizes learning from mistakes—both his own and others'—while maintaining realistic expectations about field failures and the reality that "stuff's going to break anyway."