Honeypot Notes Part 3 - endpoint data

Intro

(No AI was involved in writing, research, etc...)

See part 1 and 2 here: 

https://www.boredhackerblog.info/2026/08/honeypot-notes-part-1-deploymentdesign.html

https://www.boredhackerblog.info/2026/08/honeypot-notes-part-2-network-data.html  

Just like collecting pcap data, logs provide us with info such as payloads and how an attack was done/what the attacker is trying to do. Logs is just another source. Personally, I feel that the logs are a better/higher fidelity indicators of successful exploitation. 

You could always use an EDR agent but I'm going with the assumption that there is no budget and focusing on opensource/free stuff. 

 

Log types and why collect them:

We want endpoint logs such as process execution, file creation/deletion, network connections (contain process responsible), authentication logs, and various other system logs.

There are also specific app logs that may be specific to your honeypot or how you run the honeypot. This includes logs for web server such as apache/nginx or logs your webapp writes (audit/activity logs). 

If your app runs inside of a docker container, you'll want to capture container logs too. 

Technically these aren't logs but you can try to collect crash dumps or core dumps too.

Endpoint logs can help with identifying post-exploitation activity and also help you write signatures for detecting similar behavior in your environment. 

Specific app logs are also useful for identifying post-exploitation behavior but more focused on what the attacker does inside the app itself (like new user added). 

Log collection, storage, and processing:

Log collection tooling:

Before you start collecting logs, ensure that you have correct logging enabled. On Windows for example, you may have to enable more logging to capture process execution data. On Linux, you may have to install more tooling to capture the data that you want.

You can add tools such as sysmon, sysmon for linux, or auditd to get more data as well.

For collecting logs, there are various tools already out there. Elastic Beats, Splunk UF, Vector, fluentbit, fluentd, and more.  

Storage:

There are a couple of things you can do with logs besides letting them just sit on the host itself:

- write them into a mounted remote share - attackers can go and delete these files though

- Send logs to S3. These tools support S3 as a sink. 

- Send logs directly to SIEM/log centralization service. 

You always have the option to send logs to multiple places as well.

If you end up using something like Wazuh or Elastic agent, you can send logs directly to SIEM too.

Be sure to configure some filtering so you're not constantly capturing events for logging tool making connection or writing to disk. You'll probably need to update network traffic capture filter to avoid capturing traffic for log uploads.

 

If you are monitoring something that gets compromised a lot, you probably want to revert the honeypot VM and I'm not sure if that breaks logging or not personally. Something that you may want to test.  

You'd also have logs you'd need to collect from whatever network traffic analysis tools generated. 

Processing:

Processing logs depends on how you collected them. If they're in S3, you can always use collection tools to read files from S3. You can also trigger scripts after file is uploaded to S3 to do processing.

If you have file share w/ logs, you can use log collection tool to read them again and send them to whatever SIEM you'd like.

You will at some point need to parse the logs. This can be done within log collection tool or SIEM where you're sending the logs to, if it supports it.

 

For centralizing logs, I recommend looking at elasticsearch, opensearch, and splunk free.

I do have some collectors listed here: https://github.com/stars/BoredHackerBlog/lists/log-collectors

Also some software to store logs into for searching: https://github.com/stars/BoredHackerBlog/lists/logging 

 

Once you have your logs in one place where you can search them, make dashboards, or generate alerts, you'll probably to know when something bad happens. 

 

Signs of exploitation:

Looking for signs of exploitation in logs is pretty much same as looking for attacks in normal environments. There are a bunch of sigma rules or premade detections or dashboards that can be used. 

For more focused approach, especially if the vuln isn't known, you can look for your honeypot software or process responsible for running honeypot software (apache or something for webapp) spawning new child processes, writing files, or making odd network connections.

For webapps specifically, signs of new file being written in web server directory could be interesting (like webshell). 

Additionally, monitoring app audit logs could be helpful. For example, if you have a VPN with potential auth bypass vuln, successful exploitation may look like logs showing new VPN client or something.

I think depending on your honeypot software, you can probably determine what exactly needs to be monitored to see if it got popped.

 

As mentioned in the first post, none of this is magic. It's same as managing normal endpoints but just collecting a bit more data and hoping there is an actual compromise (if you want something interesting to research).

Honeypot Notes Part 2 - network data

Intro

(No AI was involved in writing, research, etc...)

Read part 1 here:

https://www.boredhackerblog.info/2026/08/honeypot-notes-part-1-deploymentdesign.html 

 

The reason we want pcap data is because we want to know what the attacker intends to do/execute and how. In some cases, logs don't have enough information. 

For example, if you have a patched/latest version IP/IOT camera you're monitoring and it finally gets compromised, your logs may not have enough data such as body for POST request or actual packet that caused it to execute malicious commands. Having full pcap data lets you go back and figure out what the input was that lead to the compromise.

The other reason to collect pcap data is because we want to know more about outbound traffic from our honeypot after exploitation. Sometimes the payload may be obfuscated and when executed leads the honeypot to download secondary payload and we want to know about that. (think of log4j vuln exploitation flow)

I'm going with assumption that you don't have money to buy commercial remote traffic capture sensors. I'm just using free/open source things. 

Traffic processing tools:

Here are some tools that can be helpful for processing traffic data:

Suricata/Snort - these are network intrusion detection systems. They can parse certain protocols and also support detection rules so you can look for specific payloads or type of traffic. For example, if you expect the attacker to send payload to a certain URI, you can write a custom detection to get alert on it. These can also be useful for looking at outbound traffic. 

Zeek - Zeek is also another intrusion detection software. It parses protocols as well. Zeek has a scripting language that actually lets you write scripts that run on captured traffic. This can be useful if you want to extract specific payload data. It has ability to extract files from some protocols too, which I see people using all the time.

Python Scapy - Python Scapy library lets you process network traffic data and extract and further process things through python scripting. Here's an example of me doing that: https://www.boredhackerblog.info/2016/02/extracting-images-from-crestron.html 

Arkime - last time I used this, it was called Moloch. Arkime lets you capture packets and analyze all the data through webui.

There are probably other tools I'm missing.  

Capturing data:

How do you capture data?

I used to run Suricata on the honeypot or sensor itself. I didn't like that because I'm capturing and processing data in the same place.

 

For my recent projects, I just kept it simple. I capture data using tcpdump. I'd like to keep raw packet data so I can even go process it later with various tools if needed.

One option I've thought about is using a remote tzsp capture tool and forwarding traffic to another tcpdump instance but it gets needlessly complicated and there is more chance of failure. 

Where exactly do you collect data from?

 

This would depend on your setup and it would also impact how you store and process data. There are benefits and downsides too. (storage and processing is discussed later)

You could do tcpdump on VPS, internal traffic forwarder, honeypot, or vlan port (from proxmox). 

Doing tcpdump on VPS and internal traffic forwarder gets you incoming data but you don't get outbound traffic. 

If you capture data on honeypot itself, getting that data out for processing may be a bit difficult but you can see outbound connection attempts.

Collecting data through proxmox by monitoring the specific interface could be an option too.

I have not tried this but you could make traffic forwarder machine a DHCP/DNS/gateway but drop all the honeypot traffic, then still capture outbound traffic and incoming traffic on the traffic forwarder itself. 

Personally, for the project I'm working on, i just put tcpdump on honeypot itself because it was simple. 

Storage, capture filters, and processing:

Chances are, you want to run honeypot for long term which means you'll have a ton of pcap data. 

VPS likely doesn't have enough disk space to store pcaps and also now you have to reach out to VPS to get the pcaps for processing.   

Couple of ideas I've had for storage are: 

- Mount a file share to VPS, traffic forwarder, or honeypot

- Mount a folder to VM (through your VM manager) running traffic forwarder or honeypot.

- Put pcap files on s3/remote machine based on how many traffic is captured or how much time goes by

Mounting file share requires you to create a file share, users, manage permissions, etc. Once you do that, you gotta go to VPS, traffic forwarder, or honeypot and mount the remote share. Managing gets annoying and now you risk threat actor accessing the share and deleting captured data. 

Proxmox supports mounting a folder to the VM which is great but attacker still can go and delete the pcap files. 

tcpdump has a feature that lets you capture and write new files based on how much time has passed or how much data you have captured. This is great because you can capture pcap files, upload them to an s3 bucket(even self hosted), and delete the files from disk. 

I found two posts/projects that discuss how to do this:

https://davecturner.github.io/2020/12/12/rolling-tcpdump.html

https://github.com/FastNetMon/cloud_pcap

I really like the idea of just uploading pcaps to s3 bucket where you can do better access control as well.

Capture filters:

Capture filters are very important. If you're writing pcap data to a remote file share or uploading pcaps to s3, you don't want to capture that upload/write activity back into a new pcap or else you'll keep infinitely increasing your pcap size. I've accidentally done this before. :-( 

You also want to think about what you want to capture. If it's just a simple low interaction honeypot you deployed, you may want to just capture data on one specific port. If your honeypot is expected to get fully compromised, you may want to capture all the traffic and maybe exclude storage/upload traffic. 

 

Processing traffic:

If you're writing files to disk, you can use inotify to trigger scripts when a new file has been written, alternatively, suricata has a directory monitoring feature as well.

S3 or self-hosted S3 alternatives should have a configuration for triggering webhooks for when a new file is uploaded. These options can be used to trigger scripts as well. 

Suricata and zeek both have ways to read pcap files:

https://docs.suricata.io/en/latest/capture-hardware/pcap-file.html

https://docs.zeek.org/en/current/quickstart.html#running-zeek

https://isc.sans.edu/diary/29530

You always have the option of running a custom python script with scapy to extract whatever you need. 

Your processing will produce logs and may produce binary files too. Logs will be discussed later.  

 

Encrypted traffic:

I don't have a solution to deal with encrypted traffic. I don't really know much about cryptography to be honest. 

You may have honeypot services that may use TLS/SSL encryption and you still want payload data.

First thing to check is, if you can upload/use your own cert. If that's possible, you can analyze unencrypted traffic later.

You can also do weird things like use a reverse proxy which allows HTTP traffic in but sends it to HTTPS service so when an attacker attacks, you can capture HTTP traffic. 

You may also be able to do some magic via socat. 

Signs of exploitation:

Finally, the interesting part. How do we know there was exploitation so we can go look at payloads or attack method?

If your honeypot has a known vuln, you can just focus on how that vuln is exploited and where exploit code and payload will be.

 

I think it would be cool to find in-the-wild exploitation of certain vuln before public POC exists.

If your honeypot software does not have a known vuln or public POC, there are several things you can do, at least for webapps.

First thing you can do is look at traffic to specific URI or paths that a normal scanner or bot wouldn't touch but an attacker might.

You can review parsed data or set up a suricata rule that looks for traffic to specific URI (mysite.com/plugins/very_specific_plugin/upload.php) or partial URI (mysite.com/plugins/*). If you do see traffic that matches, you can review payload and see what the attacker attempted to do.

Additionally, you can just rely on free suricata rules too to find things. I believe there is also a threat hunting rules out there that you can use with suricata.

 

Outbound traffic:

Regardless of if you have a webapp or some other honeypot service, outbound traffic can be helpful with detecting successful exploitation.  

The reason why you may want to capture outbound traffic/attempts is because that may show you signs of successful exploitation.

You can exclude known outbound traffic and look for unknown outbound traffic to maybe like a weird domain or IP.

Additionally, you can look for traffic to OAST sites. In some cases, the attacker may do exploitation and check to see if certain code ran and connected to one of the OAST domains or URL.

See this rule: https://detection.fyi/sigmahq/sigma/network/dns/net_dns_external_service_interaction_domains/ 

You can also rely on free suricata rules as mentioned earlier but focus on outbound traffic. 

 

This isn't very different from normal traffic monitoring except you have to figure out where to collect the data, how to store it, and how to process it. After processing, you just have to look for signs of your specific app being targeted and successful exploitation or at least attempts.

 

Next post looks at collecting and processing logs. 

Part 3:  

https://www.boredhackerblog.info/2026/08/honeypot-notes-part-3-endpoint-data.html 

Honeypot Notes Part 1 - deployment/design

Intro

(No AI was involved in writing, research, etc...)

Note: this blog is titled "Honeypot Notes" because I don't professionally deal with honeypots anymore and I haven't really followed what other people do. Since this isn't academic/professional writing, I haven't done lit review so I don't know what's going on out there. I'm just writing this up because maybe someone will find it useful. None of this should be new to people who professionally do this.

I first dealt with managing/deploying honeypots in 2015. It was my first infosec job.

I'm not sure if this was my idea, my managers idea, or an idea we got from CircleCityCon (rip) or BSidesIndy (rip) presentations. Either way, the company gave me money to do this.

Actually, here's what I found in my old slides (these were made after I left my job):

 

Here's how I went about setting things up:

We bought VPS (virtual private server) machines from various sites for running honeypots. VPS companies used to offer LXC/LXD containers or KVM VMs.

To pay for VPS servers, we used prepaid cards and bitcoins. 

Regarding software: 

We used MHN (Modern Honey Net). MHN let you deploy various types of honeypots and pulled the relevant data back from the honeypots to the main MHN server. MHN basically would run scripts to install whatever type of honeypot you wanted. 

If I recall correctly, MHN stored data into mongodb and we pulled that data and put it into Elasticsearch. 

The malicious IPs were used to make a blocklists for customers. Other data collected with honeypots was used for research internally. 

 

Why?

Honeypots can serve several functions. You can see who's attack things and what type of attacks they're doing. You might be able to capture malware samples or payloads to analyze. You can create blocklists based on behavior from various IPs.

Based on data collected by various people who run honeypots and share data, you could determine if you were hit with a targeted or unique attack.

Finally, honeypots may be useful for capturing in-the-wild attacks for new vulnerabilities or unknown vulns. 

When I was running honeypots, I did see Elasticsearch (which our company used internally & for customer data) being attacked in the wild (screenshot from an email):

 

My Linux botnet research project was also inspired by a malware sample I got from a honeypot as well.

https://www.boredhackerblog.info/2017/05/linux-botnet-malware-analysis-part-1.html 

I'm sure Greynoise also has blog posts on what their customers do with their data.

I'd also recommend looking at Intrusion Detection Honeypots: Detection through Deception by Chris Sanders.

In this series, I'm focusing on collecting payloads/attack data for vulnerable software and for software that does not currently have public vulns. I'm discussing some set up ideas and things I'm doing or have done in the past. 

I do recommend quickly scrolling over this post: https://www.boredhackerblog.info/2022/07/building-honeypot-network-with-inetsim.html  

Honeypot/sensor placement:

Placement of your honeypot depends on your goals and who you're trying to attract.

Some customers I've worked with in the past have had thinkst canary sensors placed inside their network. Some of them have put honeypot/deception machines on public IP owned by their org. 

Some threat actors may think twice before using a shiny new exploit on some random VPS vs IP owned by a company.

In this blog, I'm just focusing on internet facing sensors that are deployed on VPS/datacenter-owned IPs. 

You should also think about how many services your sensor will run. For example, are you going to run one VPS and put 3-5 different vulnerable services on it or are you going to run separate VPS for each vulnerable service you're running? Depending on what you do, you might catch different things.

Thinking from an attackers point of view, if I search Shodan for a vulnerable service and I see one IP with multiple vulnerable services, I'd probably not touch that. If I'm a bot/script that constantly scans the internet and tries to exploit everything, I wouldn't care if one IP is hosting multiple vulnerable services.

I'm focusing on hosting one service/profile on one VPS. 

Honeypot types & software:

There are many different articles out there regarding different types of honeypots such as low interaction, high interaction, etc. I would recommend reviewing those. 

Low interaction might be something very static that looks like the service you're pretending to be but isn't. You may catch some initial payloads with this. High interaction might be something that is actually vulnerable that someone could do a full attack on. 

You can also simulate services that someone could do a partial attack on. I think there are SMB and SSH honeypots like that out there that pretend to be vulnerable SMB server or SSH to catch payloads and/or commands.

Here are some ways you can make something low interaction, especially if you don't have the original software (licensing/access issues):

- Use wget to clone an already public facing appliance. I've done this before for a router I didn't own.

- Use Medusa (https://github.com/evilsocket/medusa) to clone existing Shodan service. I haven't used this personally.  

- Manually create simulation/service that looks like the original service. This could be like a service that's TCP socket connection-based that people connect to via telnet for example.

- Check Github to see if someone has already made a honeypot for the service.

You can modify your setup based on what you may find in Nuclei templates. Nuclei template may exist for service version discovery where it gets a specific URI/page to find a vulnerable version. Additionally, if you're setting up something to catch payloads, you can check Nuclei template to see which specific path is targeted and what's expected back from the server. 

 

There are ways to acquire the software you're trying to make a honeypot for as well. Obviously, you can try to find a Trial version from the vendor first.

You may also be able to check/search Github to see if you can find any repos with direct links or setup scripts that download the software. Github may also have a copy of the software itself because someone uploaded it to a public repo...

Finally, there is DockerHub as well. You might be able to search for premade container for the software you're interested in. You can then extract the software or just use the container if it works.

However you deploy your honeypot, do check Shodan, Censys, etc to see what it looks like. It may take a while before these services scan and index your honeypot.

Management & architecture:

If you deploy multiple VPS servers, you'll obviously have to manage them and make sure they're healthy. 

Check out DevOps for the Desperate from NoStarch books. It pretty much covers doing management better than I ever could here. 

Management of VPS isn't anything special. It's like managing traditional infrastructure. There may be some opsec considerations depending on how far you expect an attacker to get and your architecture. 

Depending on what VPS service provider you use, you might be able to do new VPS deployments using Terraform/OpenTofu, Vagrant, or just scripts. 

For management, you can simply use SSH alone or Vagrant as well. 

Essentially, once you have VPS up and running, you'll want the ability to remotely deploy scripts, updates, install software, and etc on all VPS or group of them. Vagrant allows you to do this easily.

You may also want to ensure that these machines are up and running all the time. You can use uptime monitoring tools such as Uptime Kuma or other paid solutions. These solutions can reach the sensor and make sure it responds. You may also want to do this in reverse. You can use a service like Healthchecks.io to have these machines send web request so you know there isn't a connectivity issue. You can avoid using these tools and just rely on incoming logs too.

You can also do cpu, memory, disk monitoring by installing an agent & logging or using something like Beszel. 

For managing honeypot software, you could utilize something like github, github actions, and containers. 

For example, if you have fake ssh service and you want to update version info, you can edit a file in github, have github actions build a new container, then you can use vagrant to deploy it or automatically deploy it.

 

Architecture:

MHN used to download and run the actual honeypot software on the VPS sensor itself. 

You too can run your honeypot software on VPS sensor itself. You can install the software on the VM itself or run it inside of a docker container. Depending on your software and how far you expect the attacker to get, you may need to implement a few more things, such as hardening and firewalling. 

 

 

Depending on your VPS specs (cpu, ram, disk) and the honeypot software you want to run, you may run into issues. Some VPS can't run certain things due to CPU being slow or RAM not being enough.

There are ways around this! You can do traffic forwarding! 

Essentially, the VPS doesn't run much. It just takes traffic that comes in and forwards it somewhere else, like the machine where your honeypot software is running. 

Below, I'll discuss several designs I've tried and other options as well.

I do recommend looking at this: https://github.com/opsdisk/the_cyber_plumbers_handbook 

 

First, there are several options for traffic forwarding. I guess you can use iptables but personally, I hate messing with it.

I've used rinetd, socat, and Caddy reverse proxy. Reverse proxy is for specifically web traffic. rinetd and socat work for various protocols.

You could just forward traffic from VPS to your honeypot machine directly but it might be better to do it in a virtual network. You can make a virtual network by using openvpn, wireguard or use easier tools like zerotier, tailscale, etc.

In the blog post I mentioned earlier, I did the following:

VPS, my honeypot software (inetsim), and log server are on the same network using Zerotier.

VPS run suricata for analyzing network traffic and ship data to logging server.

Rinetd forwards incoming traffic to one single inetsim server. (keep fingerprinting in mind, if you do this. Depending on what you're running, someone can figure out that all these VPS just point to the same thing)

 

This is another way:

VPS and rinet traffic forwarder box(proxmox) are connected via Zerotier

VPS runs rinetd which forwards traffic to rinetd box running in proxmox which forwards traffic to honeypot machine on isolated network.

honeypot machine and rinetd running on proxmox send the logs to logging server.

The benefit is, there is one place where i can run suricata and collect all the traffic. This is also somewhat easy to manage. You can just keep editing rinetd config and forward traffic where ever you need.

Problem with this is, if wordpress gets popped, the attacker can't get out to the internet but can start attacking other machines. You may have to do some hardening and firewall config to prevent this. 

 

You can also do something like this:

Each VPS runs rinetd to forward traffic.

Each VPS and proxmox rinetd forwarder is on a different virtual network

Each honeypot machine is on a separate network.

honeypots send logs to rinet machine on promxox and it forwards logs to log storage server.

Obviously this gets very complicated and annoying to manage.  

 

 

At this point, I wanna say check out Greynoise Swarm: https://www.greynoise.io/project-swarm

I've been using Greynoise Swarm and I plan to use it more in the future. They essentially take care of all of this automatically. It's less risky. You deploy VPS and their sensor on it and use the webui to attach it to a profile/honeypot. At the time of writing, they do support you uploading a custom honeypot OVA or you can use raspberry pi and attach a physical device (vuln camera, router, etc) you have.

Hardening & Firewall: 

If you're using honeypot software that's vulnerable or you expect the software to get popped, you'll need to worry about several things. 

You don't want to be part of an attack. You don't want the threat actor to abuse your honeypot to DDoS people or use it as a proxy to brute force & login to corporate VPS servers and emails. You also don't want the attacker to do lateral movement and potentially compromise other things in your env.

You can maybe use hardened linux distros/images and run things in a container. Obviously, this doesn't prevent everything. We're just reducing the attack surface/making it harder for the attacker to do bad things. 

You can apply firewall rules to your honeypot to prevent outbound traffic but still allow inbound traffic to the vulnerable app. Just be aware that the attacker may pop a shell, escalate privs, and disable firewall rules. You also want to reduce attack surface by applying firewall rules on your traffic forwarder (like don't allow attacker to ssh into your machine thats doing traffic forwarding).

ufw example:

ufw enable
ufw default deny outgoing
ufw default deny incoming
ufw allow in ssh (add additional rules for your honeypot service) 

Proxmox and/or opnsense firewall may allow additional firewalling that's outside of the honeypot OS itself.

If you do have a webapp honeypot, there is another issue. The attacker technically could start abusing that to host phishing lures, credential phishing, or payloads. You may want to think about reverting VMs or docker containers once in a while.

 

At the end of the day, none of this is magic and it's just like how you'd manage other PCs in your environment, except you want these machines to get compromised and wanna collect the data.

 

Next post is about gathering network data because we want payloads!

Part 2: 

https://www.boredhackerblog.info/2026/08/honeypot-notes-part-2-network-data.html