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)}

(in)sicurezza digitale

2026-05-16 14:12:22

Ghostwriter colpisce il governo ucraino con PDF georeferenziati, PicassoLoader e Cobalt Strike

A meno di ventiquattr’ore dalla pubblicazione del report ESET, emerge l’ennesima prova che il conflitto russo-ucraino si combatte su due fronti: quello fisico e quello cibernetico. Il gruppo Ghostwriter — noto anche come FrostyNeighbor, UNC1151, Storm-0257 e White Lynx — ha intensificato le proprie operazioni contro le istituzioni di Kiev, adottando una catena d’attacco sempre più sofisticata che combina phishing mirato, geofencing intelligente e payload a più stadi. La notizia, pubblicata il 14 maggio 2026 da The Hacker News sulla base della ricerca ESET, arriva mentre le operazioni cinetiche nel conflitto rimangono attive.

Chi è Ghostwriter / FrostyNeighbor

Ghostwriter è un APT attivo almeno dal 2016, ritenuto allineato con i servizi d’intelligence bielorussi. Nel corso degli anni ha condotto sia operazioni di cyberspionaggio che campagne di influenza — disinformazione, hack-and-leak, manipolazione di contenuti — contro Ucraina, Polonia, Lituania ed Estonia. ESET lo traccia con il moniker FrostyNeighbor; altri vendor lo conoscono come PUSHCHA, TA445, UAC-0057 o Umbral Bison. Il gruppo ha dimostrato una notevole capacità di adattamento: ogni campagna aggiorna strumenti e metodi di consegna per sfuggire ai sistemi di detection.

La nuova catena d’attacco: geofencing e PDF-esca

Le attività osservate da marzo 2026 evidenziano un salto qualitativo rispetto alle campagne precedenti. Il vettore iniziale è uno spear-phishing con allegato PDF che impersona la società di telecomunicazioni ucraina Ukrtelecom — un mittente di apparente legittimità per qualsiasi funzionario governativo di Kiev.

La caratteristica tecnica più rilevante è il geofencing lato server: quando il destinatario apre il PDF e clicca sul link incorporato, il server degli attaccanti verifica l’indirizzo IP del richiedente. Se l’IP non corrisponde a una geolocalizzazione ucraina, il server restituisce un documento PDF benigno e inoffensivo. Questa tecnica rende l’analisi in sandbox — tipicamente eseguita da infrastrutture cloud non ucraine — completamente inefficace, poiché l’analista riceverà sempre il file pulito.

Catena d’infezione a tre stadi

Per le vittime che superano il controllo geografico, il link nel PDF scarica un archivio RAR contenente un payload JavaScript. L’esecuzione di questo script avviene in parallelo su due binari:

• Visualizzazione del documento-esca: viene aperto un file lure convincente per mantenere la credibilità dell’allegato originale.
• Lancio di PicassoLoader: il downloader JavaScript viene eseguito in background, avviando il secondo stadio dell’attacco.

PicassoLoader, già noto dall’arsenale di Ghostwriter, svolge una funzione cruciale di fingerprinting e profilazione dell’host: raccoglie informazioni sul sistema (hostname, utente, sistema operativo, processi attivi, configurazione di rete) e le trasmette all’infrastruttura C2 degli attaccanti ogni 10 minuti. Questa telemetria consente agli operatori di valutare manualmente se la vittima è di interesse strategico.

Solo in caso di risposta affermativa da parte degli operatori, viene inviato un terzo stadio: un dropper JavaScript che installa il Cobalt Strike Beacon — il framework di post-exploitation preferito dagli APT di ogni nazionalità, qui usato per stabilire accesso persistente, esfiltrare dati e muoversi lateralmente nella rete della vittima.

Targeting selettivo: militare, difesa, governo

Secondo ESET, il targeting principale si concentra su organizzazioni militari, del settore difesa e governative in Ucraina. In Polonia e Lituania la campagna mostra un profilo vittimologico più ampio, includendo anche manifatturiero, healthcare, logistica e governo. Questa distinzione suggerisce che in Ucraina le operazioni abbiano un obiettivo di intelligence preciso — raccolta di informazioni militari e governative strategiche — mentre altrove Ghostwriter opera con una rete più larga, probabilmente per mantenere accesso a lungo termine in ottica NATO.

Il contesto più ampio: Gamaredon e BO Team

Le rivelazioni su FrostyNeighbor si inseriscono in un panorama di operazioni cyber parallele nel teatro ucraino. Contestualmente, il gruppo russo Gamaredon — attivo con campagne di spear-phishing contro istituzioni statali ucraine dal settembre 2025 — sta distribuendo GammaDrop e GammaLoad tramite archivi RAR che sfruttano la vulnerabilità CVE-2025-8088. HarfangLab descrive Gamaredon come un attore non sofisticato ma straordinariamente persistente, con un tempo operativo e una scala d’attacco difficilmente eguagliabili.

Sul fronte opposto, il gruppo filoukraino BO Team (alias Black Owl) starebbe collaborando con Head Mare (PhantomCore) in attacchi contro organizzazioni russe, impiegando backdoor come BrockenDoor, ZeronetKit e il nuovo ZeroSSH — un backdoor Go-based capace di stabilire canali SSH inversi e di compromettere anche sistemi Linux.

Indicatori di Compromissione

# Tattiche, Tecniche e Procedure (TTPs) - Ghostwriter / FrostyNeighbor (Marzo 2026)
## Vettore iniziale
- Spear-phishing con allegato PDF
- Lure document: impersonificazione Ukrtelecom
## Tecniche di evasione
- Geofencing IP lato server (solo IP ucraini ricevono payload malevolo)
- Anti-sandbox tramite user-agent check lato server
## Payload chain
1. PDF → link → server geofenzato
2. Archivio RAR → payload JavaScript
3. JavaScript → PicassoLoader (JavaScript variant)
4. PicassoLoader → fingerprint host (ogni 10 min → C2)
5. [Operatore approva] → JavaScript dropper → Cobalt Strike Beacon
## Malware families
- PicassoLoader (JavaScript variant, nuova versione 2026)
- Cobalt Strike Beacon
## Targeting primario
- Organizzazioni militari ucraine
- Settore difesa ucraino  
- Enti governativi ucraini
- Target secondari: Polonia, Lituania (industria, healthcare, logistica)
## Riferimenti
- ESET Research: FrostyNeighbor report, maggio 2026
- Tracking alias: UNC1151, Storm-0257, TA445, UAC-0057, PUSHCHA, White Lynx, Umbral Bison

Due righe per i difensori

La sofisticazione del geofencing rende inutili molte tecniche di sandboxing tradizionale. I team di difesa ucraini e dei paesi NATO nel mirino dovrebbero adottare le seguenti contromisure. Innanzitutto, simulare il download dei link presenti in PDF sospetti utilizzando proxy IP con geolocalizzazione ucraina, in modo da bypassare il filtro geografico e ottenere il payload reale. In secondo luogo, monitorare le connessioni HTTP/HTTPS in uscita ogni 10 minuti verso IP non noti, potenziale segnale di PicassoLoader in fase di beaconing. In terzo luogo, applicare una politica zero-trust sull’esecuzione di JavaScript tramite applicazioni utente: la catena d’infezione si basa interamente su JS. Infine, formare il personale governativo e militare a riconoscere le impersonificazioni di fornitori di servizi (come Ukrtelecom) come vettore di phishing ad alta credibilità.

Il report ESET sintetizza efficacemente la sfida: “FrostyNeighbor rimane un threat actor persistente e adattivo, con un elevato livello di maturità operativa. Il payload viene consegnato solo dopo una validazione lato server che combina controlli automatizzati con la validazione manuale degli operatori”. Una minaccia ibrida — tecnologica e umana — che richiede una risposta altrettanto ibrida.

(in)sicurezza digitale

2026-05-16 14:08:19

The Gentlemen smascherati: quando il secondo gruppo ransomware al mondo diventa la vittima

C’è una certa ironia nel vedere un gruppo ransomware diventare esso stesso vittima di una violazione dei dati. Il 4 maggio 2026, gli operatori di The Gentlemen — il secondo gruppo ransomware più attivo al mondo nel 2026 con oltre 400 vittime pubbliche — hanno dovuto ammettere sui forum underground che il loro database backend era stato compromesso. Check Point Research ha ottenuto una porzione di quei dati prima che venissero rimossi, producendo uno dei dossier più dettagliati mai pubblicati sull’anatomia interna di un’organizzazione RaaS moderna.

L’ascesa fulminante di un gruppo che usava l’AI per sviluppare ransomware

The Gentlemen è emerso nel panorama del cybercrime organizzato con una velocità insolita. Nei soli primi mesi del 2026 ha rivendicato oltre 240 attacchi, raggiungendo il secondo posto globale per numero di vittime secondo il Q1 2026 Ransomware Report di Check Point Research. Una crescita che non è casuale: gli analisti hanno documentato l’uso sistematico di assistenti AI per accelerare lo sviluppo del ransomware, riducendo drasticamente i tempi tra ideazione e deployment dei payload.

Il modello operativo è quello classico del Ransomware-as-a-Service: un nucleo di operatori gestisce la piattaforma, la crittografia, la negoziazione e l’infrastruttura, mentre affiliati terzi si occupano dell’accesso iniziale e del deploy nei sistemi delle vittime. Ciò che distingue The Gentlemen è la sofisticazione organizzativa e la velocità con cui ha scalato le operazioni.

La violazione: come un provider di hosting ha esposto tutto

La compromissione è stata possibile attraverso il provider di hosting 4VPS, utilizzato dal gruppo per gestire parti della propria infrastruttura backend. Una scelta operativa che si è rivelata fatale: quando 4VPS è stato compromesso, con esso è caduta anche la protezione dei database di The Gentlemen. L’annuncio è arrivato dai criminali stessi sui forum underground il 4 maggio 2026 — una mossa inusuale che testimonia quanto grave fosse la situazione.

Check Point Research è riuscita a recuperare una porzione significativa del database prima della rimozione. Il materiale ottenuto include chat interne tra operatori, roster organizzativi, trascrizioni di negoziazioni con le vittime, discussioni sugli strumenti e documentazione sulle infrastrutture utilizzate. Un tesoro informativo che i ricercatori hanno condiviso con le forze dell’ordine, con un’indagine in corso.

Anatomia di una gang: l’organigramma esposto

Il leak ha rivelato che il gruppo è gestito da circa nove operatori nominati, organizzati attorno a un singolo amministratore identificato con gli alias zeta88 e hastalamuerte. Questo profilo non è quello di un principiante: si tratta di un ex affiliato del programma ransomware Qilin, che ha imparato il mestiere sotto un’organizzazione consolidata prima di costruire una struttura concorrente. Una progressione di carriera nel crimine organizzato digitale che rispecchia schemi già visti con altre gang.

L’amministratore non si limita alla gestione della piattaforma, ma partecipa personalmente agli eventi di cifratura — un livello di coinvolgimento diretto insolito per gruppi di questa dimensione, dove solitamente il livello apicale delega completamente le operazioni tattiche agli affiliati. I log di chat mostrano un’organizzazione gerarchica con ruoli definiti: chi gestisce le trattative, chi monitora l’infrastruttura C2, chi coordina gli affiliati.

L’arsenale tecnico: SystemBC, GPO deployment e supply chain pivot

Dal punto di vista tecnico, il report di Check Point descrive una catena di attacco matura. Il punto di ingresso osservato in almeno un incident response tracciato è un Domain Controller già compromesso con privilegi Domain Admin. Da questa posizione, gli attaccanti eseguono una ricognizione sistematica della rete, utilizzando strumenti open-source come gogo per lo scanning automatizzato, validano le credenziali su tutti i sistemi raggiungibili e preparano il terreno per il deploy del payload.

Lo strumento chiave per la fase di persistenza e tunneling è SystemBC, un proxy malware che stabilisce tunnel SOCKS5 cifrati (RC4) verso il server C2 e consente il download e l’esecuzione di payload aggiuntivi, sia su disco che iniettati direttamente in memoria. Un C2 server SystemBC analizzato da Check Point ha rivelato un botnet di oltre 1.570 vittime, con un profilo di infezione orientato prevalentemente verso ambienti corporate.

Il deployment finale del ransomware avviene tramite Group Policy Object (GPO): il binario viene configurato per eseguirsi su tutti i sistemi domain-joined durante il refresh delle policy, producendo un evento di cifratura quasi simultaneo sull’intero dominio — massimizzando il danno e minimizzando la finestra di risposta per i difensori.

Particolarmente rilevante è un attacco documentato nell’aprile 2026 contro una software consultancy britannica: dopo aver violato questa azienda, The Gentlemen ha utilizzato i dati rubati — documentazione infrastrutturale, credenziali, informazioni sugli accessi dei clienti — per condurre un attacco successivo contro uno dei clienti della consultancy in Turchia. Un caso concreto di supply chain pivot che dimostra come il valore di un’intrusione non si misuri solo nei dati esfiltrati, ma nei vettori di attacco secondari che abilita.

Due righe per i difensori: cosa fare dopo questa disclosure

La violazione di The Gentlemen è un evento raro ma istruttivo. Il leak rivela tattiche, procedure e persino identità che possono supportare attività di threat intelligence proattiva. Alcuni elementi pratici: monitorare le connessioni SOCKS5 non autorizzate verso IP esterni; implementare alert su modifiche ai GPO che includono eseguibili non firmati; verificare l’integrità dei Domain Controller come primo indicatore di compromissione avanzata; e applicare il principio del minimo privilegio per limitare il blast radius nel caso di compromise di un affiliato o fornitore.

Check Point ha rilasciato regole YARA per il rilevamento basato su firma del ransomware di The Gentlemen. Per i team SOC, l’integrazione di questi indicatori nelle piattaforme SIEM/SOAR è raccomandata con priorità alta, data la velocità con cui il gruppo ha dimostrato di scalare le operazioni.

Indicatori di Compromissione (IoC)

# The Gentlemen Ransomware - IoC e TTPs
# Fonte: Check Point Research (maggio 2026)
## Tecniche MITRE ATT&CK
T1078 - Valid Accounts (credenziali rubate per lateral movement)
T1021.002 - Remote Services: SMB/Windows Admin Shares
T1484.001 - Group Policy Modification (GPO-based ransomware deployment)
T1090.001 - Proxy: Internal Proxy (SystemBC SOCKS5 tunneling)
T1486 - Data Encrypted for Impact
T1005 - Data from Local System
T1059 - Command and Scripting Interpreter
## SystemBC C2 Communication
Protocollo C2: custom RC4-encrypted SOCKS5
Botnet noto: 1.570+ vittime identificate da singolo C2 server
Caratteristica: payload iniettati in-memory per evasione AV
## Indicatori comportamentali
- Presenza di gogo scanner eseguito da account privilegiati
- Modifiche a GPO esistenti o creazione di nuovi GPO con executables
- Connessioni SOCKS5 in uscita da workstation non-server
- Autenticazioni a cascata originate da Domain Controller
  (pattern: failed auth → successful auth su multipli host)
## Operatore
Alias noti: zeta88, hastalamuerte
Background: ex affiliato Qilin ransomware
Infrastruttura: 4VPS hosting provider (compromesso maggio 2026)
## Nota
# YARA rules disponibili presso Check Point Research:
# https://research.checkpoint.com/2026/thus-spoke-the-gentlemen/

Ransomfeed

^Ransomfeed

Spcnet.it

2026-05-16 06:34:12

Microsoft DSC v3.2.0: nuove risorse Windows, version pinning e integrazione Bicep

Cos’è Microsoft DSC v3 e perché è importante

Microsoft Desired State Configuration (DSC) è uno strumento di gestione della configurazione che permette di descrivere come deve essere configurato un sistema Windows o Linux — quali servizi devono essere in esecuzione, quali regole firewall applicare, quali funzionalità installare — e di applicare o verificare automaticamente quella configurazione. Con DSC v3, Microsoft ha riscritto l’engine da zero rispetto alla versione 2.x integrata in PowerShell, separando nettamente il motore DSC dai moduli PowerShell e aprendo la strada al supporto multi-piattaforma e multi-linguaggio.

Il 29 aprile 2026, il team PowerShell ha annunciato la General Availability di DSC v3.2.0. Questa release porta con sé risorse Windows native, l’integrazione sperimentale con Bicep via gRPC, il version pinning, un linguaggio di espressioni più ricco e miglioramenti agli adapter PowerShell. Vediamo in dettaglio cosa cambia per i sistemisti e gli amministratori di sistema che adottano DSC nei loro ambienti.

Come installare DSC v3.2.0

La modalità di installazione più semplice è tramite WinGet:

winget install --id Microsoft.DSC --version 3.2.0

In alternativa è disponibile un pacchetto MSIX e un archivio ZIP per ambienti disconnessi o air-gapped. Il pacchetto ZIP è necessario per le risorse OptionalFeatureList e FeatureOnDemandList che, per il momento, non sono incluse nel pacchetto MSIX.

Nuove risorse Windows built-in

Una delle novità più attese di DSC v3.2.0 è l’espansione significativa delle risorse Windows native, ovvero risorse incluse direttamente nel pacchetto DSC e utilizzabili senza installazioni aggiuntive.

Le nuove risorse disponibili sono le seguenti:

• Microsoft.Windows/Service — gestione dei servizi Windows (stato, tipo di avvio, account di esecuzione)
• Microsoft.Windows/OptionalFeatureList — gestione delle funzionalità opzionali di Windows
• Microsoft.Windows/FeatureOnDemandList — gestione delle Features on Demand (FoD)
• Microsoft.Windows/FirewallRuleList — gestione delle regole del Windows Firewall
• Microsoft.OpenSSH.SSHD/sshd_config — gestione dell’intera configurazione del server SSH
• Microsoft.OpenSSH.SSHD/Subsystem e SubsystemList — gestione dei sottosistemi SSH
• Microsoft.OpenSSH.SSHD/Windows — configurazione Windows-specifica del server SSH (es. shell predefinita)

Un esempio pratico: per assicurarsi che il servizio Print Spooler sia disabilitato (pratica comune per ridurre la superficie d’attacco), basta ora scrivere:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: DisabilePrintSpooler
    type: Microsoft.Windows/Service
    properties:
      name: spooler
      startType: disabled
      state: stopped

Version pinning: configurazioni stabili e riproducibili

Una delle criticità di DSC v2 era la mancanza di un meccanismo affidabile per legare una configurazione a una specifica versione delle risorse. In ambienti enterprise con molti server e deployment automatizzati, una risorsa aggiornata poteva cambiare comportamento inaspettatamente.

DSC v3.2 risolve questo problema introducendo il version pinning sia a livello di documento di configurazione che a livello di singola risorsa. È possibile fissare la versione di DSC richiesta con la direttiva version e la versione di ogni risorsa con il campo requireVersion, usando la stessa sintassi semantica di npm/nuget:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
directives:
  version: '=3.2.0'          # Questa configurazione richiede esattamente DSC 3.2.0
resources:
  - name: os
    type: Microsoft/OSInfo
    requireVersion: '^1.0'   # Versioni >= 1.0.0 e =1.0.0, 

Se sul sistema non è disponibile una versione compatibile della risorsa, DSC solleva un errore esplicito invece di procedere in silenzio con una versione incompatibile. Questo rende le configurazioni DSC molto più affidabili nei pipeline CI/CD.

Supporto –what-if sulle singole risorse

Il flag --what-if esiste già da versioni precedenti per il comando dsc config set, ma era limitato all’esecuzione dell’intera configurazione. Con DSC v3.2, l’operazione di preview è disponibile anche sul comando dsc resource set, permettendo di testare il comportamento di una singola risorsa prima di applicarla:

dsc resource set --what-if \
  --resource Microsoft.Windows/Service \
  --input '{ "name": "spooler", "startType": "disabled" }'

Questo è particolarmente utile in fase di sviluppo di nuove risorse o durante troubleshooting di configurazioni complesse.

Integrazione sperimentale con Bicep via gRPC

La novità più ambiziosa di questa release è l’introduzione di un server gRPC in DSC, che permette a Bicep di orchestrare direttamente le risorse DSC senza passare per Azure Resource Manager (ARM). L’estensione dsc-bicep-ext è ora inclusa nel pacchetto MSIX e disponibile nel PATH di sistema.

In pratica, questo significa che sarà possibile scrivere configurazioni DSC nella sintassi Bicep, sfruttando il tooling e le funzionalità del linguaggio (modularità, parametri tipizzati, linting) per gestire la configurazione di sistema. L’integrazione è attualmente marcata come sperimentale, ma rappresenta una direzione strategica importante: avvicinare la gestione della configurazione di sistema agli strumenti Infrastructure-as-Code già adottati dagli ambienti Azure.

Miglioramenti al linguaggio di espressione

I documenti di configurazione DSC v3.2 supportano ora un linguaggio di espressione più ricco, che riprende in parte la sintassi ARM/Bicep:

• Lambda expressions con le funzioni map() e filter()
• Funzioni dataUri() e dataUriToString() per la gestione di contenuti encodati
• Utilizzo di reference() all’interno di loop copy
• secret() per il recupero di segreti a runtime tramite estensioni dedicate

Il campo requireVersion sostituisce il precedente apiVersion per specificare i requisiti di versione, uniformando la sintassi con i nuovi meccanismi di pinning.

Adapter PowerShell: trace automatica e manifest adattati

Per chi utilizza risorse PowerShell esistenti tramite gli adapter PSDSC, DSC v3.2 porta alcune novità significative. È stata aggiunta la conversione automatica degli stream PowerShell (Write-Verbose, Write-Warning, ecc.) in trace DSC, il che significa che le risorse esistenti partecipano automaticamente al modello di tracing senza modifiche al codice.

È stato inoltre corretto il passaggio di credenziali alle istanze di risorse PSDSC adattate, un bug che causava problemi in ambienti con configurazioni di sicurezza elevate.

Conclusione

DSC v3.2.0 consolida la piattaforma DSC v3 con funzionalità concrete e richieste dalla community: risorse Windows native, version pinning per deployment riproducibili, preview granulare con --what-if e l’avvio di un’integrazione Bicep che promette di semplificare notevolmente la gestione IaC negli ambienti Microsoft.

Per chi gestisce ambienti Windows Server, Intune o pipeline DevOps su infrastruttura Microsoft, vale la pena iniziare a esplorare DSC v3.2 e valutare la migrazione dalle configurazioni DSC v2, la cui architettura è ormai considerata legacy.

Fonte: Announcing Microsoft Desired State Configuration v3.2.0 – PowerShell Team Blog

Announcing Microsoft Desired State Configuration v3.2.0 - PowerShell Team

This post announces the General Availability of Microsoft Desired State Configuration (DSC) v3.2.0, with new Windows resources, Bicep gRPC integration, WhatIf support, expression language improvements, and adapter enhancements.

^{Jason Helmick (PowerShell Team)}

Ransomfeed

2026-05-15 15:23:23

Big milestone for Ransomfeed today 🚨

After the review process, the Ransomfeed connector for OpenCTI has now been officially approved ✅

This means that starting from this release, Ransomfeed will become part of the official OpenCTI connector ecosystem. ⏭️

#ThreatIntelligence

Release 7.260515.0 of OpenCTI/connectors official project, now show Ransomfeed contributor on code ❤️

Statement here: ransomfeed.it/?page=comunicati…

Release notes: github.com/OpenCTI-Platform/co…

Release Version 7.260515.0 · OpenCTI-Platform/connectors

Enhancements: #4919 [MISP] Add an option configuration to let users map the MISP threat level value on an OpenCTI score #4450 [CybelAngel] Create a connector #4413 [ransomfeed]: Create an external...

^GitHub

Francesco 🕳️

2026-05-07 06:16:34

cosa usate per le statistiche?
@eden @eticadigitale