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

IFTAS

2026-04-20 12:52:44

#mastodadmin #fediadmin

Services considering defederating mastodon.cloud

Be aware that account holders are attempting to move their account, and this can take considerable time to complete, several days, especially for members with large follower counts.

Others may still be on 30-day cooldown after having moved there recently.

Please consider Limiting the service while members attempting to move complete that action.

Suspending a service severs all relationships and is unrecoverable.

(in)sicurezza digitale

2026-04-19 09:13:28

PayoutsKing: il ransomware che si nasconde in una macchina virtuale per eludere gli antivirus

Un gruppo criminale noto come GOLD ENCOUNTER ha trovato un modo per rendere il proprio ransomware quasi invisibile agli strumenti di sicurezza endpoint: eseguire tutte le operazioni malevole all’interno di una macchina virtuale creata silenziosamente sui sistemi delle vittime. Il ransomware PayoutsKing, attivo da novembre 2025, sfrutta QEMU — un emulatore open source legittimo — per nascondere ogni traccia dell’attacco al di fuori del perimetro di visibilità delle soluzioni EDR e antivirus.

Il contesto: quando la virtualizzazione diventa un’arma

La tecnica di utilizzare macchine virtuali per eludere i controlli di sicurezza non è del tutto nuova: già nel 2025 diversi gruppi ransomware avevano sperimentato l’abuso di hypervisor legittimi come VMware ESXi. Ma il gruppo GOLD ENCOUNTER ha portato questa tattica a un nuovo livello di raffinatezza, usando QEMU — uno strumento open source normalmente impiegato da sviluppatori e ricercatori — per creare ambienti virtuali nascosti direttamente sui sistemi Windows delle vittime.

I ricercatori di Secureworks, che tracciano le operazioni di GOLD ENCOUNTER, hanno identificato due campagne distinte: STAC4713 (attiva da novembre 2025) e STAC3725 (identificata da febbraio 2026), entrambe caratterizzate dall’uso di QEMU come vettore di persistenza e comando-e-controllo. Secondo alcune analisi, il gruppo potrebbe avere legami con ex affiliati di BlackBasta.

Come funziona l’attacco: dalla compromissione alla VM nascosta

Il vettore di accesso iniziale varia a seconda della campagna. In STAC4713, gli attaccanti hanno sfruttato principalmente dispositivi SonicWall VPN esposti senza autenticazione a più fattori e, in almeno un incidente documentato a gennaio 2026, la vulnerabilità CVE-2025-26399 in SolarWinds Web Help Desk. La campagna STAC3725, invece, ha fatto leva su CitrixBleed2, la seconda iterazione della vulnerabilità NetScaler che ha colpito migliaia di organizzazioni.

Una volta ottenuto l’accesso iniziale, gli attori procedono con una sequenza di azioni strutturata:

• Creazione di un scheduled task denominato TPMProfiler con privilegi SYSTEM, che esegue il binario QEMU
• Deployment di un’immagine disco virtuale (custom.qcow2) mascherata da file di database o librerie DLL per evitare il rilevamento
• Avvio di una VM Alpine Linux 3.22.0 con port forwarding verso il sistema host
• Instaurazione di un tunnel SSH inverso per il comando e controllo covert

Il principio è semplice ma devastante: le soluzioni di sicurezza endpoint monitorano i processi del sistema operativo host, ma non possono ispezionare l’interno di una macchina virtuale in esecuzione. Tutto ciò che avviene dentro la VM rimane completamente opaco agli EDR.

Il toolkit nella macchina virtuale: un arsenale da penetration test

La VM Alpine Linux non è un ambiente minimale: è un’armeria completa di strumenti offensivi. In STAC4713, la VM preinstallata conteneva:

• AdaptixC2: framework C2 open source per il controllo remoto
• Chisel: tunneling TCP/UDP attraverso HTTP
• BusyBox: suite di utility Unix compatta
• Rclone: tool per l’esfiltrazione dati verso storage cloud

In STAC3725, rilevata dal CERT di Secureworks in incidenti a febbraio 2026, il toolkit era ancora più sofisticato e compilato manualmente dagli operatori: Impacket, KrbRelayx, Coercer, BloodHound.py, NetExec, Kerbrute e un’istanza di Metasploit completamente funzionale. Un arsenale che denota una profonda conoscenza delle tecniche di post-exploitation in ambienti Active Directory.

Furto di credenziali e movimento laterale

Prima di distribuire il ransomware, GOLD ENCOUNTER conduce operazioni estese di ricognizione e furto credenziali. Le tecniche documentate includono:

• Creazione di Volume Shadow Copies tramite vssuirun.exe per accedere a file altrimenti bloccati
• Esfiltrazione via SMB di NTDS.dit, SAM e dei registry hive SYSTEM — il database completo degli utenti Active Directory
• Enumerazione Kerberos con Kerbrute per identificare account validi
• Ricognizione AD tramite BloodHound per mappare percorsi di escalation dei privilegi
• Deployment di ScreenConnect e del framework Havoc C2 tramite DLL sideloading su ADNotificationManager.exe

Il ransomware PayoutsKing: cifratura furtiva

PayoutsKing utilizza uno schema di cifratura robusto: AES-256 in modalità CTR per la cifratura dei file, con scambio di chiavi tramite RSA-4096. Per i file di grandi dimensioni viene adottata una strategia di intermittent encryption — cifra solo porzioni del file — che accelera l’operazione e rende la cifratura meno rilevabile in tempo reale dai sistemi di monitoraggio comportamentale.

Le richieste di riscatto vengono gestite attraverso siti leak sul dark web, con la consueta doppia estorsione: pagare per il decryptor, o vedere i propri dati pubblicati.

Indicatori di compromissione (IoC)

# Scheduled Task sospetto
Nome task: TPMProfiler
Privilegi: SYSTEM
Binary: qemu-system-x86_64.exe (o varianti)

# File da monitorare
*.qcow2 in posizioni anomale (es. %APPDATA%, C:\ProgramData\)
File .qcow2 mascherati da .dll o .db

# Servizi sospetti installati
AppMgmt (uso anomalo)
CtxAppVCOMService

# Tool post-compromise da cercare
AdaptixC2, Chisel, Rclone, BloodHound.py
Kerbrute, Impacket, NetExec, KrbRelayx

# Traffico di rete
Tunnel SSH reversi su porte non standard
Connessioni SSH in uscita verso IP esterni insoliti
Traffico Rclone verso storage cloud (es. Mega, Dropbox)

Cosa fare per difendersi

La tecnica QEMU rappresenta una sfida concreta per i team di sicurezza perché sfrutta uno strumento legittimo e firmato. Le raccomandazioni per i difensori includono:

• Application allowlisting: bloccare l’esecuzione di qemu-system-*.exe su tutti gli endpoint non espressamente autorizzati
• Monitoraggio scheduled task: alert su qualsiasi task creato con privilegi SYSTEM che esegue binari non standard
• MFA obbligatoria su VPN e accessi remoti: quasi tutti i vettori di accesso iniziale documentati avrebbero potuto essere bloccati con MFA
• Patching tempestivo: CVE-2025-26399 (SolarWinds), CitrixBleed2 e vulnerabilità SonicWall devono essere priorità assolute
• Network monitoring: rilevare port forwarding SSH non autorizzato e connessioni in uscita verso storage cloud da server
• Hunt proattivo: cercare file .qcow2 e il processo qemu-system-x86_64.exe nell’intero parco macchine

La capacità di GOLD ENCOUNTER di operare per settimane o mesi all’interno di reti compromesse prima di distribuire il payload ransomware — sfruttando una VM nascosta impossibile da ispezionare dagli EDR — rende questo gruppo particolarmente pericoloso. È l’ennesima dimostrazione di come i ransomware operator stiano evolvendo verso tecniche da APT, con longevi periodi di dwell time dedicati alla ricognizione e alla maximizzazione del danno.

Spcnet.it

2026-04-16 14:14:54

Confronto tra stringhe in C#: Equals, OrdinalIgnoreCase, StringComparer e le insidie culturali

Il confronto tra stringhe è una delle operazioni più comuni in qualsiasi applicazione .NET, eppure è anche una delle fonti più insidiose di bug difficili da riprodurre — specialmente quando l’applicazione viene eseguita in ambienti con culture diverse o in pipeline CI/CD con impostazioni locali variabili. In questo articolo vediamo come funzionano correttamente string.Equals(), OrdinalIgnoreCase, StringComparer e come evitare le trappole più comuni legate alla cultura.

L’operatore == e il confronto ordinale

L’operatore == su stringhe esegue un confronto ordinale case-sensitive, basato sui valori Unicode dei caratteri, senza alcuna considerazione culturale:

var a = "Hello";
var b = "hello";
Console.WriteLine(a == b);       // False
Console.WriteLine(a == "Hello"); // True

Questo è corretto e prevedibile per confronti interni al codice (chiavi di dizionari, nomi di variabili, costanti). Il problema nasce quando si vuole un confronto case-insensitive, o quando si confrontano stringhe con caratteri soggetti a regole culturali.

string.Equals() con StringComparison

La regola d’oro è: passare sempre esplicitamente un parametro StringComparison. Senza di esso, alcuni overload usano CurrentCulture, creando comportamenti potenzialmente incoerenti tra ambienti diversi.

// Confronto case-insensitive, senza dipendenze culturali
bool uguale = string.Equals("admin", input, StringComparison.OrdinalIgnoreCase);

// Equivalente con metodo d'istanza
bool ancheUguale = "admin".Equals(input, StringComparison.OrdinalIgnoreCase);

Panoramica dei valori di StringComparison

Valore	Case	Cultura	Uso consigliato
Ordinal	Sensibile	Nessuna	File, chiavi, dati binari
OrdinalIgnoreCase	Insensibile	Nessuna	Comandi, URL, identificatori
InvariantCulture	Sensibile	Invariante	Testo serializzato/persistito
InvariantCultureIgnoreCase	Insensibile	Invariante	Testo serializzato, case-indipendente
CurrentCulture	Sensibile	Locale utente	Testo mostrato all’utente
CurrentCultureIgnoreCase	Insensibile	Locale utente	Ricerca/filtro lato UI

La trappola di ToLower() e ToUpper()

Uno degli antipattern più diffusi è usare ToLower() per normalizzare le stringhe prima del confronto:

// Antipattern: alloca una nuova stringa inutilmente
if (input.ToLower() == "admin") { }
if (input.ToLowerInvariant() == "admin") { }

// Corretto: nessuna allocazione, semantica esplicita
if (string.Equals(input, "admin", StringComparison.OrdinalIgnoreCase)) { }

Il problema non è solo di prestazioni (allocazione di una stringa temporanea), ma di correttezza semantica. La versione con ToLower() dipende dalla cultura corrente del thread, mentre OrdinalIgnoreCase è culturalmente neutro e deterministico.

Il problema della “i” Turca

Questo è forse il bug più famoso legato alla cultura nelle stringhe. In turco esistono quattro varianti della lettera i: la “i” minuscola con punto diventa “İ” maiuscola con punto (non “I” come in italiano), e la “ı” minuscola senza punto diventa “I” maiuscola. Il risultato:

var culture = new System.Globalization.CultureInfo("tr-TR");

// Bug su locale turco!
bool sbagliato = "file".ToUpper(culture) == "FILE"; // False! "file" diventa "FİLE" in turco

// OrdinalIgnoreCase usa regole invarianti
bool corretto = string.Equals("file", "FILE", StringComparison.OrdinalIgnoreCase); // True

Questo bug si manifesta tipicamente in applicazioni multi-tenant o globali dove il server ha una cultura diversa dall’ambiente di sviluppo. La soluzione è sempre usare OrdinalIgnoreCase per confronti tecnici (nomi di file, comandi, URL, header HTTP) e riservare CurrentCulture solo al testo destinato all’utente finale.

StringComparer per collezioni

StringComparer implementa sia IComparer<string> che IEqualityComparer<string>, rendendolo ideale per strutture dati come Dictionary, HashSet e SortedSet:

Dizionario case-insensitive per gli header HTTP

// "Content-Type" e "content-type" devono essere equivalenti
var headers = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
headers["Content-Type"] = "application/json";

Console.WriteLine(headers["content-type"]); // application/json
Console.WriteLine(headers["CONTENT-TYPE"]); // application/json

SortedSet case-insensitive

var comandi = new SortedSet<string>(StringComparer.OrdinalIgnoreCase);
comandi.Add("Start");
comandi.Add("stop");

bool haStart = comandi.Contains("START"); // True
// I duplicati vengono rilevati correttamente
comandi.Add("START"); // Non aggiunge, esiste già come "Start"
Console.WriteLine(comandi.Count); // 2

Confronto ad alte prestazioni con Span<char>

Per scenari con requisiti di performance elevati (parsing di protocolli, hot paths), .NET offre confronti allocation-free tramite ReadOnlySpan<char>:

var riga = "Content-Type: application/json";

// Confronto senza allocare nuove stringhe
bool isContentType = riga.AsSpan(0, 12).Equals(
    "Content-Type".AsSpan(),
    StringComparison.OrdinalIgnoreCase);

// StartsWith su Span
bool isHttps = url.AsSpan().StartsWith(
    "https://".AsSpan(),
    StringComparison.OrdinalIgnoreCase);

Questo approccio è particolarmente utile in middleware HTTP, parser di configurazione e codice che elabora grandi volumi di testo.

Pattern Matching con Switch

Il pattern matching di C# non supporta nativamente il confronto case-insensitive negli switch, ma esistono due approcci corretti:

// Approccio 1: Guard clause con Equals
var risultato = comando switch
{
    _ when string.Equals(comando, "start", StringComparison.OrdinalIgnoreCase) => "Avvio...",
    _ when string.Equals(comando, "stop", StringComparison.OrdinalIgnoreCase) => "Arresto...",
    _ => "Comando non riconosciuto"
};

// Approccio 2: Normalizzazione con ToUpperInvariant (accettabile per switch)
var risultato2 = comando.ToUpperInvariant() switch
{
    "START" => "Avvio...",
    "STOP" => "Arresto...",
    _ => "Comando non riconosciuto"
};

Esempio completo: parser di configurazione

public sealed class ConfigParser
{
    private readonly FrozenDictionary<string, string> _impostazioni;

    public ConfigParser(IEnumerable<KeyValuePair<string, string>> rawSettings)
    {
        // FrozenDictionary è ottimizzato per letture frequenti (immutabile dopo la creazione)
        _impostazioni = rawSettings.ToFrozenDictionary(
            kvp => kvp.Key,
            kvp => kvp.Value,
            StringComparer.OrdinalIgnoreCase);
    }

    public string? Get(string chiave) =>
        _impostazioni.TryGetValue(chiave, out var valore) ? valore : null;
}

// Utilizzo
var config = new ConfigParser(new[]
{
    new KeyValuePair<string, string>("DatabaseUrl", "Server=..."),
    new KeyValuePair<string, string>("MaxConnections", "100"),
});

Console.WriteLine(config.Get("databaseurl"));    // "Server=..."
Console.WriteLine(config.Get("MAXCONNECTIONS")); // "100"

Riepilogo: regole pratiche

1. Usa OrdinalIgnoreCase per chiavi, identificatori, URL, nomi di file, comandi, header HTTP.
2. Usa CurrentCulture solo per testo mostrato all’utente, quando le regole locali sono rilevanti.
3. Non usare ToLower() per confronti: alloca inutilmente e dipende dalla cultura.
4. Specifica sempre StringComparison esplicitamente nelle chiamate a Equals e Compare.
5. Usa StringComparer quando passi logica di confronto a strutture dati.
6. Usa MemoryExtensions su Span<char> per hot path ad alta frequenza e senza allocazioni.

Seguendo queste linee guida, si eliminano intere classi di bug difficili da riprodurre e si ottiene codice più robusto, portabile e performante.

Fonte: DevLeader — C# String Comparison: Equals, OrdinalIgnoreCase, StringComparer, and Culture Pitfalls

C# String Comparison: Equals, OrdinalIgnoreCase, StringComparer, and Culture Pitfalls

Master C# string comparison with Equals, OrdinalIgnoreCase, StringComparer, and culture-sensitive APIs. Avoid the ToLower() antipattern and Turkish i problem.

^{Nick Cosentino (Dev Leader)}