Spcnet.it

2026-05-19 14:33:40

Passkey in Microsoft Entra ID: perché l’enforcement con Conditional Access è fondamentale

Introduzione: le passkey non bastano da sole

Le passkey rappresentano uno dei passi più significativi nell’evoluzione dell’autenticazione moderna. Basate sullo standard FIDO2, eliminano le password tradizionali sostituendole con coppie di chiavi crittografiche legate al dispositivo e all’identità biometrica dell’utente. Su Microsoft Entra ID, abilitare le passkey è diventato relativamente semplice — il vero problema emerge subito dopo: abilitarle non significa renderle obbligatorie.

Molte organizzazioni configurano le passkey come metodo di autenticazione disponibile e si fermano lì, convinte di aver rafforzato significativamente la loro postura di sicurezza. In realtà, senza un enforcement esplicito tramite Conditional Access, l’utente può ancora scegliere di autenticarsi con password e SMS — esattamente come prima. Questo scenario introduce un rischio spesso sottovalutato: il downgrade attack.

Cos’è un downgrade attack nel contesto dell’autenticazione

Un downgrade attack, nell’ambito dell’autenticazione, non è un attacco sofisticato nel senso tradizionale del termine. È semplicemente la possibilità di utilizzare un metodo di autenticazione meno sicuro rispetto a quello ideale. Dal punto di vista dell’utente, si manifesta come il familiare link “Accedi in un altro modo” nella schermata di login di Microsoft.

Gli attaccanti dispongono di toolkit avanzati — come Evilginx2 o strumenti analoghi — capaci di rilevare automaticamente quali metodi di autenticazione sono disponibili per un determinato account. Se il sistema accetta password + SMS come alternativa alla passkey, l’attaccante sfrutterà il percorso più debole. La passkey registrata diventa di fatto irrilevante dal punto di vista della sicurezza pratica.

Il problema non è tecnico, è organizzativo: manca il tassello dell’enforcement. Ed è qui che entra in gioco Conditional Access insieme alle Authentication Strengths.

Authentication Strengths: il fondamento dell’enforcement

Microsoft Entra ID offre il concetto di Authentication Strength come meccanismo per specificare non solo che si richiede la MFA, ma quali specifici metodi sono accettati. Esistono tre Authentication Strengths predefinite:

• Multifactor authentication — la più permissiva, accetta password + qualsiasi secondo fattore (incluso SMS)
• Passwordless MFA — richiede metodi senza password, come Windows Hello o Microsoft Authenticator
• Phishing-resistant MFA — la più restrittiva, accetta solo certificati, Windows Hello for Business, passkey FIDO2

Il problema è che la maggior parte delle organizzazioni usa ancora la prima categoria — quella meno restrittiva. Alcune sono migrate dalla vecchia grant control “Require MFA”, ma si sono fermate al livello base. Usare Phishing-resistant MFA come Authentication Strength è già un passo corretto, ma la vera potenza arriva con le Custom Authentication Strengths.

Custom Authentication Strengths: controllo granulare

Le Authentication Strengths personalizzate permettono di specificare esattamente quali metodi sono ammessi, incluso il vincolo a specifici tipi di passkey tramite gli AAGUID (Authenticator Attestation GUID). Ogni tipo di passkey certificata — YubiKey 5C NFC, Google Titan, Microsoft Authenticator su iOS — ha il proprio AAGUID. Limitare l’accesso a specifici AAGUID garantisce che solo i dispositivi approvati dall’organizzazione possano autenticarsi.

Questo livello di granularità è particolarmente importante per gli account amministrativi, dove il rischio di compromissione è massimo.

Configurare la policy Conditional Access di baseline

Il punto di partenza consigliato è una policy di Conditional Access che prenda di mira un gruppo pilota di utenti che hanno già registrato una passkey. La policy deve:

1. Essere creata inizialmente in modalità report-only per monitorare l’impatto senza bloccare gli accessi
2. Targetizzare un security group contenente gli utenti del pilota
3. Usare la grant control “Require authentication strength” con l’Authentication Strength appropriata
4. Essere attivata in produzione solo dopo aver verificato i log di accesso e confermato che tutti gli utenti del gruppo hanno una passkey funzionante

Man mano che più utenti registrano le passkey, il gruppo viene espanso. Questo approccio graduale riduce il rischio di lockout e costruisce fiducia nelle varie business unit.

Account amministrativi: requisiti più stringenti

Gli account privilegiati richiedono una policy separata e più restrittiva. Le considerazioni principali sono:

• Creare una Custom Authentication Strength dedicata agli amministratori che accetti solo passkey specifiche (con AAGUID approvati)
• La policy Conditional Access per gli admin deve targetizzare esclusivamente le identità amministrative
• Aggiungere condizioni supplementari: accesso solo da reti trusted, dispositivi compliant o hybrid-joined
• Mantenere policy separate per accessi admin e utenti standard: facilita il troubleshooting e riduce la complessità

Un pattern comune negli ambienti Entra è la mancanza di protezioni specifiche per gli account amministrativi. Spesso questi account non hanno policy Conditional Access dedicate, o le policy esistenti si basano su MFA generica anziché su metodi phishing-resistant. Gli account amministrativi sono il bersaglio primario degli attaccanti: una compromissione a questo livello equivale a una compromissione del tenant.

Come usare i Sign-in Logs per verificare l’efficacia

Una volta attivate le policy in report-only, i log di accesso di Entra ID mostrano il risultato teorico della policy per ogni accesso. Per ogni evento di login è possibile vedere quale Authentication Strength è stata valutata, se l’accesso avrebbe soddisfatto i requisiti e quale metodo è stato effettivamente utilizzato.

Filtrando per gli utenti del gruppo pilota è possibile identificare chi ancora non ha registrato una passkey o chi tenta di usare metodi alternativi. Questo permette un’azione proattiva prima di attivare la policy in enforcement completo.

Conclusione: l’enforcement è dove il valore si manifesta

Le passkey sono una tecnologia potente e in rapida evoluzione, soprattutto nell’ecosistema Microsoft. Ma la loro efficacia dipende interamente dall’enforcement. Distribuire passkey senza Conditional Access che ne imponga l’uso equivale a blindare la porta principale lasciando le finestre aperte.

La sequenza corretta è: abilitare le passkey → creare le Custom Authentication Strengths appropriate → configurare le Conditional Access policy in report-only → espandere gradualmente il gruppo → attivare l’enforcement. Gli account amministrativi richiedono attenzione immediata e policy separate con requisiti più stringenti, incluso il binding a AAGUID specifici.

In un contesto di minacce sempre più sofisticate — con phishing kit come Tycoon 2FA che aggirano la MFA tradizionale — i metodi phishing-resistant non sono più un’opzione premium: sono il requisito minimo per chi gestisce identità critiche nel cloud Microsoft.

---

Fonte: Passkeys Aren’t Enough: Why Enforcement Matters in Entra ID — Petri IT Knowledgebase, Brandon Colley (TrustedSec)

Passkeys Aren’t Enough: Why Enforcement Matters in Entra ID - Petri IT Knowledgebase

Implementing passkeys in Microsoft Entra is far more than simply enabling a new authentication method. A successful passkey rollout requires careful planning

^{Brandon Colley (Petri IT Knowledgebase)}

(in)sicurezza digitale

2026-05-19 13:01:17

QLNX: il nuovo implant Linux silenzioso che saccheggia la supply chain del software

Si parla di:
Toggle

Un nuovo implant Linux mai documentato prima — denominato Quasar Linux RAT (QLNX) — sta prendendo di mira sviluppatori e ambienti DevOps con l’obiettivo di appropriarsi silenziosamente delle credenziali più preziose del ciclo di sviluppo software: token npm, PyPI, AWS, Kubernetes, GitHub e molto altro. La scoperta, opera dei ricercatori Aliakbar Zahravi e Ahmed Mohamed Ibrahim di Trend Micro, descrive uno strumento che non si limita ad essere un semplice trojan di accesso remoto, ma una piattaforma di spionaggio industriale progettata per persistere, nascondersi e colpire l’intera supply chain del software.

Cosa rende QLNX diverso dagli altri RAT Linux

A differenza di molti implant Linux che puntano sulla semplicità, QLNX è costruito come una piattaforma d’attacco coerente e modulare. Il suo punto di forza non sta in una singola tecnica innovativa, ma nell’integrazione armoniosa di più capacità offensive che si concatenano in un flusso d’attacco preciso: arriva, cancella le tracce dal disco, si radica con sei meccanismi ridondanti, si nasconde sia a livello userspace che kernel, e infine raccoglie sistematicamente le credenziali che contano davvero.

Il malware esegue filelessly dalla memoria, mascherandosi da thread del kernel attraverso nomi come kworker o ksoftirqd — nomi che ogni amministratore di sistema Linux incontra quotidianamente nei propri processi. Questo lo rende praticamente invisibile a una normale ispezione manuale. È inoltre in grado di profilare l’host per rilevare ambienti containerizzati, cancellare i log di sistema e stabilire persistenza attraverso non meno di sette metodi diversi, tra cui systemd, crontab e shell injection nel file .bashrc.

Un harvester di credenziali pensato per la supply chain

Il componente di furto credenziali di QLNX è ciò che lo rende particolarmente pericoloso per l’ecosistema open source. Il malware estrae sistematicamente segreti da un elenco preciso di file ad alto valore per uno sviluppatore:

File target di QLNX per il furto credenziali:

.npmrc              → Token di pubblicazione npm
.pypirc             → Credenziali PyPI
.git-credentials    → Credenziali Git
.aws/credentials    → Chiavi di accesso AWS
.kube/config        → Credenziali Kubernetes
.docker/config.json → Autenticazione Docker Registry
.vault-token        → Token HashiCorp Vault
.env                → Variabili d'ambiente con segreti
**/terraform.tfvars → Credenziali Terraform
GitHub CLI tokens   → Token di accesso GitHub

Il rischio non è solo per lo sviluppatore compromesso: un attore che ottiene accesso a uno di questi token può pubblicare pacchetti malevoli su npm o PyPI, accedere all’infrastruttura cloud o muoversi lateralmente attraverso pipeline CI/CD. È esattamente il meccanismo che ha consentito attacchi supply chain devastanti in passato, come l’operazione TeamPCP che ha colpito oltre 160 pacchetti npm e PyPI nelle scorse settimane.

Architettura rootkit a doppio livello: LD_PRELOAD + eBPF

L’aspetto più sofisticato di QLNX è la sua architettura rootkit a due livelli, che combina tecniche di occultamento a livello userspace e kernel.

Il primo strato è un rootkit userland deployato attraverso il meccanismo LD_PRELOAD del dynamic linker di Linux. Questo garantisce che tutti gli artefatti e i processi dell’implant rimangano nascosti agli strumenti di ispezione standard. Il secondo strato è un componente kernel-level basato su eBPF (Extended Berkeley Packet Filter) — il potente sottosistema Linux originariamente pensato per il networking e l’osservabilità dei sistemi. QLNX sfrutta eBPF per nascondere processi, file e porte di rete agli strumenti userland come ps, ls e netstat, su istruzione del server di comando e controllo (C2).

L’uso offensivo di eBPF per il rootkitting è una tendenza già documentata da altri ricercatori, ma la sua integrazione in un RAT con builder pipeline modulare indica una maturazione significativa di queste tecniche al di fuori di ambienti di ricerca accademica.

Backdoor PAM: furto di credenziali SSH in tempo reale

QLNX include anche un backdoor basato su PAM (Pluggable Authentication Module) che intercetta le credenziali in chiaro durante gli eventi di autenticazione SSH. Il componente PAM inline-hook registra i dati delle sessioni SSH in uscita e li trasmette al C2. È inoltre presente un secondo logger PAM che viene caricato automaticamente in ogni processo collegato dinamicamente, per estrarre nome del servizio, username e token di autenticazione.

Questa tecnica è particolarmente insidiosa perché i moduli PAM girano tipicamente con privilegi root e operano a un livello così basso nello stack di autenticazione che la maggior parte dei sistemi di monitoring tradizionali non riesce a intercettarli. Non a caso, negli ultimi mesi sono emersi altri strumenti simili — come PamDOORa, venduto su forum russi di cybercrime per 900 dollari — che sfruttano lo stesso vettore.

58 comandi C2 e un’infrastruttura operativa completa

QLNX supporta ben 58 comandi distinti che conferiscono agli operatori il controllo completo dell’host compromesso. Le capacità operative includono esecuzione di shell commands, gestione file, code injection nei processi, cattura di screenshot, keylogging, SOCKS proxy, TCP tunneling, esecuzione di Beacon Object Files (BOFs) — la stessa tecnica usata da Cobalt Strike — e gestione di una rete P2P mesh tra host compromessi.

La comunicazione con il C2 avviene su tre protocolli — TCP grezzo, HTTPS e HTTP — con un loop persistente che tenta continuamente di mantenere attiva la connessione. La vettore di infezione iniziale rimane ancora sconosciuto, ma una volta stabilito il foothold, QLNX cancella i propri artefatti dal disco e avvia la fase operativa principale.

Indicatori di compromissione e contromisure

QLNX evidenzia una tendenza preoccupante: la supply chain del software sta diventando il bersaglio privilegiato di attori sofisticati, perché compromettere un singolo sviluppatore con accesso ai registri npm o PyPI può avere effetti moltiplicatori su migliaia di utenti downstream. Per i team di sicurezza, alcune contromisure prioritarie:

• Ruotare regolarmente tutti i token di pubblicazione per npm, PyPI, GitHub e altri registri, soprattutto dopo accessi da sistemi non familiari.
• Monitorare processi Linux con nomi simili a thread del kernel — kworker, ksoftirqd ecc. — che non corrispondono agli effettivi thread del kernel: strumenti come pstree con verifica del PPID possono rivelare anomalie.
• Verificare l’integrità dei moduli PAM: controllare regolarmente che i file .so nei percorsi PAM non siano stati modificati rispetto alla versione del package manager.
• Abilitare audit logging di eBPF per rilevare il caricamento di programmi eBPF non autorizzati: auditctl -a always,exit -F arch=b64 -S bpf.
• Isolare i segreti CI/CD dall’ambiente di sviluppo locale, usando secret manager dedicati piuttosto che file in chiaro su disco.

Trend Micro ha pubblicato i dettagli tecnici completi nel proprio blog di ricerca. La natura fileless di QLNX e il suo doppio rootkit rendono il rilevamento basato su signature sostanzialmente inefficace: la difesa deve puntare su behavioral analytics e monitoraggio delle anomalie a livello di syscall, combinati con soluzioni EDR capaci di ispezionare la memoria dei processi.

Quasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a Full-Featured Linux RAT With Rootkit, PAM Backdoor, Credential Harvesting Capabilities

TrendAI™ Research breaks down Quasar Linux (QLNX), a previously undocumented sophisticated Linux RAT with low detection rates.

^{Trend Micro}

Spcnet.it

2026-05-18 17:46:56

CVE-2026-42897: vulnerabilità critica XSS in Exchange Server OWA — mitigazione di emergenza disponibile

Cos’è la vulnerabilità CVE-2026-42897

Il 14 maggio 2026 Microsoft ha divulgato pubblicamente una vulnerabilità critica nei propri server Exchange on-premises, tracciata come CVE-2026-42897. La falla, classificata come Cross-Site Scripting (XSS), risiede nel componente Outlook Web Access (OWA) e permette a un attaccante di eseguire codice JavaScript arbitrario nel browser della vittima senza richiedere alcuna interazione complessa: è sufficiente che l’utente apra una email appositamente confezionata direttamente dalla webmail.

La vulnerabilità è già sfruttata attivamente in the wild: la CISA (Cybersecurity and Infrastructure Security Agency) degli Stati Uniti l’ha aggiunta al proprio catalogo di vulnerabilità note e sfruttate (Known Exploited Vulnerabilities) con scadenza obbligatoria di remediation al 29 maggio 2026 per le agenzie federali americane. Il rischio per le organizzazioni private è ugualmente elevato.

Versioni di Exchange Server interessate

La vulnerabilità colpisce esclusivamente i server Exchange installati on-premises. In particolare:

• Exchange Server 2016
• Exchange Server 2019
• Exchange Server Subscription Edition (SE)

Exchange Online non è interessato: le organizzazioni che utilizzano esclusivamente il servizio cloud Microsoft 365 non devono intraprendere alcuna azione. Il rischio è confinato a chi gestisce ancora infrastrutture Exchange on-premises, scenario ancora comune in contesti enterprise con requisiti di compliance, residenza del dato o integrazione con sistemi legacy.

Come funziona l’attacco

Il vettore di attacco è particolarmente insidioso perché non richiede configurazioni particolari lato vittima: l’attaccante invia una email con contenuto HTML appositamente costruito. Quando il destinatario apre il messaggio tramite OWA, il payload JavaScript viene eseguito nel contesto del browser dell’utente, con accesso alla sessione OWA attiva.

Le conseguenze possibili includono:

• Furto del cookie di sessione e hijacking dell’account
• Esecuzione di azioni per conto dell’utente (invio email, accesso a cartelle, lettura di allegati)
• Lateral movement verso altri sistemi integrati con Exchange (es. Active Directory, SharePoint)
• Esfiltrazione di dati sensibili contenuti nelle caselle di posta

In un ambiente enterprise, un attacco XSS riuscito contro OWA può essere il punto di ingresso per una compromissione ben più ampia, specialmente se la webmail è accessibile dall’esterno o da reti non completamente fidate.

Mitigazioni disponibili: come intervenire subito

Microsoft ha rilasciato mitigazioni di emergenza in attesa di una patch definitiva. Esistono due percorsi principali:

1. Exchange Emergency Mitigation Service (EM Service)

Il metodo preferito è affidarsi all’Exchange Emergency Mitigation Service, che applica automaticamente una configurazione di URL Rewrite sul server IIS per neutralizzare il vettore di attacco. Il servizio EM è abilitato per default nelle installazioni supportate di Exchange Server. Se non è stato disabilitato manualmente, la mitigazione potrebbe già essere attiva.

Per verificare lo stato della mitigazione, Microsoft raccomanda di eseguire il tool Exchange Health Checker:

# Scarica ed esegui Exchange Health Checker in una Exchange Management Shell elevata
. .\HealthChecker.ps1
Invoke-HealthChecker


Il report generato indica chiaramente se la mitigazione M2 per CVE-2026-42897 è stata applicata con successo.

2. Exchange On-Premises Mitigation Tool (EOMT) per ambienti air-gap

Per i server Exchange non connessi a internet o in ambienti con restrizioni di rete, Microsoft ha reso disponibile una procedura di mitigazione manuale tramite lo strumento EOMT (Exchange On-Premises Mitigation Tool):

# Download da: https://aka.ms/UnifiedEOMT
# Eseguire da una Exchange Management Shell con privilegi elevati

.\EOMTv2.ps1 -ExchangeVersion 2019


Dopo l’applicazione, è fondamentale verificare che le regole di URL Rewrite siano state create correttamente e che il servizio IIS sia stato riavviato.

Impatto sulle funzionalità di OWA dopo la mitigazione

L’applicazione della mitigazione introduce alcune limitazioni funzionali che gli amministratori devono comunicare agli utenti:

• Immagini inline nelle email: potrebbero non essere visualizzate correttamente nel pannello di lettura di OWA. La soluzione alternativa è inviare le immagini come allegati o usare il client Outlook desktop.
• Stampa del calendario da OWA: la funzione potrebbe non operare. Gli utenti possono utilizzare screenshot o Outlook desktop come workaround.
• OWA Light (interfaccia legacy): già deprecata, potrebbe smettere di funzionare completamente. Non è una perdita significativa per la maggior parte delle organizzazioni.

Queste limitazioni sono accettabili rispetto al rischio rappresentato dalla vulnerabilità non mitigata.

Patch definitiva: cosa aspettarsi

Microsoft sta lavorando a un aggiornamento di sicurezza permanente. Un dettaglio importante per chi gestisce Exchange 2016 e 2019: le patch ufficiali saranno rilasciate solo per i clienti commerciali iscritti al programma ESU (Extended Security Update). Exchange 2016 ha raggiunto la fine del supporto mainstream nell’ottobre 2025, e Exchange 2019 raggiungerà la stessa condizione nell’ottobre 2025. Le organizzazioni che non hanno sottoscritto l’ESU si troveranno senza patch definitiva e dovranno affidarsi esclusivamente alla mitigazione di emergenza, con un rischio residuo crescente nel tempo.

Questo scenario rafforza l’urgenza di pianificare una migrazione verso Exchange Server SE o Exchange Online per chi è ancora su versioni precedenti.

Checklist di risposta per gli amministratori

Se gestisci un’infrastruttura Exchange on-premises, ecco le azioni da completare nell’ordine:

1. Verifica la versione di Exchange in uso: apri la Exchange Management Shell e lancia Get-ExchangeServer | Select Name,AdminDisplayVersion
2. Controlla se il servizio EM è attivo: Get-Service MSExchangeMitigation
3. Esegui Exchange Health Checker per verificare l’applicazione della mitigazione M2
4. Se l’EM Service è disabilitato o il server è air-gapped, applica EOMT manualmente
5. Comunica agli utenti le limitazioni temporanee di OWA
6. Monitora il blog ufficiale di Exchange (techcommunity.microsoft.com) per il rilascio della patch definitiva
7. Valuta l’iscrizione al programma ESU se stai usando Exchange 2016 o 2019

Conclusione

CVE-2026-42897 è un esempio concreto di come le infrastrutture on-premises legacy rimangano vettori di attacco critici anche in ambienti enterprise ben gestiti. La buona notizia è che Microsoft ha reagito rapidamente con mitigazioni di emergenza e ha reso la verifica dello stato accessibile tramite strumenti già noti come Exchange Health Checker. La cattiva notizia è che chi non ha ancora pianificato l’uscita da Exchange 2016/2019 si trova in una posizione sempre più rischiosa, non solo per questa vulnerabilità ma per tutte quelle future che non riceveranno patch ufficiali.

Applicare la mitigazione adesso, verificarne l’efficacia e pianificare la migrazione al più presto sono le tre priorità concrete da portare all’attenzione del management tecnico questa settimana.

---

Fonte: Microsoft Warns Exchange Server Flaw Lets Attackers Execute Code via OWA Emails – Petri IT Knowledgebase | Microsoft Tech Community – Addressing Exchange Server May 2026 vulnerability

Addressing Exchange Server May 2026 vulnerability CVE-2026-42897 | Microsoft Community Hub

We wanted to tell you how to address the Exchange Server May 2026 vulnerability CVE-2026-42897.  

^{The_Exchange_Team (TECHCOMMUNITY.MICROSOFT.COM)}

Spcnet.it

2026-05-18 17:48:54

I colli di bottiglia nascosti nei microservizi in produzione: diagnostica e soluzioni pratiche

Il problema che non si vede finché è troppo tardi

C’è un pattern ricorrente nelle architetture a microservizi: tutto funziona in modo impeccabile per mesi, i test automatici sono verdi, il monitoraggio non mostra allarmi rilevanti, e il team è soddisfatto della solidità del sistema. Poi, spesso durante un picco di traffico ordinario o un evento previsto, qualcosa si inceppa. La latenza schizza verso l’alto, le code si allungano, i timeout si moltiplicano. Il problema non è stato causato dall’evento in sé — era già lì, nascosto sotto la superficie.

Questo articolo analizza i colli di bottiglia più insidiosi che affliggono i microservizi in produzione: quelli che non emergono nei test di carico standard e che vengono spesso diagnosticati troppo tardi.

1. Esaurimento del connection pool al database

Il problema del connection pool è forse il più comune e il meno visibile fino al momento critico. In un’architettura a microservizi, ogni istanza di ogni servizio apre e gestisce il proprio pool di connessioni al database. Il calcolo è semplice: se hai 10 microservizi con 5 istanze ciascuno e ogni istanza mantiene un pool di 10 connessioni, stai occupando 500 connessioni sul database. Scala orizzontalmente per gestire un picco di traffico, e quelle connessioni raddoppiano in pochi minuti.

La maggior parte dei database relazionali ha un limite fisico di connessioni concorrenti. PostgreSQL, per esempio, ha un default di 100 connessioni per il parametro max_connections. Superato il limite, nuove richieste di connessione falliscono con errori che spesso vengono nascosti da retry automatici, mascherando il problema effettivo fino a quando il sistema non collassa.

Come diagnosticarlo

-- PostgreSQL: connessioni attive per applicazione
SELECT application_name, count(*), state
FROM pg_stat_activity
GROUP BY application_name, state
ORDER BY count DESC;

-- Verifica il limite configurato
SHOW max_connections;


Come risolverlo

La soluzione più efficace per scenari ad alta concorrenza è l’uso di un connection pooler esterno come PgBouncer. PgBouncer opera in modalità transaction pooling: riusa le connessioni al database tra più client, riducendo drasticamente il numero di connessioni fisiche necessarie indipendentemente dal numero di istanze dei servizi.

# pgbouncer.ini — configurazione essenziale
[databases]
mydb = host=pg-primary port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20
reserve_pool_size = 5


In .NET, assicurati che il pool di connessioni Npgsql sia configurato in modo coerente con i limiti imposti da PgBouncer:

// Connection string con pool sizing esplicito
"Host=pgbouncer-host;Database=mydb;Username=app;Password=...;
 Maximum Pool Size=10;Minimum Pool Size=2;Connection Idle Lifetime=300"


2. Thread pool starvation nelle chiamate sincrone

Il thread pool starvation è un problema particolarmente subdolo nelle applicazioni ASP.NET Core o nelle applicazioni Spring Boot che mischiano codice asincrono e sincrono. Quando un thread del pool viene bloccato in attesa di un’operazione I/O (una query al database, una chiamata HTTP a un servizio dipendente, una lettura da file), quel thread non è disponibile per elaborare nuove richieste. Se questo accade su scala, il thread pool si esaurisce e le nuove richieste rimangono in coda indefinitamente.

Il sintomo tipico è una degradazione progressiva delle performance durante i picchi: il throughput crolla, i tempi di risposta salgono in modo apparentemente inspiegabile, ma il database e la CPU risultano ancora sotto carico normale.

Pattern da evitare in .NET

// ❌ SBAGLIATO: blocca un thread del pool
public IActionResult GetData()
{
    var result = _service.GetDataAsync().Result; // .Result blocca il thread
    return Ok(result);
}

// ❌ Altrettanto problematico
public IActionResult GetData()
{
    var result = _service.GetDataAsync().GetAwaiter().GetResult();
    return Ok(result);
}


// ✅ CORRETTO: il thread viene restituito al pool durante l'attesa
public async Task<IActionResult> GetData()
{
    var result = await _service.GetDataAsync();
    return Ok(result);
}


Come diagnosticare il thread pool starvation

In .NET, puoi monitorare lo stato del thread pool a runtime:

ThreadPool.GetAvailableThreads(out int workerThreads, out int completionPortThreads);
ThreadPool.GetMaxThreads(out int maxWorker, out int maxCompletionPort);

// Se workerThreads è vicino a 0 con carico moderato, sei in starvation
Console.WriteLine($"Available: {workerThreads}/{maxWorker}");


Strumenti come dotnet-counters offrono un monitoraggio continuo in produzione senza impatto significativo:

dotnet-counters monitor --counters System.Runtime[threadpool-thread-count,threadpool-queue-length] -p <PID>


3. Cascading failures per dipendenze lente o non responsive

In un’architettura a microservizi, ogni servizio dipende da altri servizi. Questa catena di dipendenze è la fonte di uno dei problemi più difficili da gestire in produzione: il cascading failure. Se il Servizio B risponde lentamente, il Servizio A che lo chiama accumula richieste in attesa. I thread del pool di A vengono occupati in attesa di B, la latenza di A aumenta, il Servizio C che dipende da A inizia a ricevere timeout, e nel giro di pochi minuti l’intera catena collassa.

La soluzione consolidata è il pattern Circuit Breaker, che interrompe temporaneamente le chiamate verso un servizio degradato e restituisce immediatamente un errore (o una risposta di fallback), permettendo al sistema di degradare in modo controllato invece di collassare a cascata.

Implementazione con Polly in .NET

// Configurazione circuit breaker con Polly v8
var circuitBreakerPolicy = new ResiliencePipelineBuilder()
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5,              // Apre dopo il 50% di fallimenti
        SamplingDuration = TimeSpan.FromSeconds(10),
        MinimumThroughput = 10,          // Minimo 10 richieste nel campione
        BreakDuration = TimeSpan.FromSeconds(30), // Attende 30s prima di riprovare
        OnOpened = args =>
        {
            _logger.LogWarning("Circuit breaker aperto per {Service}", serviceName);
            return default;
        }
    })
    .AddTimeout(TimeSpan.FromSeconds(3)) // Timeout esplicito su ogni chiamata
    .Build();

// Uso
var result = await circuitBreakerPolicy.ExecuteAsync(async token =>
    await _httpClient.GetFromJsonAsync<OrderDto>("/api/orders/123", token),
    cancellationToken);


4. Mancanza di backpressure nei flussi di messaggi

I sistemi basati su message broker (Kafka, RabbitMQ, Azure Service Bus) introducono un’ulteriore classe di colli di bottiglia: quando il ritmo di produzione dei messaggi supera la capacità di elaborazione dei consumer, le code crescono indefinitamente. Questo può portare a latenza crescente nell’elaborazione, out-of-memory degli broker, e scenari in cui messaggi vengono elaborati con ore o giorni di ritardo rispetto alla loro produzione.

La soluzione è implementare la backpressure: i consumer controllano attivamente il ritmo di ricezione in base alla propria capacità di elaborazione. In Kafka, questo si gestisce configurando correttamente il numero di partizioni, il numero di consumer nel consumer group, e i parametri max.poll.records e fetch.max.bytes.

// Esempio: consumer con controllo esplicito del concurrency via MassTransit
services.AddMassTransit(x =>
{
    x.UsingRabbitMq((ctx, cfg) =>
    {
        cfg.ReceiveEndpoint("orders-queue", e =>
        {
            e.PrefetchCount = 10;        // Non prelevare più di 10 messaggi alla volta
            e.ConcurrentMessageLimit = 5; // Elabora al massimo 5 messaggi in parallelo
            e.ConfigureConsumer<OrderConsumer>(ctx);
        });
    });
});


5. N+1 queries non rilevate in produzione

Il problema delle N+1 queries è ben noto in teoria ma sorprendentemente comune in produzione, soprattutto dopo refactoring o l’aggiunta di nuove funzionalità. L’ORM carica una lista di entità (1 query), poi per ogni entità carica lazy una relazione (N query). In sviluppo, con 10 elementi nel database, il problema è invisibile. In produzione, con 10.000 elementi, si traducono in 10.001 query per ogni richiesta.

// ❌ N+1: per ogni ordine viene eseguita una query separata per i prodotti
var orders = await _context.Orders.ToListAsync();
foreach (var order in orders)
{
    // Lazy load: ogni accesso a order.Products genera una nuova query
    var productNames = order.Products.Select(p => p.Name);
}

// ✅ Eager loading: una sola query con JOIN
var orders = await _context.Orders
    .Include(o => o.Products)
    .ToListAsync();


Per rilevare le N+1 in produzione, abilita il logging delle query EF Core in ambiente di staging con soglia di warning per query lente:

// Program.cs
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .LogTo(Console.WriteLine, LogLevel.Information)
           .EnableSensitiveDataLogging(false) // Mai in produzione
           .ConfigureWarnings(w => w.Throw(RelationalEventId.MultipleCollectionIncludeWarning)));


Monitoraggio proattivo: gli indicatori chiave

Rilevare questi problemi prima che diventino incidenti richiede un set di metriche mirate. Oltre alle metriche standard (CPU, RAM, latenza), monitora attivamente:

• Connessioni attive al database per istanza e per servizio
• Thread pool queue length: una coda crescente anche sotto carico moderato è un segnale di allarme
• Circuit breaker state changes: ogni apertura di un circuit breaker è un evento da tracciare e analizzare
• Message lag sulle code Kafka/RabbitMQ: il ritardo tra produzione e consumo
• Slow queries: percentuale di query che superano una soglia prefissata (es. 500ms)

Strumenti come Prometheus + Grafana con i rispettivi exporter per PostgreSQL, RabbitMQ e .NET (via prometheus-net) permettono di costruire dashboard specifiche per questi pattern senza dipendere esclusivamente dai log.

Conclusione

I colli di bottiglia nascosti nei microservizi hanno una caratteristica comune: emergono sotto carico, in condizioni che i test standard non replicano fedelmente. Connection pool esauriti, thread in starvation, cascading failures, code in crescita incontrollata e N+1 queries sono problemi architetturali che richiedono attenzione già in fase di design, non solo quando il sistema è già in produzione e sotto stress.

Identificare preventivamente questi pattern, configurare correttamente i pool e i circuit breaker, e costruire un layer di osservabilità specifico per questi indicatori è l’investimento tecnico con il miglior ritorno in termini di stabilità per qualsiasi sistema distribuito di dimensioni non banali.

---

Fonte: The Hidden Bottlenecks That Break Microservices in Production – DZone

(in)sicurezza digitale

2026-05-18 15:39:00

UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici

Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182

Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde

Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

• Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
• Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
• Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
• Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.

Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione

Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

• SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
• Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
• Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
• Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
• Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.

Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi

CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori

Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

• Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
• Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
• Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
• Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
• Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.

CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Fonti: Cisco Talos, CISA KEV, SecurityWeek, Help Net Security, Tenable, Dark Reading

(in)sicurezza digitale

2026-05-18 15:45:00

Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI

Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza

Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione

La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso

Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali

Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche

OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack

L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

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

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

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

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

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

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog

TanStack and 160+ npm/PyPI Packages Compromised in Supply Chain Worm Attack

Over 160 npm/PyPI packages like TanStack were compromised by the Mini Shai-Hulud worm. Orca helps prioritize remediation and immediate action.

^{Roi Nisimi (Orca Security)}

(in)sicurezza digitale

2026-05-18 14:10:58

Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile

Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P

Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker

Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

• Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
• Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
• Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti

Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina

Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori

Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Fonti: Microsoft Security Blog, BleepingComputer, The Hacker News

Kazuar: Anatomy of a nation-state botnet | Microsoft Security Blog

Kazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under constant development for years and continues to evolve in support of espionage-focused operations.

^{Microsoft Threat Intelligence (Microsoft Security Blog)}

m0nt4lb4n0

2026-05-06 06:09:14

2° Meeting nazionale TWC Italia

Inizia: Sabato Giugno 13, 2026 @ 12:00 AM GMT+02:00 (Europe/Rome)

Finisce: Domenica Giugno 14, 2026 @ 12:00 AM GMT+02:00 (Europe/Rome)

Incontriamoci. Confrontiamoci. Organizziamoci.

🌍 LSA100Celle - Roma

📍13 e 14 giugno ci vediamo a #Roma per il secondo Meeting nazionale di Tech Workers Coalition Italia. Un'occasione per discutere delle criticità del settore tech italiano e globale e mettere in rete le pratiche di mobilitazione.Un grande log out nazionale per costruire l'alternativa possibile nei nostri luoghi di lavoro. Non lasciamoci deformare dalla tecnologia.

Sostieni il meeting su OpenCollective e segui tutti gli aggiornamenti sul programma sul nostro sito.

Instagram

Create an account or log in to Instagram - Share what you're into with the people who get you.

^Instagram

Spcnet.it

2026-05-17 10:39:02

MCP, A2A e AG-UI: lo stack dei protocolli per agenti AI nel 2026

Nel 2026, chi sviluppa agenti AI si trova inevitabilmente a fare i conti con tre acronimi: MCP, A2A e AG-UI. La domanda più comune è: sono standard in competizione tra loro? Devo usarli tutti e tre? Quale mi serve davvero?

La risposta breve è che non competono affatto — si completano. Ciascuno risolve un problema diverso a un livello diverso dell’architettura degli agenti. Un’analogia utile: pensateli come TCP, HTTP e HTML nel web — protocolli che operano a strati diversi e insieme rendono possibile il funzionamento del sistema.

Il quadro d’insieme

Prima di entrare nel dettaglio, ecco una tabella riassuntiva:

Protocollo	Creato da	Connette	Risponde alla domanda
MCP	Anthropic	Agente ↔ Strumenti e dati	“Come fa il mio agente a usare i tool?”
A2A	Google / Linux Foundation	Agente ↔ Agente	“Come parlano gli agenti tra di loro?”
AG-UI	CopilotKit	Agente ↔ Interfaccia utente	“Come comunica il mio agente con l’utente?”

MCP — Il layer degli strumenti

Il problema che risolve

Il vostro agente deve fare cose concrete: interrogare un database, chiamare un’API, leggere un file, cercare sul web. Prima di MCP, ogni integrazione era custom: codice ad hoc per ogni strumento, ogni framework, ogni modello. MCP standardizza tutto questo in un unico protocollo.

Come funziona

MCP usa un’architettura client-server basata su JSON-RPC 2.0. Il server MCP espone:

• Tools: funzioni che il modello può invocare, con nome, descrizione e schema tipizzato degli input
• Resources: dati in sola lettura che l’agente può consultare (schemi DB, file di configurazione)
• Prompts: template riutilizzabili

Il client MCP — tipicamente integrato nel framework dell’agente — scopre queste capacità e le invoca per conto del modello. I transport sono flessibili: stdio per tool locali (subprocess), Streamable HTTP per deployment remoti in produzione.

Quando usarlo

Usate MCP ogni volta che il vostro agente deve interagire con sistemi esterni: database, API REST, file system, servizi cloud. Se state wrappando un’API esistente per renderla accessibile agli agenti, MCP è il protocollo giusto. L’ecosistema è già maturo: AWS fornisce server MCP open source per S3, DynamoDB, CloudWatch; sono disponibili server per GitHub, Slack, PostgreSQL e decine di altri servizi.

Quando NON usarlo

MCP non è pensato per la comunicazione tra agenti, né per aggiornare interfacce utente. Se avete un agente che deve delegare sotto-task a un altro agente specializzato, quello è territorio di A2A.

A2A — Il layer di collaborazione tra agenti

Il problema che risolve

Avete costruito più agenti specializzati: uno per la ricerca, uno per la generazione di codice, uno per la gestione dei deployment. Come farli collaborare su task complessi senza condividere stato interno, tool o prompt? A2A standardizza come gli agenti si scoprono, delegano task e si scambiano risultati.

Come funziona

A2A usa un modello client-server su HTTP con JSON-RPC 2.0 (e opzionalmente gRPC dalla v0.3). Il principio chiave è l’opacità: gli agenti non espongono i propri internals, pubblicizzano solo ciò che sanno fare.

I concetti fondamentali:

• Agent Cards: documenti JSON ospitati su /.well-known/agent.json che descrivono nome, capacità (“skills”), tipi di input/output supportati e requisiti di autenticazione. Un biglietto da visita machine-readable.
• Tasks: l’unità di lavoro. Un client invia un messaggio al remote agent, che crea un task con lifecycle: submitted → working → completed (o failed, canceled).
• Interaction patterns: sincrono per task semplici, SSE (Server-Sent Events) per streaming su task lunghi, webhook per workflow veramente asincroni.

Quando usarlo

A2A brilla nei sistemi multi-agente dove gli agenti non devono condividere stato interno. Pattern comuni:

• Un agente supervisor che delega a specialisti
• Collaborazione cross-organizzazione (il vostro agente che interagisce con quello del vendor)
• Setup multi-framework: un agente LangGraph che coordina un agente CrewAI — grazie all’opacità, non importa cosa c’è “dentro”

Quando NON usarlo

Per agenti singoli che devono solo chiamare tool, A2A aggiunge overhead non necessario. Se avete bisogno di accoppiamento stretto tra agenti (condivisione di memoria o stato), A2A non è lo strumento giusto.

AG-UI — Il layer dell’interfaccia utente

Il problema che risolve

I vostri agenti hanno bisogno di comunicare con gli utenti in tempo reale: messaggi incrementali, aggiornamenti di stato, handoff per l’approvazione umana. Prima di AG-UI, ogni team implementava questo in modo proprietario — WebSocket custom, polling, SSE artigianali.

Come funziona

AG-UI è un protocollo a eventi strutturati che collega il backend dell’agente con il frontend. Definisce un insieme standard di eventi (message chunks, tool calls, state updates, human-in-the-loop requests) che qualsiasi UI può consumare. È leggero — basato su SSE — e disaccoppiato dal framework dell’agente.

Quando usarlo

Ogni volta che il vostro agente ha una UI interattiva: chatbot, assistenti embedded, dashboard con feedback in tempo reale. Se invece l’agente è un job in background senza interazione utente (elaborazione batch, task schedulati), AG-UI aggiunge complessità inutile.

Come si combinano in pratica

Lo stack completo per un sistema agente enterprise tipico appare così:

┌─────────────────────────────────────┐
│           Interfaccia Utente        │
│         (React, Vue, ecc.)          │
└─────────────┬───────────────────────┘
              │ AG-UI (SSE events)
┌─────────────▼───────────────────────┐
│         Agente Principale           │
│    (LangGraph / CrewAI / custom)    │
│                                     │
│  ┌──────────┐    ┌───────────────┐  │
│  │  MCP     │    │     A2A       │  │
│  │ (tools)  │    │ (subagenti)   │  │
│  └──────────┘    └───────────────┘  │
└─────────────────────────────────────┘
         │                 │
    DB, API, File    Agenti Specializzati


Un agente principale riceve l’input dell’utente via AG-UI, chiama tool esterni tramite MCP (database, API), e se il task è complesso delega a sotto-agenti specializzati tramite A2A — che a loro volta possono usare MCP per i propri tool.

Lo stato dell’ecosistema nel 2026

MCP ha vinto il layer dei tool: è supportato da praticamente tutti i framework principali (LangChain, LlamaIndex, AutoGen, Semantic Kernel) e ha un ecosistema di centinaia di server pre-costruiti. A2A sta emergendo come standard per il layer di coordinamento e la Linux Foundation ne gestisce ora la governance insieme a MCP. AG-UI è più giovane ma sta guadagnando terreno rapidamente grazie all’integrazione con CopilotKit e framework React.

La combinazione dei tre è sempre più considerata il baseline atteso per deployment agente enterprise — come HTTP, TLS e OAuth sono diventati il baseline per i servizi web.

Conclusione

Se state iniziando a costruire agenti AI, ecco un percorso pragmatico:

1. Iniziate con MCP — è maturo, ha un ecosistema enorme e copre la maggior parte dei casi d’uso con un singolo agente
2. Aggiungete A2A quando avete più agenti specializzati che devono collaborare
3. Integrate AG-UI solo se l’agente ha una UI interattiva che richiede aggiornamenti in tempo reale

La buona notizia è che questi protocolli sono progettati per coesistere: adottarli incrementalmente è la strategia giusta.

---

Fonte originale: The Agent Protocol Stack: MCP vs. A2A vs. AG-UI (DZone) — approfondito con ulteriori riferimenti da Dev.to e subhadipmitra.com.

The Agent Protocol Stack: Why MCP + A2A + A2UI Is the TCP/IP Moment for Agentic AI

MCP handles agent-to-tool. A2A handles agent-to-agent. A2UI handles agent-to-interface. Together they form a protocol stack that nobody has mapped properly - including the security gaps that should terrify you.

^{Subhadip Mitra}

Spcnet.it

2026-05-17 10:38:35

Zombie API: il rischio nascosto nelle tue vecchie integrazioni (e come eliminarlo)

Tre anni fa il vostro team ha costruito un’integrazione di pagamento. Funzionava perfettamente. Poi siete passati a una soluzione migliore, avete rilasciato la nuova versione e tutti si sono dedicati al progetto successivo. Nessuno ha aperto un ticket formale per disattivare il vecchio endpoint. Nessuno ci ha nemmeno pensato.

Quell’endpoint probabilmente sta ancora girando adesso. Benvenuti nel problema delle Zombie API.

Cosa sono le Zombie API

Una Zombie API è un’interfaccia applicativa che rimane accessibile ma che l’organizzazione non monitora più, non aggiorna e non supporta ufficialmente. Continua a funzionare in background, risponde alle richieste, restituisce dati — ma nessuno la presidia. Può trattarsi di:

• Un’API versione 1 dimenticata dopo il lancio della v2
• Un endpoint di test mai rimosso dall’ambiente di produzione
• Un’integrazione con un sistema esterno deprecato ma mai formalmente chiusa
• Un servizio interno esposto durante uno sprint e poi lasciato lì

La differenza rispetto alle Shadow API è sottile ma importante: le Shadow API sono endpoint mai documentati ufficialmente (spesso creati da sviluppatori senza seguire i processi aziendali); le Zombie API sono endpoint che erano ufficiali, ma sono sopravvissute alla loro utilità.

Perché le Zombie API sono pericolose

1. Controlli di sicurezza obsoleti

Le Zombie API nascono in un’epoca diversa. Possono ancora utilizzare meccanismi di autenticazione deboli come API key in plaintext, HTTP Basic Auth senza HTTPS, o sessioni senza scadenza. Non hanno mai ricevuto le patch per le vulnerabilità scoperte negli anni successivi alla loro creazione. I framework e le librerie che usano sono datati, spesso con CVE note e non risolte.

# Esempio: vecchio endpoint con autenticazione debole
GET /api/v1/payments?user_id=1234&token=abc123
# Nessuna validazione token server-side, nessun rate limiting,
# nessun log di accesso attivo


2. Assenza di monitoraggio

Gli endpoint zombie non compaiono nei dashboard di osservabilità, non generano alert, non vengono inclusi nei penetration test periodici. Eppure continuano a restituire dati: record di clienti, token di sessione, informazioni di sistema. Le violazioni che li coinvolgono possono passare inosservate per mesi.

3. Superficie di attacco invisibile

Dal punto di vista del team di sicurezza, l’endpoint non esiste. Dal punto di vista di un attaccante, invece, è perfettamente raggiungibile. Gli scanner automatici — e nel 2026 sempre più spesso gli agenti AI autonomi — individuano questi endpoint attraverso pattern comuni: /api/v1/, /api/legacy/, file Swagger dimenticati, entry in file robots.txt.

4. Il vettore degli agenti AI

Una dimensione nuova nel 2026: i sistemi agentic AI che chiamano autonomamente API per completare task possono scoprire e interagire con endpoint zombie che il team di sicurezza umano non ha mai pensato di inventariare. Un agente che esegue fuzzing automatico o che segue link nei file di documentazione può “risvegliare” endpoint che nessuno controllava da anni.

Come identificare le Zombie API nel vostro ambiente

Inventario tramite discovery automatica

Il primo passo è vedere ciò che non si riesce a vedere. Strumenti come OWASP ZAP, Burp Suite, o soluzioni enterprise come Noname Security, Salt Security e Traceable AI possono scansionare il traffico di rete per identificare endpoint che ricevono richieste ma non compaiono nella documentazione ufficiale.

# Con curl e grep: cerca pattern di API versionate nei log
grep -E "/api/v[0-9]+/" /var/log/nginx/access.log |   awk '{print $7}' | sort | uniq -c | sort -rn | head -50


Analisi del codice sorgente

Una scansione statica del codice può estrarre tutti i route definiti nell’applicazione e confrontarli con quelli registrati nel gateway API. La differenza è la lista candidata di zombie (o shadow).

# Esempio con grep per trovare route Express.js
grep -rE "app\.(get|post|put|delete|patch)\s*\(" ./src   | grep -oP "(?

Analisi del traffico reale

Anche se un endpoint non viene più mantenuto, potrebbe ancora ricevere traffico — da client legacy, da integrazioni di partner non aggiornate, o da attaccanti che lo scandagliano. Analizzare i log di accesso degli ultimi 90-180 giorni rivela endpoint “morti” che in realtà rispondono ancora.

Come mitigare il rischio

Governance del ciclo di vita delle API

La soluzione strutturale è implementare un API lifecycle management formale, con quattro fasi chiare:

1. Active: l’API è in produzione, monitorata e manutenuta
2. Deprecated: l’API funziona ancora ma è stata annunciata la dismissione. I client ricevono header Deprecation e Sunset in ogni risposta
3. Sunset: la data di dismissione è imminente, le richieste restituiscono warning espliciti
4. Retired: l’endpoint è stato disattivato, risponde con 410 Gone

# Header HTTP di deprecazione (RFC 8594)
HTTP/1.1 200 OK
Deprecation: Sat, 31 Dec 2025 23:59:59 GMT
Sunset: Sat, 30 Jun 2026 23:59:59 GMT
Link: <https://api.example.com/v2/payments>; rel="successor-version"


Applicate il principio del minimo privilegio anche alle API

Le API che non sono più in uso attivo non dovrebbero avere accesso ai sistemi di produzione. Prima di decommissionare formalmente, rimuovete le credenziali, revocate i token di accesso e isolate l’endpoint dalla rete interna.

Automatizzate il testing di sicurezza su tutto l’inventario

Il penetration test periodico deve includere anche gli endpoint “vecchi”. Configurate scanner DAST (Dynamic Application Security Testing) per coprire l’intero inventario API, non solo gli endpoint documentati nella versione corrente.

# Esempio con OWASP ZAP via CLI
docker run -t owasp/zap2docker-stable zap-api-scan.py   -t https://api.example.com/api/v1/openapi.yaml   -f openapi   -r zap-report.html


Risk scoring degli endpoint

Non tutti gli endpoint zombie hanno lo stesso livello di rischio. Prioritizzate in base a:

• Metodo di autenticazione (nessuna > API key > OAuth 2.0)
• Sensibilità dei dati esposti (PII, dati finanziari, credenziali)
• Esposizione a traffico esterno vs. solo interno
• Presenza di vulnerabilità note nel framework usato
• Volume e origine del traffico recente

Un piano d’azione in tre settimane

Per team che vogliono affrontare il problema in modo pragmatico:

Settimana 1 — Discovery: Eseguite una scansione completa del traffico degli ultimi 90 giorni. Estraete tutti gli endpoint dal codice sorgente. Confrontate con il registro ufficiale dell’API gateway.

Settimana 2 — Triage: Per ogni endpoint non documentato, determinate se è un’API shadow (mai documentata) o zombie (precedentemente documentata). Applicate il risk scoring. Identificate i proprietari originali tramite git blame o cronologia dei ticket.

Settimana 3 — Remediation: Gli endpoint ad alto rischio vanno disabilitati immediatamente. Per quelli con traffico ancora attivo, notificate i client e stabilite una data di sunset. Implementate il processo di governance per prevenire il problema in futuro.

Conclusione

Le Zombie API non sono un problema teorico. Sono un debito tecnico e di sicurezza reale, spesso invisibile, che cresce silenziosamente ad ogni rilascio. Con l’aumento dei sistemi agentic AI che interagiscono autonomamente con le API, il rischio di “risvegliare” questi endpoint aumenta ulteriormente.

La buona notizia è che il problema è risolvibile con processi ben definiti: discovery sistematico, governance del ciclo di vita, e testing automatizzato su tutto l’inventario — non solo sulla versione corrente dell’API.

Non aspettate che sia un attaccante a scoprire cosa avete dimenticato.

---

Fonte originale: The “Zombie API” Attack: Why Your Old Integrations Are Your Biggest Security Risk (DZone) — approfondito con riferimenti da Salt Security, GetAstra e Checkmarx.

API Security Best Practices: How to Catch Shadow and Zombie APIs Before Attackers Do

Catch shadow and zombie APIs before attackers do. Learn API security best practices with SAST, DAST, and API discovery for full protection.

^{Avi Hein (Checkmarx)}