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).