BreakglassIntelligence
Back to reports
highPhishing

RedTail Reloaded: Inside a Go-Based Cryptomining Botnet That Mines Your CPU, Backdoors Your PAM, and Worms Through Your SSH

PublishedMarch 12, 2026
Threat Actors:ProfileAssessmentlocation)Timeline
phishingcryptominerc2botnetbrute-forceexploitiotapt

TL;DR: A truncated RedTail cryptominer sample pulled from MalwareBazaar led us to a full 17.6MB Go binary that revealed capabilities well beyond what prior Akamai and SANS reporting documented. This is not just an XMRig dropper. It is a multi-functional botnet framework with dual CPU/GPU mining (XMRig + NBminer), a PAM authentication backdoor that survives password changes, an SSH brute-force worm with an embedded credential dictionary, systemd persistence, and ChaCha20-encrypted C2 communications -- all compiled into a single Go binary targeting four architectures. Six dropper script variants point to four C2 download servers, three of which share a common Neterra (Bulgaria) backbone. The campaign has been active since at least March 2023, with 274 unique VirusTotal submissions confirming widespread deployment. No wallet addresses were recovered -- the operator runs private mining pools and pushes all configuration dynamically from C2 at runtime, making static IOC detection nearly useless.

The Sample That Was Missing 28 Megabytes

This investigation started with a familiar scenario: a fresh upload to MalwareBazaar tagged as RedTail. SHA256 6168f5d0...edcda246, classified by ReversingLabs as "Multiverze," uploaded from France on March 10, 2026.

The first thing that went wrong was trying to analyze it.

The file is 2,097,152 bytes -- exactly 2MB. But when you parse the ELF headers, the LOAD segments reference 30.3MB of data. The section headers point to offset 0x1CE6018 (30,302,232 bytes), which is roughly 28MB beyond the end of the file. Someone -- whether the collector, a honeypot, or the dropper itself -- truncated this binary during capture. The sample would not execute. Static analysis would have to do.

But this is where the investigation got interesting, because MalwareBazaar had something else: a companion sample. SHA256 db7fc2fe...6e843b, 17.6MB, uploaded the same day. This one had enough Go runtime metadata intact to tell us exactly what this malware does -- and it does considerably more than anyone had previously documented.

What Was Found vs. What Was Known

Prior public reporting on RedTail comes primarily from Akamai's 2024 research and two SANS Internet Storm Center diaries. Those reports described a capable but relatively straightforward cryptominer that exploited Log4j, PAN-OS, and ThinkPHP vulnerabilities to deploy XMRig. Our analysis of the Multiverze variant reveals a substantially more advanced framework.

AspectPrior Reporting (Akamai/SANS 2024)Our Findings
MiningXMRig only (CPU)XMRig + NBminer (dual CPU/GPU mining)
PropagationExploit-based (Log4j, PAN-OS, ThinkPHP)Exploits + SSH brute-force worm with credential dictionary
BackdoorSSH key persistenceSSH keys + full PAM authentication backdoor
PersistenceCron jobsCron + systemd service units
C2 InfrastructureNot fully mapped4 servers across 3 hosting providers, 3 on Neterra backbone
Config EncryptionNot documentedChaCha20/Salsa20 with Poly1305 AEAD
LanguageC/C++ (XMRig-based)Go (CGo) with C interop for PAM and system libraries
WalletPrivate mining pools (no public wallet)Confirmed: dynamic config delivery, zero hardcoded IOCs
ScopeHoneypot observations274 VT submissions since March 2023

Every column in that table where our findings diverge from prior reporting represents a capability upgrade that defenders need to account for. The addition of NBminer means GPU-equipped servers are now targets. The PAM backdoor means password rotations will not remediate a compromise. The SSH worm means lateral movement happens without any exploit -- just a dictionary of bad passwords.

The Attack Chain: From Bash Script to Full Compromise

The full infection sequence runs through six stages. Each one is designed to maximize the chances of successful deployment on whatever Linux system the dropper lands on.

[Initial Access]            [Execution]              [Pre-Deployment]
Exploit / SSH brute    -->  Bash dropper fires  -->  "clean" script kills
(Log4j, PAN-OS,             dlr() downloads          competing miners
 ThinkPHP, SSH creds)       arch-specific payload    (turf protection)
                                   |
                                   v
                            [Architecture Detection]
                            uname -mp --> x86_64 / i686 / aarch64 / arm7
                            Find writable, exec-capable dir (noexec bypass)
                                   |
                                   v
                            [Installation]                [Lateral Movement]
                            Rename to .redtail   -------> SSH worm component
                            Install systemd service       Brute-force with
                            Deploy PAM backdoor           embedded dictionary
                            Write SSH authorized_keys     Deploy via SFTP as "sshd"
                                   |
                                   v
                            [Mining Operations]
                            C2 pushes config at runtime:
                              - XMRig (CPU, Monero/RandomX)
                              - NBminer (GPU, multi-algo)
                              - Pool address, wallet, algorithm
                            ChaCha20-Poly1305 encrypted C2 channel

Two things stand out about this chain. First, the "clean" script -- a pre-deployment step that kills competing miners before RedTail installs itself. This is turf warfare. The operator knows their targets are likely already compromised by other cryptojacking campaigns, and they want the compute resources for themselves.

Second, the entire mining configuration is dynamic. There are no hardcoded pool addresses. No wallet strings baked into the binary. Everything comes from the C2 at runtime. This is consistent with Akamai's 2024 observation that RedTail operators run private mining pool proxies, but seeing the actual config schema confirms just how thoroughly they have decoupled the malware binary from any trackable financial indicators.

Inside the Binary: Go, CGo, and a Lot More Than Mining

The Multiverze variant is a Go binary compiled with CGo -- Go's mechanism for calling C code. This is unusual for a cryptominer and immediately tells you the developer needed capabilities that Go's standard library does not provide. In this case, that capability is PAM.

The PAM Backdoor

Linux PAM (Pluggable Authentication Modules) is the framework that handles user authentication on every major Linux distribution. When you type your password at a login prompt, su to root, or SSH into a server, PAM is what verifies your credentials.

RedTail's binary includes CGo bindings to the complete PAM API:

pam_authenticate()     // Authentication bypass
pam_open_session()     // Session management
pam_close_session()    // Session teardown
pam_acct_mgmt()        // Account management
pam_setcred()          // Credential manipulation
pam_chauthtok()        // Password change interception
pam_get_item()         // Configuration read
pam_set_item()         // Configuration write

This is not a passive credential stealer. It is a full PAM module that can intercept and override the authentication process itself. Once installed, the malware can accept a hardcoded password for any user account on the system. Change your passwords all you want -- the PAM backdoor does not care. It operates at a layer below password storage.

For incident responders, this is the most dangerous finding in the entire investigation. A system compromised by this variant cannot be remediated by password rotation alone. You have to audit every PAM module on the system -- every shared object in /lib/security/ and every configuration file in /etc/pam.d/ -- to verify that no unauthorized modules have been installed.

The SSH Worm

The binary embeds a full SSH client library (golang.org/x/crypto/ssh) and uses it for automated lateral movement. The Go type metadata reveals the internal data structures:

type credential struct {
    privatekey string
    username   string
    ip         string
    password   string
}

// attackqueue - queue of targets for brute-force

The worm discovers targets by parsing known_hosts files on compromised systems -- a technique that maps the trust relationships between SSH servers in an organization. Every host a compromised server has previously connected to becomes a new brute-force target.

The embedded credential dictionary is predictable but effective:

root, admin, password, 123456, 1234, master,
raspberry, qwerty, portfolio, administrator

"raspberry" tells you they are hunting Raspberry Pi devices and IoT endpoints. "portfolio" is an unusual inclusion that may target developer environments or web hosting accounts.

After successful authentication, the binary deploys itself to the new target via SFTP, masquerading as sshd -- the legitimate SSH daemon process name. On a server running dozens of SSH connections, one more sshd process does not raise alarms.

Dual Mining: CPU and GPU

Prior reporting described RedTail as an XMRig-based miner. The Multiverze variant still includes XMRig for CPU mining, but adds NBminer for GPU mining. The C2 configuration schema extracted from Go struct tags tells the full story:

{
  "xmrig_enabled": true,
  "xmrig_algo": "randomx",
  "xmrig_poolAddr": "<delivered from C2>",
  "xmrig_poolUser": "<delivered from C2>",
  "xmrig_poolPass": "<delivered from C2>",
  "xmrig_nicehash": false,

  "nbminer_enabled": true,
  "nbminer_algo": "<delivered from C2>",
  "nbminer_poolAddr": "<delivered from C2>",
  "nbminer_poolUser": "<delivered from C2>",
  "nbminer_poolPass": "<delivered from C2>",

  "downloadURL": "<payload update URL>",
  "ver": "<version>",
  "checksum": "<integrity hash>"
}

This dual-miner approach is strategic. Most cryptojacking campaigns target CPU because it is universally available. But GPU mining is far more profitable per watt on systems that have discrete GPUs -- which increasingly includes cloud instances, rendering farms, machine learning infrastructure, and high-end servers. By supporting both, RedTail extracts maximum value from whatever hardware it compromises.

The configuration also includes a complete process telemetry schema -- CPU usage, memory (RSS/VMS/swap/stack), page faults, thread states, I/O wait. The operator is monitoring the health and performance of their mining fleet in real time. This is not a fire-and-forget operation. It is a managed botnet.

Encryption and C2 Protocol

C2 communications are encrypted with ChaCha20-Poly1305, an authenticated encryption scheme. The telltale key expa constant (the first 8 bytes of the ChaCha20/Salsa20 key expansion string "expand 32-byte k") was found in the binary, along with references to the full chacha20poly1305 AEAD package. The C2 channel itself uses HTTP/2 over TLS, making traffic analysis difficult even for organizations with SSL inspection capabilities.

The Dropper: Six Variants, One Template

Six dropper script variants were recovered from MalwareBazaar, each following the same bash template but evolving over time. The evolution tells a story about operational maturity.

How the Dropper Works

Every variant implements the same core logic:

  1. Define a dlr() function with three download methods: wget, curl, and a /dev/tcp fallback for minimal systems that have neither
  2. Search for a writable directory that is not mounted with noexec -- a direct bypass of a common Linux hardening measure
  3. Download and execute a clean script that kills competing miners
  4. Detect CPU architecture via uname -mp
  5. Download the architecture-specific binary (x86_64, i686, aarch64, or arm7)
  6. Rename the binary to .redtail (the leading dot hides it from ls)
  7. Execute

The noexec bypass deserves attention. Hardened Linux systems mount /tmp, /var/tmp, and other world-writable directories with the noexec flag to prevent arbitrary code execution. The dropper actively searches for directories that are both writable and executable by creating test files (.testfile, .testfile2), setting the execute bit, and attempting to run them. Later variants parse /proc/mounts directly to identify candidate directories. This is not a script kiddie technique -- it shows awareness of enterprise security hardening.

Dropper Evolution Timeline

PeriodC2 IPKey Changes
Jun 2024185[.]172[.]128[.]93First variants. Basic noexec check. Plain architecture filenames.
Jun 2024194[.]59[.]31[.]109"Sybir" variant introduces image file disguise -- binaries named aZr.png, bJL.png, OrI.png, POz.png to evade URL-based detection.
Late 202487[.]120[.]117[.]92Migration to Lycatel infrastructure. Basic variant.
Dec 2024+94[.]156[.]177[.]109Enhanced noexec bypass using /proc/mounts. Added clean pre-deployment script. Added rm -rf $1 cleanup in dlr().

The "sybir" variant name is a linguistic breadcrumb. "Sybir" is the Polish/Ukrainian word for Siberia, placing the developer firmly in an Eastern European cultural context.

Infrastructure: The Neterra Connection

Four C2 download servers were extracted from the dropper scripts. At first glance they look like unrelated hosting providers across multiple countries. Look closer and a pattern emerges.

Tier 0 Backbone:  Neterra Ltd (Sofia, Bulgaria) -- MNT-NETERRA
                    |
Tier 1 Transit:   AS41745 (Fortis/HIP)    AS399486 (Virtuo)    Lycatel
                    |                        |                    |
Tier 2 C2:        94.156.177.109          194.59.31.109        87.120.117.92
                    (RU/NL)                 (FR/CA)              (GB/BG)

Separate:         NesterTelecom LLC -- 185.172.128.93 (RU, AS52008)

Three of the four C2 IPs share a single RIPE maintainer object: MNT-NETERRA. Neterra is a Bulgarian Tier 2 backbone provider that sells transit to hosting resellers across Eastern Europe. The operator appears to use a single provisioning relationship -- possibly one reseller account -- to acquire infrastructure across nominally different hosting brands in different countries. On paper it looks distributed. On the wire, it all goes through Sofia.

The Bulletproof Tell

The 94[.]156[.]177[.]0/24 subnet (Fortis Host, registered to Baykov Ilya Sergeevich in Moscow) contains multiple IPs with spoofed reverse DNS records pointing to github.com, microsoft.com, and lk.x5.ru. When a hosting provider's IP space features fake PTR records for Microsoft and GitHub, you are looking at bulletproof hosting infrastructure. These are networks where the provider either ignores abuse complaints or actively facilitates them.

C2 Status (as of March 11, 2026)

IPASNProviderCountryStatus
94[.]156[.]177[.]109AS41745Fortis HostRU/NLLIVE (SSH only, HTTP offline)
194[.]59[.]31[.]109AS399486Virtuo NetworksFR/CALIVE (445/3389/5357 -- Windows host)
87[.]120[.]117[.]92--LycatelUK/BGOFFLINE
185[.]172[.]128[.]93AS52008NesterTelecomRUOFFLINE

Two of four servers are still reachable. The primary C2 at 94[.]156[.]177[.]109 has its HTTP service offline but still responds on SSH -- possibly reconfigured or preparing for the next wave. The 194[.]59[.]31[.]109 host appears to be a Windows server (SMB, RDP, and WSD ports open), which is unusual for a Linux malware C2 but could serve as a staging or management node.

Persistence: The Triple Threat

RedTail does not rely on a single persistence mechanism. It deploys three, each operating at a different layer of the system.

Layer 1 -- systemd (boot persistence): A systemd service unit with WantedBy=multi-user.target ensures the malware starts on every boot. This is the most visible mechanism and the one most likely to be caught by configuration management tools.

Layer 2 -- PAM module (authentication persistence): The PAM backdoor embeds itself into the authentication stack. Even if you find and remove the systemd service, the attacker retains the ability to log in as any user with the backdoor password. This survives password changes, SSH key rotations, and most standard incident response procedures.

Layer 3 -- SSH authorized_keys (remote access persistence): The attacker's SSH public key is written to authorized_keys files, providing key-based access that does not depend on either the systemd service or the PAM module being intact.

Removing any one mechanism leaves the other two operational. A complete remediation requires addressing all three simultaneously, which means most automated cleanup scripts will fail.

Who Is Behind This?

Attribution Assessment

FactorAssessmentConfidence
RegionEastern Europe / RussiaHIGH
MotivationFinancial (cryptojacking)HIGH
SophisticationMedium-HighHIGH
GroupUnattributed; possible Lazarus overlap per AkamaiLOW

The evidence points to an Eastern European operator with moderate-to-high technical sophistication:

  • Hosting choices concentrate on Russian providers (Fortis Host in Moscow, NesterTelecom) and Bulgarian backbone (Neterra)
  • "Sybir" dropper name -- the Polish/Ukrainian word for Siberia -- places the developer in an Eastern European linguistic context
  • Go language choice is consistent with the Eastern European cybercrime ecosystem's shift away from C/C++ toward Go for cross-platform malware
  • Private mining pools indicate operational maturity -- the operator is sophisticated enough to run their own pool infrastructure rather than mining to public pools where wallet addresses could be tracked

Akamai's 2024 research noted similarities to Lazarus Group (DPRK) TTPs in the private mining pool operation. We found no direct evidence supporting or refuting this in our samples, and maintain this at LOW confidence. The operational pattern is more consistent with organized cybercrime than state-sponsored activity.

Campaign Timeline

DateEvent
Mar 2023First VirusTotal submission of primary sample
Jan 2024RedTail first publicly documented by CSA (Log4j exploitation)
Apr 2024PAN-OS CVE-2024-3400 exploit integration (Akamai)
May 2024First Kaspersky detection of Multiverze variant
Jun 2024Dropper scripts deployed from 185[.]172[.]128[.]93 and 194[.]59[.]31[.]109
Jun 2024"Sybir" variant introduces image file disguise (aZr.png)
Late 2024Infrastructure migration to Lycatel (87[.]120[.]117[.]92)
Dec 2024Primary C2 shifts to Fortis Host (94[.]156[.]177[.]109); clean script added
Feb 2025redtail.x86 sample collected
Aug 2025Last Kaspersky detection
Nov 2025Batch upload of 12 Multiverze-tagged variants
Dec 2025sshd masquerading sample captured (US origin)
Jan 2026UPX-packed variant captured
Mar 2026Current samples uploaded by "enthec" (France)

This is a three-year campaign with periodic infrastructure rotations and incremental capability upgrades. The operator invests in maintaining and evolving the tooling rather than spinning up throwaway campaigns.

Detection

What to Hunt For

The most effective detections target behavioral indicators rather than static IOCs, because RedTail's dynamic configuration model means file hashes and network addresses rotate regularly.

On the filesystem:

  • Hidden files named .redtail in writable directories
  • Test artifacts: .testfile, .testfile2 in /tmp, /var/tmp, /dev/shm
  • Unknown systemd service units with WantedBy=multi-user.target
  • Unauthorized PAM modules in /lib/security/ or /lib64/security/
  • Unexpected entries in ~/.ssh/authorized_keys across all user accounts
  • The clean script (transient -- kills competing miners during deployment)

On the network:

  • HTTP downloads of architecture-named files (/x86_64, /i686, /aarch64, /arm7) from external IPs
  • HTTP downloads of PNG-named files (/aZr.png, /bJL.png, /OrI.png, /POz.png) that are actually ELF binaries
  • Outbound SSH connections at high frequency from non-administrative hosts (worm behavior)
  • SFTP transfers deploying binaries named sshd to unusual directories
  • ChaCha20-Poly1305 encrypted channels to non-standard endpoints

On the host:

  • Processes named sshd running from unexpected paths (not /usr/sbin/sshd)
  • Anomalous CPU or GPU utilization patterns, particularly on servers not expected to perform compute-intensive work
  • Go Build ID TegskTGfBzL5ZXVeATJZ/Kg4gGwZNHviZINPIVp6K in ELF binaries

YARA Rules

Five YARA rules are provided targeting different components of the malware. The most reliable is RedTail_Multiverze_Config_Schema, which matches on the mining configuration struct tags that are unique to this family:

rule RedTail_Multiverze_Config_Schema
{
    meta:
        description = "Detects RedTail/Multiverze mining config schema in Go binary"
        author = "GHOST - Breakglass Intelligence"
        date = "2026-03-10"
        severity = "HIGH"

    strings:
        $xmrig_pool = "xmrig_poolAddr" ascii
        $xmrig_user = "xmrig_poolUser" ascii
        $xmrig_pass = "xmrig_poolPass" ascii
        $xmrig_algo = "xmrig_algo" ascii
        $xmrig_en = "xmrig_enabled" ascii
        $nbminer_pool = "nbminer_poolAddr" ascii
        $nbminer_user = "nbminer_poolUser" ascii
        $nbminer_en = "nbminer_enabled" ascii
        $nbminer_algo = "nbminer_algo" ascii
        $download_url = "downloadURL" ascii
        $attack_queue = "attackqueue" ascii

    condition:
        uint32(0) == 0x464C457F and
        (
            (3 of ($xmrig_*) and 2 of ($nbminer_*)) or
            (4 of ($xmrig_*) and $download_url)
        )
}

A second rule targets the SSH worm component by matching on Go struct metadata:

rule RedTail_SSH_Worm_Component
{
    meta:
        description = "Detects RedTail SSH worm component via Go struct metadata"
        author = "GHOST - Breakglass Intelligence"
        date = "2026-03-10"
        severity = "HIGH"

    strings:
        $cred_struct = "privatekey string; username string; ip string; password string" ascii
        $attack_q = "attackqueue" ascii
        $main_cred = "main.credential" ascii
        $systemd = "WantedBy=multi-user.target" ascii
        $pam_handle = "pam._Ctype_struct_pam_handle" ascii

    condition:
        uint32(0) == 0x464C457F and
        (
            ($cred_struct and $attack_q) or
            ($main_cred and $systemd) or
            ($pam_handle and any of ($attack_q, $main_cred))
        )
}

Suricata Rules

Twelve Suricata/Snort rules are available, keyed on C2 IP addresses, payload download URIs, and SSH brute-force behavioral patterns. The highest-value rule for organizations that cannot deploy all twelve:

alert http $HOME_NET any -> [94.156.177.109,87.120.117.92,185.172.128.93,194.59.31.109] any (
    msg:"BREAKGLASS RedTail C2 Download Server Contact";
    flow:to_server,established;
    classtype:trojan-activity;
    sid:2026031001; rev:1;
    metadata:author GHOST,severity HIGH,family RedTail;
)

MITRE ATT&CK Mapping

TacticTechniqueIDHow RedTail Uses It
Initial AccessExploit Public-Facing ApplicationT1190Log4j, PAN-OS CVE-2024-3400, ThinkPHP
Initial AccessValid AccountsT1078SSH brute-force with credential dictionary
ExecutionCommand and Scripting Interpreter: BashT1059.004Dropper scripts with wget/curl/dev-tcp
PersistenceCreate or Modify System Process: SystemdT1543.002WantedBy=multi-user.target service unit
PersistenceAccount Manipulation: SSH Authorized KeysT1098.004Key-based persistent access
PersistenceModify Authentication Process: PAMT1556.003Full PAM module backdoor
Defense EvasionMasqueradingT1036.005Process named sshd
Defense EvasionHidden Files and DirectoriesT1564.001.redtail filename
Defense EvasionSoftware PackingT1027.002UPX packing in later variants
Defense EvasionFile DeletionT1070.004clean script removes competitor malware
Credential AccessBrute Force: Password SprayingT1110.003SSH dictionary attack
DiscoverySystem Information DiscoveryT1082uname -mp for architecture detection
DiscoveryFile and Directory DiscoveryT1083find + /proc/mounts for writable exec dirs
Lateral MovementRemote Services: SSHT1021.004SSH worm propagation
Lateral MovementLateral Tool TransferT1570SFTP binary deployment
CollectionData from Local SystemT1005SSH key harvesting (known_hosts, id_rsa)
Command and ControlEncrypted ChannelT1573ChaCha20-Poly1305 C2 communications
Command and ControlApplication Layer Protocol: HTTPT1071.001HTTP/2 with TLS
ImpactResource HijackingT1496XMRig (CPU) + NBminer (GPU) mining

Indicators of Compromise

C2 / Download Servers

IPASNProviderCountryStatus
94[.]156[.]177[.]109AS41745Fortis HostRU/NLACTIVE
194[.]59[.]31[.]109AS399486Virtuo NetworksFR/CAACTIVE
87[.]120[.]117[.]92--LycatelUK/BGOffline
185[.]172[.]128[.]93AS52008NesterTelecomRUOffline

Download URLs

hxxp://94[.]156[.]177[.]109/x86_64
hxxp://94[.]156[.]177[.]109/i686
hxxp://94[.]156[.]177[.]109/aarch64
hxxp://94[.]156[.]177[.]109/arm7
hxxp://94[.]156[.]177[.]109/clean
hxxp://194[.]59[.]31[.]109/aZr.png     (x86_64 disguised as image)
hxxp://194[.]59[.]31[.]109/bJL.png     (i686 disguised as image)
hxxp://194[.]59[.]31[.]109/OrI.png     (aarch64 disguised as image)
hxxp://194[.]59[.]31[.]109/POz.png     (arm7 disguised as image)

File Indicators -- ELF Binaries

SHA256SizeDescription
6168f5d053f4c3d413327947c37b927a759b316d68ac341908695879edcda2462.0 MBTruncated primary sample
db7fc2fef4f644d06e378b426e9a5a5c5ac7c29fb0d09ba56903fed1dbe6843b17.6 MBFull binary with Go type metadata
a2344aa530706d76200c8c4fff2ba9b37791bee1d587ffe13732d21cd42524ea17.3 MBsshd masquerading variant
9875fb1a96f06fb4ffde6c24cbaaa15eacd9df8652756e25e6e13f125f2019ec4.7 MBredtail.x86
1dab38eaba06e088ad1eb6d5e7b541c84d1ef8b198d961eb61eb19cd62dcd0681.8 MBUPX-packed variant

File Indicators -- Dropper Scripts

SHA256C2 IPFirst Seen
de96a56c5508bb69c20f171a141263ebed92823eb3249dccb9db1ff350b37b3194[.]156[.]177[.]1092024-12-05
b7004d1b9da9d453742088a02b0aba30aad672b475f37ea20cda502c7e5bdebd94[.]156[.]177[.]109--
d5b55117f713a1a265dcab0dc68ceb4a607069f3831bd2594aa1330d5d0eac8187[.]120[.]117[.]92--
2c602147c727621c5e98525466b8ea78832abe2c3de10f0b33ce9a4adea205eb185[.]172[.]128[.]932024-06-15
b33b415cbee7d64d4cbedda4c61d97437393b6095d53f597b5ee247b16591b6f194[.]59[.]31[.]1092024-06-08
ed8fe6eb98c8a487c631dee11ddbe11c322e446666280f7b97844d259fdb10f5185[.]172[.]128[.]932024-06-08

Additional File Hashes (Primary Sample)

SHA256:  6168f5d053f4c3d413327947c37b927a759b316d68ac341908695879edcda246
SHA1:    9a0c3a89bedb0d4c6c5db54350f19cc8dce00782
MD5:     2bea413875c5516ab9969d7ea3e370fd
TLSH:    T12EA5F757E49590E4C0EEE174C726A213BEA13499473837E36FA187F11B26FE4A6BC314

Behavioral Indicators

# Filesystem artifacts
.redtail                              Hidden binary in writable directory
.testfile / .testfile2                Noexec bypass test artifacts
clean                                 Competitor-killing script (transient)

# Process indicators
sshd (from non-standard path)         Process masquerading
WantedBy=multi-user.target            systemd persistence
PAM module in /lib/security/          Authentication backdoor

# Network indicators
HTTP GET /x86_64, /i686, etc.         Architecture payload download
SSH brute-force (rapid auth failures) Worm propagation
SFTP binary transfer as "sshd"        Lateral tool transfer
ChaCha20-Poly1305 encrypted channel   C2 communications

# Go Build ID
TegskTGfBzL5ZXVeATJZ/Kg4gGwZNHviZINPIVp6K/-aw3x4amOW3feyTomlq7/WXkOJPhAhVPtgkpGtlhH

What Defenders Should Do Right Now

Immediate (24-48 hours):

  • Block all four C2 IPs at perimeter firewalls and IDS/IPS
  • Search for .redtail files across all Linux systems (find / -name ".redtail" 2>/dev/null)
  • Audit systemd services for unknown units (systemctl list-unit-files --state=enabled)
  • Review PAM configuration for unauthorized modules in /etc/pam.d/ and /lib/security/
  • Check SSH authorized_keys files for unauthorized entries across all accounts
  • Deploy the YARA and Suricata rules from this report

Short-term (1-2 weeks):

  • Parse auth.log / secure logs for brute-force patterns against SSH
  • Check for anomalous CPU/GPU utilization across server fleet
  • Implement SSH key rotation and disable password authentication where feasible
  • Consider blocking Neterra AS41745 transit at network perimeter if not business-critical
  • Review /proc/mounts for volumes that should be noexec but are not

Medium-term (1-3 months):

  • Implement PAM module integrity monitoring (hash all .so files in /lib/security/ and alert on changes)
  • Deploy certificate-based SSH authentication to replace password-based auth
  • Apply noexec to all non-essential mount points
  • Conduct full incident response on any system where IOCs are found -- the PAM backdoor means re-imaging is the safest remediation

Analytical Limitations

Five factors constrain our analysis:

  1. The primary sample is truncated at 2MB of a likely 30MB binary -- 28MB of potential hardcoded configurations, embedded payloads, and overlay data remain unanalyzed
  2. The full binary contains rich Go type metadata but actual runtime config values are encrypted or packed
  3. No sandbox behavioral data is available because the truncated sample will not execute
  4. All C2 HTTP servers are offline -- we could not capture a live config push to extract pool addresses or wallet IDs
  5. No wallet address was recovered anywhere in the analysis, consistent with the private mining pool model but preventing financial tracking of the operation

References

Published by Breakglass Intelligence. Investigation conducted 2026-03-11. 1 binary. 4 C2 servers. 3 persistence mechanisms. A three-year campaign that mines your CPU, backdoors your PAM, and worms through your SSH. Classification: TLP:CLEAR

Share