This threat analysis concerns the mdrfckr SSH malware campaign, tracked since 2018, which persists by writing a stable authorized_keys file (SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2) to compromised systems. The campaign uses a known credential dictionary and a sequence of post-authentication commands including defensive disarm and competitor cleanup. In April 2026, a sensor observed a cluster of 24 IPs using a new libssh client version 0.11.1, generating a new hassh fingerprint (03a80b21afa810682a776a7d42e5e6fb) not previously documented. This new fingerprint differs from those observed in 2022 and 2023, indicating the campaign's client tooling is evolving. Detection rules based on older hassh values will miss this new variant, though the authorized_keys file hash remains a reliable indicator. The campaign's coordinated login attempts occur in short bursts from multiple IPs, evading per-IP rate limiting. The campaign infrastructure appears stable, with the client library version advancing roughly every few years.

The campaign enables persistent unauthorized SSH access to compromised systems by writing a known authorized_keys file, allowing attackers to maintain access and execute commands. The evolution of the SSH client library used by the campaign means that detection systems relying on older client fingerprints may fail to detect current activity, potentially allowing continued undetected access. The coordinated nature of the attacks and use of common credential pairs increases the risk of successful compromise. However, the campaign's core indicators have remained stable, providing reliable detection points if properly updated.

Detection and response teams should update SSH client fingerprint (hassh) based detection rules to include the new fingerprint 03a80b21afa810682a776a7d42e5e6fb associated with libssh 0.11.1 to detect this campaign variant. Reliance on the stable authorized_keys file SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 remains effective and should be prioritized. Alerting should aggregate login attempts by target account rather than by source IP to detect coordinated bursts. No patch or vendor fix applies as this is a malware campaign exploiting SSH access; mitigation focuses on detection and blocking. Operators should monitor for the known credential dictionary and the documented post-authentication command sequences. Collaboration with sensor networks like DShield and ISC handlers is encouraged to track evolving fingerprints.