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 

Doing malware research without spending money

Just doing a quick write up of tools I use to do malware/threat research for free. Most of the time, I don't really have any company directly backing the research/analysis stuff I put on this blog. I'm also not a professional malware analyst/threat researcher, for what its worth.

(I wrote this myself. No AI was used)

 

I do recommend these courses if your employer pays:

https://paralus.co/online/ - Applied Threat Intelligence/Operational Threat Intelligence - I've done this course and it goes over handling IOCs, pivoting, and more.

https://academy.intel-ops.io/courses/hunting-adversary-infra - Hunting Adversary Infrastructure - I haven't done this course but I've seen the authors work on Twitter and Medium and it was interesting.

 

Regarding articles and finding things to research:

Hunt.io blog (https://hunt.io/blog) and Censys Arc blog (https://censys.com/censys-arc/)  have info about interesting things they've come across.

I also use this: https://start.me/p/wMrA5z/cyber-threat-intelligence which has links to various other sites/blogs.

You can always come up with your own ideas based on what you see or what you think you should see in an attack.

 

There are a bunch of tools in start.me link but I'm just focusing on things I use.

There is obviously VirusTotal. 

You can search hashes, domains, IPs, and etc and do limited pivoting off of it or move to other tools.

For files, the Details tab provides binary info which may include things like pdb path, certificate info, imphash, etc that you can pivot from (using other tools) or search on Google.

Relations tab will let you find related domains/IPs/files, etc which may lead to additional files. In some cases, this will provide in-the-wild URL where this file was downloaded from.

Behavior tab has sandbox results which again may help find additional IOCs which may lead to more files. You may see yara/sigma/suricata rules in here as well that may help with pivoting.

 

VirusTotal free does not let you download files.

If you actually want files, you may be able to use AnyRun, Hybrid-Analysis, Triage, VXUG, and Abuse.ch to acquire files.  You may also be able to ask for files in certain Slack and Discord channels. Make friends!

 

AnyRun, Hybrid-Analysis, and Triage also support basic searches like hashes, IP's, and domains. 

You can also obtain pcaps, memory dumps, dropped files, and other behavior data from these products.

These tools may report suricata/snort signatures. You can view sigs on Evebox: https://rules.evebox.org/

Hybrid-Analysis researcher account also supports searching yara signatures/string searches to find files. 

AnyRun Intelligence (https://intelligence.any.run) lets you also do complex behavior searches like if you wanted to search for a family that specifically writes a file to one very specific location or uses a very specific command. They also let you do yara searches. 

 

Abuse.ch provides multiple products that may be useful for tracking malware campaigns. 

Malware Bazaar has files. You can pivot off of various fields too.

 

Feodo Tracker has C2 info. This could be useful if you wanna monitor C2 with emulated malware or use C2 info to do more pivoting.

URLhaus has URLs for malware. 

YARAify lets you do yara scans on files but besides that, you can search files that have matched yara rules. 

Malware Bazaar, URLhaus, Yaraify all give you options to get notified based on various things such as yara match,  URL match, etc... It's under Hunting Alerts option. 

URLScan is another tool I use. I think a lot of people use this but never use the filtering options. Free account has limits obviously. You can see filters here: https://docs.urlscan.io/pages/search-api-reference#searchable-fields 

 

 

For IP's/infra, you can use Shodan, Censys, and other tools (listed in start.me link). 

Shodan and Censys both let you pivot off of certain fields, such as favicon hash, content hash, cert info, html page title, etc.. 

 

You can utilize Greynoise and AbuseIPDB for IPs. You just have to make sure you look at timestamp for events you see. Threat actors can just use a VPS for an hour then get a new one and have a completely different IP. 

 

Finally,  Github search and other tools that search github are very useful. These two exist beside just GH search feature:

Sourcegraph - https://sourcegraph.com/search

Grep App - https://grep.app/ 

You can search Github for certain strings/variables names or commands you may see during your analysis. You may discover analysis from other people or maybe source code.

REDCap exploitation in 2023

Intro

I saw Google Threat Intelligence teams article regarding REDCap exploitation here: Public and Private Medical Community Targeted by China-Nexus Threat Actor Pursuing Artificial Intelligence, Cyber, Medical, and National Defense Research - https://cloud.google.com/blog/topics/threat-intelligence/prc-targets-us-medical-research

"The earliest known compromise occurred in September 2023, after which GTIG observed a consistent operational pattern. The threat actor exploited externally facing REDCap (Research Electronic Data Capture) servers and deployed custom malware named INFINITERED to capture legitimate REDCap login credentials. " -from the article

They also said the following: "GTIG was not able to confirm how UNC6508 initially gained access to the REDCap server. " 

This article caught my attention because I (technically, Crowdstrike generated the alert) saw REDCap getting exploited in 2023 as well but it was different and I never got closure on how it was exploited. I did a ton of searching online and read patch notes but never figured out how the exploitation may have happened. 

The exploitation I saw was a bit different than what Google Threat Intelligence group saw. I'm posting this to share what I saw. 

 

Activity seen

This activity was observed in September 2023. 

Crowdstrike alerted on Apache process spawning some bash commands.

Apache server was hosting REDCap app. I'm unsure about the version. 

One of the commands was for doing bash reverse shell via bash -i >& /dev/tcp technique. 

Searching the rev shell destination IP shows a report by Fortinet regarding the IP exploiting TeamCity vuln in 2023 and actor potentially being APT29. (just mentioning what I saw. I'm not doing attribution. I also know what Pyramid of Pain is as well.)

There was another command that was executed. It was sh -c echo BASE64 | base64 -d | tee DIRECTORY/update.php

This wrote a basic php shell to disk, which took GET request w/ "update_process" AND "cmd" parameters and executed commands via system().

(I kept watching VirusTotal for the file hash and content expecting some web admin to find the file and upload it but I have not seen this file get uploaded. Could be because its easy to read and see its just a simple webshell)

 

Log review did not show any commands in URI's or provide clear info on how this exploitation could've happened. 

This may have been done via POST request, though some cookie values or headers, abuse of existing compromise, or some other way. I have no idea. The software isn't open source so there isn't anything I could've done further to research how the compromise happened. 

In 2024, assuming that the threat actor exploited more REDCap instances the same way, I did some research. I did find multiple (maybe about 50) compromised REDCap instances, all over the world. There were various REDCap versions seen being hosted on various servers (apache, nginx, etc..). It's always possible that an older version was exploited then the victim updated and I saw compromised server with different version.

Conclusion

Maybe check for file update.php w/ content  "update_process" AND "cmd" on your redcap server or check web traffic logs for URI containing update.php AND update_process AND cmd? I'd hope the file was detected and cleaned up by now since this happened in 2023.

I'd love to know more details about how the initial exploitation happened and what the attackers actually did afterwards.

At the end of the day, I'm just a soc analyst with limited telemetry and there is always another alert in the queue that needs to be worked... :( 

 

How Unifi OS exploitation may have happened

Note: if images or formatting is broken, blame Blogger. 

Jun 5 EDIT: I found Bishop Fox post today regarding this (them doing patch reversing and finding a way to get revshell is pretty cool!): https://bishopfox.com/blog/popping-root-on-unifi-os-server-unauthenticated-rce-chain-detection-analysis

Also here's my poc script if anyone wanted to try doing this the way i did: https://gist.github.com/BoredHackerBlog/b2ba31f7ab6a5b2f3eb619f7b44eb2c5 

/EDIT 

Jun 6 EDIT: after reading through the Bishop Fox post, I figured out how to get unauth command exec. 

(obviously, original vuln reporters mentioned in advisory and bishop fox researcher did all of the hard work) 

 

This whole thing was fun but I think I'm done now. 

/EDIT

 

 (from discord)

 

What's going on?

Last week when I was on break doing training, I saw a reddit post regarding someones Unifi having an account added. Someone got admin user "John Sim" added & removed to/from their device.

In the replies, there were other people saying that this happened to them as well. I was going to look into this and maybe even set up a honeypot but I didn't have time.

 

Post: https://www.reddit.com/r/Ubiquiti/comments/1tnygst/super_admin_added_whilst_on_holiday/

 

Today I saw another post regarding this activity (post is like a week old but i saw it today)

This new post had URI info for the attack. I'm not sure if it's all the URLs in their logs though. 

 

Post: https://www.reddit.com/r/Ubiquiti/comments/1tp9san/aidriven_campaign_appears_to_be_targeting/

 

Unifi Post about multiple vulnerabilities: https://community.ui.com/releases/Security-Advisory-Bulletin-064-064/84811c09-4cf4-42ab-bd61-cc994445963b

For affected products, it says: UniFi OS Server (Version 5.0.6 and earlier)

 

The setup

I actually didn't find 5.0.6 version for UDR7 and I didn't want to go lower. I just had reset and rebuilt my whole network.

I found Unifi OS for Windows with version 5.0.6 and installation was easy so I went with that.

Download page: https://ui.com/download/software/unifi-os-server

This is what I installed: UniFi OS Server 5.0.6 for Windows (x64)

So I have Unifi OS 5.0.6 running for testing and I have my UDR7 with latest updates and SSH access (this comes in handy later).

Research 

skip to exploitation section at the bottom if you don't care about my methodology & extra commentary 

 

I believe I'm looking at CVE-2026-34909: "A malicious actor with access to the network could exploit a Path Traversal vulnerability found in UniFi OS devices to access files on the underlying system that could be manipulated to access an underlying account." (source: Unifi Advisory) 

 

I started by going to /proxy/users/public/avatar/x?filename=../../../../data/unifi-core/config/jwt.yaml

This gets me the JWT secret.  

 

 Next I logged into Unifi OS to see what the auth activity looks like and there is JWT token!

 

 JWT.io was used for decoding. Decoded data looks like this:

 

The next URI in reddit post is /api/auth/validate-sso/../../../proxy/users/api/v2/identity/user/owner/credential where the attacker gets 200 response. 

I visited the URL and did not get 200. 

 

At this point, I started modifying the JWT token. 

I noticed that jti and csrfToken fields didn't matter. exp field can be anything in the future. it's epoch timestamp. userId needed to be correct and same with passwordRevision. 

I crafted a new JWT token and tried it against validate-sso URI and it worked! 

 

 

Now I'm wondering how did the threat actor get legitimate userId and passwordRevision data?

The reddit post didn't mention anything else.

I ssh'ed into my UDR7 and went to the directory where the jwt.yaml file came from and started looking for passwordRevision and userid.

I found out that there is a json file that contains passwordRevision. unique_id that you see is the userId. 

 

 

I sent a request to /proxy/users/public/avatar/x?filename=../../../../data/unifi-core/config/cache/users.json. This is the second use of that traversal vuln, without auth token. 

This gets us everything we need. With jwt secret and this data, we can craft the correct token.  

 

 

What about adding users?

This is what legitimate user addition request looks like:

 

Can we add users with JWT token we crafted?

 Yes! Just make sure that the CSRF token in your request matches the token in your JWT token.

 

 

  

 Exploitation

 Here's what the process looks like from the testing I've done.

1. Request jwt.yaml

extract secret 

2. Request users.json

extract unique_id and password_revision for admin

3. Create valid JWT token

4. Use token and send request to validate-sso/credential URI and check for 200!

 

 

 

 

End

I'm not exactly sure if this is the exact method the threat actor was using. I don't have a honeypot. I don't have logs/forensic data either. I don't know of anyone that can go replicate this for me either. 

The Ubiquiti Security Advisory shows multiple vulns so there might be more things going on. 

I'm not sure about how many people have vuln Unifi OS and have it exposed to the internet. Obviously, people on reddit who got compromised did but I feel like there shouldn't be too many vulnerable setups out there but who knows. 

Someone (not me) should probably make a nuclei template for this.

 

Thanks to https://github.com/InfosecExtra for bouncing around ideas. 

 

Use of MQTT in malware part 2: quick analysis

link to part 1:  https://www.boredhackerblog.info/2026/06/use-of-mqtt-in-malware.html

 

Note: I've had limited time to work on this. I took some time off to finish some training but wanted to finish this project as well since it's been sitting on my todo list for months. 

I'm not a professional malware analyst or threat intel person. I'm not super confident in my analysis. I also have a limited set of tools, services, and time. 

If text formatting/spacing sucks or you can't see images, it's Bloggers fault.  

 

Analysis 

I'm labeling by hashes. You should be able to copy them to VT, Triage, Hybrid-Analysis, and Anyrun to find sandbox reports, pcaps, etc... 

 

Python samples

There were multiple Python samples found. Also I kinda went for these samples because they would be relatively easy to analyze and some of them exhibited malicious behavior when looking at VT & sandbox results.

05d9f87cc1bc5272d37a0da8d8bb5a5732760c13f7745395ef388951ee3963ad

I'm guessing this was someone doing POC or testing because they had named their app trojan.py

 

They added persistence capability with startup. 

The analysis also shows screenshot ability, for Windows and Linux systems. 

 

 This sample also does IP info gathering, which might actually be an interesting behavior to look for when searching sandbox results containing broker traffic. Bunch of malware does similar with various IP lookup sites.

 

ae0b5e6dd44ecce8bdc6e71c32f007011d9dd991540e7bbf3831c72f894f0325

Another Python sample. This one also does persistence the same way, using Startup folder.

 

C2 setup

 

Command execution ability

 

It also seems to have ability to open URL and go through files. 

 

71071750fa9c9e1d9305bbb9a1f1ed75ee86bf42c0d25c12def512aae3d8b097

This sample actually used TLS/SSL communication with the broker. This sample was also very simple, well besides encryption & encoding.  

0551b908ae6233a709107c5a787f47206ed174d01ce937cee7975c969fa1b23e

This sample was actually manipulating Defender, setting up persistence, and hiding itself.  

 

 

The sample apparently can run on linux as well.

 

 

FCTRL/secure is used for communication

 

 5e69317295f1c6bf0a545261d6a814cf77c0132dacbe340cb1e605ab49436c15

 This is another sample that seems to do a lot of odd things.

Scheduled task is used for persistence 

 

Recovery settings are changed.

 

 There are various commands/abilities that you're provided

 

pctrtl topic is used in this case.

 

07e4e006a2c76fd19143d95af25d22dfc65d971f4a63db0d06e751ad4ce20d22

Final Python sample. This one also had various abilities, like screenshot, persistence, keylogger, etc.. 

There are actually multiple samples I came across that used the topic/shared key shown in this sample.

Persistence

 

 

keylogging 

 

Commands/abilities

 

 

Golang samples

I found three samples that were similar and they are being detected by AV but I don't think I've seen any write ups when I was searching for some of the function names. 

There were probably the most interesting samples I saw. The issue is, I'm not sure how prevalent these are, how they're spreading, and who's using them and for what. 

486aab85f1445776580ae854c25be52198e7e120d454daa14ce8e54bddb1326d

ffd9273d8de6b9ba66adc5a2acff0761061cdb89e1d0f4ca972b86ed004b23af

b3c1b4c66b99f970c892770ad64899ddd625cfa99707d7e3b351793d3048e30c

Communication seems to be done with /commands/ topic.  

 

 File path artifacts for .go files

 

 

 

 There are multiple commands and abilities but one of those that stood out is ability to install AnyDesk

 

 

Here are some other abilities/commands but I didn't really dive deeper into them. They're self-explanatory.  

 

 

 

Others 

ea78ccfbe0b8e91ffa8eec30f79192b0dc89c3434775914ccc575705146e59e9

This sample was interesting. File was UPX packed. (technically golang) It seems to be doing some SQL testing. This was one of the samples I didn't fully analyze.

Besides the broker, this also connects to netlify.  spiffy-crepe-c667e8[.]netlify[.]app. VT has a comment for this domain: "NKNShell Malware Distributed via VPN Website" - https://asec.ahnlab.com/en/91139/

This malware uses NKN protocol (https://nkn.org/) as well. 

Tools used

I used Ghidra, Wireshark, and MQTTExplorer. Triage and Hybrid-analysis both provide sandbox results and pcaps, memory dumps, dropped files, etc... 

 

For Python-based samples specifically, I just used web-based tools (obviously be aware of what kinda data you're handling before uploading it to random sites...)

 

https://pyinstxtractor-web.netlify.app/

https://pylingual.io/ 

https://www.decompiler.com/python

 

 

 

End

 

There are things I would do differently if I had more time and resources. Doing complex queries on VT Enterprise or sandbox data would be one of the things. Broker connection + other weird behavior would find interesting things to look at.  

 

The other I'd love to do is monitor broker for C2 traffic but I mainly avoid that to avoid dealing with cryptography/math and I'm not sure if I'd see much anyway.  

 

I also didn't look for any ELF files or standalone scripts. I think those might be interesting, especially scripts if you can look for specific imports.

This was fun to look into for a bit but there are other more important security issues going on, obviously. 

 

Shoutouts

 

Thanks to Hybrid-Analysis/Crowdstrike and RecordedFuture/Hatching Triage for researcher accounts! <3