Introducing HoneyBee: How We Automate Honeypot Deployment for Threat Research

Honeypots are a powerful tool in threat research. They are intentionally vulnerable systems designed to attract attackers, allowing researchers to observe their techniques and learn from their behavior. By studying how real-world threats interact with these decoys, security teams gain valuable insights into attacker tactics, payloads, and emerging malware campaigns.

However, setting up honeypots can be challenging. Manually configuring realistic systems takes time, and outdated vulnerable applications rarely reflect modern cloud environments. What researchers need is a way to rapidly deploy an observable, vulnerable, yet otherwise secure instance of any given application. These environments must be realistic enough to attract attackers while remaining isolated and safe for analysis.

This is where HoneyBee comes in.

What is HoneyBee?

HoneyBee takes popular cloud-deployed applications such as databases, storage services, and web apps, and automatically generates intentionally insecure Dockerfiles and Docker Compose manifests. These are designed to mimic the types of mistakes we see in real environments, from overly permissive authentication settings to insecure storage bucket configurations.

To see what this looks like in practice, here’s a docker-compose.yaml file HoneyBee generated for a PostgreSQL instance with no password:

services:
  db:
    container_name: 'db'
    environment:
      POSTGRES_DB: 'mydatabase'
      POSTGRES_PASSWORD:
      POSTGRES_USER: 'admin'
    image: 'postgres:13'
    logging:
      driver: 'json-file'
      options:
        max-file: '3'
        max-size: '10m'
    ports:
      - '5432:5432'
    restart: 'always'
    volumes:
      - 'db_data:/var/lib/postgresql/data'
version: '3.8'
volumes:
  db_data:

HoneyBee has the following key features:

• AI-generated misconfigurations based on real-world patterns

• Dockerized setups that are easy to deploy and reset

• Nuclei templates generated alongside each setup to allow for external validation of the misconfiguration (to confirm attackers can indeed exploit it)

• Optional network monitoring using tcpdump to observe attacker behavior

You can try it out yourself at github.com/yaaras/honeybee.

How we use HoneyBee at Wiz

Internally, HoneyBee has become our go-to tool for deployment of misconfigured environments. We currently use it for various use-cases:

1. Testing detection rules

Our detection engineering teams deploy HoneyBee environments to validate that our risk detection rules trigger on realistic misconfigurations without risking production systems, and that our threat detection rules correctly identify successful exploitation of these misconfigurations by attackers.

2. Orchestrating honeypots

We use HoneyBee to create multiple honeypots across different types of cloud environments. Each honeypot is also equipped with tcpdump, Wiz Sensor, and integrated with Wiz CSPM and Wiz Defend. This allows us to capture both network activity and security alerts in real time, while relying on Wiz as a holistic detection suite. We then rely on Slack alerts to notify us of exploitation events, working under the assumption that any modifications made to our otherwise immutable decoy applications are indicative of malicious activity.

For instance, our research into exposed Java Debug Wire Protocol (JDWP) exploitation was made possible by HoneyBee. We deployed a series of honeypots with intentionally exposed JDWP ports. Within hours, we observed attackers exploiting this misconfiguration to deploy a customized XMRig cryptominer. Thanks to our HoneyBee setup, we were able to safely monitor the entire attack, from the initial exploit to the malware's sophisticated persistence techniques, which included creating systemd services and cron jobs to ensure it survived reboots. This provided invaluable intelligence that we used to build stronger detection rules for our customers.

HoneyBee was similarly instrumental when we investigated a cryptomining campaign targeting PostgreSQL servers. We quickly spun up a honeypot with a weakly configured PostgreSQL instance, and as expected, it was later targeted by the attackers. We observed them using weak credentials to gain access and deploy a fileless XMRig variant, a technique designed to evade traditional security defenses. The insights we gathered from this honeypot allowed us to document the attacker's evolving tactics and enhance our platform's ability to detect and prevent such threats.

Each of these incidents provided valuable visibility into attacker priorities and techniques, and by analyzing the full sequence of events from initial reconnaissance through post-compromise actions we were able to improve both our misconfiguration risk detection and our behavioral detection logic. This iterative feedback loop is one of the main ways HoneyBee directly contributes to strengthening our defensive capabilities.

3. Security research and training

For threat research, HoneyBee provides us with quick access to modern, vulnerable setups that reflect the technologies our customers actually use. We can then investigate how these applications are configured and what mistakes might be made during configuration, so that we can add detections for both the misconfiguration risk and the exploitation threat.

For internal training purposes, it allows new security researchers to gain hands-on experience with realistic scenarios in a safe environment.

Conclusion

For our team, HoneyBee has become an essential part of our research workflow. The ability to quickly spin up vulnerable targets and gather real-world intelligence has been invaluable for improving our own detections.

We know we aren't the only ones working on these challenges, which is why we’re open-sourcing HoneyBee with the hope that it can be just as useful to others in the security community. Our goal is to provide a simple, effective tool that helps us all build better defenses based on how attackers actually operate. We invite you to try it out and we'd welcome your feedback.