(in)sicurezza digitale

2026-04-21 09:52:18

The Gentlemen e SystemBC: anatomia di un’operazione ransomware con botnet da 1.570 vittime aziendali

Si parla di:
Toggle

• Il profilo del gruppo: RaaS ad alta velocità
• La scoperta della botnet SystemBC
• La kill chain: da accesso iniziale a cifratura domain-wide in poche ore
• Evasione difensiva: preparazione metodica alla cifratura
• Schema crittografico ibrido: X25519 + XChaCha20
• Indicatori di compromissione (IoC)
• Raccomandazioni per i difensori

Un’indagine di Check Point Research ha portato alla luce l’infrastruttura operativa di The Gentlemen, uno dei gruppi ransomware-as-a-service (RaaS) a crescita più rapida del 2026. L’analisi forense di un singolo incidente ha disvelato una botnet SystemBC con oltre 1.570 host aziendali compromessi, un arsenale di post-exploitation maturo e un modello operativo che spiega la rapidità con cui il gruppo ha raggiunto 320 vittime rivendicate, 240 delle quali concentrate nei primi mesi di quest’anno.

Il profilo del gruppo: RaaS ad alta velocità

Emerso intorno alla metà del 2025, The Gentlemen si è rapidamente affermato come uno dei programmi RaaS più aggressivi nel panorama del cybercrime organizzato. Il modello economico è generoso per gli affiliati: 90% dei proventi ai partner, 10% agli operatori. Questo split ha attratto affiliati con elevate competenze tecnico-operative, capaci di orchestrare intrusioni complesse nelle reti enterprise. Il gruppo opera una piattaforma di doppia estorsione con leak site Tor e countdown di 7 giorni prima della pubblicazione dei dati esfiltrati. Le comunicazioni avvengono tramite Tox, Session e l’account X @TheGentlemen25. Tra le vittime documentate: Oltenia Energy Complex (Romania) e Adaptavist Group.

La scoperta della botnet SystemBC

L’elemento più allarmante emerso dall’analisi è la presenza di una botnet SystemBC con 1.570 host compromessi, prevalentemente in ambienti aziendali distribuiti tra Stati Uniti, Regno Unito, Germania, Australia e Romania. SystemBC è un malware proxy che stabilisce tunnel SOCKS5 all’interno della rete vittima, comunicando con il C2 tramite un protocollo custom cifrato RC4. La botnet non è di proprietà esclusiva di The Gentlemen: indica che gli affiliati si integrano in un ecosistema più ampio di tooling condiviso, amplificando l’impatto operativo ben oltre le vittime rivendicate pubblicamente. I settori più colpiti sono manifatturiero e tecnologico, con healthcare in crescita come terzo target.

La kill chain: da accesso iniziale a cifratura domain-wide in poche ore

Il processo di attacco documentato rivela una kill chain estremamente efficiente. Dopo l’accesso iniziale — vettore non ancora determinato nell’incidente analizzato — gli attaccanti procedono con la compromissione del Domain Controller tramite Mimikatz per credential harvesting, seguita dal deploy di Cobalt Strike via RPC per il controllo remoto. Una volta ottenuti i privilegi di Domain Admin, viene attivata la propagazione via Group Policy Objects (GPO) per una detonazione sincronizzata sull’intera rete.

Per il lateral movement, il gruppo implementa sei vettori simultanei: PsExec con credenziali esplicite, WMI tramite wmic /node: process call create, Scheduled Tasks remoti, Windows Services, PowerShell Remoting via WinRM e accesso alle SMB Admin Shares (ADMIN$ e C$\Temp). L’uso parallelo di tutti i vettori massimizza la velocità di propagazione e rende difficile il contenimento.

Evasione difensiva: preparazione metodica alla cifratura

Prima dell’avvio della cifratura, il ransomware esegue una sequenza di operazioni per neutralizzare le difese:

# Disabilita Windows Defender real-time
powershell -Command Set-MpPreference -DisableRealtimeMonitoring $true -Force

# Disabilita Windows Firewall
netsh advfirewall set allprofiles state off

# Elimina le Shadow Copy
vssadmin delete shadows /all /quiet

# Cancella i log di sistema
wevtutil cl System
wevtutil cl Application
wevtutil cl Security

Vengono inoltre rimossi file di prefetch, log RDP e file di supporto di Windows Defender. LSA viene configurato per l’accesso anonimo e SMB1 viene riabilitato per compatibilità. Un comportamento rivelatore: il ransomware ignora esplicitamente la directory “! Cynet Ransom Protection(DON’T DELETE)”, dimostrando una conoscenza specifica dei meccanismi di rilevamento dei vendor di sicurezza.

Schema crittografico ibrido: X25519 + XChaCha20

Il payload Windows è scritto in Go, quello ESXi/Linux in C. Lo schema crittografico è progettato per massimizzare la velocità. Per ogni file viene generata una chiave privata effimera random a 32 byte; l’algoritmo X25519 (Curve25519) effettua lo scambio ECDH e i primi 24 byte del segreto condiviso diventano il nonce per XChaCha20. File inferiori a 1 MB vengono completamente cifrati; file più grandi subiscono cifratura parziale (1%, 3% o 9% del contenuto) per ottimizzare la velocità. Il footer apposto ai file è del tipo: --eph--[base64_key]--marker--GENTLEMEN.

La variante ESXi gestisce le VM tramite vim-cmd vmsvc/power.off e esxcli vm process kill --type=force, con persistenza tramite /etc/rc.local.d/local.sh e crontab @reboot, mascherandosi come /bin/.vmware-authd.

Indicatori di compromissione (IoC)

# Cobalt Strike C2
91.107.247[.]163

# SystemBC C2
45.86.230[.]112

# SystemBC SHA-256
992c951f4af57ca7cd8396f5ed69c2199fd6fd4ae5e93726da3e198e78bec0a5

# Leak site Tor
tezwsse5czllksjb7cwp65rvnk4oobmzti2znn42i43bjdfd2prqqkad.onion

# Contatto operatori
@TheGentlemen25 (X/Twitter)

Raccomandazioni per i difensori

Le priorità difensive si concentrano su tre fronti. Credential protection: implementare Windows Credential Guard, monitorare l’esecuzione di Mimikatz e lsass dumps, imporre MFA su tutti gli account privilegiati e in particolare su quelli con accesso al Domain Controller. GPO e lateral movement: allertare su modifiche non autorizzate ai Group Policy Objects, monitorare la creazione di scheduled task con contesto SYSTEM su host remoti, disabilitare SMB1 dove non strettamente necessario e bloccare PsExec non autorizzato. Detection comportamentale: correlare l’esecuzione parallela di PsExec, WMI e PowerShell Remoting su più host in breve tempo; monitorare la disabilitazione di Windows Defender e la cancellazione massiva di log come precursori di un evento ransomware. Check Point ha rilasciato una YARA rule specifica che rileva campioni compilati in Go tramite le stringhe caratteristiche del gruppo.

The Gentlemen rappresenta l’evoluzione moderna del RaaS: affiliati specializzati, infrastruttura condivisa con altri threat actor, velocità operativa che comprime la finestra di rilevamento a poche ore. La scoperta di 1.570 host aziendali compromessi nella botnet correlata suggerisce che l’impatto reale del gruppo superi significativamente le 320 vittime rivendicate pubblicamente — e che l’ecosistema criminale che supporta le sue operazioni sia molto più vasto di quanto finora documentato.

The Gentlemen e SystemBC: anatomia di un’operazione ransomware con botnet da 1.570 vittime aziendali - (in)sicurezza digitale

Check Point Research ha documentato come il gruppo ransomware-as-a-service The Gentlemen impieghi la botnet SystemBC per orchestrare attacchi devastanti: 320 vittime rivendicate, 1.

^{Dario Fadda ((in)sicurezza digitale)}

Spcnet.it

2026-04-21 07:55:23

RAG in .NET con Semantic Kernel: le insidie che i tutorial non ti dicono

RAG — Retrieval-Augmented Generation — è diventato il pattern dominante per integrare conoscenza dominio-specifica nei modelli linguistici. Ma tra un tutorial “hello world” e un sistema RAG che funziona davvero in produzione c’è un abisso. Questo articolo esplora le insidie reali che i tutorial non affrontano, partendo da un’implementazione in .NET con Semantic Kernel.

Il pipeline RAG in cinque fasi

Prima di entrare nei dettagli critici, è utile avere una mappa mentale del pipeline completo. Un sistema RAG ben strutturato si articola in cinque fasi sequenziali:

1. Ingestion — caricamento dei documenti sorgente
2. Chunking — suddivisione in segmenti adatti all’embedding
3. Embedding — conversione dei chunk in vettori numerici
4. Storage — persistenza dei vettori in un vector store
5. Retrieval + Generation — ricerca dei chunk rilevanti e generazione della risposta

Ogni fase nasconde decisioni non banali. Vediamo quelle che fanno davvero la differenza.

Il chunking è la variabile più sottovalutata

La qualità del chunking influenza il retrieval più di qualsiasi altra scelta, incluso il modello di embedding. La maggior parte dei tutorial usa split naive basati su caratteri o token fissi, ignorando la struttura semantica del documento.

Con Semantic Kernel, la scelta corretta per documenti Markdown è TextChunker.SplitMarkdownParagraphs(), che rispetta i confini dei paragrafi:

var chunks = TextChunker.SplitMarkdownParagraphs(
    lines: markdownContent.Split('\n').ToList(),
    maxTokensPerParagraph: 512,
    overlapTokens: 50
);

Due parametri critici spesso ignorati:

• overlapTokens: senza sovrapposizione, le frasi che cadono al confine tra due chunk vengono perse. Una sovrapposizione del 10-15% (qui 50 token su 512) risolve il problema.
• Pre-processing HTML→Markdown: se i sorgenti sono pagine web, convertire in Markdown prima del chunking (con librerie come HtmlAgilityPack) elimina tag irrilevanti che degradano la qualità dell’embedding.

Un’altra best practice avanzata: separare i blocchi di codice dalla prosa e taggare ogni chunk con metadati (tipo di contenuto, sezione, sorgente) per poter filtrare durante il retrieval.

Le soglie di rilevanza non sono universali

I tutorial usano tipicamente soglie di similarità coseno tra 0.75 e 0.80. Questo valore è quasi sempre sbagliato per il tuo corpus specifico. La soglia ottimale dipende da: qualità dell’embedding model, distribuzione semantica del corpus, tipologia delle query.

L’approccio corretto:

1. Costruire manualmente un set di valutazione di 20-30 coppie query/risposta attesa
2. Partire da 0.70 e iterare misurando Context Recall
3. Non affidarsi mai ai default senza validazione corpus-specifica

Scegliere il vector store giusto

Semantic Kernel supporta diversi backend. La scelta sbagliata genera complessità inutile o performance inadeguate:

• VolatileMemoryStore — solo per demo, dati persi al restart
• SqliteMemoryStore — sviluppo locale e prime versioni production: zero infrastruttura, persistenza garantita
• Elasticsearch — stack esistenti con ricerca ibrida (full-text + vettoriale)
• Azure AI Search — produzione su Azure, gestione scalabilità automatica
• Qdrant / Pinecone — carichi vettoriali dedicati ad alta scala

Per molte applicazioni aziendali, SQLite è la scelta razionale fino a migliaia di documenti. Aggiungere infrastruttura vettoriale dedicata ha senso solo con volumi e requisiti di latenza che lo giustificano effettivamente.

Evitare il re-embedding a ogni avvio

Uno degli errori più costosi (in termini economici e di latenza) è re-embeddare l’intero corpus a ogni riavvio dell’applicazione. La soluzione è semplice: verificare l’esistenza della collection prima di procedere all’ingestion:

var collections = await sqliteStore.GetCollectionsAsync().ToListAsync();
if (!collections.Contains(CollectionName))
{
    await ragService.IngestDocumentsAsync(documents, CollectionName);
}

Con Azure AI Search o Qdrant, la logica è analoga ma si basa sulle API specifiche del provider.

Il prompt di grounding non è opzionale

La costruzione del prompt è la difesa principale contro le allucinazioni. C’è una differenza sostanziale tra queste due istruzioni:

• “Usa il contesto seguente per rispondere” — il modello può integrare con la sua conoscenza generale
• “Rispondi SOLO usando il contesto seguente. Se la risposta non è nel contesto, dillo esplicitamente.” — vincolo semantico forte

La parola “SOLO” cambia radicalmente il comportamento del modello. In produzione, il prompt di sistema deve essere esplicito e non ambiguo.

Semantic caching per ridurre latenza e costi

Un ottimizzazione ad alto impatto spesso ignorata: se una query è semanticamente simile a una già elaborata, si può restituire la risposta cached senza chiamare il vector store né il modello:

var cachedAnswer = await cacheService.FindSimilarAsync(query, threshold: 0.92f);
if (cachedAnswer != null)
{
    return cachedAnswer.Answer;
}

Con una soglia alta (0.90-0.95), il cache serve solo query davvero simili, evitando risposte errate. Per sistemi con pattern di query ripetitivi (FAQ, assistenti documentali), questo ottimizzazione può ridurre i costi LLM del 40-60%.

Osservabilità: cosa monitorare

Un sistema RAG senza osservabilità è un sistema cieco. I KPI da tracciare per ogni richiesta:

• TopChunkScore: se costantemente sotto 0.75, il retrieval fatica. Rivedere chunking o embedding model.
• ChunksRetrieved: se raggiunge sempre il limite massimo, espandere la finestra di ricerca.
• CacheHit: se sempre false con alta latenza, la soglia del cache è troppo restrittiva.
• Latency: separare la latenza di retrieval da quella LLM per identificare il bottleneck.

Valutazione continua e CI

Il rischio silenzioso del RAG è la regressione: una modifica al chunking o alla soglia migliora alcune query e ne peggiora altre. La soluzione è integrare un set di valutazione nel pipeline CI con xUnit:

• Context Recall: i chunk corretti vengono recuperati?
• Faithfulness: la risposta rimane ancorata al contesto?
• Answer Correctness: corrisponde alla risposta attesa?

Il set di test deve includere query facili, domande che richiedono sintesi multi-documento, e domande a cui il sistema non dovrebbe rispondere (out-of-scope) — queste ultime sono fondamentali per rilevare allucinazioni.

Conclusione

Costruire un sistema RAG che funziona nei demo è relativamente semplice con Semantic Kernel. Costruirne uno che funziona in produzione — con costi controllati, latenza accettabile, assenza di allucinazioni e monitoraggio efficace — richiede decisioni architetturali precise. Il chunking con overlap, le soglie calibrate sul corpus reale, il caching semantico e l’osservabilità non sono optional: sono la differenza tra un prototipo e un sistema affidabile.

Fonte originale: RAG in .NET: What the Tutorials Don’t Tell You di Jamie Maguire.

RAG in .NET: What the Tutorials Don’t Tell You. Chunking, Embedding, and Production Gotchas – Jamie Maguire

RAG in .NET: What the Tutorials Don’t Tell You. Chunking, Embedding, and Production Gotchas

^{jamie_maguire (Jamie Maguire)}