Tracking RedTail's 2025-2026 evolution: persistent SSH compromise expands to RISC-V and embedded devices

RedTail is cryptocurrency mining malware that steals system resources to mine Monero for malicious actors, using advanced evasion and persistence techniques. Cybersecurity Reach Foundation’s honeypot caught RedTail intrusion attempts and its post-exploitation actions in both 2025 and 2026.

A honeypot is a specific system or resource designed to attract cyberattacks by simulating a legitimate target. In this specific case, the honeypot was utilized to gather intelligence on attackers’ techniques, methods, and motivations without putting production systems in danger. This report focuses on comparing the 2025 version of the RedTail miner to its contemporary 2026 variant.

Who gets hurt

RedTail targets public systems and servers that are reachable through the internet to exploit their computational resources for the purpose of mining Monero cryptocurrency. While RedTail can make intrusion attempts on any systems it can potentially compromise, small and medium-sized companies and organizations are particularly in danger due to often having limited security resources and protections, which makes them common and fairly reachable targets for a mass-spread miner such as RedTail. When it comes to large firms, their services are also prone to exploitation; however, they are less likely to become victims of the RedTail campaign as they often have mature security divisions that have already built and implemented defenses against mass-spread malware.

In our specific case, RedTail gained initial system access via SSH brute-force (repeatedly attempting common SSH username and password combinations to establish an SSH connection). Thus, we can confidently infer that any systems with an open SSH port and weak or common credentials face the risk of being exploited by RedTail. Apart from SSH brute-force attacks, RedTail has been shown to infect systems through other methods that will not be covered in this report, such as CVE-2024-3400, CVE-2023-46805, CVE-2024-21887, CVE-2023-1389, CVE-2022-22954, and CVE-2018-20062.

How the RedTail attack unfolds

One of the ways RedTail infects the targeted systems is via SSH brute-force, as could be observed on multiple SSH login attempts in the screenshot below:

After Initial Access is obtained, malicious RedTail payloads and scripts are uploaded via the SFTP protocol:

Right after all the files are uploaded to a victim machine, the following CMD command gets executed:

Based on the analysis above, we can conclude that the command’s purpose is to:

1. Execute previously uploaded .sh files.
2. Establish the SSH backdoor.
3. Return an obfuscated output so an attacker can confirm the success of the exploitation.

The detailed analysis of what exactly clean.sh and setup.sh achieve could be found in the “What changed between 2025 and 2026” section. To put it shortly, clean.sh eliminates rival cryptominers if such already exist on a system, and setup.sh detects the system’s CPU architecture and sets up the respective variation of RedTail.

After the CMD command above is executed, the SSH connection gets terminated.

What changed between 2025 and 2026

One of the most noticeable difference in 2025 and 2026 versions of RedTail campaign is an increase in the number of files utilized for system infection.

To the previously used .arm7, .arm8, .i686, .x86, and .x86_64 files, the new redtail.riscv was added.

To understand what stands behind this change, we need to understand the context of what these variations stand for. RedTail uses different redtail.[arch] files in order to work on systems with varying CPU architectures - arm7 and arm8 are part of the ARM architecture family, while i686, x86, and x86_64 are all members of the x86 family.

The redtail.riscv extends coverage for RedTail by introducing the payload RISCV, which is part of the RISC architecture family. While the RISCV architecture could be utilized in many different systems, it is currently popular in low-cost devices and specialized chips, especially those for embedded and IoT systems.

Interestingly, the IP addresses involved in attacks have changed as well. In 2025, attacks were initiated from 3 IPs, while in 2026, only from 2 IPs.

Moreover, in 2025, malicious redtail.[arch] files sent from different IPs in different countries had different hashes, while in 2026 all files had no hash differences. This could indicate that in 2025 RedTail was distributing different variations of a cryptominer, using different IPs for the spread of different RedTail versions.

Speaking of the changes within the payload files, the core logic of the setup.sh script remained the same in both 2025 and 2026. However, the 2026 version introduced updates that focused on evading detection, reaching more platforms, and leaving fewer traces, as could be seen in the differences table below:

setup.sh behaviour: 2025 vs 2026

Behaviour	2025	2026	Change
Payload filename	Fixed hidden file .redtail	Random hidden name (about 4-35 alphanumeric characters) from get_random_string(), trying openssl rand, then /dev/urandom, then $RANDOM, then falling back to redtail	Fixed filename removed (it was an easy IOC)
Mount detection	Only parses /proc/mounts	Prefers findmnt -O noexec, keeps /proc/mounts as fallback	findmnt added
riscv architecture detection	Not detected	Detected	New
Binary handling	Copies redtail.* into the chosen writable directory, then deletes them from both locations	Moves the binaries; the extra rm -rf "$CURR"/redtail.* cleanup step is gone	Copy-and-delete replaced by move

As for the clean.sh, it received updates focusing on improving elimination of potential rival malware, fixing the issue of RedTail accidentally deleting itself from the system, and lowering the chance of malware misbehaving by making the code cleaner. The table of changes in clean.sh behaviour can be found below:

clean.sh behaviour: 2025 vs 2026

Behaviour	2025	2026	Change
Helper function	clean_crontab()	clean_file()	Renamed for broader use
Strip immutable/append-only attributes	chattr -ia	chattr -ia	None
Line filter	wget|curl|/dev/tcp|/tmp|.sh|nc|bash -i|sh -i|base64 -d	Same	None
Temporary output file	/tmp/clean_crontab	/tmp/clean_file	Renamed
Overwrite original	mv	mv -f	Forced overwrite
Rival services disabled and stopped	c3pool_miner	c3pool_miner, bot[.]service	New competitor targeted
Cleans user crontabs in /var/spool/cron/crontabs/*	Yes	Yes	None
Clears system crontabs in /etc/crontab, and /etc/crontabs	Yes	Yes	None
Clears /etc/cron[.]hourly, .daily, .weekly, .monthly, and /etc/cron.d	Yes	Yes	None
Clears anacrontab in /etc/anacrontab	Yes	Yes	None
Clears active user's crontabs	No	Yes	New
Wipes /tmp, /var/tmp, /dev/shm	rm -rf $i/*	find -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +	Now also deletes hidden dotfiles
Checks each directory exists before wiping	No	Yes	New
Skips its own directory with pwd -P	No	Yes	New: self-preservation, won't delete its own payloads
Safer deletion (--, quoted variables)	No	Yes	New
Shell profile cleanup (~/.bashrc, ~/.bash_profile, ~/.profile)	No	Yes	New persistence locations

Regarding the aspects of RedTail that remained the same, the SSH-RSA persistence key used to establish a backdoor on affected systems has not changed since 2025. Furthermore, the whole CMD script that the malicious actor runs on the victim machine after initial access is obtained had no alterations. Based on this, and behaviour comparison tables, it becomes clear that the main execution flow stayed the same, so the campaign kept its core tradecraft, while simultaneously improving reach and stability.

What we did not find

Analyzing the code within the redtail.[arch] binaries fell outside the scope of this report. Unpacking and reverse-engineering these files to evaluate their static state and active behavior requires dedicated analysis, which is better suited for a standalone report.

In addition to that, the identity of the threat actor standing behind the RedTail campaign remains undiscovered. Obtaining the IPs from which the attack was initiated is not a challenging task, but going further and tracking down the connection chain to inspect where the attack actually originates from is a substantially more complex task. In practice, such investigation would often need specific warrants, permissions, and support of law-enforcement cyber-oriented units to succeed, and thus resides outside of the scope of this report.

What this tells us

The overall direction of RedTail modifications clearly indicates that RedTail is actively maintained and updated. After the analysis, we may infer that the primary focus of those changes was:

• Broader platform support
• Improved stealth and evasion
• More reliable cleanup
• Anti-rival-malware behavior
• Operational consistency

The observed evolution of RedTail manages to balance expanding reach of systems, better evasion, cleaner code, stronger anti-rival solutions, and improved trace coverage without changing the logic behind key operations.

The emphasis of RedTail updates shows that the actor behind this crypto-mining campaign sharpens its approach and progresses

How to protect your systems

In order to protect your systems from RedTail, consider the following recommendations:

1. Do not use banal SSH credentials with common usernames and passwords
   • Disable password login at all and use SSH key pairs instead. This would make your machine much harder to brute-force.
2. Do not leave the SSH port open to access outside of your network
   • Configure a VPN solution or a Jump Server to securely access your systems with SSH remotely, and limit other access to the SSH port outside of your own network via the practice of IP whitelisting.
3. Do not keep unused ports and services open
   • In observed attacks, RedTail used the SFTP protocol to transfer malicious files. By disabling all the unused ports and services on your machine, you can heavily decrease the attack vector, making any malware infection, including RedTail, much more challenging for the attacker.
4. Do not ignore system updates and software updates
   • One of the most important measures when it comes to defending information systems is to keep the software and OS up to date—patching them with the most recent security updates.
5. Do not neglect anti-malware solutions
   • If you introduce a reliable and well-configured anti-malware solution on your systems, then the chances of successful attacks being fully executed are lower, as they could be addressed much earlier than in cases where such defenses are not present.

Indicators of compromise

Even though the RedTail attack unfolds very quickly, we can still configure our defence to the associated IoCs to protect our machines or servers.

The clearest and earliest sign of RedTail (or other malicious actors attempting SSH brute-force) is multiple unsuccessful SSH login attempts, as observed in the screenshot below:

Another indicator of compromise linked to the RedTail attack is a persistent SSH-RSA key added to the authorized keys list as a backdoor. To check for this injected key, inspect ~/.ssh/authorized_keys for the following RedTail-associated key:

AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK216q0q/7neNVqm7AgvfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv66I5yuZTEaDAG6cPXxg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96hu1GthAMtPAFahqxrvaRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWpO2xF6tzfdmHbiVdSmdw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUslEf/zevIcX8+6H7kUMRr

As the purpose of RedTail is to mine cryptocurrency on infected systems, it naturally increases the system’s resource consumption, such as CPU and GPU load. This is among the most popular indicators of crypto-mining malware, including RedTail.

About CSRF

The Cybersecurity Reach Foundation is a volunteer-run 501(c)(3) nonprofit bringing cybersecurity and scam awareness to everyday people. Check anything suspicious with our free Scam Checker, report scams to ScamArchive, get alerts from WatchOut, and reach our researchers at info@cybersecurityreach.org. Support our work.

Domains and addresses in this report are defanged (for example, example[.]com) so they can’t be opened by accident. Please don’t visit them. Findings reflect what we could see on the dates given in the report.