mdrfckr SSH Campaign Reaches Persistence 22 Seconds After Login

On May 23, 2026, an automated actor authenticated to a SANS Internet Storm Center honeypot at 01:06:43 UTC using the credentials root / Aa123123123. Twenty-two seconds later it had injected a backdoor SSH key into authorized_keys, changed the root password, cleared /etc/hosts.deny, and finished automated system reconnaissance. (Source: Isc)

That timeline is the operational problem. Twenty-two seconds is shorter than most alert pipelines take to correlate an authentication event, shorter than a five-minute log polling interval, and far shorter than the time an on-call engineer needs to open a ticket and read it. By the time a human sees the successful login, persistence already exists and the legitimate administrator password no longer works.

The behavior came from ISC intern Daryl Jiminez's Cowrie v2.3.0 sensor, a Raspberry Pi 5 on a residential connection listening on port 2222 behind external port 22. Over a 30-day window the sensor recorded more than 112,000 SSH sessions and 72,000+ authentication attempts from 175+ unique malicious source IPs.

On May 23 alone, the sensor logged 21 successful logins from 21 different source IPs, clustered between 01:00 and 02:30 UTC — wave-based scanning rather than isolated attempts.

This activity ties to the mdrfckr SSH campaign, a long-running automated SSH scanning operation documented by honeypot operators worldwide. Ninety-three IPs from published mdrfckr indicator lists were still hitting the sensor weeks after first being recorded. The primary actor IP, 163.7.8.79, resolves to Byteplus cloud infrastructure (AS150436) and carries over 5,700 abuse reports for SSH brute force.

Nothing here exploits a flaw in OpenSSH. The entry point is password authentication combined with a weak or default credential, and the campaign wordlists reach beyond generic Linux accounts — minecraft / 12345 appeared in the captured credential set, indicating scanning for game server installations.

If your organization runs any Linux host reachable on port 22 with password authentication enabled, it falls inside the scope of this campaign's scanning. For leadership, the cost is a server where the root password has been replaced and an attacker key sits in place, which turns a routine hardening gap into an incident response engagement.

Attack Mechanics: SSH Brute Force, Cowrie Deployment, and Post-Login Execution

The sensor behind this data is Cowrie v2.3.0, an SSH honeypot running on a Raspberry Pi 5 over a residential internet connection. It listens on port 2222 with external port 22 forwarded to it, records every credential pair, shell command, and file transfer attempt, and ships the results to ISC DShield. Cowrie is the observation platform here — the attacker's tooling is what executed inside the emulated shell.

Over a 30-day window the sensor logged more than 112,000 SSH sessions and 72,000+ authentication attempts from 175+ unique malicious source IPs. That volume against a single residential host with no advertised services is the baseline noise floor for anything reachable on port 22 with password authentication enabled.

The credential phase is pure wordlist work. The lists in play mix Linux defaults with application-specific pairs, including minecraft / 12345 — evidence that operators are sweeping for game server installations alongside generic Linux hosts. For a business, that means an unmanaged test box, a game server a developer spun up, or a forgotten appliance is scanned on the same pass as your production infrastructure.

On May 23, 2026 the sensor recorded 21 successful logins from 21 different source IPs in a single 24-hour period, clustered between 01:00 and 02:30 UTC. That clustering points to wave-based scanning from coordinated infrastructure rather than unrelated actors stumbling onto the same host.

Post-login execution and persistence artifacts

The interesting mechanical detail is how the key gets planted. The actor deletes the existing .ssh directory, recreates it, and then writes its own key into authorized_keys. Removing the directory first strips any legitimate administrator keys, so the backdoor becomes the only key-based path onto the box. Cowrie captured the injected key with hash:

a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2

The script also terminates processes as part of clearing access restrictions, mapping to T1562 (Impair Defenses) alongside T1078 (Valid Accounts), T1098 (Account Manipulation), and T1059 (Command Execution). The sequencing never varies: 163.7.8.79 reconnected to the sensor every few minutes throughout the day and replayed the identical command order, identical timing, and identical key material on each successful session. Fixed ordering with no exploratory commands is the signature of a compiled playbook, and it means the artifacts left behind are byte-for-byte reproducible across victims.

Infrastructure and indicators

• 163.7.8.79 — primary actor, Byteplus cloud infrastructure, AS150436. AbuseIPDB rates it at 100% confidence of abuse with over 5,700 reported incidents, mostly SSH brute force. GreyNoise classifies it as internet-wide brute-force and reconnaissance scanning.
• 80.94.92.184, 80.94.92.186, 80.94.92.171 — three high-volume sources from the same /24 hitting the sensor concurrently, consistent with a botnet or distributed scanning platform spreading load across nodes in one network block.
• 93 IPs from the documented mdrfckr SSH campaign list were still active against the sensor weeks after their initial documentation.

Forensically, the useful traces are the recreated .ssh directory with a fresh timestamp, a single unfamiliar entry in authorized_keys, an emptied /etc/hosts.deny, and an auth.log accepted-password event followed within seconds by a dense burst of shell commands. Because the operator changes the root password after key injection, the first sign on a production host is often an administrator who can no longer log in with known credentials.

Operational and Organizations Impact of Rapid Persistence

Root-level persistence is only half of what an automated SSH compromise costs you. The actor deleted the existing .ssh directory before recreating it and injecting its own key, which means any legitimate authorized_keys entries on that host were destroyed in the same second the backdoor was installed.

Think about what depends on those keys in your environment: backup agents pulling from the host, configuration management runs, CI/CD deployment jobs, monitoring scripts, and cross-server file transfers. Combined with the changed root password, you lose administrative access to your own system while the actor keeps theirs. Recovery starts with out-of-band console access or a rebuild, not a normal remote login.

The scale on a single sensor tells you how thin the odds are for any exposed host. In one 24-hour period the honeypot recorded 21 successful logins from 21 different source IPs, clustered between 01:00 and 02:30 UTC. That clustering matters operationally — the wave arrived during hours when most organizations run a skeleton on-call rotation, and each successful login was an independent foothold requiring its own investigation.

The primary actor IP also reconnected every few minutes throughout the day, running the same fixed command sequence each time. If your response is to remove the injected key and move on, the next session reinstalls it. Cleanup that does not also close the authentication path buys you minutes, not days.

Forensic scope grows faster than the intrusion

Because the same SSH key hash appeared across every session, scoping an incident means auditing authorized_keys on every host that shares a credential pattern, image, or provisioning template with the compromised one — not just the box that raised the alert. That is where investigation hours accumulate. Each additional host in scope adds log collection, memory and disk review, and a decision about whether to trust or rebuild it.

The scoping problem drives your compliance exposure too. Root access plus cleared host-based restrictions means an attacker had the technical ability to read anything on the system. If your logging does not prove what was and was not accessed during that window, counsel generally cannot rule out data exposure, and notification decisions get made on the assumption of access rather than evidence of it. Regulatory notification clocks in most regimes start from awareness, and awareness arrives late when the compromise takes 22 seconds.

Who carries the most exposure

• Web hosting and managed service providers — customer-provisioned instances with password authentication enabled, often outside your hardening baseline.
• Cloud infrastructure operators — the actor IP traced to Byteplus hosting (AS150436), showing how cheaply this scanning capacity is rented and how your own tenant space can be used the same way.
• Game and application server hosts — the credential lists included minecraft / 12345, so hosting stacks aimed at gaming customers are being scanned specifically, not incidentally.
• Critical infrastructure with SSH-accessible nodes — jump hosts, engineering workstations, and remote gateways where a locked-out administrator means a site visit.

The intelligence picture also undercuts blocklist-based comfort. AbuseIPDB records over 5,700 reported incidents for the primary IP at 100% abuse confidence, and 93 IPs previously documented in the mdrfckr campaign were still reaching the sensor weeks later. Sources you blocked last month are the same ones authenticating this month.

For decision-makers, the budget question is response speed, not just access control. Your detection and containment must operate on machine timelines, because the compromise completes before a human reads the first alert.

Detection and Immediate Response for Active Compromise

Identify established connections on port 22 with ss -tnp state established '( dport = :22 or sport = :22 )', cross-check logged-in users with who -u, then kill the offending session's process tree directly rather than restarting sshd, which leaves existing sessions alive on most distributions.

Capture volatile state in the same few minutes. Snapshot running processes with full command lines, all listening sockets and outbound connections, and the contents of every user's ~/.ssh/authorized_keys to a host you know is clean. Compare captured key material against the fingerprint a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 — a match confirms this campaign rather than an unrelated intrusion, which changes your scope of investigation.

Turn up SSH verbosity before the next wave arrives. Set LogLevel VERBOSE in /etc/ssh/sshd_config so the daemon records the key fingerprint used for every accepted authentication. That single field lets you distinguish your own administrators' keys from an injected one in log review, without touching the host filesystem.

Within the first few hours

• Diff /etc/passwd and /etc/shadow against your last known-good copy, looking for added UID 0 accounts and changed root hashes.
• Enumerate scheduled execution end to end: crontab -l for every account, /etc/cron.d/, /etc/crontab, and systemctl list-timers --all for timer units created outside your build process.
• Check for tampering aligned with T1562 (Impair Defenses) — cleared host-based access control files, stopped logging or blocking services, and terminated monitoring processes.
• Pull authentication history and look for the brute-force-then-success shape: a burst of failures followed by one accepted password from the same source, then shell activity seconds later.

Two SIEM rules catch this behavior reliably. The first correlates an accepted SSH password authentication with any command execution or file write under a user's .ssh directory inside a 60-second window; human administrators rarely move that fast, automated post-exploitation always does. The second alerts on multiple successful logins from distinct source IPs in a short interval — the honeypot recorded 21 successful logins from 21 different IPs in one day, clustered between 01:00 and 02:30 UTC, which is a wave pattern no legitimate access schedule produces.

Feed your blocklist the campaign infrastructure: the 93 mdrfckr-associated IPs still active against the sensor, the primary actor at 163.7.8.79 (Byteplus, AS150436), and the coordinated cluster at 80.94.92.171, 80.94.92.184, and 80.94.92.186. Because these actors rotate through cloud hosting, treat ASN-level and subnet-level blocking as more durable than single-address rules.

Because this attack class runs entirely on valid credentials (T1078), the detection that matters most is identity-based. In environments Capstone manages, Adlumin monitors authentication events for first-time source IPs, off-hours logins, and privileged accounts authenticating from infrastructure they have never used before, which surfaces a successful credential reuse before the follow-on commands finish.

For the durable fix, apply M1042: set PasswordAuthentication no and PermitRootLogin prohibit-password, then restrict port 22 to VPN or named management ranges under M1030. Add fail2ban for the failed-attempt volume that remains, and confirm each change by attempting a password login from outside your management network.

Hardening SSH Access and Monitoring to Prevent mdrfckr Infection

The single change that ends this attack class is turning off SSH password authentication. In /etc/ssh/sshd_config set PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no, and AuthenticationMethods publickey, then validate with sshd -t before reloading. No wordlist matters against a host that will not accept a password, which is why MITRE lists M1042 (Disable or Remove Feature) as the controlling mitigation here.

Generate your key material as ed25519 (ssh-keygen -t ed25519) and set a rotation schedule you actually enforce, because long-lived static keys spread across laptops and build agents become their own persistence problem. If your team is larger than a handful of admins, move to SSH certificate authentication instead: publish a CA public key with TrustedUserCAKeys and issue short-lived, principal-scoped certificates.

Certificates expire on their own, so an operator who leaves or a workstation that gets stolen does not require you to hunt authorized_keys files across every server. That removes the manual key inventory work that usually gets skipped during staff changes.

Then reduce who can reach port 22 at all. M1030 (Network Segmentation) applies directly: put SSH behind a bastion host, require MFA at the bastion, allow inbound 22 only from that bastion's address in host firewall rules, and force all session logs to a central collector. Layer fail2ban on the bastion with a low maxretry and a long bantime to blunt repeat scanning from the same infrastructure.

Also drop the known infrastructure at the edge. The reported actor IP 163.7.8.79 (Byteplus, AS150436) and the coordinated cluster at 80.94.92.184, 80.94.92.186, and 80.94.92.171 belong in your blocklists, along with the 93 overlapping mdrfckr campaign addresses. Blocklists age quickly, so treat this as noise reduction rather than a control you rely on.

For detection, watch the files this playbook touches. Add auditd watches so any write generates an event:

• -w /root/.ssh/authorized_keys -p wa -k ssh_key_change
• -w /etc/hosts.deny -p wa -k hostsdeny_change
• -w /etc/shadow -p wa -k credential_change
• -a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec

The last rule captures every root-executed command, which is what lets you spot the behavioral signature: a successful sshd accepted-publickey or accepted-password event followed by a dense burst of execve calls in the same handful of seconds. Build that correlation as an alert — authentication success plus rapid sequential command execution plus a write to authorized_keys — because the individual events look ordinary and only the ordering is suspicious.

Ship those logs off the host as they are written. An actor with root can edit local logs, so rsyslog or journald forwarding to a collector the SSH host cannot write back to preserves the evidence you need. SentinelOne flags this post-login execution chain on Linux servers across managed environments, including the key injection and credential modification steps, so the sequence surfaces without waiting on a log-review cycle.

If a host has already been touched, confirm forensic scope first, then rotate credentials broadly: every SSH key pair that host trusted or presented, all local account passwords, any service account tokens stored on it, and any CA-issued certificates it held. Search every server for the injected key hash a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 to establish whether the backdoor spread beyond the original host. Rebuild the affected system from known-good images rather than cleaning it in place.

Key Takeaway: Speed Demands Automation, Not Manual Response

Both halves of this operation are automated. The scanning came from cloud hosting infrastructure (Byteplus, AS150436) carrying 100% abuse confidence and more than 5,700 prior reports at AbuseIPDB, and the post-authentication sequence ran from a fixed script with identical command order and identical key material on every session. That sets a tempo your response process has to match.

Look at when the activity landed. The sensor recorded 21 successful logins from 21 different source IPs inside a single 24-hour period, clustered between 01:00 and 02:30 UTC. If your authentication log review happens during business hours, the window that produced every one of those compromises falls outside it.

The persistence of the infrastructure matters for how you think about coverage. The primary actor IP reconnected to the sensor every few minutes throughout the day, and 93 IPs tied to the same campaign were still hitting the sensor weeks after they were first documented publicly. Blocking one address or one session does not end the attempt against a host that still answers password authentication.

A sequence that reaches root persistence in 22 seconds is outside the range of human response. No analyst reads a log line, confirms context, and intervenes inside that window, and no scheduled review catches it before the backdoor is already in place.

If you operate internet-facing SSH without either automated login anomaly alerting tied to session termination, or endpoint detection with process-level visibility on every host that accepts SSH, treat that as a critical coverage gap. One of the two is enough to change the outcome of this sequence.