Five Minutes and an Empty Port Part 2: Shark Jack, Packet Squirrel, and LAN Turtle

Part 1 laid out why this category works at all. This part gets specific about the three purpose-built wired devices in Hak5’s current lineup, because despite all three looking like variations on “small box with an Ethernet port,” they solve three different problems and belong in three different scenarios.

The one thing they share: a switch port trusts them completely

Every device in this part relies on the same base assumption from Part 1: a switch port with no 802.1X, no port security, and no DHCP snooping configured has no way to distinguish “the laptop that’s lived on this desk for two years” from “a $100 device that arrived thirty seconds ago.” All three request a DHCP lease like any other device, and all three get one, because nothing on the wire is checking.

Shark Jack: the quick-strike tool

The Shark Jack is built around a three-position physical switch, and the switch position is the whole interaction model. The position closest to the USB-C port is off, used for charging. The middle position is arming mode: the Shark Jack comes up with a static IP of 172.16.24.1 and an SSH server, so you can load or edit the payload script that attack mode will run. The forward position, closest to the Ethernet jack, is attack mode: on power-up, it automatically runs whatever’s sitting in /root/payload as payload.sh or payload.txt, no further interaction needed.

That’s the entire value proposition: arm it once at a desk, then walk up to a target jack, plug it in, and walk away. It doesn’t need to stay plugged in either. A payload can run a quick nmap sweep of the local subnet, grab the DHCP-assigned gateway and DNS servers, and either write the results to onboard storage for later retrieval or push them out immediately over Hak5’s Cloud C2 if the segment has outbound internet access. Ten to fifteen minutes of battery is the stated runtime, which tells you the intended use case in one number: this is a device you plug in, let run for a couple of minutes, and pull back out, not one you leave behind.

Use case: opportunistic recon and a fast exit. A conference room during a break, an unattended desk during a site visit, a facilities closet with an exposed patch panel. The Shark Jack answers “what’s actually on this network” faster than carrying a laptop in and connecting it visibly ever could.

Packet Squirrel Mark II: the one that stays

The Packet Squirrel Mark II solves a different problem. Where the Shark Jack is a drop-in-drop-out recon tool, the Packet Squirrel is designed to sit inline, physically between a target device and its switch, for as long as it goes unnoticed. It has two Ethernet ports specifically for this: one faces the target, one faces the switch, and traffic passes through transparently by default while the Packet Squirrel watches, and optionally alters, everything crossing it.

The stock payload set on the Packet Squirrel gives a sense of what “inline” is actually good for: a simple pass-through packet capture that logs everything to a USB drive in PCAP format for later analysis in Wireshark, a DNS sinkhole payload that intercepts and redirects DNS responses for chosen domains (a live man-in-the-middle, not just passive capture), and a VPN payload that tunnels the captured segment’s traffic out over OpenVPN or WireGuard to a remote endpoint. There’s also a Gatekeeper payload that uses the device’s built-in pushbutton to physically toggle whether traffic is allowed through at all, and a printer-capture payload that intercepts PCL print jobs in plaintext through a dynamic proxy, worth remembering the next time “the printer” seems like an odd thing to worry about on a network diagram. Payloads are written in a simplified DuckyScript variant, or in full Bash or Python 3 for anything more involved than the stock set covers.

Use case: sustained interception, not a snapshot. This is the tool for “I need to see everything this specific device sends and receives over the next several days,” deployed somewhere it can plausibly be mistaken for a legitimate adapter, dongle, or cable-management clutter.

LAN Turtle: covert, persistent, and hiding in plain sight

The LAN Turtle is built for the third scenario: long-term, low-maintenance remote access, housed in a case deliberately shaped like a generic USB-Ethernet adapter, the exact kind that shows up in every IT department’s spares drawer and draws zero attention sitting under a desk or behind a monitor.

Where the Shark Jack and Packet Squirrel run one payload script, the LAN Turtle has a proper module system, with modules installed and configured through a menu-driven shell. The autossh module is the core one: it establishes an SSH connection outbound to an attacker-controlled host and keeps it alive indefinitely, meaning the attacker never needs to know the LAN Turtle’s IP address or punch any hole in the target’s firewall, since the connection is entirely outbound-initiated. This is exactly the “call home” pattern this site’s own Pivoting and Tunneling series builds SSH -R forwarding and Chisel around, just packaged into purpose-built hardware instead of a manual SSH command. A meterpreter module does the same thing but establishes a Metasploit Meterpreter session instead of a plain shell, an nmap module runs configurable scans against the local segment and logs the results, and a DNS spoofing module redirects chosen lookups, similar in spirit to the Packet Squirrel’s sinkhole payload but running from a persistently-installed device rather than an inline tap.

Use case: weeks, not minutes. A LAN Turtle deployed once and left in place is the physical equivalent of a persistent backdoor, valuable specifically because nobody’s looking for it, and because it phones home rather than waiting to be found.

Comparing the three

	Shark Jack	Packet Squirrel Mark II	LAN Turtle
Deployment style	Plug in, run, pull out	Inline, stays for the duration	Persistent, left in place
Typical dwell time	Minutes	Hours to days	Weeks
Primary job	Recon and exfil	Traffic capture / MITM	Covert remote access
Disguise	None needed, it’s gone before anyone looks	Looks like cable clutter	Looks like a USB-Ethernet adapter
Rough price	~$100	~$150	Commercial line, currently unavailable

None of these three need a single misconfiguration to work, just an open port and the few minutes of physical access Part 1 argued is easier to get than most organizations assume. Part 7 comes back to exactly this table when it covers what actually stops each of them: port security defeats the drop-in-drop-out pattern by refusing an unrecognized MAC entirely, but a persistent, patient device like the LAN Turtle is a different, harder problem, because by the time it’s noticed, it’s already had weeks to establish itself.

Part 3 moves from the network port to the USB port, and to a class of device that none of the controls in Part 7 through 9 can see at all.