Introduction

The SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 is one of the most-observed Outlaw / Shellbot artifacts on the public internet. VirusTotal first ingested it on 5 July 2018 [2]. It is the SHA-256 of the authorized_keys file written by the campaign whose persistence comment string is mdrfckr, a campaign documented in handler diaries, vendor reports, and independent honeypot research for nearly seven years.

This diary does not announce a new campaign. The file hash, the public key, the mdrfckr comment string, the chattr -ia .ssh defensive disarm, the chpasswd account hijack, and the /tmp/secure.sh competitor cleanup are all well-described in prior reporting [3][4][5][6][7]. What this diary does add is one new data point in an existing lineage: between 14 and 21 April 2026, my DShield sensor [8] observed the mdrfckr campaign using a third libssh client version that has not, to my knowledge, been published as part of this campaign’s hassh chronology. The botnet’s authorized_keys file is unchanged across four years. Its SSH client library is on its third documented major version. Detection rules pinned to the older hasshes will miss the current generation.

The point of this diary is to put the prior reports side by side with my April 2026 observation, document the new hassh, and offer detection-engineering guidance for handlers maintaining mdrfckr-aware rules.

What is already known

I want to be careful to credit the prior work this diary builds on, because the new contribution is small relative to it.

The mdrfckr persistence key was first associated with the Outlaw / Dota family by Trend Micro in 2018 [3], with subsequent updates in 2019 and follow-up reporting from Anomali, Yoroi [9], Juniper [10], CounterCraft [11], Cybereason, and Kaspersky. The recon command sequence and the competitor-cleanup playbook are described across that body of work. None of the file or behaviour signatures discussed in this diary are novel.

In late 2022 and early 2023, the port22.dk blog [4][7] published a two-part deep dive on the campaign. Part one (data from October–November 2022) observed 12,913 unique IPs writing the mdrfckr key from a network of 10 honeypots. Crucially, the post introduced hassh-based clustering as a defender’s tool: 99.1% of the observed mdrfckr-key writes shared the hassh 51cba57125523ce4b9db67714a90bf6e, which corresponds to the SSH client banner SSH-2.0-libssh-0.6.0 / SSH-2.0-libssh-0.6.3. Part two (data from December 2022 onward) documented the campaign migrating to a second hassh f555226df1963d1d3c09daf865abdc9a, corresponding to SSH-2.0-libssh_0.9.5 / SSH-2.0-libssh_0.9.6, with ~30,000 unique IPs across the new fingerprint and a 94.5% confidence link. Part two also documented two new related command variants: chattr -ia .ssh; lockr -ia .ssh as a separate command, and lockr -ia .ssh run on its own, executed alongside the original key-write command.

In May 2023, a SANS ISC diary by Jesse La Grew [5] presented two example sessions writing the same SHA-256, captured via a cowrie-log enrichment script. One session originated from a DigitalOcean datacentre IP; the other from a VPN-fronted Tencent IP. Both sessions executed the post-December-2022 split-command variant.

In May / June 2023, Guy Bruneau’s monthly DShield diary [6] noted the same key-write playbook in honeypot data and attributed it explicitly to the Outlaw group via the original Trend Micro reporting.

That is the public chronology this observation extends.

What the April 2026 sensor saw

Between 2026-04-14 01:23:41 UTC and 2026-04-21 02:22:56 UTC, my DShield sensor logged 24 unique source IPs writing the SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 to /root/.ssh/authorized_keys (and to other compromised account paths). The cluster wrote 229 authorized_keys modifications across 1,230 SSH sessions and executed 4,133 post-authentication commands.

The peak burst occurred on 19 April 2026: 20 of the 24 IPs first connected to the sensor between 06:05:19 UTC and 06:07:30 UTC, a 131-second window. The remaining four IPs appeared on neighbouring days but executed the same playbook with the same key.

The defensive-disarm and key-write command observed across every successful session is the post-December-2022 split variant documented by port22 part two:

The new data point is the SSH client.

The new hassh: libssh 0.11.x

Every one of the 24 IPs in the April 2026 cluster advertised the SSH client banner SSH-2.0-libssh_0.11.1 and produced the hassh fingerprint 03a80b21afa810682a776a7d42e5e6fb.

This hassh does not match the hashes documented in port22 parts one and two, nor in the May 2023 ISC diary.

A hassh is a hash of the SSH client’s advertised cipher, MAC, key-exchange, and compression algorithm lists [12]. Different libssh major versions ship with different default algorithm preferences, so each new libssh version a campaign adopts produces a new hassh. The 2026 hassh 03a80b21afa810682a776a7d42e5e6fb is the third documented entry in this campaign’s libssh version walk, separated from port22’s last published value by approximately three years and one major libssh version (0.9 → 0.10 → 0.11).

I do not have a baseline of how prevalent this hassh is across the full DShield sensor population – that is the question I would most like other handlers and DShield operators to help answer. On my single sensor, this hassh accounted for 3,473 SSH log lines across the eight-day window, making it the most active SSH attacker-tooling fingerprint observed during the period.

The 24-IP burst: small confirmation of an existing observation

Twenty of the 24 cluster IPs first connected within a 131-second window. This is consistent with the coordination behaviour documented at much larger scale by port22, and does not represent a new claim. I mention it only for completeness, and because it has one practical implication for detection: per-source-IP rate limits (fail2ban, sshguard) will not trigger on this pattern because each IP performs only ~10 login attempts. Detection rules useful against this campaign should aggregate by target account rather than by source IP – ten distinct IPs attempting steam:Steam29! against the same host within five minutes is a stronger signature than any individual IP’s behaviour.

The cluster IPs and the credential dictionary are listed in the indicators section. None of the credential pairs are new: steam:Steam29!, postgres:q1, dev:dev5, sammy:sammy26, root:AAAaaa111, root:root000@, sysadmin:test123, test1:passwd, tester:testerpass, sammy:12345. This is the existing Outlaw target list.

Why this matters for defenders

The detection-engineering implication of the libssh version walk is straightforward: hassh-based detection rules written in 2022 or 2023 against 51cba57125523ce4b9db67714a90bf6e or f555226df1963d1d3c09daf865abdc9a will silently miss the 2026 generation of the same campaign. The SHA-256 of the authorized_keys file remains the most reliable single indicator (it has not changed in four years), but operators relying on hassh enrichment as a leading indicator – for example, alerting on hassh values before a successful authentication occurs – should add 03a80b21afa810682a776a7d42e5e6fb to their watch lists.

More broadly, the four-year libssh version walk suggests the campaign operator (or operators – the persistence model has always been consistent with shared infrastructure rather than self-propagation in the strict sense) keeps the targeting infrastructure stable while letting the underlying client library age forward. A defender writing a detection rule against this campaign should expect the hassh to change again on a roughly multi-year cadence as libssh ships new defaults, and should pin alerting to the SHA-256, the public key blob, the mdrfckr comment string, and the recon command sequence – none of which have changed since 2018 – rather than to any single hassh value.

What I am not claiming

The 24-IP April 2026 cluster is much smaller than the populations port22 worked with. I cannot meaningfully extend port22’s hassh-confidence statistics from one sensor’s eight-day window. The 99.1% / 94.5% figures published in 2022 and 2023 should not be extrapolated to the 2026 hassh from this data alone – that calculation requires a multi-sensor population study, which is exactly the kind of analysis ISC handlers and the DShield operator community are positioned to do better than any of my sensors.

Indicators

• authorized_keys SHA-256 (unchanged since 2018): a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
• Public key comment string: mdrfckr
• April 2026 hassh: 03a80b21afa810682a776a7d42e5e6fb
• April 2026 SSH client banner: SSH-2.0-libssh_0.11.1
• Burst window: 19 April 2026, 06:05:19 → 06:07:30 UTC
• Credential dictionary: steam:Steam29!, postgres:q1, dev:dev5, sammy:sammy26, root:AAAaaa111, root:root000@, sysadmin:test123, test1:passwd, tester:testerpass, sammy:12345
• 24 source IPs from the April 2026 cluster (Appendix A)

Conclusion

The mdrfckr campaign is older than many of the SSH honeypots currently watching it. Its authorized_keys file is approaching its eighth anniversary on VirusTotal and has not been rotated. Its target dictionary, recon sequence, and competitor-cleanup playbook have all remained stable across the four years that public researchers have been tracking the libssh version walk. What changes is the client.

The April 2026 hassh 03a80b21afa810682a776a7d42e5e6fb joins 51cba57125523ce4b9db67714a90bf6e and f555226df1963d1d3c09daf865abdc9a as the third documented entry in this campaign’s lineage. Detection rules pinned to either earlier hassh will miss it. I would be very interested to hear from any other DShield operator or ISC handler who has independently observed the 0.11.x hassh writing the SHA-256 above – particularly with population data that would let the community update the hassh-to-mdrfckr confidence figures published by port22 in 2022 and 2023.

Acknowledgments

Drafting assistance from Claude (Anthropic) [13]. All log review, the hassh and SHA-256 verification, the credential and IP enumeration, and the comparison against prior reporting were done from the sensor’s own logs and the cited public sources.

References

Appendix A: Source IPs (24)