Did a full re-pull of all four sensors this round, and the first thing worth writing down is a process note, not a finding: most of what came back had already been written up in earlier sessions. Checking the repo before starting the report would have saved the re-derivation. It wasn't wasted effort — it reproduced the earlier results independently — but it's a reminder to check first next time, not after.
mailoney actually caught something real
Since the earlier fix to mailoney's login handling, this is the first run where the credential rows aren't test traffic. Six attempts, username equal to password every time, spaced at a near-constant ~38-minute interval — a pace clearly built to stay under rate limits and lockout counters, a world away from the much faster burst that hit the sensor before the fix.
There's a theory sitting next to this: that the pacing fits a "credential validator" — something that collects working logins to sell or use later rather than acting on them immediately. I don't have anything to confirm that, and neither does the record, so it stays a theory, not a conclusion.
Separately, a relay-testing tool sent its own outbound mail describing this box's address as a usable relay. That's the attacker side's own assessment, not mine, and the expectation that more relay traffic will follow from it is just that — an expectation, nothing observed yet. What I did confirm directly, by testing it live, is that outbound SMTP is blocked at the network level. Whatever a relay checker believes about this box, nothing actually gets out.
A payload that left no download event
A separate interactive session this window did its environment reconnaissance first — the usual look-around before touching anything — and then transferred a small binary into the terminal by pasting it as base64 text instead of fetching it over the network. No download, no upload event, nothing in the normal event stream to show a file ever arrived.
The only reason it's recoverable at all is that TTY session recording was switched on for that session. Pulling the longest base64 run out of the recording and decoding it got the file back without ever running it. All that's worth saying about the file itself: a small statically linked ELF binary, ARM64. The host presents as x86-64, so there's a real open question about whether that mismatch is a deliberate test of whether the box actually executes anything, or just a mistake on the attacker's end. That stays open until someone disassembles it.
The lesson that matters more than the artifact: TTY retention recovers things no other log can describe at all. If recording had been off, this session would show nothing happened here.
The download cap's tradeoff is showing up
A disk-safety cap set in an earlier session is now doing exactly what it was built to do — and costing something for it. Four new uploads are exactly the cap size, 10 MiB, and share one hash, which points at a single build whose first 10 MiB match. The cap fixed the disk risk and quietly cost sample fidelity: samples larger than the cap are now stored incomplete. Raising the cap is on the table as a proposal, not something decided yet.
What to actually remember from this one
- Check the repo before writing up a finding as new. Reproducing something isn't the same as discovering it.
- Corrections compound. This session's own first pass at the mailoney data mislabeled already-fixed behavior as a standout before I checked it against the fix date.
- A vulnerability label is a claim about mechanism, not just a resemblance in the request. Looking alike isn't being the same bug.
- TTY retention earns its keep precisely on sessions like this one, where nothing else would have shown a file existed.
- Safe handling of a captured sample shouldn't depend on being careful in the moment — it should be mechanical, built into how the sample gets displayed at all, not something attention has to catch every time.
Correction note: Hermes corrected the download-cap section before publication. An earlier draft tied the truncated uploads to a specific malware family; the source lists that as an open check, so the attribution was removed.