[This is a Guest Diary by Jin Quan Low, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

Ransomware [2] is often the first word that comes to mind when we think about cybercriminals chasing financial gain. It barges in, locks files, drops ransom notes, and causes immediate disruption.

Cryptojacking [3], on the other hand, acts like a quiet trespasser. It slips in unnoticed, makes itself at home, and hijacks computing resources in the background to mine cryptocurrency while the victim stays unaware. Because it rarely causes disruptions, cryptojacking does not get the same level of attention as ransomware. 

Over the past three months, my DShield honeypot captured repeated attempts to deploy RedTail, a cryptojacking malware first observed in early 2024 [4]. RedTail targets Monero cryptocurrency [5], typically gaining access through brute-forced SSH logins or exploiting vulnerabilities and deploying scripts to establish persistence and launch mining processes. The activity observed showed that compromises can extend beyond simple cryptomining, making RedTail a relevant case study for defenders.

Mapping Attacks to MITRE ATT&CK Tactics, Techniques and Procedures (TTPs)

Malware IOCs are very useful for quick detection, but they can be easily invalidated. Attackers only need to change part of their code, and those indicators lose all value. RedTail malware is no exception. Researchers had already detected different hashes of the same malware [6]. 

TTPs on the other hand rarely change and can be leveraged to detect similar threat behaviours. Hence, the observed attack involving RedTail malware will be mapped to the MITRE ATT&CK framework and how we can better defend ourselves. 

ATT&CK framework can be categorized into PRE-ATT&CK and ATT&CK (Refer to Figure 1).

Figure 1: PRE-ATT&CK & ATT&CK (MITRE ATT&CK framework)

The following attack sequence observed from my honeypot is mapped to this framework as an example.

PRE-ATT&CK

The early phases — reconnaissance and weaponization — may not always appear in logs, but later activity on the honeypot shows the existence of those phases (refer to Figure 2).

• Reconnaissance: Attackers scan IP ranges to look for exposed services (T1595.001: Active Scanning – Scanning IP Block).
• Weaponization: They develop or package their malware payloads (T1587.001: Develop Capabilities – Malware) and stage them for delivery (T1608.001: Stage Capabilities – Upload Malware).

Figure 2: PRE-ATT&CK phase showing reconnaissance and weaponization techniques observed

ATT&CK

ATT&CK phase entails the Deliver, Exploit, Control, Execute and Maintain stages.

The Deliver phase (refer to Figure 3) is mapped to the following stages:

• Initial Access: In my honeypot, attackers attempted brute-force SSH logins and eventually succeeded using valid credentials (T1078.002: Valid Accounts – Local Account).
• Execution: Once inside, attackers ran clean.sh and setup.sh to prepare the environment (T1059.004: Command and Scripting Interpreter – Unix Shell).
• Persistence: Attackers implanted their own SSH keys to maintain access (T1098.004: Account Manipulation – SSH Authorized Keys). This allowed them to return at will, bypassing password controls.

Figure 3: Deliver phase highlighting brute-forced SSH access, script execution, and persistence methods)

The Exploit to Execute phase (refer to Figure 4) is mapped to the following stages:

• Defense Evasion: Attackers deleted files to cover their tracks (T1070.004: Indicator Removal – File Deletion). 
• Discovery: Attackers queried system information to confirm compatibility before deploying RedTail (T1082: System Information Discovery).

Figure 4: Exploit and Execute phase showing file deletion and system discovery activity

The Execute and Maintain phase (refer to Figure 5) is mapped to the following stages:

• Command and Control: Outbound HTTPS traffic (Port 443) from infected systems to malicious mining pool servers [6]. This matches ATT&CK’s T1071.001: Application Layer Protocol – Web Protocols.
• Impact: RedTail malware is known to hijack CPU cycles to mine cryptocurrency (T1496.001: Resource Hijacking – Compute Hijacking). While subtle, this creates financial and performance costs for victims.

Figure 5: Execute and Maintain stage including outbound pool traffic and cryptojacking impact

Unique Observations from Honeypot

While RedTail has been reported in multiple incidents, my honeypot logs revealed several noteworthy behaviors beyond generic cryptojacking activity:

• Brute-forced SSH access: Attackers brute-forced SSH logins before deploying RedTail, showing that weak credentials remain an active entry vector.
• Script-based setup: After gaining access, they uploaded and executed setup.sh to configure the miner. They also ran clean.sh to remove competing cryptomining processes, ensuring RedTail had exclusive use of system resources.
• Persistence through SSH keys: Attackers implanted their own SSH keys into ~/.ssh/authorized_keys, allowing them to return without repeating brute-force attempts.
• Defense evasion: Logs recorded file deletion commands, which indicated that attackers tried to cover their tracks after installation.

These observations show that RedTail campaigns extend beyond simple cryptomining. Attackers maintain persistence, remove competition, and conceal their activity — behaviors that defenders should use when building detection and response strategies.

Mitigation

Defending against RedTail and similar cryptojacking malware requires a two-stage approach: prevention and detection/response.

1. Prevention (First Line of Defense)
   • Hardening Access
     • Use SSH key authentication and disable password logins.
     • Rate-limit SSH login attempts; enforce lockouts on repeated failures (fail2ban).
     • Disable root logins (PermitRootLogin no) and unnecessary services.
   • Patching and Updates
     • Apply security updates.
   • Network Controls
     • Restrict unnecessary inbound access.
     • Segment honeypots and exposed systems from production assets.
     • Block or sinkhole known mining pool connections.
        
2. Detection & Response (Catching What Slips Through)
   • Visibility
     • Enable detailed SSH, process, and outbound network logging.
     • Monitor CPU, memory, and disk I/O for abnormal sustained spikes.
   • TTP-Based Detection
     • Watch for brute-force attempts and repeated failed logins.
     • Flag unauthorized entries in ~/.ssh/authorized_keys.
     • Detect creation of unusual systemd services.
     • Monitor encrypted outbound traffic to unknown/private pools.
   • Response Actions
     • Isolate compromised hosts immediately.
     • Remove attacker SSH keys and terminate mining processes.
     • Rebuild compromised systems from clean images.
   • Continuous Monitoring
     • Track for reinfection attempts.
     • Use honeypots (like DShield) to capture new TTPs and feed them into defenses.

Conclusion

The only way to detect threats is to look for them, and detection has little value without response. Protecting devices and networks remains challenging but achievable with layered defenses. As the world grows more connected and attackers getting craftier, defenders must improve too.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://www.checkpoint.com/cyber-hub/threat-prevention/ransomware/
[3] https://www.malwarebytes.com/cryptojacking
[4] https://www.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit
[5] https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/
[6] https://isc.sans.edu/diary/30950
[7] https://www.virustotal.com/gui/file/89782d8142297907c9962eebdae29c28df86805a99f38a683ab55c8fa1596dd8/behavior

--
Jesse La Grew
Handler