What happened
At 01:06:43 UTC on May 23, 2026, source IP 163.7.8.79 connected to the Cowrie honeypot and authenticated one second later. The complete persistence and reconnaissance sequence executed within 22 seconds. Observed actions included replacing the .ssh directory, injecting an authorised key, changing the root password, clearing /etc/hosts.deny and running reconnaissance. Attribution posture: SANS ISC correlated 93 source IPs with the mdrfckr SSH campaign but established no responsible actor.
On August 6, 2026, SANS ISC published the 30-day honeypot analysis. The sensor recorded more than 112,000 SSH sessions, more than 72,000 authentication attempts and more than 175 unique malicious source IPs during the analysed 30-day period. The researcher found 93 IP addresses overlapping the mdrfckr campaign list still hitting the sensor. Observed indicators were IP address 163.7.8.79, credential pair root / Aa123123123 and SSH key hash a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2. Three high-volume scanning addresses in one subnet were 80.94.92.184, 80.94.92.186 and 80.94.92.171.
Why this matters now
The telemetry comes from one honeypot and should not be interpreted as an enterprise victim count. Its decision value is the observed speed and repeatability. Once a valid password succeeded, persistence and defence impairment completed before a normal alert could be reviewed. Prevention and machine-speed containment therefore matter more than an assumption that analysts can interrupt the sequence manually.
Weak credentials are only one part of the exposed condition. Direct internet reachability, root password authentication, unrestricted source networks and missing alerts on authorised_keys or password changes combine to create the practical path. Cloud and legacy estates are particularly vulnerable when emergency administration exceptions become permanent and disappear from central exposure inventories.
The decision for security leaders
Require infrastructure owners to reconcile external attack-surface data with SSH daemon configuration and identity policy. Direct administrative exposure should be removed behind a bastion, VPN or zero-trust access broker. Password authentication should be disabled where feasible, root login restricted and emergency exceptions assigned an owner, compensating controls and expiry date.
SOC teams should detect successful authentication followed immediately by .ssh replacement, authorised_keys writes, root-password changes or modification of host access controls. A match to the published key hash or a successful login from listed infrastructure should trigger host isolation and credential review. Blocking addresses alone is insufficient because the campaign uses distributed infrastructure.
Evidence of closure
- External testing confirms administrative SSH is unreachable outside approved paths.
- Configuration evidence shows password authentication disabled on scoped hosts.
- SIEM tests detect authorised_keys changes immediately after authentication.
- Exception records identify owners, expiry dates and compensating controls.
The Security.io assessment
The source supports active automated credential abuse, but not a claim that every listed address belongs to one operator or that the campaign compromised production enterprises. Reputation-service correlations and recurring command order strengthen the assessment of coordinated automation, while actor identity remains unresolved. The weak password used by the honeypot was intentionally accepted, so the event demonstrates attacker behaviour rather than a failed product control.
The closure standard should be exposure-based. An organisation has not closed the risk because it blocked one address or changed one password. It needs evidence that administrative SSH is reachable only through approved paths, that password authentication is removed or explicitly excepted, and that successful login followed by persistence activity produces an immediate machine-actionable alert.
Questions for the morning meeting
- Which systems still expose SSH directly to the internet?
- Can emergency-access requirements be met without password authentication?
- Does telemetry capture the first command after successful login?
- Who owns time-bound exceptions for legacy administrative access?