(in)sicurezza digitale

2026-05-03 15:43:34

CVE-2026-41940: il bug CRLF di cPanel che ha consegnato 44.000 server al ransomware “Sorry”

Quando il 28 aprile 2026 WebPros International ha pubblicato la patch per CVE-2026-41940, la vulnerabilità critica nel suo pannello di controllo hosting cPanel & WHM, era già tardi per decine di migliaia di server. Gli attaccanti avevano sfruttato la falla in silenzio almeno dall’inizio di marzo — forse da febbraio — trasformandola nel vettore di accesso iniziale per una campagna ransomware attiva e distruttiva denominata Sorry. Con un CVSS di 9.8 su 10 e oltre 1,5 milioni di installazioni cPanel nel mondo, l’impatto potenziale di questa vulnerabilità è difficile da sopravvalutare.

La Meccanica dell’Attacco: CRLF Injection nel Daemon di Autenticazione

A differenza dei classici buffer overflow o delle SQL injection, CVE-2026-41940 sfrutta un meccanismo sottile ma devastante: un’iniezione CRLF (Carriage Return Line Feed) nel processo di login e caricamento delle sessioni di cpsrvd, il daemon principale di cPanel.

Il flusso di autenticazione di cPanel prevede che cpsrvd scriva un nuovo file di sessione su disco prima che l’autenticazione vera e propria sia completata. Questo comportamento, probabilmente introdotto per ottimizzare le performance, diventa fatale in presenza della vulnerabilità. Un attaccante non autenticato può manipolare il cookie whostmgrsession omettendo un segmento atteso del suo valore, bypassando così il processo di cifratura della sessione. Iniettando caratteri raw attraverso un header di autorizzazione HTTP appositamente costruito, l’attaccante forza il sistema a scrivere il file di sessione senza sanitizzare l’input, permettendo l’inserimento di proprietà arbitrarie come user=root.

Il risultato finale: accesso amministrativo completo al server hosting, alle sue configurazioni, ai database e a tutti i siti web che gestisce — senza fornire alcuna credenziale valida. La Shadowserver Foundation ha rilevato sin da subito decine di migliaia di IP che scansionavano attivamente honeypot alla ricerca di istanze vulnerabili.

Timeline: Zero-Day Sfruttato per Mesi

La ricostruzione della timeline rivela un gap di esposizione particolarmente preoccupante:

• Febbraio 2026 (data presunta): prime evidenze di sfruttamento nei log di server compromessi
• 23 febbraio 2026: data confermata di prime attività malevole documentate da Shadowserver e altri sensori
• 28 aprile 2026: WebPros pubblica security advisory e rilascia la patch (versioni corrette: 118.0.38, 120.0.23, 122.0.6)
• 1 maggio 2026: CISA aggiunge CVE-2026-41940 al catalogo KEV, imponendo alle agenzie federali US l’aggiornamento entro 3 settimane
• 2-3 maggio 2026: BleepingComputer documenta almeno 44.000 host cPanel compromessi; centinaia di siti già indicizzati da Google con evidenza di deface e ransomware

Il fatto che la vulnerabilità fosse nota agli attaccanti almeno due mesi prima della patch suggerisce o una scoperta interna da parte del gruppo criminale, o un acquisto sul mercato zero-day. In entrambi i casi, la finestra di esposizione è stata sufficiente per costruire un’infrastruttura di attacco scalabile.

Il Ransomware “Sorry”: un Linux Encryptor Progettato per i Server Hosting

Una volta ottenuto l’accesso root via CVE-2026-41940, gli attaccanti non si limitano alla ricognizione o all’esfiltrazione di dati: distribuiscono direttamente un encryptor Linux denominato Sorry, progettato specificamente per ambienti server e hosting. Il payload agisce su filesystem ext4 e XFS, prende di mira le directory tipiche degli stack web LAMP/LEMP (/home/*/public_html, /var/www, database MySQL in /var/lib/mysql) e cifra i file aggiungendo l’estensione .sorry. La ransom note lasciata sui sistemi compromessi include un indirizzo di contatto su rete Tor e una richiesta di pagamento in Bitcoin o Monero.

L’aspetto più insidioso per i provider hosting è che un singolo server cPanel compromesso può ospitare centinaia o migliaia di siti di clienti diversi. La compromissione di un account root su cPanel non è una violazione singola: è una catastrofe di scala industriale per chi gestisce hosting condiviso o rivenditori (reseller). Il provider hosting si trova così a dover comunicare la violazione a ogni singolo cliente presente sul server, con implicazioni legali e reputazionali enormi.

Impatto Globale: 1,5 Milioni di Installazioni a Rischio

Secondo le stime di Picus Security e Bitsight, al momento della divulgazione pubblica esistevano oltre 1,5 milioni di installazioni cPanel/WHM esposte su Internet. Watchtowr Labs, che ha pubblicato un’analisi tecnica con proof-of-concept, ha definito la situazione “The Internet Is Falling Down”, un titolo che rende l’idea della portata del problema. Rapid7 ha confermato l’elevata sfruttabilità nel suo Emergency Threat Response.

cPanel è il pannello di controllo hosting più diffuso al mondo, utilizzato non solo da grandi provider ma anche da decine di migliaia di piccole aziende di hosting e rivenditori. Molte di queste realtà non dispongono di processi di patch management strutturati, il che ha contribuito a mantenere alta la percentuale di installazioni non aggiornate anche giorni dopo la pubblicazione della fix.

Indicatori di Compromissione (IoC)

# Estensione aggiunta ai file cifrati dal ransomware Sorry
*.sorry
# Ransom note lasciata sui sistemi colpiti
READ_ME_SORRY.txt
# Pattern header malevolo rilevato nei log (CRLF injection)
# Authorization: Basic contiene \r\n seguito da user=root
# Percorsi sospetti post-exploit
/var/cpanel/sessions/raw/[stringa_casuale_anomala]
/tmp/.cpanel_*
/root/.bash_history con comandi curl/wget verso .onion o IP anomali
# Verifica crontab aggiunti
crontab -l -u root | grep -vE '^(#|$)'
# Versioni cPanel vulnerabili (da aggiornare immediatamente)
# Tutte le versioni precedenti a: 118.0.38 / 120.0.23 / 122.0.6
# Fonti IoC aggiornati
# https://bazaar.abuse.ch/browse/tag/sorry-ransomware/
# https://www.shadowserver.org/

Azioni di Difesa Immediate

Priorità assoluta: aggiornare cPanel & WHM alle versioni 118.0.38, 120.0.23, 122.0.6 o superiori. La patch è applicabile tramite il meccanismo nativo (upcp --force da root).

• Audit retroattivo: ispezionare i log di cpsrvd in /usr/local/cpanel/logs/ alla ricerca di header Authorization anomali con caratteri non-ASCII o accessi root senza credenziali valide dal febbraio 2026 in poi
• Isolamento in caso di compromissione: se si sospetta l’intrusione, isolare immediatamente il server prima dell’analisi forense — il ransomware Sorry agisce rapidamente e la cifratura può avvenire in pochi minuti dall’accesso
• Verifica account e credenziali: controllare la presenza di nuovi account amministrativi, chiavi SSH non autorizzate in /root/.ssh/authorized_keys, crontab anomali
• Regole WAF/IDS: implementare firme per rilevare header Authorization HTTP contenenti sequenze CRLF (\r\n)
• Backup offsite: verificare che i backup siano conservati su storage disconnesso dalla macchina principale — i backup locali vengono cifrati insieme al server

CVE-2026-41940 è un caso esemplare di come vulnerabilità architetturali in software di infrastruttura ad alta diffusione possano trasformarsi in crisi su scala industriale. La finestra di due mesi tra sfruttamento attivo e patch pubblica, combinata con i ritardi nell’aggiornamento tipici del settore hosting, ha creato le condizioni ideali per una campagna ransomware sistematica. Per chi gestisce server cPanel, l’unica risposta razionale è aggiornare immediatamente e verificare retroattivamente la compromissione risalendo almeno a febbraio 2026.

Spcnet.it

2026-05-02 14:41:55

Deserializzazione JSON sicura in .NET 10: guida completa a JsonSerializerOptions.Strict

Considera questo payload JSON in arrivo alla tua API:

{"Amount": 100, "Amount": -999}

Due proprietà con lo stesso nome. La sezione 4 di RFC 8259 dice che i nomi degli oggetti dovrebbero essere univoci, ma non lo impone. System.Text.Json, di default, adotta l’approccio permissivo: vince l’ultima scrittura, nessun avviso, nessun errore. Il valore dell’attaccante passa silenziosamente.

Questo non è solo un problema di proprietà duplicate. La deserializzazione di default ignora anche campi extra che un attaccante potrebbe iniettare, lascia scivolare i valori null nelle proprietà non-nullable e salta dati richiesti mancanti. Ogni di queste “comodità” è una potenziale vulnerabilità al confine della tua API.

JsonSerializerOptions.Strict: cinque protezioni in un solo preset

.NET 10 introduce JsonSerializerOptions.Strict, un nuovo preset di sola lettura che si affianca a Default e Web. Mentre Default dà priorità alla retrocompatibilità e Web ottimizza per le API HTTP tipiche, Strict segue le best practice di sicurezza attivando cinque impostazioni protettive simultaneamente.

var strict = JsonSerializerOptions.Strict;
// AllowDuplicateProperties:             False
// UnmappedMemberHandling:               Disallow
// PropertyNameCaseInsensitive:           False
// RespectNullableAnnotations:            True
// RespectRequiredConstructorParameters:  True

Confronto tra i tre preset

Impostazione	Default	Web	Strict
AllowDuplicateProperties	true	true	false
UnmappedMemberHandling	Skip	Skip	Disallow
PropertyNameCaseInsensitive	false	true	false
RespectNullableAnnotations	false	false	true
RespectRequiredConstructorParameters	false	false	true

I dati serializzati con Default possono essere deserializzati con Strict. La compatibilità va in una sola direzione: Strict è più severo su ciò che accetta, non su ciò che produce.

1. Proprietà duplicate vietate

I protocolli che stratificano il parsing JSON (OAuth 2.0, OpenID Connect, firme webhook) possono essere sfruttati se parser diversi gestiscono input duplicati in modo diverso. Con Strict, ogni tentativo di deserializzare JSON con proprietà duplicate genera immediatamente una JsonException:

string duplicateJson = @'{"Amount": 100, "Amount": -999}';

try
{
    JsonSerializer.Deserialize<Payment>(duplicateJson, JsonSerializerOptions.Strict);
}
catch (JsonException ex)
{
    // JsonException: Duplicate property 'Amount' encountered during deserialization
    Console.WriteLine(ex.Message);
}

public record Payment(int Amount);

Questa protezione si estende oltre i POCO (plain-old C# objects): funziona anche con JsonDocument, JsonNode e Dictionary<string, T>.

2. Rifiuto dei membri non mappati

La deserializzazione di default scarta silenziosamente le proprietà JSON che non corrispondono al tuo tipo .NET. È comodo durante lo sviluppo, ma è pericoloso a un confine di fiducia perché non sai cosa sta inviando il client.

string extraFieldJson = @'{"Name": "Alice", "Role": "user", "IsRoot": true}';

// Default: ignora silenziosamente "IsRoot"
var user = JsonSerializer.Deserialize<User>(extraFieldJson);
// Name=Alice, Role=user - "IsRoot" scompare senza tracce

// Strict: rifiuta la proprieta' non mappata
JsonSerializer.Deserialize<User>(extraFieldJson, JsonSerializerOptions.Strict);
// throws: The JSON property 'IsRoot' could not be mapped to any .NET member

public record User(string Name, string Role);

3. Corrispondenza case-sensitive dei nomi di proprietà

In modalità Strict, la case sensitivity diventa un contratto preciso: i nomi delle proprietà JSON devono corrispondere esattamente ai nomi delle proprietà C#. Se i tuoi client inviano camelCase ma i tuoi tipi usano PascalCase, aggiungi [JsonPropertyName("nomeCamelCase")] per rendere il contratto esplicito nella definizione del tipo.

4. Enforcement delle annotazioni nullable

I nullable reference types di C# aiutano a intercettare i problemi di null a compile time, ma System.Text.Json li ignora di default durante la deserializzazione. Con Strict, se hai dichiarato string Name (non string? Name), il serializzatore rifiuterà qualsiasi JSON con null per quella proprietà:

string nullNameJson = @'{"Name": null, "Email": "alice@example.com"}';

// Default: null va nella stringa non-nullable senza errori
var contact = JsonSerializer.Deserialize<Contact>(nullNameJson);
// contact.Name == null (silenzioso!)

// Strict: genera eccezione
JsonSerializer.Deserialize<Contact>(nullNameJson, JsonSerializerOptions.Strict);
// throws: The constructor parameter 'Name' doesn't allow null values

public record Contact(string Name, string Email);

5. Parametri obbligatori del costruttore

I record type e le classi con costruttori parametrizzati possono avere parametri obbligatori silenziosamente riempiti con valori di default quando il JSON manca dei dati. Strict lo impedisce:

string missingParamJson = @'{"FirstName": "Alice"}';

// Default: LastName mancante diventa silenziosamente null
var person = JsonSerializer.Deserialize<Person>(missingParamJson);
// person.LastName == null

// Strict: richiede tutti i parametri
JsonSerializer.Deserialize<Person>(missingParamJson, JsonSerializerOptions.Strict);
// throws: JSON deserialization was missing required properties: 'LastName'

public record Person(string FirstName, string LastName);

Integrazione in ASP.NET Core Minimal APIs

Nei demo sopra usiamo JsonSerializer direttamente. In un’applicazione web, configuri le opzioni JSON una volta e ogni endpoint le eredita. Nota: JsonSerializerOptions.Strict è un singleton frozen, quindi non puoi passarlo direttamente a ConfigureHttpJsonOptions che richiede un’istanza mutabile. Imposta le singole proprietà:

builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.AllowDuplicateProperties = false;
    options.SerializerOptions.UnmappedMemberHandling =
        System.Text.Json.Serialization.JsonUnmappedMemberHandling.Disallow;
    options.SerializerOptions.PropertyNameCaseInsensitive = false;
    options.SerializerOptions.RespectNullableAnnotations = true;
    options.SerializerOptions.RespectRequiredConstructorParameters = true;
});

app.MapPost("/payments", (Payment payment) =>
{
    // Se il body ha proprieta' duplicate, campi non mappati o dati mancanti,
    // il framework risponde con 400 Bad Request prima che questo codice venga eseguito.
    return Results.Ok(payment);
});

Il framework intercetta JsonException durante il model binding e restituisce un 400 Bad Request con problem details. Il tuo endpoint vede solo oggetti validi e completamente inizializzati.

Configurazione per-endpoint

Se hai bisogno di validazione strict su alcuni endpoint ma parsing più flessibile su altri, puoi deserializzare manualmente dal body della richiesta con le opzioni desiderate:

app.MapPost("/api/strict", async (HttpContext context) =>
{
    var payment = await context.Request.ReadFromJsonAsync<Payment>(
        JsonSerializerOptions.Strict);
    return Results.Ok(payment);
});

Supporto per i Source Generator

Per scenari AOT o per i benefici prestazionali dei source generator, configura manualmente le impostazioni equivalenti su JsonSourceGenerationOptionsAttribute. Non esiste una scorciatoia Strict per l’attributo: ogni proprietà va impostata individualmente.

[JsonSourceGenerationOptions(
    AllowDuplicateProperties = false,
    UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow,
    PropertyNameCaseInsensitive = false,
    RespectNullableAnnotations = true,
    RespectRequiredConstructorParameters = true
)]
[JsonSerializable(typeof(Payment))]
internal partial class StrictJsonContext : JsonSerializerContext;

Il codice generato include tutta la logica di validazione a compile time, senza overhead di reflection.

Quando usare Strict (e quando no)

Usalo ai confini di fiducia: endpoint token, ricevitori di webhook, controller API che accettano JSON da client non controllati completamente. Il costo è una JsonException quando i payload non corrispondono al contratto. Questo è esattamente lo scopo.

Evitalo per l’ingestione flessibile: se consumi JSON da API di terze parti con schemi inconsistenti, la modalità strict rifiuterà payload che potresti voler gestire con più grazia. In questi casi usa Default o Web e valida dopo la deserializzazione.

Migra in modo incrementale: non è necessario passare tutto a Strict subito. Inizia dagli endpoint ad alto rischio, intercetta JsonException, registra i problemi, correggi i client che inviano payload non conformi, poi espandi.

Sappi i limiti: Strict valida le violazioni del contratto strutturale ma non protegge da JSON profondamente annidato (usa MaxDepth), payload eccessivi (imposta limiti HTTP) o type confusion polimorfico. È un layer di difesa, non l’unico.

Conclusione

Ogni endpoint API che accetta JSON è un confine di fiducia. La deserializzazione permissiva rende quel confine poroso. JsonSerializerOptions.Strict non aggiunge nuova logica: attiva protezioni già presenti in System.Text.Json ma disattivate di default per retrocompatibilità. Una riga di configurazione le attiva tutte.

Questo è particolarmente rilevante ai confini di protocollo come OAuth 2.0 e OpenID Connect, dove una proprietà duplicata o un campo inatteso non è solo un bug — è un potenziale vettore di exploit.

Fonte: Harden Your .NET JSON Deserialization with System.Text.Json and JsonSerializerOptions.Strict — Khalid Abuhakmeh, Duende Software (30 aprile 2026)

Harden Your .NET JSON Deserialization with System.Text.Json and JsonSerializerOptions.Strict

Learn how .NET 10's new JsonSerializerOptions.Strict preset activates five security protections in System.Text.Json to close gaps at your API trust boundaries.

^{Khalid Abuhakmeh (Duende Software)}

(in)sicurezza digitale

2026-05-02 14:37:38

SHADOW-EARTH-053: la campagna APT cinese che spia governi asiatici, la NATO e i diplomatici cubani

Una campagna di cyberspionaggio di alto livello, attribuita ad attori allineati agli interessi strategici della Cina, ha colpito nell’arco degli ultimi mesi governi, contractor della difesa, aziende tecnologiche e media in almeno otto paesi asiatici e in Polonia, unico Stato membro della NATO nel mirino. Nell’ambito dello stesso quadro operativo, un’operazione parallela ha violato la casella email di 68 diplomatici cubani a Washington durante uno dei momenti di tensione geopolitica più acuti del 2026. Il quadro che emerge è quello di una macchina d’intelligence cinese capace di operare su più fronti simultaneamente, adattando toolchain e vettori di attacco a obiettivi molto diversi tra loro.

SHADOW-EARTH-053: profilo del gruppo e attribuzioni

Il 30 aprile 2026, Trend Micro ha pubblicato un’analisi tecnica dettagliata di un nuovo intrusion set temporaneo denominato SHADOW-EARTH-053. Il gruppo è attivo almeno dal dicembre 2024 e viene valutato con elevata confidenza come allineato agli interessi della Repubblica Popolare Cinese. I target identificati spaziano dall’Asia meridionale (Pakistan, India, Sri Lanka, Myanmar) a quella orientale (Taiwan) e sud-orientale (Thailandia, Malaysia), fino a un Paese europeo membro della NATO: la Polonia.

La campagna si concentra principalmente su organizzazioni governative e del settore difesa, ma ha colpito anche aziende del settore tecnologico, trasporti e media. L’ampiezza geografica e la diversità dei target riflettono le priorità di intelligence della Cina nella regione Indo-Pacifica, con la Polonia che rappresenta probabilmente un obiettivo correlato al monitoraggio dell’assistenza militare occidentale all’Ucraina.

Vettori di accesso iniziale: da Exchange a React2Shell

SHADOW-EARTH-053 dimostra notevole flessibilità nei vettori di accesso iniziale. Il gruppo sfrutta vulnerabilità note ma non patchate in Microsoft Exchange Server — in particolare la catena ProxyLogon (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) — e nei server Internet Information Services (IIS). La presenza di server Exchange senza patch a distanza di anni dalla disclosure rimane un problema sistemico nelle reti governative di molti paesi target.

Più recentemente, il gruppo ha aggiunto al proprio arsenale lo sfruttamento di CVE-2025-55182, alias React2Shell, una vulnerabilità critica con CVSS score di 10.0 che affligge React Server Components, Next.js e framework correlati. La falla consente l’esecuzione di codice arbitrario remoto pre-autenticazione tramite una singola richiesta HTTP malevola. In alcuni casi, ShadowPad è stato recapitato anche tramite AnyDesk, mostrando adattabilità nella catena di compromissione.

La toolchain: ShadowPad, Godzilla e Noodle RAT

Dopo l’accesso iniziale, SHADOW-EARTH-053 installa web shell Godzilla per mantenere un accesso persistente al server compromesso. Godzilla consente l’esecuzione remota di comandi e offre funzionalità di gestione file, proxy SOCKS5 e memory injection, rendendola una piattaforma di staging ideale per le fasi successive.

Il payload principale è ShadowPad, un backdoor modulare di uso esclusivo dei gruppi APT cinesi sin dalla sua comparsa nel 2017. ShadowPad viene caricato tramite DLL sideloading di eseguibili legittimi firmati digitalmente (Microsoft, Samsung e altri vendor), con il payload cifrato spesso archiviato nel registro di sistema ed eliminato dopo il primo utilizzo. La persistenza è garantita da un task pianificato denominato “M1onltor”, configurato per eseguire il binario sideloaded ogni cinque minuti con i massimi privilegi disponibili.

Su infrastrutture Linux, i ricercatori hanno identificato con bassa confidenza campioni di Noodle RAT, una RAT cross-platform distribuita tramite la stessa infrastruttura e controllata via domini con temi office365. Ciò suggerisce un’espansione verso ambienti non-Windows, tipicamente meno monitorati nelle reti enterprise.

Movimento laterale e ricognizione interna

Post-compromissione, SHADOW-EARTH-053 esegue una ricognizione sistematica di Active Directory e Exchange direttamente dalla web shell: enumerazione degli admin di dominio, discovery dei domain controller tramite nltest, export AD via csvde e mapping di utenti e mailbox con Get-DomainUser di PowerView.

Per il movimento laterale il gruppo utilizza IOX, un tool di tunneling proxy, configurando LocalAccountTokenFilterPolicy = 1 per abilitare Pass-the-Hash sugli account amministratori locali. Il movimento laterale si avvale di WMIC per distribuire backdoor e tool su host Windows aggiuntivi, affiancato da un launcher RDP personalizzato (smss.exe) e da Sharp-SMBExec, un tool C# per operazioni SMB.

L’operazione sull’ambasciata cubana: spionaggio diplomatico in tempo reale

Parallelamente alla campagna SHADOW-EARTH-053, la società Gambit Security ha documentato un’operazione distinta ma stilisticamente riconducibile a gruppi di intelligence cinesi: la compromissione dei server di posta elettronica dell’ambasciata cubana a Washington. L’attacco è iniziato a gennaio 2026 e ha interessato le caselle email di 68 funzionari, tra cui l’ambasciatore e il suo vice. I vettori di intrusione sono stati — anche qui — vulnerabilità nei server Microsoft Exchange, rimaste non patchate per circa cinque anni.

La tempistica dell’operazione è significativa: gli hacker hanno letto corrispondenza diplomatica riservata proprio mentre gli Stati Uniti intensificavano le pressioni su Cuba sull’onda delle operazioni in Venezuela, con restrizioni alle forniture di petrolio che hanno causato blackout di massa sull’isola. Nella stessa finestra temporale, la stessa infrastruttura ha condotto attacchi contro il governo del Venezuela e il suo Ministero degli Affari Esteri. Separatamente, lo sfruttamento della vulnerabilità React (CVE-2025-55182) ha consentito al gruppo di ottenere accesso a circa 5.000 server in pochi giorni, inclusi sistemi governativi in Texas e aziende private.

Tecniche di evasione

SHADOW-EARTH-053 adotta diverse tecniche per ostacolare il rilevamento. Il packer RingQ viene usato per offuscare i payload. I tool come net.exe e PowerShell vengono rinominati con nomi casuali con estensione .log. I domini di command and control mimicano prodotti di sicurezza o servizi DNS legittimi. L’uso estensivo di living-off-the-land binaries (LOLBins) riduce ulteriormente la firma di rilevamento sugli endpoint.

Indicatori di compromissione (IoC)

# Tool e binari associati a SHADOW-EARTH-053
# Scheduled Task persistence
Task name: M1onltor
Trigger: ogni 5 minuti, SYSTEM privileges

# Strumenti post-compromissione
- IOX proxy tunneling tool
- Sharp-SMBExec (C# SMB lateral movement)
- RingQ packer (per offuscamento payload)
- PowerView (Get-DomainUser)
- csvde.exe (AD export)
- nltest.exe (domain controller discovery)

# Malware identificati
- ShadowPad backdoor (DLL sideloading via eseguibili firmati Microsoft/Samsung)
- Godzilla webshell
- Noodle RAT (variante Linux, bassa confidenza)

# CVE sfruttate
- CVE-2021-26855 / CVE-2021-26857 / CVE-2021-26858 / CVE-2021-27065 (ProxyLogon - Exchange)
- CVE-2025-55182 "React2Shell" (CVSS 10.0 - RCE pre-auth su React Server Components)

# Indicatori infrastrutturali
- Domini C2 che imitano prodotti di sicurezza o servizi DNS
- Domini con temi "office365" per Noodle RAT C2
- Eseguibili rinominati con estensione .log (net.exe, PowerShell)

Implicazioni e raccomandazioni per i difensori

La campagna SHADOW-EARTH-053 evidenzia alcune priorità difensive urgenti. Patch management su Exchange e IIS rimane critico: la persistenza di vulnerabilità come ProxyLogon a distanza di anni dalla divulgazione indica processi di patching inadeguati in molte organizzazioni pubbliche. Il monitoraggio di task pianificati con nomi insoliti (come “M1onltor”) e del DLL sideloading da processi firmati legittimi dovrebbe essere parte delle regole di detection SIEM standard. Il rilevamento di tool come IOX, csvde e nltest in contesti anomali può segnalare ricognizione post-compromissione. La protezione delle API React Server Components e l’applicazione del patch per CVE-2025-55182 è urgente per chiunque gestisca applicazioni Next.js in produzione.

Sul piano geopolitico, la combinazione SHADOW-EARTH-053 + operazione ambasciata cubana dimostra la capacità dei servizi di intelligence cinesi di condurre operazioni simultanee e multi-obiettivo, adattando gli strumenti in funzione del target — dal backdoor militare ShadowPad per i governi alla compromissione silente dei server di posta diplomatici. Per i team di sicurezza delle organizzazioni governative, difesa e infrastrutture critiche in Europa e Asia, questa campagna rappresenta un segnale d’allerta difficile da ignorare.

Spcnet.it

2026-05-01 22:09:04

A2A v1: comunicazione cross-platform tra agenti AI nel Microsoft Agent Framework per .NET

Con il rilascio dell’A2A Protocol v1.0 e il relativo supporto nel Microsoft Agent Framework per .NET, il mondo degli agenti AI multi-vendor fa un passo importante verso la maturità. Non si tratta solo di un aggiornamento di versione: A2A v1 è il primo standard stabile e production-ready per la comunicazione tra agenti intelligenti, indipendentemente dal framework o dal provider che li ospita.

Il problema: isole di agenti incompatibili

Chi sviluppa sistemi multi-agente in ambienti aziendali lo sa bene: ogni team usa il proprio framework, ogni divisione ha i propri provider AI, e ogni volta che due agenti devono comunicare si finisce a scrivere codice di integrazione su misura. Il costo di questo «collante» cresce più in fretta del valore che gli agenti stessi producono.

Il protocollo A2A nasce esattamente per eliminare questa frizione. L’analogia è quella di HTTP e REST per i servizi web: prima di avere standard condivisi, ogni integrazione richiedeva codice proprietario. Dopo, è diventato possibile comporre servizi indipendentemente dal linguaggio o dalla piattaforma sottostante. A2A vuole fare la stessa cosa per gli agenti AI.

Chi c’è dietro A2A v1

Il protocollo è governato da un comitato tecnico con rappresentanti di AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP e ServiceNow. Non è un progetto Microsoft-only, ma uno standard aperto con ampio supporto industriale. La versione 1.0 segnala che il protocollo è maturo: i contorni aspri delle bozze precedenti sono stati levigati, le aree ambigue chiarite, e la superficie API è stata progettata per la durabilità nel tempo.

Novità di A2A v1 rispetto alla v0.3

Per chi veniva dalla versione precedente (v0.3), ecco cosa cambia:

• Stabilità e supporto a lungo termine: v1.0 è la prima versione con garanzie di compatibilità stabile. L’investimento nel codice scritto oggi sarà protetto.
• Funzionalità enterprise: supporto multi-tenancy, Agent Card firmate crittograficamente per la verifica dell’identità degli agenti, e flussi di sicurezza migliorati per ambienti regolamentati e multi-parte.
• Architettura web-aligned: A2A v1 si appoggia su protocolli e pattern già consolidati nell’infrastruttura web. È possibile scalare le interazioni tra agenti usando gli stessi load balancer, gateway e strumenti di observability già in uso per i servizi HTTP.

Come funziona nel Microsoft Agent Framework per .NET

La filosofia di design del framework è che l’interoperabilità non deve richiedere una ristrutturazione del codice. Un agente remoto A2A appare nel codice esattamente come qualsiasi altro AIAgent locale: stessa interfaccia RunAsync, stesso streaming, stessa gestione della sessione.

Connettere un agente remoto A2A via discovery automatica

Il protocollo A2A definisce un percorso standard per la discovery degli agenti: /.well-known/agent-card.json. Con A2ACardResolver è possibile scoprire e istanziare un agente remoto in una sola chiamata:

using A2A;
using Microsoft.Agents.AI;

// Punta il resolver all'host dell'agente remoto
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));

// Risolve l'Agent Card e crea un AIAgent in un solo passaggio
AIAgent agent = await resolver.GetAIAgentAsync();

// Usalo come qualsiasi altro AIAgent
Console.WriteLine(await agent.RunAsync("Qual è il meteo a Milano?"));

Configurazione diretta (per ambienti di sviluppo)

In scenari di sviluppo o sistemi strettamente accoppiati dove l’endpoint è già noto, si può creare un A2AClient direttamente:

using A2A;
using Microsoft.Agents.AI;

A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(
    name: "my-agent",
    description: "Un assistente specializzato.");

Console.WriteLine(await agent.RunAsync("Di cosa ti occupi?"));

Selezione del protocollo di trasporto

A2A v1 supporta più binding di protocollo. Per default, il framework preferisce HTTP+JSON con JSON-RPC come fallback. È possibile specificarlo esplicitamente:

A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
A2AClientOptions options = new()
{
    PreferredBindings = [ProtocolBindingNames.HttpJson]
};
AIAgent agent = await resolver.GetAIAgentAsync(options: options);

Streaming in tempo reale

A2A supporta lo streaming via Server-Sent Events. RunStreamingAsync permette di ricevere aggiornamenti in tempo reale mentre l’agente elabora la risposta — particolarmente utile per task lunghi o per mostrare progressi all’utente:

await foreach (var update in agent.RunStreamingAsync("Analizza questo documento..."))
{
    Console.Write(update.Text);
}

Esporre il proprio agente come endpoint A2A

Il meccanismo funziona anche in senso inverso: qualsiasi AIAgent già costruito — su Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, AWS Bedrock o qualsiasi altro provider supportato — può essere esposto come endpoint A2A con poche righe di hosting. Nessun boilerplate di protocollo da scrivere, nessun refactoring necessario quando si decide di rendere un agente interno disponibile ad altri team o a partner esterni.

Quando ha senso adottare A2A v1

A2A v1 diventa rilevante non appena si esce dai prototipi mono-agente. I casi d’uso tipici includono:

• Un agente di procurement che deve consultare un servizio di compliance di un partner
• Un agente di customer support che cede il controllo a un agente specializzato di un’altra divisione
• Pipeline di elaborazione dove agenti diversi (analisi, sintesi, verifica) sono costruiti da team differenti
• Ecosistemi ISV dove prodotti di terze parti devono integrarsi con gli agenti della piattaforma principale

Conclusioni

A2A v1 è una tappa importante nell’evoluzione degli agenti AI verso sistemi distribuiti e interoperabili. La scelta di costruirlo come standard aperto con sponsorship industriale ampio — e non come API proprietaria Microsoft — è un segnale di maturità dell’ecosistema. Per i team .NET che stanno costruendo o pianificando sistemi multi-agente, vale la pena investire nella migrazione dalla v0.3 o nell’adozione diretta di v1: la stabilità garantita e le funzionalità enterprise rendono il protocollo adatto alla produzione oggi.

Fonte: A2A v1 Is Here – Microsoft Agent Framework Blog (Sergey Menshykh, Microsoft)

A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET | Microsoft Agent Framework

As organizations move from single-agent prototypes to multi-agent production systems, the ability for agents to communicate reliably across platforms and organizational boundaries becomes essential. With the release of A2A Protocol v1.

^{Sergey Menshykh (Microsoft Agent Framework)}

Spcnet.it

2026-05-01 07:48:38

PowerToys 0.99: Grab And Move, Power Display e miglioramenti a Command Palette

Microsoft ha rilasciato PowerToys 0.99, un aggiornamento ricco di novità per sviluppatori e utenti avanzati di Windows. Il protagonista di questa release è l’introduzione di due nuove utility in anteprima: Grab And Move e Power Display, insieme a una serie di miglioramenti significativi a Command Palette e al Dock. Vediamo nel dettaglio cosa cambia.

Grab And Move: trascina le finestre da qualsiasi punto

Chi lavora su monitor grandi o con molte finestre aperte conosce bene il problema: per spostare una finestra bisogna mirare con precisione alla barra del titolo, spesso sottile pochi pixel. Grab And Move risolve questo limite permettendo di trascinare qualsiasi finestra tenendo premuto Alt + Click sinistro ovunque sulla finestra stessa.

Lo stesso vale per il ridimensionamento: Alt + Click destro avvia l’operazione di resize dal punto esatto in cui si trova il cursore, senza dover raggiungere i bordi della finestra. Per chi già usa Alt come modificatore di sistema, è possibile passare al tasto Win come alternativa.

Grab And Move è particolarmente utile in questi scenari:

• Monitor ad alta risoluzione dove le barre del titolo sono sottilissime in scala DPI
• Finestre che sono finite parzialmente fuori schermo e sono difficili da afferrare
• Applicazioni che nascondono la barra del titolo o usano layout custom
• Workflow con tante finestre sovrapposte dove la precisione è critica

L’utility si integra con il sistema di impostazioni di PowerToys, supporta le Group Policy (GPO) per ambienti aziendali e include una pagina OOBE per la prima configurazione.

Power Display: controllo monitor dal system tray

La seconda novità di rilievo è Power Display, una utility che porta il controllo hardware dei monitor direttamente nel system tray di Windows, eliminando la necessità di cercare i pulsanti fisici sul retro dello schermo.

Una volta abilitata, un’icona nella tray apre un flyout che mostra i monitor collegati al sistema. Per i display compatibili, Power Display permette di regolare:

• Luminosità e contrasto
• Volume audio del monitor
• Profilo colore

Una delle funzionalità più interessanti è la gestione dei profili: è possibile salvare configurazioni complete (es. «modalità sviluppo» con alta luminosità e temperatura colore neutra, oppure «serata» con luminosità ridotta e toni caldi) e passare da uno all’altro con un clic singolo dal flyout.

Power Display si integra anche con Light Switch: nella configurazione di Light Switch è possibile associare un profilo monitor al cambio di tema chiaro/scuro, così quando Windows passa automaticamente al tema scuro la sera, anche il monitor si adatta.

Command Palette e Dock: Compact mode e cronologia calcolatrice

Command Palette riceve in questa release una serie di miglioramenti alla stabilità e alle performance, insieme a nuove funzionalità:

• Compact Dock: quando il Dock è posizionato in alto o in basso, è ora disponibile una modalità compatta che nasconde il sottotitolo, rendendo il layout più essenziale e meno ingombrante.
• Cronologia della calcolatrice: i calcoli vengono ora salvati in modo persistente, con la possibilità di riutilizzare, eliminare o cancellare le voci precedenti. È anche possibile configurare l’azione primaria e sostituire la query premendo Invio.
• Pinning migliorato: quando si aggiunge un comando al Dock, un nuovo dialogo consente di scegliere la posizione e se mostrare o nascondere titolo e sottotitolo.
• Supporto nuovi content type: le estensioni possono ora esporre contenuti di tipo plain text e image viewer direttamente nel pannello dei contenuti.
• Affidabilità: corretti due crash legati alla digitazione, migliorato il caricamento delle estensioni in modo che un’estensione difettosa non mandi in crash l’intera lista, e aggiunto il supporto a Windows Terminal profile pinning.

Il Dock ora supporta anche la modalità always-on-top, tenendosi visibile sopra le altre finestre — utile per chi lo usa come launcher rapido.

Come aggiornare

PowerToys 0.99 è disponibile tramite Windows Package Manager (WinGet) oppure direttamente dalla pagina delle release su GitHub. Se avete già PowerToys installato, l’aggiornamento automatico dovrebbe proporvelo a breve nelle impostazioni dell’app.

winget upgrade Microsoft.PowerToys

Le due nuove utility (Grab And Move e Power Display) sono in anteprima e disabilitate di default: dovrete attivarle manualmente dalle impostazioni di PowerToys per cominciare a usarle.

Conclusioni

PowerToys 0.99 si conferma come uno strumento imprescindibile per chi usa Windows in modo intensivo. Grab And Move risolve un problema di usabilità quotidiana che molti utenti conoscono, mentre Power Display porta finalmente un controllo centralizzato dei monitor senza software proprietari. Gli aggiornamenti a Command Palette completano un rilascio solido che vale l’aggiornamento immediato.

Fonte: PowerToys 0.99 is here – Windows Command Line Blog (Niels Laute, Microsoft)

PowerToys 0.99 is here: new monitor controls, easier window management, and Dock upgrades

We’re back with a fresh PowerToys release! This month introduces Power Display for controlling your monitors from the system tray, Grab And Move for quickly moving and resizing windows, and a wave of improvements to Command Palette and the Dock, alon…

^{Niels Laute (Windows Command Line)}

(in)sicurezza digitale

2026-05-01 08:07:57

18 estensioni browser AI come RAT e Spyware: Unit 42 smonta la facciata dei tool GenAI per la produttività

Con la diffusione esplosiva degli strumenti di intelligenza artificiale generativa, il Chrome Web Store è diventato il nuovo vettore privilegiato per la distribuzione di malware camuffato da produttività. Il team Unit 42 di Palo Alto Networks ha pubblicato il 30 aprile 2026 una ricerca sistematica che documenta 18 estensioni browser ad alto rischio — commercializzate come assistenti AI per email, coding e ricerca — che nascondono Remote Access Trojan (RAT), attacchi meddler-in-the-middle (MitM), infostealer e spyware a tutti gli effetti. Google ha rimosso o emesso avvisi sulle estensioni segnalate, ma la ricerca espone un problema strutturale: il modello di permessi delle estensioni browser, combinato con la fiducia degli utenti verso i tool AI, crea una superficie di attacco lato client difficile da presidiare.

Perché le estensioni AI sono un bersaglio ideale

Le estensioni browser operano all’interno del processo trusted del browser con permessi concessi dall’utente. Possono leggere e modificare contenuti web, intercettare richieste di rete, accedere ai cookie e comunicare con server esterni — le stesse capacità di strumenti legittimi come ad blocker, password manager e tool per sviluppatori. La distinzione tra uno strumento legittimo e uno malevolo è invisibile all’utente medio.

L’AI generativa amplifica il rischio in modo qualitativo. Quando un utente digita un prompt in un servizio AI come ChatGPT o Claude, condivide routinariamente codice proprietario, bozze di comunicazioni riservate e piani strategici. Un’estensione posizionata tra l’utente e il servizio AI intercetta dati di valore incomparabilmente superiore ai metadati di navigazione tradizionalmente presi di mira dal browser malware. Unit 42 ha rilevato campioni specifici che prendono di mira i prompt inviati a ChatGPT prima che lascino il dispositivo, esfiltrandoli verso domini a bassa reputazione.

Le tecniche di attacco documentate da Unit 42

L’analisi retrospettiva di Unit 42 ha identificato cinque tecniche ricorrenti nelle 18 estensioni ad alto rischio:

1. WebSocket C2 persistente

Le estensioni stabiliscono connessioni WebSocket bidirezionali verso server C2 remoti. La connessione si riconnette automaticamente agli interrupt di rete e persiste attraverso i riavvii del browser senza richiedere iniezione di processo. Il traffico appare come normale traffico HTTPS dal punto di vista della rete. L’esempio più esplicito è “Chrome MCP Server – AI Browser Control”: mascherato da tool di automazione basato su Model Context Protocol, è di fatto un RAT completo che si connette a wss://mcp-browser.qubecare[.]ai/chrome, con la listing che riportava falsamente “100% local processing – your data never leaves your browser”.

2. Browser API Hooking

Gli script di contenuto sostituiscono le API native del browser (window.fetch o XMLHttpRequest) per intercettare le richieste di rete prima della trasmissione. In questo modo l’estensione può leggere il payload di qualsiasi richiesta — incluse quelle cifrate — prima che lascino la pagina. Questa tecnica permette la cattura di prompt, credenziali di form e token di sessione.

3. Osservazione passiva del DOM

Gli script di contenuto monitorano passivamente le modifiche al Document Object Model (DOM) in applicazioni target come Gmail o Notion. L’estensione legge il contenuto renderizzato — testo in chiaro di email composte, note, messaggi — e lo trasmette in chiaro a server esterni. Unit 42 ha documentato casi in cui il contenuto delle email e gli OTP vengono esfiltrati tramite questa tecnica prima ancora dell’invio.

4. Traffic Proxying via PAC

Alcune estensioni configurano le impostazioni proxy del browser tramite file PAC (Proxy Auto-Configuration) per instradare il traffico attraverso infrastrutture controllate dall’attaccante. Questo approccio non richiede permission esplicite per i singoli siti e opera in modo trasparente per l’utente.

5. Decifrazione HTTPS via Chrome Debugger Protocol

La tecnica più sofisticata: alcune estensioni agganciano il Chrome Debugger Protocol per leggere il corpo delle risposte HTTPS già decifrate. Questo bypassa la protezione della cifratura transport-layer, consentendo l’intercettazione di qualsiasi risposta HTTPS — incluse risposte delle API AI, contenuti bancari e dati di sessione autenticati.

Il ruolo degli LLM nella produzione industriale di malware browser

Un dato particolarmente significativo: diversi campioni analizzati da Unit 42 contenevano fingerprint di codice generato da LLM. I threat actor stanno utilizzando strumenti di code generation AI per accelerare lo sviluppo di estensioni malevole e scalare le campagne. Questo abbassa drasticamente la barriera tecnica per la produzione di browser malware sofisticato e rende obsoleta la correlazione tra qualità del codice e minaccia reale. La stessa tecnologia che promette produttività agli utenti legittimi viene weaponizzata per costruire più velocemente gli strumenti del crimine informatico.

Le estensioni analizzate (case study)

Tra le 18 estensioni documentate da Unit 42 con comportamenti ad alto rischio, i principali case study includono: Chrome MCP Server – AI Browser Control (RAT completo via WebSocket), Supersonic AI (infostealer di prompt), Reverse Recruiting (esfiltrazione di dati di profilo e comunicazioni), Chat AI for Chrome (intercettazione conversazioni AI), e l’estensione di traduzione Huiyi (spyware con DOM observation). Tutti si presentavano come tool di produttività AI legittimi con descrizioni convincenti sullo store Chrome.

Qualche raccomandazione

• Gestione centralizzata delle estensioni: le organizzazioni dovrebbero implementare policy di allowlisting delle estensioni browser tramite Chrome Enterprise o equivalente, vietando l’installazione autonoma da parte degli utenti su dispositivi aziendali.
• Principio del minimo privilegio per le estensioni: auditare i permessi richiesti da tutte le estensioni installate. Un’estensione che chiede accesso a debugger, webRequest, proxy e storage.sync contemporaneamente dovrebbe essere trattata con estrema cautela.
• Diffidare delle promesse di privacy locale: affermazioni come “100% local processing” non sono verificabili dall’utente e sono state documentate come false in almeno un caso della ricerca.
• Monitoraggio del traffico di rete: le connessioni WebSocket persistenti verso domini a bassa reputazione da processi browser sono un segnale di allarme rilevabile a livello di proxy/firewall aziendale.
• Aggiornare le policy di sicurezza per includere esplicitamente le estensioni browser AI come superficie di rischio, alla stregua di software di terze parti installato.

Fonte primaria: Unit 42, Palo Alto Networks, “That AI Extension Helping You Write Emails? It’s Reading Them First”, 30 aprile 2026. Le 18 estensioni sono state segnalate a Google, che ha rimosso o inviato avvisi ai proprietari per violazione delle policy.