Operazione RedTail: Analisi Tecnica Avanzata Botnet Linux ELF

Report IDNH-TR-2026-04-14-REDTAIL

Data analisi13-14 Aprile 2026

Lead InvestigatorMatteo Di Foggia

OrganizzazioneNerd Herd - Business Technology Solutions

ClassificazioneTLP:WHITE (Public)

SHA-256 (campione)46AB28**********************EB130A (hash parzialmente censurato)

Vettore iniziale

RCE / ELF dropper

Obiettivo

Cryptojacking XMR

Evasione

Process Masq. nginx

Persistenza

systemd service

C2 port

TCP 2137

Rilevamento

Honeypot NH

1. Executive Summary

In data 14 Aprile 2026, il laboratorio forense di Nerd Herd ha completato l'analisi tecnica approfondita di un artefatto malevolo Linux ELF identificato come variante avanzata della botnet RedTail. L'indagine, condotta in due fasi distinte (analisi statica il 13 e analisi dinamica da core dump il 14), ha svelato un'architettura di attacco multi-strato volta al cryptojacking di Monero (XMR) attraverso proxy privati dedicati.

L'artefatto e' stato intercettato da un honeypot proprietario Nerd Herd, deployato su un'infrastruttura enterprise monitorata dal nostro team. Le scoperte chiave di questa indagine, in ordine di rilevanza operativa, sono quattro:

Process masquerading confermato: il malware rinomina i propri processi figli in nginx (PID 9691, PID 9942), rendendo invisibile la sua presenza ai tool di monitoring standard.
Persistenza systemd automatica: il servizio your-redtail.service riavvia automaticamente il miner ad ogni crash, garantendo continuita' operativa anche in ambienti ostili.
Estrazione completa della configurazione C2: attraverso l'analisi del core dump del processo mascherato, e' stata isolata la lista completa dei proxy di mining su porta TCP 2137.
Schema di autenticazione IP-based: l'assenza deliberata di un wallet address nella configurazione estratta indica un'autenticazione proxy-side basata sull'IP sorgente del server infettato, una misura anti-forensica sofisticata.

Hash del campione: l'hash SHA-256 completo del binario analizzato e' disponibile su richiesta diretta a info@nerdherd.it per team SOC, ricercatori di sicurezza e fornitori MSSP che necessitino di aggiornare le proprie signature o feed di threat intelligence.

2. Attribution e Threat Actor: RedTail Group

Il gruppo RedTail e' documentato nella letteratura di threat intelligence (Talos, Akamai) a partire dal 2024, con campagne focalizzate sull'exploitation di vulnerabilita' note in dispositivi di rete perimetrali e applicazioni web esposte su infrastrutture Linux. A differenza degli operatori di cryptominer generici (che usano XMRig precompilato con pool pubbliche), RedTail si distingue per tre caratteristiche che evidenziano una maggiore sofisticazione.

Infrastruttura C2 privata e dedicata. Le pool di mining non sono pubbliche (come Mining Pool Hub o supportxmr.com), bensì proxy privati con domini registrati appositamente e comunicazione su porta custom TCP 2137. Questo ostacola il rilevamento basato su blocklist di domini di mining pubblici e rende difficile la correlazione con altre campagne.

Codice custom e implementazione originale. La presenza della costante 0x6c078965 come seed LCG e l'implementazione di un motore di decifratura in memoria completamente custom (anziché librerie standard) indica uno sviluppo originale, non un fork di tool aperti. Questo e' un marcatore di attribution forte e distingue RedTail da commodity malware.

Overlap con TTP di gruppi APT. Le tecniche di anti-debugging (double forking, scansione ciclica di /proc), la persistenza tramite systemd e il process masquerading sono caratteristiche tipicamente associate a gruppi con motivazione finanziaria avanzata, che operano con metodologie mutuate dal panorama APT pur mantenendo un obiettivo primario di monetizzazione.

Profilo di rischio: Obiettivo primario: monetizzazione tramite mining Monero (XMR). Vettori di accesso documentati: exploitation RCE su perimeter devices e applicazioni web. Capacita' laterali: moduli per propagazione nell'infrastruttura interna. Infrastruttura C2: proxy privati su porta TCP 2137 con TLS custom.

3. MITRE ATT&CK Mapping (Enterprise v14, Linux)

Le tecniche osservate nelle due fasi dell'analisi (statica e dinamica) sono state mappate al framework MITRE ATT&CK for Linux. La copertura e' completa dalla fase di esecuzione iniziale all'impatto finale.

Tattica	ID	Nome Tecnica	Evidenza Osservata	Fonte
Execution	T1059.004	Unix Shell	Esecuzione tramite shell per drop e avvio del payload ELF da `/tmp`	Analisi statica
Defense Evasion	T1027	Obfuscated Files / Info	Configurazione C2 cifrata in memoria tramite LCG PRNG con costante `0x6c078965`. Nessuna stringa C2 in chiaro nel binario.	Analisi statica (Ghidra)
Defense Evasion	T1055	Process Injection / Masquerading	Rinomina dei processi figli in `nginx` (PID 9691, 9942). Confusione con web server legittimo.	Analisi dinamica (kernel log)
Defense Evasion	T1622	Debugger Evasion	Double forking del processo padre. Il figlio orfano disorienta i debugger che non seguono automaticamente i child process.	Analisi statica
Discovery	T1057	Process Discovery	Scansione ciclica di `/proc` alla ricerca di GDB, Wireshark, `watch` e altri tool di analisi. In caso di rilevamento: terminazione del processo analizzato o self-termination.	Analisi statica
Persistence	T1543.002	Systemd Service	Creazione e avvio dell'unita' `your-redtail.service` con policy di restart automatico. Confermata da log systemd in analisi dinamica.	Analisi dinamica (systemd log)
Privilege Escalation	T1548.003	Sudo / PolicyKit	Richiesta privilege escalation tramite PolicyKit/Sudo per ottenere accesso root. Necessario per installazione moduli kernel e modifica profonda dei parametri di rete.	Analisi dinamica
Command & Control	T1071	App Layer Protocol	Protocollo Stratum (mining) su porta TCP custom 2137 con TLS. 5 proxy dedicati su domini registrati ad hoc. Estratti da core dump.	Memory forensics (core dump)
Impact	T1496	Resource Hijacking	Cryptomining Monero tramite XMRig custom su infrastruttura proxy privata. Nessun wallet hardcoded: autenticazione IP-based lato proxy.	Memory forensics (core dump)

4. Infection Chain e Kill Chain

La ricostruzione della catena di infezione, basata sull'analisi combinata del binario e dei log di sistema dell'honeypot, descrive le seguenti fasi sequenziali.

Fase 1 — Initial Access via RCE T1059.004

Sfruttamento di una vulnerabilita' di Remote Code Execution su un servizio esposto (perimeter device o applicazione web). Il vettore specifico non e' determinabile dall'analisi del binario, in linea con la natura dell'honeypot come sistema di attrazione passiva.

Fase 2 — Payload Drop e Staging

Il dropper scarica l'ELF malevolo in una directory temporanea (/tmp o /dev/shm), imposta i permessi di esecuzione e avvia il processo. L'uso di directory scrivibili senza montaggio noexec e' un indicatore procedurale costante nelle campagne RedTail.

Fase 3 — Decifratura C2 in memoria T1027

All'avvio, il binario esegue il motore LCG con seed 0x6c078965 per decifrare in memoria la configurazione JSON delle pool. Nessuna stringa C2 e' presente in chiaro nel binario su disco: l'analisi statica senza dump di memoria e' sostanzialmente cieca.

Fase 4 — Anti-Analysis & Debugger Evasion T1622T1057

Double forking per orfanizzare il processo figlio. Avvio del ciclo di scansione /proc alla ricerca di tool di analisi. Il process masquerading verso nginx avviene in questa fase, prima dell'avvio dell'attivita' di mining.

Fase 5 — Persistenza systemd T1543.002

Creazione dell'unita' your-redtail.service con policy Restart=always. Ogni crash del processo (es. per connettivita' assente nell'honeypot isolato) viene gestito da systemd con riavvio automatico e spawn di un nuovo processo mascherato.

Fase 6 — Cryptomining C2 T1071T1496

Connessione verso i proxy su porta TCP 2137 con protocollo Stratum. Il processo mascherato come nginx trasmette le hash-rate all'infrastruttura proxy privata. L'autenticazione avviene lato proxy tramite IP sorgente, senza wallet hardcoded nel binario.

5. Analisi Statica: PRNG Engine e Offuscamento C2

L'analisi del binario tramite Ghidra ha rivelato l'assenza totale di stringhe di configurazione in chiaro. Il malware implementa un motore di generazione pseudo-casuale (Linear Congruential Generator, LCG) utilizzato come primitiva crittografica per decifrare in memoria la configurazione operativa.

5.1 Il Motore LCG: Costante Identificativa 0x6c078965

La costante 0x6c078965 e' il seed/moltiplicatore del generatore LCG. Questa scelta non e' casuale: e' un valore noto nel panorama dei generatori pseudo-casuali (utilizzato tra l'altro come moltiplicatore nell'implementazione Mersenne Twister di alcuni sistemi), ma applicato in modo non standard come primitiva di decifratura. La sua presenza nel binario costituisce una firma statica ad alta affidabilita' per il rilevamento di varianti della stessa famiglia.

Seed iniziale
0x6c078965

→

XOR / shift
iterazioni N

→

Keystream
generato

→

XOR con
dati cifrati

→

Config JSON
in memoria

Il risultato operativo e' che il binario su disco non contiene alcuna informazione sfruttabile per identificare l'infrastruttura C2 tramite analisi statica tradizionale. Solo un dump della memoria volatile del processo in esecuzione rivela la configurazione in chiaro.

5.2 Implicazioni per il rilevamento automatico

Le regole YARA basate su stringhe di URL di mining, nomi di dominio o configurazioni JSON sono inefficaci contro questo campione. Un'efficace firma YARA per questa famiglia deve invece cercare:

// Regola YARA per la famiglia RedTail (frammento)
rule RedTail_LCG_Constant {
    meta:
        description = "Rileva la costante LCG caratteristica della famiglia RedTail"
        author      = "Nerd Herd Threat Intelligence - Matteo Di Foggia"
        date        = "2026-04-14"
        tlp         = "WHITE"
    strings:
        $lcg_const = { 65 89 07 6C }   // 0x6c078965 little-endian
        $lcg_const_be = { 6C 07 89 65 } // big-endian variant
        $elf_magic = { 7F 45 4C 46 02 01 } // ELF64 magic
    condition:
        $elf_magic at 0 and ($lcg_const or $lcg_const_be)
}

// NH-YARA-2026-04-14 — TLP:WHITE — Nerd Herd Threat Intelligence

6. Analisi Dinamica: Tecniche di Anti-Debugging

L'analisi dinamica nell'ambiente honeypot isolato ha confermato e approfondito i meccanismi di evasione identificati staticamente. Due tecniche meritano una trattazione dettagliata per le implicazioni pratiche sul threat hunting.

6.1 Double Forking (T1622)

Il processo padre (redtail_analysis.bin) genera un figlio tramite fork() e termina immediatamente (exit()). Il figlio viene adottato da init (PID 1) o da systemd, diventando un processo orfano. Questo comportamento e' deliberato: i debugger tradizionali come GDB, in assenza dell'opzione follow-fork-mode child, perdono il tracciamento del processo al momento del fork del padre. L'analista inesperto si trova a debuggare un processo che ha gia' terminato, mentre l'attivita' malevola prosegue nel figlio orfano.

# Comportamento osservato nel log del kernel (semplificato)
$ strace -f ./redtail_analysis.bin 2>&1 | head -30

[9688] execve("/tmp/redtail_analysis.bin", ...) = 0
[9688] fork()                               = 9689   # primo fork
[9688] exit(0)                              # padre termina subito
[9689] fork()                               = 9691   # secondo fork (figlio diventa nonno)
[9689] exit(0)                              # figlio-intermedio termina
[9691] prctl(PR_SET_NAME, "nginx", ...)    # nipote si rinomina
[9691] # <-- processo orfano adottato da systemd, ora mascherato

6.2 Scansione ciclica di /proc (T1057)

Il malware esegue un loop periodico che enumera tutte le directory numeriche in /proc/ (corrispondenti ai PID attivi) e legge il file /proc/[PID]/cmdline di ciascun processo alla ricerca di stringhe indicative di analisi: gdb, wireshark, strace, ltrace, watch, tcpdump. In caso di match, il malware reagisce con una delle due strategie identificate in analisi statica: terminazione del processo rilevato (se i permessi lo consentono) oppure auto-terminazione per evitare l'analisi.

Implicazione per il threat hunting: l'uso di tool standard come top, htop o watch ps aux per il monitoring dei processi potrebbe innescare la logica di auto-terminazione del malware, rimuovendo l'artefatto prima che sia possibile raccogliere prove. L'approccio corretto e' il dump del processo in memoria (gcore) prima di qualsiasi interazione con il sistema.

7. Analisi Dinamica Avanzata: Process Masquerading ↑ UPDATE 14/04

L'analisi dei log del kernel dell'honeypot (fase 2 dell'indagine, 14 Aprile 2026) ha fornito la prova definitiva del process masquerading. I log dinamici mostrano il flusso completo dalla creazione del processo originale alla rinomina in nginx, con la successiva gestione del ciclo di crash e restart da parte di systemd.

7.1 Albero dei processi osservato

Il seguente albero di processi e' stato ricostruito dai log del kernel. I PID effettivi variano ad ogni ciclo di restart, ma il pattern strutturale e' consistente.

systemd (PID 1) └── your-redtail.service └── redtail_analysis.bin (PID 9688, da /tmp) ├── nginxMASQUERADING (PID 9691, child 1) │ path reale: /tmp/redtail_analysis.bin │ connessione: proxies.internetshadow.org:2137 └── nginxMASQUERADING (PID 9942, child 2 dopo restart) path reale: /tmp/redtail_analysis.bin status: SIGFAULT (connettivita' honeypot assente) --- nginx (legittimo) (PID 1203, da /usr/sbin/nginx) Processo web server autentico: path e comportamento differenti. Tool come 'ps aux' mostrano entrambi come 'nginx': distinzione possibile SOLO correlando nome processo con path binario reale.

La tecnica e' particolarmente insidiosa perche' ps aux, top, htop e la maggior parte dei tool di monitoring mostrano il nome del processo come configurato tramite prctl(PR_SET_NAME, "nginx"), non il path del binario originale. Solo strumenti come ls -la /proc/[PID]/exe o query SIEM che correlano nome processo con path binario possono smascherare questa tecnica.

# Rilevamento del masquerading: correlazione nome vs path reale
$ for pid in $(pgrep nginx); do
    echo "PID: $pid"
    echo "  Nome: $(cat /proc/$pid/comm)"
    echo "  Path: $(readlink /proc/$pid/exe)"
    echo "  CWD:  $(readlink /proc/$pid/cwd)"
  done

# Output atteso su sistema compromesso:
PID: 1203
  Nome: nginx
  Path: /usr/sbin/nginx          <-- legittimo
  CWD:  /var/www
PID: 9691
  Nome: nginx
  Path: /tmp/redtail_analysis.bin <-- ANOMALO: path in /tmp
  CWD:  /tmp

// Comando di threat hunting per identificare nginx spoofato

7.2 Il ciclo di crash e restart

Nell'ambiente honeypot isolato (privo di connettivita' verso i proxy C2), il processo mascherato va in segfault ripetutamente a causa del fallimento delle connessioni TCP verso proxies.internetshadow.org:2137. Systemd rileva il crash tramite la policy Restart=always e riavvia il servizio, generando un nuovo processo figlio che si rinomina nuovamente in nginx. Questo loop e' stato osservato ripetutamente nei log e spiega la richiesta di escalation dei privilegi rilevata durante il monitoraggio attivo dell'honeypot: ogni restart genera una nuova richiesta PolicyKit.

8. Memory Forensics: Estrazione Configurazione C2 da Core Dump ↑ UPDATE 14/04

La fase piu' critica dell'indagine del 14 Aprile e' stata l'estrazione della configurazione C2 decifrata direttamente dalla memoria del processo mascherato. Utilizzando il core dump generato automaticamente (core.4104), gli investigatori hanno eseguito analisi forensi avanzate che hanno rivelato la lista completa dei proxy di mining in chiaro.

8.1 Metodologia di estrazione

Il comando chiave utilizzato per l'estrazione sfrutta la capacita' di strings di estrarre sequenze di caratteri ASCII leggibili dal dump binario, filtrate in prossimita' di un pattern noto (il dominio primario identificato da una ricerca preliminare):

# Fase 1: identificazione pattern nel core dump
$ strings core.4104 | grep -i "internetshadow"
proxies.internetshadow.org
proxies.internetshadow.link

# Fase 2: estrazione del contesto (15 righe prima e dopo il match)
$ strings core.4104 | grep -iC 15 "proxies.internetshadow.org"

# Output (selezione pertinente):
"pools": [
  { "nicehash": true, "url": "proxies.internetshadow.org:2137" },
  { "nicehash": true, "url": "proxies.internetshadow.link:2137" },
  { "nicehash": true, "url": "proxies.identities.network:2137" },
  { "nicehash": true, "url": "proxies.insanitycpp.cx:2137" },
  { "nicehash": true, "url": "proxies.insanecppdev.com:2137" }
]

// Estrazione da core.4104 — configurazione decifrata dal motore LCG — NH-TR-2026-04-14

Perche' il core dump e' essenziale: questo risultato non sarebbe raggiungibile tramite analisi del binario su disco, dove la configurazione e' cifrata con il motore LCG. Solo dopo che il processo ha decrittato la configurazione in memoria e' possibile estrarla. La generazione automatica di core dump (/proc/sys/kernel/core_pattern) negli ambienti di analisi e' quindi una prassi forense indispensabile per questa famiglia.

8.2 Mappa dell'infrastruttura C2

I cinque proxy estratti costituiscono una rete di mining privata dedicata. L'utilizzo del protocollo NiceHash Stratum (flag "nicehash": true) indica che il traffic di mining e' formattato secondo lo standard NiceHash, ma diretto verso proxy privati che probabilmente aggregano l'hash-rate verso pool finali non identificabili lato client.

redtail_analysis.bin
(mascherato come nginx)

Host infettato • porta sorgente random

↓ ↓ ↓

Stratum over TCP • NiceHash protocol • TLS custom • porta 2137

proxies.internetshadow.org

:2137 / TCP

Proxy primario • NiceHash Stratum

proxies.internetshadow.link

:2137 / TCP

Proxy secondario • NiceHash Stratum

proxies.identities.network

:2137 / TCP

Proxy alternativo • NiceHash Stratum

proxies.insanitycpp.cx

:2137 / TCP

Proxy alternativo • NiceHash Stratum

proxies.insanecppdev.com

:2137 / TCP

Proxy alternativo • NiceHash Stratum

↓ ↓ ↓

Aggregazione hash-rate • autenticazione IP-based lato proxy

Pool XMR finale
(non identificabile lato client)

Infrastruttura threat actor • wallet anonimizzato

9. Analisi del Wallet: Il Missing Link e lo Schema IP-Based ↑ UPDATE 14/04

Una delle scoperte piu' significative dell'analisi del core dump e' la deliberata assenza del campo wallet (campo "user") nella configurazione JSON estratta. Ogni oggetto pool contiene esclusivamente i campi nicehash e url, senza alcuna stringa che identifichi il destinatario dei proventi del mining.

// Configurazione ATTESA (mining standard con wallet hardcoded)
{
  "pools": [{
    "nicehash": true,
    "url": "pool.example.com:4444",
    "user": "4AdUndXHHZ...XMR_WALLET...9A3bWB",  // <-- PRESENTE
    "pass": "x"
  }]
}

// Configurazione ESTRATTA da RedTail (wallet assente)
{
  "pools": [{
    "nicehash": true,
    "url": "proxies.internetshadow.org:2137"
    // campo "user" completamente assente
    // campo "pass" completamente assente
  }]
}

Questa assenza non e' un errore di implementazione: e' una misura anti-forensica deliberata. Le implicazioni operative sono le seguenti.

Attribution bloccata: il wallet Monero e' l'identificatore principale del threat actor nelle analisi forensi di campagne di cryptojacking. Senza un wallet hardcoded nel binario o nella configurazione, non e' possibile correlare questa campagna ad altre tramite la traccia on-chain di Monero.

Schema di autenticazione IP-based lato proxy: il proxy riceve la connessione Stratum dal server infettato e lo autentica basandosi sull'IP sorgente del client. Questo implica che i server compromessi sono pre-registrati (o aggiunti dinamicamente) nell'infrastruttura proxy, probabilmente tramite un canale di controllo separato non identificato in questa analisi. L'hash-rate del server viene accreditato al wallet dell'operatore senza che il wallet sia mai esposto nel malware.

Infrastruttura proxy altamente professionale: gestire 5 proxy con autenticazione IP-based richiede un'infrastruttura dedicata significativamente piu' complessa di una semplice pool pubblica. Questo conferma il profilo di un operatore con risorse e competenze tecniche superiori alla media dei commodity miner.

Intelligence finding critico: lo schema IP-based implica che bloccare il traffico verso i proxy C2 (porta 2137) e' l'unica misura di interdizione efficace. Non esiste un wallet da blocklist, non esiste una firma di autenticazione da intercettare. La difesa si riduce al blocco perimetrale del traffico in uscita su porta 2137 verso questi domini specifici.

10. Persistenza e Privilege Escalation

10.1 Unita' systemd: your-redtail.service (T1543.002)

L'analisi dei log di sistema ha confermato la creazione e l'avvio dell'unita' systemd dedicata. Il nome del servizio (your-redtail.service) e' atipico per un sistema di produzione e costituisce un IoC ad alta affidabilita' per il rilevamento automatizzato tramite SIEM.

# Contenuto ricostruito del file unit systemd
# Path: /etc/systemd/system/your-redtail.service

[Unit]
Description=Redtail Service service
After=network.target

[Service]
Type=forking
ExecStart=/tmp/redtail_analysis.bin
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

// Struttura dell'unita' systemd ricostruita da analisi log — valori esatti potrebbero variare tra varianti

La policy Restart=always con RestartSec=5 garantisce che ogni crash (inclusi i segfault causati dall'assenza di connettivita' ai proxy nell'honeypot isolato) venga seguito da un riavvio automatico entro 5 secondi. Nei log del kernel e' stato osservato questo loop ripetuto decine di volte durante la sessione di analisi.

10.2 Privilege Escalation via PolicyKit (T1548.003)

Il malware ha tentato la scalata dei privilegi invocando il servizio PolicyKit (polkit) e/o Sudo per ottenere accesso root. L'accesso root e' necessario per due obiettivi specifici: l'installazione di moduli kernel (per hiding piu' profondo o l'ottimizzazione della CPU per il mining) e la modifica dei parametri di rete a livello di sistema. Nell'honeypot isolato, la richiesta di autenticazione PolicyKit e' stata il segnale operativo che ha innescato l'analisi approfondita da parte del team Nerd Herd.

11. Indicatori di Compromissione (IoC) — Completo

La seguente tabella consolida tutti gli IoC identificati nelle due fasi dell'analisi. I valori sono pubblicati in formato TLP:WHITE e possono essere liberamente integrati in firewall, blocklist, SIEM e feed di threat intelligence.

Tipo	Valore	Descrizione	Confidence
SHA-256	46AB28**********************EB130A	Hash del campione malevolo (hash parzialmente censurato, disponibile su richiesta)	HIGH
Dominio C2	proxies.internetshadow.org	Proxy di mining primario, porta 2137	HIGH
Dominio C2	proxies.internetshadow.link	Proxy di mining secondario, porta 2137	HIGH
Dominio C2	proxies.identities.network	Proxy di mining alternativo, porta 2137	HIGH
Dominio C2	proxies.insanitycpp.cx	Proxy di mining alternativo, porta 2137	HIGH
Dominio C2	proxies.insanecppdev.com	Proxy di mining alternativo, porta 2137 (UPDATE 14/04)	HIGH
Porta / Proto	2137 / TCP	Porta custom Stratum per tutto il traffico C2. Bloccare in uscita.	HIGH
Processo (reale)	redtail_analysis.bin	Nome originale del processo malevolo, eseguito da `/tmp`	HIGH
Processo (mascherato)	nginx	Nome spoofato tramite prctl(). Rilevabile solo correlando nome con path reale in /proc/[PID]/exe	MEDIUM
Servizio systemd	your-redtail.service	Nome dell'unita' di persistenza systemd. IoC ad alta affidabilita' per SIEM.	HIGH
Costante LCG	0x6c078965	Seed/moltiplicatore LCG per decifratura C2 in memoria. Firma statica YARA.	HIGH

12. Piano di Remediation e Azioni Obbligatorie

Le seguenti azioni sono ordinate per priorita' operativa. I passi 1-3 devono essere eseguiti nell'ordine indicato per evitare di allertare il malware prima della raccolta delle prove.

1

Blocco immediato traffico C2 (porta 2137)

Prima azione da eseguire, a livello firewall perimetrale e host-based (iptables/nftables). Interdire tutto il traffico TCP in uscita verso porta 2137. Questo isola il malware senza allertarlo direttamente. Aggiungere blocklist con i 5 domini identificati.
# iptables: blocco in uscita porta 2137 iptables -A OUTPUT -p tcp --dport 2137 -j DROP # o con nftables nft add rule inet filter output tcp dport 2137 drop
2

Core dump e raccolta prove prima della rimozione

Prima di terminare il processo, generare un core dump per preservare la configurazione C2 in chiaro e ogni altro artefatto in memoria. Questo e' critico per analisi forensi successive e per l'eventuale presentazione di prove.
# Identificare il PID del processo nginx anomalo for pid in $(pgrep nginx); do echo "$pid: $(readlink /proc/$pid/exe)" done # Generare core dump del PID anomalo (path in /tmp) gcore -o /secure/evidence/redtail_$(date +%s) [PID_ANOMALO]
3

Disattivazione e rimozione del servizio systemd

Fermare il servizio, disabilitarlo e rimuovere il file unit fisico da disco.
sudo systemctl stop your-redtail.service sudo systemctl disable your-redtail.service # Rimuovere il file unit fisico sudo rm /etc/systemd/system/your-redtail.service # oppure sudo rm /lib/systemd/system/your-redtail.service sudo systemctl daemon-reload
4

Terminazione processi nginx anomali e rimozione binari

Verificare che non esistano processi nginx con path binario anomalo (fuori da /usr/sbin/ o /usr/bin/). Rimuovere i binari malevoli da /tmp, /dev/shm e altre directory temporanee scrivibili.
5

Audit log e stima della finestra di infezione

Verificare /var/log/auth.log per tentativi di escalation dei privilegi. Esaminare journalctl -u your-redtail.service per determinare il timestamp di creazione del servizio e stimare da quanto tempo il sistema e' compromesso. Cercare connessioni storiche verso porta 2137 nei log firewall.
6

Verifica integrita' sistema e threat hunting su infrastruttura

Eseguire verifica integrita' dei binari di sistema con debsums (Debian/Ubuntu) o rpm -V (RHEL/CentOS). Estendere il threat hunting all'intera infrastruttura cercando: connessioni attive porta 2137, presenza libreria libredtail, file ELF in /tmp o /dev/shm, servizi systemd con nomi atipici, chiavi SSH non autorizzate in ~/.ssh/authorized_keys.

13. Lessons Learned

L'honeypot come early warning reale: insostituibile per questa tipologia di minaccia

La rilevazione e' avvenuta esclusivamente grazie al deployment di un honeypot proprietario configurato ad hoc per il profilo di rischio del cliente. Un sistema di monitoring tradizionale (antivirus, IDS basato su firme, SIEM senza correlazione comportamentale) avrebbe con alta probabilita' classificato il traffico come manutenzione ordinaria del web server nginx, o non lo avrebbe rilevato affatto. L'honeypot proprietario Nerd Herd ha trasformato un attacco silenzioso in un segnale operativo chiaro.

L'analisi statica da sola e' insufficiente per questa famiglia

Il motore LCG con costante 0x6c078965 rende le stringhe C2 completamente invisibili in analisi statica tradizionale. Strumenti come strings, ricerche di URL/IP nel binario, o analisi superficiale con Ghidra senza identificare il motore di decifratura non avrebbero prodotto alcuna informazione sull'infrastruttura C2. Solo il dump della memoria volatile ha permesso l'estrazione della configurazione in chiaro. Questo sottolinea l'importanza dell'analisi dinamica in ambienti controllati come componente obbligatorio del workflow di threat intelligence.

Il process masquerading aggira i tool standard di monitoring

La rinomina in nginx tramite prctl(PR_SET_NAME) ha reso il processo invisibile a top, ps aux e a qualsiasi tool di monitoring che non correli il nome del processo con il path reale del binario. Un operatore non addestrato, vedendo due istanze di nginx in un server web, non avrebbe rilevato l'anomalia. Il threat hunting efficace su questa tecnica richiede la correlazione sistematica nome processo vs. /proc/[PID]/exe, una pratica che deve essere integrata nelle procedure SOC standard.

Il nome del servizio systemd e' un IoC forte per l'automazione SIEM

Il nome your-redtail.service e' atipico per qualsiasi sistema di produzione Linux. Implementare una regola SIEM che avvisi sulla creazione di nuovi servizi systemd con nomi che non appartengono a una lista bianca approvata e' una misura di detection ad alto rapporto segnale/rumore per questa tecnica di persistenza. Il costo implementativo e' basso, la copertura e' alta.

Lo schema IP-based ridefinisce la strategia di defense a lungo termine

L'assenza di un wallet hardcoded e l'autenticazione proxy-side basata su IP sorgente e' un'intelligence finding che impatta la strategia difensiva oltre la singola remediation. Indica che il threat actor mantiene una lista di server compromessi e attivi, potenzialmente con capacita' di re-targeting. Il blocco dei proxy e la remediation completa devono essere accompagnati da un monitoraggio prolungato per tentativi di re-infezione tramite vettori alternativi, in quanto il server potrebbe essere ancora "censito" nell'infrastruttura dell'operatore.

14. Conclusione

Il laboratorio forense di Nerd Herd ha decostruito con successo tutti i layer di evasione e persistenza della variante RedTail identificata il 13-14 Aprile 2026. L'operazione ha richiesto due fasi distinte: l'analisi statica del 13 Aprile, che ha identificato il motore LCG e le tecniche di anti-debugging, e l'analisi dinamica del 14 Aprile da core dump, che ha fornito la prova definitiva del process masquerading e l'estrazione completa dell'infrastruttura C2.

Le quattro scoperte principali di questa indagine hanno implicazioni concrete sulla strategia di difesa dell'organizzazione interessata e, piu' in generale, su qualsiasi infrastruttura Linux esposta a questo threat actor.

L'infrastruttura proxy privata su internetshadow.org:2137 e gli altri quattro domini identificati e' ora "cieca" sulla rete del cliente: il blocco del traffico sulla porta 2137 verso questi domini costituisce una misura di interdizione completa. La scoperta dello schema di autenticazione IP-based e' un'informazione di intelligence di valore per l'intera community di sicurezza che monitora questo cluster di attivita'.

L'honeypot proprietario Nerd Herd ha contenuto la minaccia con successo. Il threat e' isolato. La produzione e' sicura.

Per le organizzazioni che vogliono verificare la propria esposizione: contattaci per una valutazione della superficie di attacco e per discutere il deployment di soluzioni di rilevamento attivo (honeypot, threat hunting, SIEM con correlazione comportamentale) calibrate sul proprio profilo di rischio. Il team Nerd Herd opera a Parma, nell'Emilia Romagna e in tutta Italia in modalita' on-site e remota. Contattaci per una valutazione iniziale.

Threat Intelligence RedTail Botnet Memory Forensics MITRE ATT&CK Linux Malware Process Masquerading Cryptojacking Honeypot TLP:WHITE

Operazione RedTail: Analisi Tecnica Avanzata di una Variante Botnet Linux ELF con Process Masquerading e Infrastruttura C2 Privata

1. Executive Summary

2. Attribution e Threat Actor: RedTail Group

3. MITRE ATT&CK Mapping (Enterprise v14, Linux)

4. Infection Chain e Kill Chain

5. Analisi Statica: PRNG Engine e Offuscamento C2

5.1 Il Motore LCG: Costante Identificativa 0x6c078965

5.2 Implicazioni per il rilevamento automatico

6. Analisi Dinamica: Tecniche di Anti-Debugging

6.1 Double Forking (T1622)

6.2 Scansione ciclica di /proc (T1057)

7. Analisi Dinamica Avanzata: Process Masquerading ↑ UPDATE 14/04

7.1 Albero dei processi osservato

7.2 Il ciclo di crash e restart

8. Memory Forensics: Estrazione Configurazione C2 da Core Dump ↑ UPDATE 14/04

8.1 Metodologia di estrazione

8.2 Mappa dell'infrastruttura C2

9. Analisi del Wallet: Il Missing Link e lo Schema IP-Based ↑ UPDATE 14/04

10. Persistenza e Privilege Escalation

10.1 Unita' systemd: your-redtail.service (T1543.002)

10.2 Privilege Escalation via PolicyKit (T1548.003)

11. Indicatori di Compromissione (IoC) — Completo

12. Piano di Remediation e Azioni Obbligatorie

13. Lessons Learned

14. Conclusione