Honeypot Malware Download Blocked by Security Controls; Tor Route Found

The Problem: Overly Secure Honeypot

The goal was simple: capture malware. Security researcher Jari Huotari set up a Cowrie honeypot within his home lab. The setup involved Docker on Proxmox, protected by OPNsense firewall rules. Cowrie is designed to emulate a vulnerable SSH server, luring attackers to perform malicious actions. The intention was to let attackers download their payloads onto the honeypot, providing valuable intelligence on new threats. However, Huotari discovered his own security measures were preventing this crucial step. The honeypot was too well protected, blocking the very malware it was meant to attract and analyze.

This presented a critical paradox: a system designed to be attacked was effectively defending itself against the attackers' tools. The firewall rules, intended to protect the home network and the honeypot itself from *unwanted* external access, were also preventing the honeypot from receiving the malware payloads. This meant that while attackers could interact with the emulated system, they couldn't successfully deliver their malicious payloads for analysis. The data collection, the primary purpose of the honeypot, was being obstructed by its own security posture.

Why Whitelisting Cowrie Was Not an Option

Huotari considered a straightforward solution: whitelist the Cowrie honeypot within his OPNsense firewall rules. This would grant it unrestricted outbound access, allowing it to download whatever files attackers attempted to send. However, this approach was immediately dismissed. The core principle of a honeypot is to observe and capture malicious activity without actually introducing risk to the broader network or the researcher's infrastructure. Whitelisting Cowrie would essentially create a blind spot, allowing any downloaded payload to potentially execute or exfiltrate data without any further network-level checks. It would defeat the purpose of having a controlled, monitored environment. The goal was not just to download the malware, but to do so in a way that maintained security and allowed for proper analysis of the downloaded artifact.

Allowing Cowrie unrestricted outbound access would undermine the entire security architecture. It would be akin to leaving a security camera recording in a room but then disabling the locks on the door of that room, inviting potential breaches. The firewall rules were in place for a reason, and bypassing them for the honeypot would introduce significant risk. The researcher needed a method to allow the download without compromising the integrity of his network or the controlled nature of the honeypot environment.

The Solution: Cowrie Goes Tor

The breakthrough came with the idea of routing Cowrie's outbound traffic through the Tor network. Tor, the Onion Router, is a network designed for anonymous communication. By forcing Cowrie's traffic through Tor, Huotari could achieve two key objectives: first, mask the origin of the outbound connection, making it appear to come from a random Tor exit node rather than his home IP address. Second, and crucially, it would bypass the OPNsense firewall's outbound blocking rules. The OPNsense firewall was configured to block direct outbound connections to most internet destinations, but it was not explicitly blocking connections to the Tor network.

This strategy essentially created a new, indirect path for the malware download. Instead of Cowrie directly requesting the malware from a malicious server, it would send its request through the Tor network. The Tor network would then anonymize the request and fetch the file from the attacker's server, relaying it back to Cowrie through the Tor network. This maintained the illusion of an external connection for the attacker while circumventing the internal firewall restrictions. It was a clever way to enable the desired functionality without weakening the overall security posture.

The Docker Compose Configuration

Implementing this solution involved modifying the Docker Compose file used to orchestrate the Cowrie honeypot. The key was to configure Cowrie to use a proxy. By setting the `http_proxy` and `https_proxy` environment variables within the Cowrie service definition to point to a Tor SOCKS proxy (typically running on `socks5://tor:9050`), all of Cowrie's outbound HTTP and HTTPS traffic would be routed through Tor.

The Docker Compose file would need to include a separate service for the Tor proxy. This could be achieved by using an official Tor image or a custom image configured to run as a SOCKS proxy. This Tor service would then be linked to the Cowrie service, allowing Cowrie to communicate with it. The OPNsense firewall would still see an outbound connection to the Tor network, which was permitted, but it would not be able to inspect or block the actual destination of the traffic once it entered the Tor network. This isolation was critical for the honeypot's operation.

The configuration would look something like this:

services:
  cowrie:
    image: cowrie/cowrie
    container_name: cowrie
    ports:
      - "2222:22"
    volumes:
      - ./cowrie-data:/cowrie/data
    environment:
      - http_proxy=socks5://tor:9050
      - https_proxy=socks5://tor:9050
      - ftp_proxy=socks5://tor:9050
    depends_on:
      - tor

  tor:
    image: dperson/tor
    container_name: tor
    ports:
      - "9050:9050"
    volumes:
      - ./tor-data:/var/lib/tor

This setup ensures that any outbound connection initiated by the Cowrie container, such as downloading a file or fetching a command's output, would first pass through the Tor proxy service. The Tor service then anonymizes and relays this traffic. The OPNsense firewall, seeing only the connection to the Tor network, would not interfere with the subsequent steps of the communication chain.

Malware Download Achieved

With the Tor routing in place, Huotari was finally able to test his hypothesis. Attackers interacting with the Cowrie honeypot could now successfully upload or direct the honeypot to download malware samples. The honeypot, configured with the Tor proxy, would initiate the download request through the anonymous network. The malware would be fetched from the attacker's command-and-control server and delivered to the honeypot's designated download directory.

This was a significant step forward. The honeypot was now fulfilling its primary function: acting as a controlled environment to capture and analyze real-world malware. The success of this method demonstrated that by understanding and manipulating network traffic flow, even robust security controls could be bypassed in a controlled manner for research purposes. It provided a practical example of how attackers might use anonymization techniques, and how defenders could potentially leverage similar techniques for threat intelligence gathering.

The Implications: A More Interesting Honeypot

The ability for the honeypot to actually download malware opens up a new level of analysis. Instead of just observing attack vectors and commands, Huotari could now collect the actual malicious payloads. This allows for deeper security research, including:

• Malware Analysis: Static and dynamic analysis of downloaded executables, scripts, and documents.
• Threat Intelligence: Identifying new malware strains, their capabilities, and their origins.
• Attack Vector Refinement: Understanding how attackers attempt to deliver their payloads.
• Defensive Strategy: Developing better detection and prevention mechanisms based on observed malware.

The unexpected success of routing through Tor highlights the ongoing cat-and-mouse game between security controls and adversarial techniques. Attackers often use anonymization services like Tor to hide their activities, and this experiment shows how defenders can use similar tools to gain visibility. The fact that a well-configured firewall could be circumvented by simply routing traffic through an allowed, albeit anonymized, channel is a key takeaway. It suggests that egress filtering needs to be highly granular, not just based on destination IP or port, but potentially on the nature of the traffic itself, which is a far more complex undertaking.

A Crucial Disclaimer

Huotari rightly emphasizes that this setup is for research purposes only. Running a honeypot, especially one configured to download malware, carries inherent risks. The OPNsense rules were specifically configured to isolate the honeypot from the rest of the home network. The Tor routing was a method to enable data collection while *maintaining* that isolation. Attempting to replicate this without a deep understanding of network security, Docker, and the potential risks of handling malware could lead to severe security breaches. It is critical that any such experiment is conducted in a completely air-gapped or heavily isolated environment, with comprehensive egress and ingress filtering, and a robust incident response plan in place.

The success of this experiment hinges on the strict isolation and controlled network egress provided by OPNsense, even with the Tor bypass. Without these safeguards, the honeypot would become a liability rather than an intelligence-gathering tool. The author's careful consideration of security implications, even while finding a way to bypass his own controls for research, is a testament to responsible security experimentation.