Two things came out of this session and they pull in opposite directions. I want them in the same note so I don't end up remembering only the flattering one: a visitor whose uploaded file I can finally call confirmed benign, and two sessions I had flagged as possible sophisticated human attackers that were actually people trying to fix a server they believed was theirs.
The filter, rebuilt twice
The first version matched on raw command vocabulary (cat, nano, cd) plus a list of common greetings. Too chatty, and two problems showed up right away.
Command found: and CMD: both log the same action, so every match printed twice and I was reading a log that counted one action as two. And the filter walked straight past a genuinely human greeting, because the greeting list was too narrow.
The second version scoped to CMD: only, one line per action, and widened the greetings to how people actually type on a phone: hi, ih, hii, hey, yo. The arrangement I settled on is three terminal windows instead of one clever filter — raw tail -f, a broad "interesting events" filter for downloads, uploads and crashes, and the human-hunter filter. Three narrow views beat one filter that tries to do everything, and that conclusion took me longer to reach than it should have.
Command vocabulary is not identity
This is the line I keep having to relearn: botnet scripts run cat, cd and ls too. The filter shortens a large log down to candidates worth reading. It is never the verdict.
Each candidate then gets read by hand against the intent-shaped-behavior framing from the log-analysis training — persistence, payload delivery, exfiltration-shaped reads, scale. What comes out is a confirmed list per side rather than a guess.
On the human side: explicit human context stated in-session; arrivals from a public thread that was testing a leaked address, which carries a caveat further down; and exploratory, non-destructive commands — a nano edit on a decoy file, a poke into a cloud-credentials config directory out of curiosity rather than harvesting it at scale.
On the bot side: high-volume Telnet traffic looping the Mirai enable → shell → busybox sequence; a key-planting sequence plus a heavier SSH loader variant from a second bot; and a cryptomining recon bot running hardware-profiling commands at scale, the same actor this log had already flagged in an earlier session.
The one capture that closed completely
One visitor produced the most thoroughly corroborated human capture of the project so far, with behavior and forensics pointing the same way.
First session: real terminal negotiation, then a greeting that explicitly mentioned being on a phone, a read of the honeytoken CSV, general directory poking, and a bare apt before an idle timeout. No persistence, no payload — the same shape as every other human-attributed session.
A later session from the same visitor opened the SFTP subsystem rather than a shell, and genuinely uploaded a file: a short MP4, about 1 MB, named in the pattern mobile screen-recorder apps use.
The forensic pass was hash-first and never executed or opened the file directly. Size and a magic-byte check (head -c 32 | xxd) confirmed a real MP4 container rather than a renamed executable. The SHA256 came back clean against a public multi-vendor scanning service, zero vendor flags. Only after every check passed did the file get pulled to an isolated machine and played, and it was exactly what it claimed to be: a short kitten video.
That is the reference example of what a fully closed loop looks like, and it is one case. Most other human-traffic entries are well argued but still inferential, and I don't want to flatten that difference in my own head.
Texture from the rest of the session
The honeypot's exploit detector fired on a live attempt and logged it as a specific CVE: protocol Telnet, the event id for a Telnet exploit attempt, and CVE-2026-24061. The traffic carried the Telnet negotiation sequence associated with that CVE, then a crafted USER=-f root string. That read as a named vulnerability being probed, not a generic credential guess. No shell followed, so it was a probe rather than a completed chain; what the detector contributed was recognising and logging that specific CVE.
Downloads got filtered by size, on the working rule that anything under roughly 10 KB is usually a marker or a failed grab rather than a real payload. The rest got catalogued: several architecture-specific Mirai-family ELF binaries (ARM, MIPS, i386), a few dropper shell scripts, an OpenSSH keypair captured as part of a bot's own persistence attempt, and the cryptominer sample confirmed earlier. Every file gets hashed and checked and never executed — the standing rule from day one of the build.
The near-miss in the middle
The honeypot's public address had been posted in a public forum thread by someone asking for help logging into what they believed was their own broken server, with their own attempted login pasted into the comments. For some window of time, part of the inbound traffic was curious readers of that thread testing the address rather than attackers.
Two sessions I had initially flagged as possible sophisticated human attackers got re-attributed after review. The tells: typing dir out of Windows muscle memory and then correcting to ls, and checking whether apt update worked, as if troubleshooting their own box. That is someone trying to fix a server they think is theirs, not tradecraft.
Treating that curiosity as attacker behavior would have been a real attribution error, and what caught it was paying attention to the shape of the commands instead of counting them as "interactive activity."
What I want to remember
A filter is a triage tool, not a verdict, and attribution still means reading the session. Check the event type before counting anything, or the same action gets logged twice and I reason from a number that isn't real. Publicity changes the traffic mix, and conflating curiosity with attack is a real analytical error rather than a harmless one. When I want to call something confirmed benign, I need behavioral and forensic evidence pointing the same way — human context plus an independently verified, clean file is a much stronger claim than either half alone.
The two sessions that looked like sophistication were people trying to fix their own box. That's the one I'd rather not repeat.