The campaign kept working while the SSH fingerprint changed
Across the observed window in April 2026, the cluster kept doing the same dull set of things: writing a fixed authorized_keys persistence key, running the split command variant, and pushing through the same recon, password change, competitor cleanup, and chattr disarm steps. The output changed in the SSH handshake, not in the useful part of the attack.
That matters because the handshake is often what IDS pipelines see first. If the client banner and algorithm list shift, the hassh changes with it. The behaviour after login does not need to move very far for a live campaign to end up outside a rule set built around an older fingerprint.
Why older hassh-based rules stopped matching
The April cluster advertised SSH-2.0-libssh_0.11.1 and produced hassh 03a80b21afa810682a776a7d42e5e6fb. Earlier activity from the same campaign had been tied to libssh-0.6.0, libssh-0.6.3, libssh_0.9.5, and libssh_0.9.6, each with their own hassh values. If detection logic pins the rule to one of the older hashes, current activity walks straight past it.
libssh version changes the client banner and algorithm list
The banner is not the whole story, but it does reflect the client version. libssh updates can alter default algorithm preferences, which changes the hash generated from the handshake. That is enough to break a rule that treats hassh as a stable identifier instead of a versioned fingerprint.
The awkward bit is that the campaign is still the same campaign. It is just using a newer library build. A signature that only knows the old handshake ends up detecting yesterday’s copy and missing today’s.
Stable post-auth behaviour still leaves a clear trail
Once the login lands, the cluster behaves in a way that is much easier to recognise than the handshake. It writes the same persistence key, touches /root/.ssh/authorized_keys, runs /tmp/secure.sh, changes passwords with chpasswd, and uses chattr -ia .ssh or the split variant with lockr -ia .ssh. That post-auth trail is much harder to hide than a changed client library.
For detection, that gives a cleaner anchor than hassh alone. A handshake match is useful, but the chain of actions after authentication is where the campaign leaves the real mess behind.
Build detections that survive signature drift
A single indicator will drift. A single rule will go stale. IDS signatures need to sit beside host-level events and command sequences, not replace them. The useful pattern here is the combination of a suspicious SSH client fingerprint, writes to authorized_keys, and the command burst that follows.
Correlate hassh with authorised_keys writes and command sequences
Hassh is strongest when it acts as a join key, not a lone alert. Pair it with writes to authorized_keys, fixed comment strings, and the post-login commands that the cluster keeps reusing. On a Cowrie sensor, that kind of correlation gives a much better picture of what is happening than any one signal on its own.
A practical rule can look for:
- a known hassh or libssh banner
- a write to an existing
authorized_keysfile - command sequences that include
chpasswd,chattr -ia .ssh, or a split disarm pattern - repeated access to the same compromise path rather than a one-off login
That catches the behaviour even when the handshake moves. It also cuts down on the usual swamp of harmless SSH noise.
Refresh IDS signatures, YARA rules, and IOC updates together
If the fingerprint changes, the rest of the detection content should not stay frozen in time. IDS signatures, YARA rules, and IOC updates need to move together, or one layer keeps believing an old version of the threat.
The point is not to chase every new hash as if it were a trophy. The point is to keep the rule chain aligned with the current campaign state. A stale hassh plus fresh host indicators still misses the attack. Fresh hassh plus stale IOC lists misses it in a different way. Both need the same update cycle.
Keep SSH monitoring useful in the real world
Per-source-IP throttling can look comforting and still do very little. The cluster spread short bursts across many IPs, so controls like fail2ban or sshguard never saw enough attempts from one address to matter. That is a neat way to make rate limits feel decorative.
For SSH monitoring to stay useful, watch the session pattern, not just the login count. In the April cluster, the sensor saw 24 unique source IPs, 229 authorized_keys modifications, 1,230 SSH sessions, and 4,133 post-authentication commands. That is not random background churn. It is a repeated operational pattern, and it is far easier to detect when the pipeline keeps the handshake, file write, and command trail in the same view.
