Research, findings and other field notes…

At the time of writing, I’m 42 years old and the CTO of a small co-op in Alabama. I have been married to my best friend for almost 20 years and we have three incredible children. I am a Marine Corps Veteran (0311, E5) and have an associate degree from Valley Forge Military College in Wayne, PA. Currently I am enrolled in the SEC511 course of the BACS program through the SANS Technology Institute, as well as the SANS ISC Internship that is part of that program. Last year I was on the Dean’s List and hopefully, God willing, I will finally have my bachelor’s before the year is out. ...

Time and Date of Activity: Primary window: 2026-07-11 16:52 UTC through 2026-07-12 06:11 UTC (the web exploitation from .64 and the SSH loader session from .230). Related activity from the same /24 continued on 2026-07-14 with the .243 Mirai Telnet sweep. This observation is a cluster rather than a single host. Four IPs in one /24 (94.154.43.0/24) worked in concert to stand up a fresh Mirai-variant IoT botnet, which I am calling titanjr after its payload naming. Unlike the RedTail loader I wrote up previously, which uploaded its binaries over SFTP, this operation split the work across the block: 94.154.43.64 ran the web-facing exploitation, 94.154.43.230 handled SSH and pulled the payload set, 94.154.43.192 served the payloads from an open directory, and 94.154.43.243 ran a Mirai Telnet sweep two days later. What earns this the final observation is that the payloads were actually captured (real hashes, not the empty stubs I see on most sessions) and the campaign was brand new: every sample was first seen on VirusTotal on 2026-07-11, one day before my sensor caught them. ...

OSINT enrichment for the RedTail SSH campaign: per-indicator attribution of six hashes (four RedTail ELF variants plus loader/installer scripts), VirusTotal detection context, and a triage recommendation. Companion appendix to the third attack observation.

A SSH-2.0-Go actor at 130.12.180.51 brute forced HoneyPi, then ran a two-stage shell loader, implanted an authorized_keys entry for persistence, and dropped six architecture-specific RedTail payloads over SFTP. Same bundle seen from a second IP two weeks earlier points to shared tooling.

Standing up two FortiSwitches as an active-active MCLAG pair behind an HA FortiGate over FortiLink, including the firmware-skew and hidden mclag-icl CLI gotchas the official docs skip.

The full setup and configuration process behind HoneyPi was documented in the earlier parts of this series, so this post skips the build and goes straight to the first attack observation report I put together for my SANS Internet Storm Center internship. It focuses on a single attacker and walks it end to end. Initial Attack Observation Time and Date of Activity: 2026-06-15 00:00:07 UTC through 2026-06-17 02:11:21 UTC The attacker (source 87.251.64.176) was active for around 45 hours, with 114 successful logins occurring in bursts, indicating automated tooling running through a set of target IPs/hosts. Successful logins would occur in a burst, quiet down for a couple of hours then another burst. It should be noted that similar SSH-2.0-Go campaigns have been observed from other attackers since deployment of the HoneyPi, however this particular attacker was interesting because its attack pattern was persistent and observed from a single source, rather than cycling through different IPs like in other campaigns. ...

I wanted to post a sample of the AI-Generated reporting that I was able to achieve with only a little bit of tweaking to the prompts in the base script. The value add here for someone in my position with limited time and resources is incredible. My next implementation of this, will be internal focused on that Security Onion stack and the report will be directed at what I need to address daily on my internal assets. ...

The previous two posts got all three streams into Loki, unified by src_ip and joinable by Community ID. That’s a powerful dataset, but it has a problem: it’s enormous. A single day produces tens of thousands of Cowrie events, thousands of Suricata alerts, and thousands of Zeek records. Nobody is reading that by hand every morning. This post covers the layer that makes the whole thing usable, a Python script that pulls the day’s data, scores attackers by how interesting they are, and hands the most significant ones to Claude to write up as per-attacker narratives. ...

In the previous post I got two of the three streams live on the Pi: Cowrie and Suricata, both shipping to Loki through Alloy with a shared src_ip key. This post covers the Mac side, which is where the third stream comes in and where the whole correlation idea stops being a diagram and starts being something you can actually query. By the end of it, one attacker IP lights up across all three tools at once, and any single network flow can be matched between Suricata and Zeek deterministically rather than by eyeballing timestamps. ...

A quick preface before we get into the technical stuff. The next several sections are AI generated. I dumped my notes, config files, scripts and all the rest into a project in Claude, then prompted it through how I wanted the post compiled, linked and published. I have already had many nights of tinkering, troubleshooting and building a rather large note repository on this project, I didn’t want to take another week trying to type up, link and copy/paste code snippets in here. This is just much more efficient and I highly encourage it. Now, on to the juicy details! ...

Now we get into the part of the project that I have little to no experience in. While I have used the tools, I don’t have years of working knowledge and I have certainly never combined them in this way in an attempt to build a narrative around an attack. Thus enter my good buddy Claude to fill in the gaps. I knew what I wanted, but not how to get there. I have been in school with SANS for some time now and while I have learned an absolute ton, I don’t claim myself to be an expert in anything. Since this is my first experience setting up a honeypot like this, I started reading about different ways to parse the data… and man there are a lot of them. I decided that while I could follow a write up of someone that had come before me to the letter and have a working solution in no time, I would probably learn more by explaining what I wanted to AI and having it coach me through the process. ...

Next came the network. For the deployment of the device I chose the office. I am at work more than I am at home and it also offers a lot more in terms of security and configurability. This will likely remain after the internship so that I can continue to play with it. Also, it can’t hurt to have something sitting in our block that looks like a juicy target. It’s a long shot but if someone scans our block and sees this maybe they will waste time here instead of on my actual assets. ...

Finally found a cool use for the old Pi 4 I bought years ago. I bought it just because I have a need to collect all things technical in nature. The SANS ISC internship is giving me the perfect opportunity to put it to use! Since it had been years I decided on a fresh install of the OS. I downloaded the latest Raspberry Pi Imager and followed the simple steps to creating a bootable microSD for my soon to be Honey Pi (yes a perfect name… you can hold your applause). I highly recommend during this process to setup the Raspberry Pi Connect as it helped me get to the thing remotely when I made a mistake on the networking side later on in the setup. Also, the imager will give you an option to go ahead and load your SSH Keys, I would do this as well since it makes connecting via SSH that much easier later on. ...