Spcnet.it

2026-07-23 16:40:29

CVE-2026-8933: come una race condition in snap-confine dà root su Ubuntu Desktop

Una race condition nascosta nel cuore del sandboxing di Snap

Il 21 luglio 2026 il Threat Research Unit di Qualys ha reso pubblica CVE-2026-8933, una vulnerabilità di local privilege escalation (LPE) che colpisce snap-confine, il componente che costruisce l’ambiente sandbox per le applicazioni Snap su Ubuntu. Il difetto, classificato come “High” severity, permette a un utente locale non privilegiato di ottenere accesso root completo sulle installazioni di default di Ubuntu Desktop 24.04, 25.10 e 26.04.

La cosa interessante, dal punto di vista di chi amministra sistemi Linux, non è tanto la gravità in sé (le LPE locali sono un classico), quanto come ci si è arrivati: una modifica pensata per aumentare la sicurezza ha introdotto, per effetto collaterale, una finestra di race condition sfruttabile.

Perché snap-confine è cambiato

snap-confine è il binario che Canonical usa per costruire l’ambiente isolato in cui gira ogni applicazione Snap: monta i namespace, applica i profili AppArmor/seccomp e prepara le directory temporanee di lavoro. Storicamente era un binario set-uid-root: partiva già con i privilegi di root e li abbandonava progressivamente.

Per ridurre la superficie d’attacco, Canonical ha migrato snap-confine a un modello basato su set-capabilities: il processo ora gira con l’UID effettivo dell’utente chiamante, ma mantiene comunque delle capability quasi-root (tra cui CAP_SYS_ADMIN e simili) necessarie per completare il setup del sandbox. È un cambiamento in linea con il principio del least privilege, ma ha spostato il problema: durante l’inizializzazione, le directory temporanee sotto /tmp vengono create con proprietario l’utente non privilegiato, e solo in un secondo momento la ownership passa a root. In quella finestra, per quanto stretta, l’attaccante ha ancora pieno controllo sui file.

La catena di exploit

Il team Qualys ha ricostruito un attacco che combina due race condition concorrenti:

• Bypass del mount namespace via FUSE: l’attaccante monta un filesystem FUSE sopra la directory temporanea di scratch appena creata, prima che snap-confine applichi l’isolamento tramite mount namespace. In questo modo la directory resta accessibile anche dall’esterno del sandbox.
• Symlink race su fchown(): l’attaccante sostituisce un file atteso con un symlink verso un target arbitrario. Quando snap-confine tenta di creare un file nel sandbox, la open() segue il symlink e scrive sul target reale. Una seconda race condition permette poi di allargare i permessi a 0666 prima che venga invocata fchown() per trasferire la ownership a root.
• Escalation via udev: per aggirare la confinazione AppArmor, l’exploit punta al percorso /run/udev/, che consente accesso in lettura/scrittura. Depositando un file .rules malevolo in /run/udev/rules.d/ e innescando un ciclo di mount/unmount FUSE, l’attaccante costringe il demone systemd-udevd a eseguire comandi arbitrari come root.

Il risultato finale: da semplice accesso locale non privilegiato a controllo completo del sistema, senza bisogno di interazione da parte di altri utenti.

Versioni coinvolte e patch disponibili

Sono interessate le release che spediscono di default la variante set-capabilities di snap-confine:

• Ubuntu Desktop 26.04
• Ubuntu Desktop 25.10
• Ubuntu Desktop 24.04 (con pacchetti snapd aggiornati)

Canonical ha rilasciato pacchetti snapd corretti, tra cui 2.76+ubuntu26.04.3 per Ubuntu 26.04, 2.76+ubuntu24.04.1 per Ubuntu 24.04 e 2.76+ubuntu22.04.1 per Ubuntu 22.04. La disclosure è stata coordinata con l’Ubuntu Security Team.

Come verificare se un sistema è vulnerabile

Per controllare la versione di snapd installata:

snap version
apt-cache policy snapd

Se la versione del pacchetto snapd è precedente a quelle corrette indicate sopra, il sistema va aggiornato immediatamente:

sudo apt update
sudo apt install --only-upgrade snapd
snap version

Per un controllo su larga scala, chi usa strumenti di vulnerability management (Qualys CSAM o equivalenti) può cercare asset con sistema operativo Ubuntu e pacchetto snapd installato, incrociando poi la versione con quella patchata.

Mitigazioni in attesa della patch

Se non è possibile applicare l’aggiornamento immediatamente, alcune contromisure temporanee riducono l’esposizione:

• Limitare l’accesso a shell locale ai soli utenti fidati, specialmente su workstation condivise o ambienti multi-utente (lab, terminal server, VDI).
• Monitorare la creazione di regole udev non autorizzate sotto /run/udev/rules.d/, ad esempio con auditd:

• auditctl -w /run/udev/rules.d/ -p wa -k udev_rules_watch

• Disabilitare il montaggio FUSE per utenti non privilegiati dove non strettamente necessario, tramite policy su /etc/fuse.conf o restrizioni AppArmor aggiuntive.

Nessuna di queste misure sostituisce la patch ufficiale: sono palliativi utili solo per il tempo strettamente necessario a pianificare l’aggiornamento.

Conclusione

CVE-2026-8933 è un promemoria utile per chi progetta meccanismi di sandboxing e privilege dropping: il passaggio da set-uid a set-capabilities è, sulla carta, una scelta più sicura, ma introduce una superficie temporale (la finestra tra creazione del file e trasferimento della ownership) che va gestita con la stessa attenzione riservata alle race condition classiche nei binari set-uid. Per chi amministra flotte Ubuntu Desktop, la priorità pratica resta semplice: verificare le versioni di snapd installate, applicare la patch e, nel frattempo, restringere l’accesso shell locale dove possibile.

Fonte: Qualys Threat Research Unit – CVE-2026-8933: Local Privilege Escalation in Set-Capabilities snap-confine

CVE-2026-8933: Local Privilege Escalation in Ubuntu snap-confine | Qualys

Qualys TRU discovered CVE-2026-8933, a High-severity Local Privilege Escalation in snap-confine affecting Ubuntu Desktop 24.04, 25.10, and 26.04. Learn detection with Qualys QIDs and how to remediate.

^{Saeed Abbasi (Qualys)}

Spcnet.it

2026-07-23 16:40:42

Azure Event Grid Namespaces: Autoscale automatico per i workload di messaggistica dinamici

Il problema delle Throughput Unit statiche

Chi ha già lavorato con Azure Event Grid Namespaces conosce bene il concetto di Throughput Unit (TU): ogni TU definisce una capacità fissa di ingress/egress per gli eventi, di publish MQTT e di connessioni client MQTT. Fino ad oggi, il numero di TU andava impostato in fase di creazione del namespace e poi regolato manualmente ogni volta che il pattern di traffico cambiava — tipicamente sovradimensionando “per sicurezza” durante i picchi, con conseguente spreco di capacità (e di budget) nei periodi di bassa attività.

Microsoft ha da poco introdotto in public preview la funzionalità Autoscale per Event Grid Namespaces (tier Standard), che elimina questa gestione manuale: il servizio monitora il carico e regola automaticamente le TU tra un minimo e un massimo configurati dall’amministratore.

Come funziona Autoscale

Il funzionamento è deliberatamente semplice, in linea con la filosofia “meno configurazione, più automazione” che Azure sta applicando a diversi servizi PaaS. Event Grid valuta continuamente l’utilizzo su quattro categorie:

• Event ingress: tasso di eventi in ingresso sui namespace topic HTTP.
• Event egress: tasso di eventi in uscita verso i sottoscrittori.
• MQTT publish rate (inbound/outbound): frequenza dei messaggi pubblicati e ricevuti sul broker MQTT.
• MQTT client count: numero di client MQTT registrati e connessi.

Quando una qualunque di queste metriche supera la soglia di scale-up, il servizio aggiunge automaticamente Throughput Unit. Quando tutte le categorie scendono sotto la soglia di scale-down, le TU in eccesso vengono rilasciate. L’amministratore non definisce policy o soglie personalizzate: si limita a impostare i limiti minimo e massimo di TU, e Event Grid gestisce internamente le decisioni di scaling.

Un richiamo ai concetti di namespace

Per chi non ha ancora familiarità con il modello a namespace di Event Grid (distinto dai topic “classici” di Event Grid Basic), vale la pena ricordare la struttura:

• Un namespace è un contenitore di gestione che espone un FQDN unico e due endpoint: uno HTTP per i namespace topic, uno MQTT per scenari IoT.
• I namespace topic supportano sia la pull delivery (il consumer si collega ed estrae i messaggi con semantica queue-like) sia la push delivery (attualmente verso Event Hubs come destinazione).
• Gli eventi pubblicati devono rispettare lo standard CloudEvents 1.0 del CNCF, con binding HTTP e formato JSON.

Autoscale agisce a livello di namespace, quindi tutte le risorse contenute (topic, topic space MQTT, client, client group) beneficiano della stessa capacità elastica senza bisogno di scaling indipendente per ciascuna.

Abilitare Autoscale: portale, ARM e REST API

La funzionalità, essendo in preview, va abilitata esplicitamente. Dal portale Azure basta aprire il namespace Event Grid, andare nella sezione di configurazione della capacità e attivare l’opzione Autoscale specificando TU minime e massime.

Per chi gestisce l’infrastruttura as code, lo stesso risultato si ottiene via ARM template (o Bicep) impostando le proprietà di scaling sulla risorsa del namespace:

{
  "type": "Microsoft.EventGrid/namespaces",
  "apiVersion": "2025-04-01-preview",
  "name": "ns-iot-produzione",
  "location": "westeurope",
  "sku": {
    "name": "Standard",
    "capacity": 4
  },
  "properties": {
    "isZoneRedundant": true,
    "topicsConfiguration": {},
    "publicNetworkAccess": "Enabled",
    "topicSpacesConfiguration": {
      "state": "Enabled"
    }
  }
}

Nota: al momento della stesura la configurazione fine di Autoscale (min/max TU) va completata tramite portale o REST API dedicata, poiché lo schema ARM per questa preview è ancora in evoluzione — vale la pena controllare la pagina di supporto ufficiale prima di automatizzare il deployment in pipeline CI/CD.

Via REST API, la capacità del namespace si legge e modifica sulla stessa risorsa esposta dall’API di gestione di Event Grid:

GET https://management.azure.com/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.EventGrid/namespaces/{namespaceName}?api-version=2025-04-01-preview

Quando ha senso usarlo

Autoscale è pensato in particolare per due categorie di carico che chi lavora con architetture event-driven conosce bene:

• Workload IoT con MQTT: il numero di dispositivi connessi e il fan-out delle sottoscrizioni possono variare rapidamente (pensiamo a una flotta di sensori che si riattiva tutta insieme dopo un’interruzione di rete). Dimensionare le TU staticamente per il picco significa pagare capacità inutilizzata per la maggior parte del tempo.
• Event broker con traffico “a burst”: pipeline di ingestion che ricevono ondate di eventi correlate a batch job, deployment, o processi di business con picchi orari/giornalieri (fine mese, chiusura contabile, campagne marketing).

Per i .NET developer che costruiscono microservizi basati su eventi, questo significa poter progettare la sottoscrizione a namespace topic senza dover stimare a priori il traffico di picco con lo stesso margine di sicurezza richiesto finora — riducendo sia il rischio di throttling sotto carico sia i costi nei periodi di quiete.

Conclusione

Autoscale per Event Grid Namespaces arriva in un’area, il messaging event-driven, dove il dimensionamento manuale è da sempre un compromesso scomodo tra costo e resilienza. Essendo ancora in public preview, prima di adottarlo su workload di produzione critici vale la pena testarlo su un namespace non critico, verificando i tempi di reazione dello scaling automatico sotto carico reale e monitorando le metriche di throttling durante la fase di transizione tra un livello di TU e l’altro.

Fonte: Petri IT Knowledgebase – Azure Event Grid Namespaces Add Autoscale for Dynamic Messaging Workloads; concetti tecnici da Microsoft Learn – Concepts for Event Grid namespace topics

Microsoft Releases Autoscale for Azure Event Grid Namespaces

Microsoft has introduced Autoscale for Azure Event Grid Namespaces, allowing automatic capacity adjustments for event-driven and IoT workloads.

^{Rabia Noureen (Petri IT Knowledgebase)}

(in)sicurezza digitale

2026-07-23 16:36:53

Cl0p sfrutta una falla critica in PTC Windchill e FlexPLM: webshell ed estorsioni nella supply chain del manufacturing

Cl0p torna a colpire dove sa fare più male: non un endpoint qualsiasi, ma il software che tiene insieme la catena di progettazione e produzione di centinaia di aziende manifatturiere, automotive, aerospaziali e di abbigliamento. La gang, la stessa che ha reso celebri gli attacchi di massa contro MOVEit, GoAnywhere MFT e Accellion FTA, sta ora sfruttando una falla critica in PTC Windchill e FlexPLM per ottenere accesso non autenticato, installare webshell e avviare campagne di estorsione su scala industriale.

Un bersaglio scelto con cura: il PLM come infrastruttura critica invisibile

Windchill è la piattaforma di Product Lifecycle Management (PLM) di PTC usata da produttori e ingegneri per gestire distinte base, disegni CAD, cicli di revisione e conformità normativa. FlexPLM è la sua controparte pensata per retail, abbigliamento, calzature e beni di consumo. Sono, in sostanza, il “sistema nervoso” della progettazione di prodotto: chi compromette Windchill non ruba solo dati, ottiene la proprietà intellettuale che tiene in piedi intere linee produttive, spesso condivise con fornitori e terze parti a valle della catena. È esattamente il tipo di software “orizzontale ma invisibile” che Cl0p ha sempre preferito, sul modello già visto con MOVEit nel 2023: individuare una falla in un prodotto enterprise diffuso, sfruttarla in massa prima che le patch si diffondano, poi monetizzare i dati sottratti con estorsioni multiple.

La falla: CVE-2026-12569, CVSS 9.3

La vulnerabilità alla base della campagna è un caso di improper input validation legato alla deserializzazione di dati non attendibili in Windchill, che consente a un attaccante remoto e non autenticato di eseguire codice arbitrario con una singola richiesta malformata. Secondo l’advisory diffusa da ricercatori di threat intelligence (ecrime.ch) e ripresa dagli analisti, l’affiliato Cl0p osservato in queste settimane concatena due debolezze distinte: una falla di information disclosure nel WSDL di FlexPLM, che permette di mappare gli endpoint e raccogliere informazioni utili sull’istanza target, e una vulnerabilità nel servlet di login di Windchill, che consente di bypassare l’autenticazione e ottenere RCE. Il risultato è una catena di exploit pienamente “unauthenticated to RCE”, il tipo di primitiva che i gruppi ransomware più organizzati amano weaponizzare in pochi giorni.

PTC ha comunicato la vulnerabilità il 17 giugno 2026, rilasciando le prime patch il giorno successivo dopo aver confermato exploitation attiva in the wild. CISA ha inserito CVE-2026-12569 nel proprio Known Exploited Vulnerabilities (KEV) catalog il 25 giugno, imponendo alle agenzie federali statunitensi la remediation entro il 28 giugno: è la prima vulnerabilità di un prodotto PTC ad entrare nel KEV. In Germania, il BSI e la polizia federale (BKA) hanno avvisato direttamente le aziende esposte già dalla notte del 17 giugno, un déjà-vu rispetto a un’altra vulnerabilità RCE nelle stesse piattaforme (CVE-2026-4681) divulgata a marzo 2026.

Dalla falla alla webshell: la firma operativa dell’attacco

Una volta ottenuta l’esecuzione di codice, gli operatori osservati droppano webshell JSP persistenti seguendo uno schema di naming riconoscibile: file con nome esadecimale a 16 caratteri collocati sotto il percorso di login di Windchill. Da lì gestiscono comandi da remoto, effettuano attività di file-listing (lasciando spesso una traccia in un file temporaneo) ed esfiltrano dati prima di passare alla fase di estorsione, con email inviate direttamente alle organizzazioni colpite nei settori Manufacturing, Automotive, Aerospace e Retail/Apparel. Non risultano, al momento, evidenze pubbliche di deployment di ransomware “classico” con cifratura dei file: lo schema resta quello, tipico di Cl0p dal 2023 in poi, di furto massivo di dati seguito da doppia estorsione senza necessariamente criptare gli ambienti compromessi.

Due righe per i difensori: rischio supply chain, non solo perimetrale

Il vero elemento di rischio geopolitico e industriale qui non è la singola azienda compromessa, ma l’effetto a cascata: Windchill e FlexPLM sono spesso condivisi con OEM, fornitori Tier 1 e partner di co-design. Un accesso non autorizzato ai repository PLM significa potenziale esposizione di disegni tecnici, specifiche di materiali, cicli di produzione e roadmap di prodotto — informazioni che hanno valore sia per la criminalità organizzata in cerca di leva estorsiva, sia, in scenari più sensibili (difesa, aerospazio), per attori interessati allo spionaggio industriale. È lo stesso pattern di rischio già visto con gli attacchi a piattaforme di file transfer enterprise: la superficie non è l’endpoint dell’utente, ma il software B2B che nessuno vede ma su cui si regge la produzione.

• Applicare immediatamente le patch PTC per Windchill e FlexPLM (rilasciate dal 18 giugno 2026) su tutte le versioni supportate.
• Verificare la presenza di webshell nel percorso /Windchill/login/ con nomi esadecimali a 16 caratteri.
• Analizzare i log HTTP per richieste POST anomale verso gli endpoint di login e per l’header X-windchill-req.
• Bloccare al perimetro gli indirizzi IP noti come infrastruttura di comando e controllo.
• Limitare l’esposizione diretta a Internet dell’endpoint di login Windchill dove operativamente possibile, instradando l’accesso tramite VPN o gateway con MFA.
• Effettuare un controllo retrospettivo dei log di accesso per individuare eventuali esfiltrazioni avvenute prima della patch.

Indicatori di compromissione

# Indirizzi IP associati all'infrastruttura d'attacco
172.111.38.31
216.152.148.54
104.243.35.131
74.50.76.146
5.180.41.35   # C2 - bloccare immediatamente al perimetro
# Pattern webshell
/Windchill/login/[0-9a-f]{16}.jsp
# Hash file webshell (SHA-256)
55a1eb4c2d3da04376df39d7ba832569c6af1a37a0cf2b95f754ac898023a30c
# Marcatore di attivita di file-listing dell'attaccante
/tmp/flst.txt  (o nella working directory di Windchill)
# Header HTTP sospetto usato dagli operatori
X-windchill-req: *

Per i team di sicurezza che gestiscono ambienti PLM esposti, il messaggio è chiaro: la finestra tra disclosure pubblica e weaponization da parte di gruppi come Cl0p si è ormai ridotta a giorni, non settimane. Chi non ha ancora patchato Windchill o FlexPLM dovrebbe considerare l’ambiente potenzialmente già compromesso e agire di conseguenza, con hunting retroattivo prima ancora del solo deployment della patch.

(in)sicurezza digitale

2026-07-23 16:38:59

Cruciferra: il crypter da 2.000 dollari al mese che uccide gli EDR e fa sparire il malware dal disco

Sui forum underground si vende come “il crypter più letale del sottosuolo”. Cruciferra, in vendita dall’autunno 2025 su Exploit[.]in a partire da 450 dollari al mese fino a 2.000 per la versione completa, non è l’ennesimo offuscatore di malware: secondo un’analisi pubblicata da Proofpoint il 20 luglio, il servizio combina disattivazione degli EDR via driver vulnerabili, syscall indiretti, un motore di cifratura polimorfico con oltre 90 combinazioni di algoritmi e una variante custom della tecnica di Process Ghosting. Il risultato è un payload che gira in memoria senza mai esistere in forma scansionabile su disco.

Un “umbrella service” per decine di gruppi criminali scollegati tra loro

Cruciferra non è legato a un singolo attore: Proofpoint lo descrive come un servizio “ombrello”, utilizzato in decine di campagne indipendenti per proteggere payload molto diversi tra loro, da AsyncRAT e Agent Tesla a Remcos, XWorm, zgRAT, Formbook/XLoader, DarkCloud Stealer, Phantom Stealer, Snake Keylogger e ValleyRAT. Scritto in Mono, il crypter viene sempre eseguito tramite DLL side-loading: la vittima scarica un archivio contenente un eseguibile legittimo in apparenza e una DLL malevola, che viene caricata automaticamente al lancio del programma principale.

Tra i clienti identificati da Proofpoint figura TA4922, gruppo cinese di cybercrime già noto per l’espansione delle proprie campagne a livello globale. Tra fine aprile e inizio giugno 2026, TA4922 ha condotto almeno quattro campagne da poche centinaia di email ciascuna, con esche a tema fiscale che impersonavano l’Income Tax Department indiano per convincere le vittime a scaricare archivi ZIP contenenti il loader di AsyncRAT. Altre campagne osservate hanno sfruttato notifiche fasulle della Social Security Administration statunitense per distribuire XWorm e AdaptixC2 tramite file VHD, mentre una campagna di fine giugno ha usato reclami di ospiti su presunte cimici da letto per colpire il settore alberghiero con zgRAT.

Come Cruciferra acceca gli EDR

Prima ancora di eseguire il payload finale, Cruciferra dedica gran parte del proprio codice a rendersi invisibile agli strumenti di analisi e difesa. Il DLL principale contiene spesso centinaia o migliaia di funzioni esportate fittizie che puntano a codice spazzatura: solo una manciata di export porta effettivamente al codice malevolo, rendendo più difficile per un analista o un sandbox individuare il punto di ingresso reale. Il malware nasconde poi le finestre di console che potrebbero tradire un’infezione, tramite un thread in background che scandisce ripetutamente l’albero dei processi cercando finestre di classe “ConsoleWindowClass” da occultare con ShowWindow e SetWindowPos.

Sul fronte della telemetria, Cruciferra applica un unhooking sistematico delle funzioni monitorate da EDR e antivirus, ripristinando una copia pulita delle DLL di sistema in memoria per rimuovere gli hook installati dai prodotti di sicurezza. Ricorre inoltre a syscall indiretti: legge una copia pulita di ntdll.dll dal disco e ne conserva gli stub in una struttura globale, così da invocare le API senza passare dagli hook inline che gli EDR installano solitamente su ntdll.dll. A completare il quadro, il malware ripara anche eventuali hook sulla Import Address Table (IAT), una tecnica più datata ma qui reintrodotta deliberatamente, e disabilita le notifiche di sistema modificando chiavi di registro come ToastEnabled e Balloon, per impedire che Windows Defender o il Security Center mostrino avvisi visibili all’utente.

BYOVD: un driver forense trasformato in killer di EDR

L’elemento più aggressivo del crypter è l’abuso di driver kernel legittimi ma vulnerabili, tecnica nota come Bring-Your-Own-Vulnerable-Driver (BYOVD). Cruciferra rilascia sul sistema un “helper driver” firmato digitalmente, spesso il driver GoFlyDrv.sys, e lo usa per inviare comandi IOCTL a basso livello che terminano i processi degli agenti EDR individuati scandendo la lista dei processi attivi. In alternativa, gli analisti hanno osservato anche altri driver impiegati con la stessa logica: Core64.sys, HwOs2Ec.sys, LnvMSRIO.sys, MemoryInformer.sys, NTIOLib_X64.sys, ProcessMonitorDriver.sys e selfprot.sys. Trattandosi di driver firmati da produttori legittimi (spesso strumenti diagnostici o di manutenzione hardware), Windows li carica senza obiezioni nonostante le vulnerabilità note che permettono di trasformarli in armi contro gli stessi prodotti di sicurezza che dovrebbero fermarli.

Per elevare i propri privilegi quando non gira già come amministratore, Cruciferra sfrutta inoltre il bypass dello User Account Control tramite COM Elevation Moniker, e garantisce la persistenza scrivendo una voce denominata “putty” nella chiave di registro Run, così da rieseguirsi automaticamente a ogni riavvio del sistema.

Process Ghosting “potenziato”: nessun file da scansionare

Per l’esecuzione finale del payload, Cruciferra adotta una variante della tecnica di Process Ghosting: crea un file temporaneo, lo marca per l’eliminazione tramite NtSetInformationFile, vi scrive il payload malevolo, quindi crea una sezione immagine con NtCreateSection e SEC_IMAGE prima di chiudere l’handle. Il file viene cancellato dal disco dal sistema operativo, ma la sezione di memoria che lo rappresenta resta viva; un processo legittimo viene poi creato in stato sospeso, la sezione “fantasma” vi viene mappata tramite NtMapViewOfSection, e il contesto del thread viene reindirizzato al vero punto di ingresso del payload prima di riprendere l’esecuzione. Il risultato è un processo in esecuzione supportato da un’immagine PE che non è mai esistita su disco in una forma analizzabile.

Cruciferra aggiunge due ulteriori accorgimenti a questa tecnica, già di per sé insidiosa: applica una patch a ZwQueryVirtualMemory in modo che, quando un EDR interroga la regione di memoria “fantasma”, riceva una risposta manipolata che nasconde l’anomalia del file cancellato; e neutralizza NtManageHotPatch, funzione che il sistema operativo può usare per validare l’integrità delle sezioni immagine caricate rispetto al file su disco che le supporta, impedendo così qualunque verifica di coerenza da parte del kernel.

Crittografia su misura: oltre 90 algoritmi ricombinati

Il payload viene conservato nella sezione “.reloc” del binario, codificato in Base16 con un set di caratteri personalizzato, e protetto da uno delle oltre 90 varianti di algoritmi crittografici che Cruciferra può generare combinando componenti presi da cifrari e generatori di numeri pseudocasuali noti: Keccak (SHA-3), convoluzione ciclica, reti Feistel generalizzate, SPECK-128/256 in modalità CTR, PRNG multiply-accumulate, una versione modificata di Threefish-256, combinazioni Xorshift64/middle-square e diverse varianti ARX (Addition-Rotation-XOR). L’unico algoritmo standard rimasto intatto è DES-CBC-PKCS7. Questo approccio “bring your own crypto” rende ogni campione sostanzialmente unico dal punto di vista crittografico, complicando enormemente il rilevamento basato su firme statiche.

Un dettaglio utile ai difensori: i metadati “File Version Information” dei binari generati da Cruciferra contengono spesso stringhe casuali generate combinando due o quattro parole a caso (ad esempio “2026 Colpoplastric Semipreactical Group” nei campi Copyright, Product e Description), un pattern che, unito a firme YARA mirate, ha permesso a Proofpoint di tracciare su VirusTotal nuove build del crypter caricate a intervalli di pochi minuti, segno di un servizio in sviluppo attivo e continuo.

Due righe per i difensori

• Bloccare il caricamento dei driver kernel noti come vulnerabili tramite la lista di blocco di Microsoft (HVCI/driver blocklist) e strumenti come LOLDrivers, includendo GoFlyDrv.sys e gli altri driver associati a Cruciferra.
• Monitorare la creazione di sezioni immagine da file marcati per l’eliminazione (NtCreateSection su file con delete-pending) come indicatore di Process Ghosting, oltre a chiamate anomale a NtManageHotPatch.
• Verificare la presenza della chiave di persistenza “putty” nel Run key del registro, un IOC comportamentale a basso costo di rilevamento.
• Applicare filtri anti-phishing rafforzati sulle esche a tema fiscale e previdenziale, particolarmente ricorrenti nelle campagne osservate.
• Dare priorità a soluzioni EDR con protezione kernel indipendente dal proprio agente in user-mode, per resistere a tecniche BYOVD che colpiscono direttamente il processo dell’agente.

Cruciferra conferma una tendenza ormai consolidata nel malware-as-a-service: la sofisticazione tecnica un tempo riservata agli APT state-sponsored è oggi acquistabile con un abbonamento mensile, e la vera barriera all’ingresso per il cybercrime commodity non è più scrivere codice evasivo, ma semplicemente pagare chi lo ha già scritto.

IoC

# Driver BYOVD abusati da Cruciferra (SHA-256)
Core64.sys               17aae57cf6255c7eb169bf62ea67376d9708976eb7831f8cdd0ea38bdcb37dc4
GoFlyDrv.sys              2fdfdd13a0c548bb68c9d5aa8599a9265d4659da3e237fe7a42ac6ac06b9a06a
HwOs2Ec.sys               c4e93449453cf67c5d5605bb8f425207a738a242fdb432d720acc32faa74926c
LnvMSRIO.sys              c5b1e9aafc8f2b4ab05effc00fd43f3114b9ef1d592a086c952793ac4e299809
MemoryInformer.sys        7887e919555fb5948c217556ba149392a72982b1bc427d3db779db9dcbf09ee8
NTIOLib_X64.sys           09bedbf7a41e0f8dabe4f41d331db58373ce15b2e9204540873a1884f38bdde1
ProcessMonitorDriver.sys  5b4f59236a9b950bcd5191b35d19125f60cfb9e1a1e1aa2e4f914b6745dde9df
selfprot.sys              c46e907886e2158cbc453e767183aecf07887b5ac8848f19684451883d69f5f0
# Campagna TA4922 / Cruciferra / AsyncRAT
hxxp://hsahyteiows[.]gu[.]cc
hxxp://yicoweytcbtw[.]gu[.]cc
hxxp://xkcifgieusr[.]gu[.]cc
hxxp://fuaytrwese[.]love
3c181f642e24c28602a87be7f195e2f3d1ffa30b37e20f5121d99f88b22ab80e  (Tax-Number52563.zip, SHA256)
66dbe675480dc229e5b3ab8ad74207f73486e64e57805074f784bb2e01bcb865  (Tax-Number809863.zip, SHA256)
# Campagna XWorm
gatuso[.]duckdns[.]org                                            (C2)
# Campagna zgRAT
digital-magicians[.]com/photo295825092412[.]zip                  (Payload URL)
0zbqnac1t4dv2t2wuodv1m[.]com                                      (C2)
89[.]34[.]90[.]99:56001                                           (C2)
# Persistenza
Registro: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\putty

La Quadrature du Net

2026-07-22 16:58:06

L'interdiction faite aux mineur·es de moins de 15 ans d'accéder aux réseaux sociaux vient d'être votée par le Parlement. Si le Conseil constitutionnel ne censure pas la loi en août, les réseaux sociaux pourraient être forcés de vérifier l'âge de tous les internautes dès septembre. C'est-à-dire d'imposer un contrôle d'identité avant d'avoir le droit de s'exprimer en ligne.

laquadrature.net/2026/07/22/le…

Le Parlement vote l’interdiction des réseaux sociaux aux jeunes de moins de 15 ans – La Quadrature du Net

Le Parlement vote l’interdiction des réseaux sociaux aux jeunes de moins de 15 ans

^{La Quadrature du Net}