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
