Spcnet.it

2026-04-23 07:54:20

TypeScript 7.0 Beta: il nuovo compilatore in Go è circa 10 volte più veloce

Il team di TypeScript ha rilasciato la beta ufficiale di TypeScript 7.0, e non si tratta di un aggiornamento incrementale: il compilatore è stato riscritto in Go, con miglioramenti di performance che in molti scenari superano un fattore 10x. Dopo quasi un anno di anteprime tecniche sotto il nome TypeScript Native Preview, Microsoft porta la versione nativa del compilatore a un pubblico molto più ampio e la raccomanda per uso quotidiano, pur restando formalmente in beta.

Perché riscrivere il compilatore in Go

Il compilatore di TypeScript era storicamente scritto nello stesso linguaggio che compilava. Questa scelta, elegante dal punto di vista del bootstrapping, ha sempre comportato un costo: su codebase di grandi dimensioni il tsc può impiegare decine di secondi (o minuti) per il type-checking e il watch mode si appesantisce rapidamente all’aumentare dei file.

La riscrittura in Go non è un rewrite da zero: il team parla esplicitamente di un port metodico, mantenendo parità strutturale con la logica di type-checking di TypeScript 6.0. Questo approccio riduce il rischio di regressioni semantiche: la stessa base di casi di test, le stesse regole, ma con le velocità permesse da codice nativo e dal parallelismo reale a memoria condivisa.

Il risultato, secondo Microsoft, è che TypeScript 7.0 è circa 10 volte più veloce di TypeScript 6.0. Team come Bloomberg, Figma, Google, Slack e Vercel hanno riportato numeri comparabili durante la beta privata, con riduzioni drastiche dei tempi di build in CI.

Come provarlo oggi

L’installazione avviene come package separato per non rompere le pipeline esistenti. Basta un singolo comando:

npm install -D @typescript/native-preview@beta
npx tsgo --version
# Version 7.0.0-beta

Durante la fase beta, l’eseguibile si chiama tsgo al posto di tsc. Per Visual Studio Code è disponibile l’estensione “TypeScript Native Preview”, che affianca il language service classico permettendo di confrontare i tempi di risposta in tempo reale.

Parallelismo configurabile

Una delle novità più sottili, ma con maggiore impatto pratico, è il parallelismo integrato nel compilatore:

• --checkers N: numero di worker dedicati al type-checking (default 4). I worker mantengono viste indipendenti per evitare ricalcoli ridondanti, ma i risultati restano deterministici.
• --builders N: abilita la compilazione parallela di più progetti referenziati (project references). Ha un effetto moltiplicativo quando combinato con --checkers, ed è particolarmente efficace nei monorepo.
• --singleThreaded: forza l’esecuzione sequenziale per debugging o ambienti con memoria limitata (container CI con poca RAM, ad esempio).

Alzare --checkers aumenta la velocità ma anche il consumo di memoria: su agenti CI piccoli conviene fare qualche prova empirica prima di spingerlo oltre 8.

Breaking changes: la pulizia annunciata

TypeScript 7.0 è anche l’occasione per rimuovere anni di retrocompatibilità. Chi mantiene progetti legacy dovrà prestare attenzione, perché molte opzioni di configurazione sono semplicemente scomparse:

• target: es5 non è più supportato.
• downlevelIteration, moduleResolution: node/node10/classic, e i moduli amd, umd, systemjs, none sono stati rimossi.
• baseUrl è stato eliminato: usare paths relativo alla root del progetto.
• esModuleInterop, allowSyntheticDefaultImports e alwaysStrict non possono più essere disattivati.

Cambiano anche diversi default: strict: true, module: esnext, target pari all’ultima versione ECMAScript stabile prima di esnext, noUncheckedSideEffectImports: true, e soprattutto types: []. Quest’ultimo è il cambiamento che più spesso romperà le build: prima @types/* venivano inclusi automaticamente, ora vanno dichiarati esplicitamente:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Sul fronte del supporto a JavaScript con JSDoc, la pulizia è ancora più netta: i valori non possono più sostituire i tipi (usare typeof valore), la sintassi Closure-style function(string): void è rimossa, così come @enum e l’operatore postfisso !.

Convivenza con TypeScript 6.0

Per chi non può migrare subito tutte le pipeline, è possibile installare entrambe le versioni affiancate:

npm install -D typescript@npm:@typescript/typescript6

Così typescript continua a puntare a 6.0, mentre tsgo (o tsc7 dopo il rilascio finale) resta disponibile come entry point separato. È lo scenario consigliato per confrontare gradualmente i due compilatori su progetti reali prima di fare il cutover.

Roadmap e cosa aspettarsi

La beta è datata 21 aprile 2026; il rilascio stabile è previsto entro due mesi, con una release candidate alcune settimane prima. Nel frattempo arriveranno un --watch più efficiente, la parità di declaration file emit per JavaScript, miglioramenti all’editor (ricerca dei riferimenti ai file, comandi import/export più granulari) e una API programmatica stabile, attesa per TypeScript 7.1 o successiva.

Vale la pena migrare subito?

Per team che lavorano su codebase grandi e soffrono di type-check lenti, la risposta è “quasi sicuramente sì, almeno in parallelo”. Microsoft stessa dichiara il compilatore “altamente stabile e altamente compatibile” sulla base di test su codebase da milioni di righe. La strategia più prudente è: installare @typescript/native-preview come dev dependency aggiuntiva, introdurlo come job di CI opzionale accanto al tsc esistente, misurare i tempi reali e segnalare eventuali incompatibilità sul repository microsoft/typescript-go.

Le incompatibilità che emergeranno non saranno di natura logica ma di configurazione: soprattutto il nuovo default types: [] e la rimozione di baseUrl. Chi si è tenuto aggiornato con le versioni recenti dovrebbe cavarsela con poche modifiche al tsconfig.json.

Fonte: Announcing TypeScript 7.0 Beta di Daniel Rosenwasser sul blog ufficiale TypeScript (Microsoft DevBlogs).

Announcing TypeScript 7.0 Beta - TypeScript

Today we are absolutely thrilled to announce the release of TypeScript 7.0 Beta! If you haven’t been following TypeScript 7.0’s development, this release is significant in that it is built on a completely new foundation.

^{Daniel Rosenwasser (TypeScript)}

Spcnet.it

2026-04-22 15:21:43

12 tecniche per ottimizzare le query PostgreSQL su dataset di grandi dimensioni

Quando una tabella PostgreSQL cresce oltre il milione di righe, query che prima restituivano risultati in millisecondi iniziano ad impiegare secondi — o peggio. La buona notizia è che PostgreSQL offre strumenti potenti per affrontare questo problema. La cattiva notizia è che molti sviluppatori conoscono solo una parte di questi strumenti.

In questo articolo passiamo in rassegna le 12 tecniche più efficaci per ottimizzare le query su grandi dataset, con esempi SQL concreti per ciascuna.

1. Creare indici sulle colonne frequentemente filtrate

Il consiglio più noto, ma non per questo meno importante. Un indice trasforma una scansione sequenziale (O(n)) in una ricerca B-tree (O(log n)). La differenza su una tabella da un milione di righe può essere di due ordini di grandezza.

-- Prima: full sequential scan su ordini
SELECT * FROM orders WHERE customer_id = 42;

-- Creazione dell'indice
CREATE INDEX idx_orders_customer_id ON orders(customer_id);

-- Dopo: index scan, da 240ms a pochi ms

Usate EXPLAIN ANALYZE per verificare che l’indice venga effettivamente utilizzato.

2. Normalizzare il database in modo strategico

La normalizzazione riduce la ridondanza e migliora la coerenza dei dati, ma va applicata con giudizio. Una normalizzazione eccessiva crea decine di JOIN che possono diventare colli di bottiglia. La regola pratica: normalizzate i dati che cambiano spesso o che hanno alta cardinalità (liste di prodotti, clienti, categorie), denormalizzate i dati storici o di report dove la velocità di lettura è critica.

3. Evitare SELECT *

Selezionare tutte le colonne ha due costi nascosti: aumenta il volume di I/O e impedisce a PostgreSQL di soddisfare la query direttamente dall’indice (index-only scan). Specificate sempre le colonne necessarie:

-- Evitare
SELECT * FROM orders WHERE customer_id = 42;

-- Preferire
SELECT id, created_at, total_amount FROM orders WHERE customer_id = 42;

Quando le colonne selezionate fanno parte di un indice composito, PostgreSQL può restituire i dati senza accedere all’heap, eliminando un intero livello di I/O.

4. Ordinare i JOIN in modo efficiente

Il query planner moderno di PostgreSQL determina autonomamente l’ordine ottimale dei JOIN grazie al cost-based optimizer. Tuttavia, in scenari con molte tabelle o con join_collapse_limit ridotto, conviene strutturare i JOIN in modo che le tabelle più piccole (o più filtrate) vengano processate per prime, riducendo la cardinalità delle operazioni successive.

5. Usare LIMIT durante l’esplorazione dei dati

Apparentemente ovvio, ma spesso trascurato: se l’interfaccia utente mostra al massimo 50 risultati, non ha senso recuperarne un milione dal database.

SELECT id, name, email 
FROM customers 
ORDER BY created_at DESC 
LIMIT 50 OFFSET 0;

Attenzione al pagination problem: con OFFSET elevati, PostgreSQL scansiona comunque tutte le righe precedenti. Per paginazione su grandi dataset, preferite il keyset pagination (cursor-based).

6. Indici parziali per subset frequenti

Un indice parziale indicizza solo le righe che soddisfano una condizione, riducendo dimensioni e costo di manutenzione:

-- Indice solo sugli ordini completati (subset più frequentemente interrogato)
CREATE INDEX idx_completed_orders
ON orders(customer_id)
WHERE status = 'Completed';

-- La query deve includere la stessa condizione per usare l'indice
SELECT id, total_amount 
FROM orders 
WHERE customer_id = 42 AND status = 'Completed';

In un test pratico, questo indice ha dimezzato i tempi rispetto a un indice standard su tutte le righe.

7. Usare i tipi di dato più piccoli necessari

Ogni byte conta quando moltiplicato per milioni di righe. Preferite sempre il tipo più compatto che soddisfa il requisito:

• integer (4 byte) invece di bigint (8 byte) per chiavi primarie < 2 miliardi
• smallint (2 byte) per enumerazioni con pochi valori
• timestamp invece di timestamptz se il fuso orario è fisso
• varchar(n) con limite appropriato invece di text illimitato dove possibile

Tipi più piccoli significano pagine di dati più dense, quindi meno I/O per ogni query.

8. Non applicare funzioni sulle colonne indicizzate

Applicare una funzione a una colonna indicizzata invalida l’utilizzo dell’indice:

-- L'indice su name NON viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

-- Soluzione: creare un indice funzionale
CREATE INDEX idx_customers_lower_name ON customers(LOWER(name));

-- Ora l'indice viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

Lo stesso vale per funzioni su date come DATE(created_at): usate range di timestamp o create l’indice sulla funzione.

9. Partizionare le tabelle molto grandi

Il partizionamento divide una tabella logica in sotto-tabelle fisiche, permettendo a PostgreSQL di escludere partizioni irrilevanti (partition pruning) durante le query:

-- Tabella partizionata per anno
CREATE TABLE orders_partitioned (
    id         serial NOT NULL,
    customer_id integer,
    created_at  timestamp NOT NULL,
    CONSTRAINT pk_orders PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- Creazione delle partizioni annuali
CREATE TABLE orders_2024 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

CREATE TABLE orders_2025 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

Una query che filtra per anno legge solo la partizione corrispondente, ignorando completamente le altre.

10. Usare le transazioni per operazioni bulk

PostgreSQL esegue un commit (e quindi una scrittura sincrona su WAL) dopo ogni statement. Raggruppare più operazioni in un’unica transazione riduce drasticamente i costi di I/O:

-- Lento: un commit per ogni INSERT
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000

-- Veloce: un solo commit per tutto il batch
BEGIN;
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000
COMMIT;

In test pratici, l’approccio con transazione singola completa lo stesso lavoro in meno della metà del tempo rispetto agli inserimenti individuali.

11. Evitare transazioni long-running

Il modello MVCC (Multi-Version Concurrency Control) di PostgreSQL mantiene versioni multiple delle righe per garantire la consistenza delle letture. Le transazioni long-running bloccano il processo di VACUUM dal rimuovere le versioni obsolete, causando table bloat: tabelle che crescono fisicamente anche quando i dati logici non aumentano.

Spezzettate le operazioni pesanti in batch più piccoli e monitorate le transazioni attive con:

SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE state != 'idle' AND query_start IS NOT NULL
ORDER BY duration DESC;

12. Gestire il bloat con VACUUM

Ogni UPDATE e DELETE lascia righe “morte” sul disco. VACUUM le recupera:

-- VACUUM standard: recupera spazio senza bloccare le letture
VACUUM orders;

-- VACUUM FULL: recupera tutto lo spazio ma blocca l'accesso alla tabella
-- Usare solo in finestre di manutenzione programmate
VACUUM FULL orders;

-- Verificare lo stato del bloat
SELECT relname, n_dead_tup, n_live_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

Per la maggior parte dei workload, autovacuum è sufficiente. Assicuratevi che sia abilitato e calibrate i threshold in base al volume di modifiche della vostra applicazione:

-- Verificare la configurazione autovacuum per una tabella specifica
SELECT reloptions FROM pg_class WHERE relname = 'orders';

Riepilogo operativo

Non tutte le tecniche si applicano a ogni scenario. Un approccio efficace inizia sempre dall’analisi con EXPLAIN (ANALYZE, BUFFERS) per identificare i reali colli di bottiglia, poi applica le ottimizzazioni in modo mirato. L’indice sbagliato o il partizionamento mal configurato possono peggiorare le prestazioni invece di migliorarle.

Il punto di partenza universale resta lo stesso: misurare prima, ottimizzare dopo.

---

Fonte: 12 practices for optimizing PostgreSQL queries for large datasets — elmah.io Blog

12 practices for optimizing PostgreSQL queries for large datasets

Boost PostgreSQL performance with 12 expert tips for large datasets from partitioning to partial indexes and avoiding bloat. Stay fast and scale.

^{Ali Hamza Ansari (elmah.io Blog - .NET Technical tutorials/guides and new features)}

Spcnet.it

2026-04-22 09:19:56

Creare addon nativi per Node.js con .NET Native AOT: addio a Python e node-gyp

Da sempre, creare addon nativi per Node.js significava entrare nel mondo di C++ e node-gyp, con la necessità di installare Python, Visual Studio Build Tools e una serie di dipendenze che trasformavano il setup dell’ambiente in un’impresa. Il team di C# Dev Kit di Microsoft ha trovato una soluzione elegante: usare .NET Native AOT per produrre librerie condivise compatibili con l’interfaccia N-API di Node.js, scritte interamente in C#.

In questo articolo vediamo come funziona questa tecnica, analizzando la struttura del progetto, il meccanismo di interop e i punti critici da tenere d’occhio in produzione.

Perché Node.js supporta addon scritti in qualsiasi linguaggio

Un addon nativo per Node.js è semplicemente una libreria condivisa (.dll su Windows, .so su Linux, .dylib su macOS) che esporta un punto di ingresso preciso: la funzione napi_register_module_v1. Node.js carica la libreria, chiama questa funzione e da quel momento il modulo è disponibile per JavaScript.

L’interfaccia che rende tutto questo possibile è N-API (Node-API), una API C stabile e ABI-compatibile tra le versioni di Node.js. Questo significa che qualsiasi linguaggio in grado di produrre una shared library ed esportare una funzione C può diventare un addon Node.js — incluso C# compilato con Native AOT.

Configurazione del progetto .NET

Il file di progetto è sorprendentemente minimale:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <PublishAot>true</PublishAot>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
  </PropertyGroup>
</Project>

Due impostazioni chiave:

• PublishAot: abilita la compilazione Ahead-of-Time, producendo una shared library nativa invece di un assembly IL.
• AllowUnsafeBlocks: necessario per l’interop con N-API tramite function pointer e tipi non gestiti.

Il punto di ingresso del modulo

L’entry point usa l’attributo [UnmanagedCallersOnly], che istruisce il compilatore a generare una funzione C-callable con la firma esatta attesa da Node.js:

[UnmanagedCallersOnly(
    EntryPoint = "napi_register_module_v1",
    CallConvs = [typeof(CallConvCdecl)])]
public static nint Init(nint env, nint exports)
{
    // Registrazione delle funzioni esposte
    return exports;
}

Il tipo nint (native-sized integer) rappresenta gli handle opachi che N-API usa per riferirsi agli oggetti JavaScript. Non si tratta di puntatori diretti a memoria, ma di token gestiti dall’engine V8 tramite N-API.

Risoluzione delle funzioni N-API a runtime

Le funzioni N-API (come napi_create_string_utf8 o napi_get_cb_info) sono esportate direttamente da node.exe, non da una DLL separata. Per fare in modo che P/Invoke le risolva correttamente, si registra un custom resolver:

private static void Initialize()
{
    NativeLibrary.SetDllImportResolver(
        System.Reflection.Assembly.GetExecutingAssembly(),
        ResolveDllImport);
}

private static nint ResolveDllImport(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
    if (libraryName == "node")
        return NativeLibrary.GetMainProgramHandle();
    return IntPtr.Zero;
}

Questo permette di dichiarare le importazioni P/Invoke con [LibraryImport("node")] e averle risolte contro il processo host a runtime.

Marshalling delle stringhe UTF-8

Uno dei punti più delicati è la conversione tra stringhe JavaScript (UTF-16 internamente in V8, UTF-8 via N-API) e stringhe .NET. La strategia ottimale prevede:

• Uso dello stack per stringhe piccole (≤512 byte) tramite stackalloc
• Uso di ArrayPool<byte> per stringhe più grandi, evitando allocazioni sull’heap

private static string GetStringArg(nint env, nint info, int argIndex)
{
    // Recupera l'handle dell'argomento
    nint value = GetArgument(env, info, argIndex);
    
    // Prima chiamata: ottieni la dimensione necessaria
    nuint byteCount;
    napi_get_value_string_utf8(env, value, null, 0, out byteCount);
    
    // Allocazione efficiente in base alla dimensione
    if (byteCount <= 512)
    {
        Span<byte> buffer = stackalloc byte[(int)byteCount + 1];
        napi_get_value_string_utf8(env, value, buffer, (nuint)buffer.Length, out _);
        return Encoding.UTF8.GetString(buffer[..^1]);
    }
    else
    {
        byte[] buffer = ArrayPool<byte>.Shared.Rent((int)byteCount + 1);
        try
        {
            napi_get_value_string_utf8(env, value, buffer, (nuint)buffer.Length, out _);
            return Encoding.UTF8.GetString(buffer, 0, (int)byteCount);
        }
        finally
        {
            ArrayPool<byte>.Shared.Return(buffer);
        }
    }
}

Implementazione di una funzione reale: lettura dal Registry

L’esempio concreto mostrato dal team di Microsoft è un lettore del Windows Registry, che sostituisce il precedente addon C++:

private static nint ReadStringValue(nint env, nint info)
{
    try
    {
        var keyPath = GetStringArg(env, info, 0);
        var valueName = GetStringArg(env, info, 1);
        
        using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);
        
        return key?.GetValue(valueName) is string value
            ? CreateString(env, value)
            : GetUndefined(env);
    }
    catch (Exception ex)
    {
        // CRITICO: le eccezioni non gestite in [UnmanagedCallersOnly] crashano il processo
        ThrowError(env, $"Registry read failed: {ex.Message}");
        return 0;
    }
}

Attenzione: in un metodo [UnmanagedCallersOnly], le eccezioni non gestite provocano il crash dell’intero processo Node.js. Il pattern try/catch con ThrowError trasforma l’eccezione .NET in un errore JavaScript, mantenendo stabile il runtime.

Integrazione con TypeScript

Dopo dotnet publish, il file prodotto viene rinominato con estensione .node (convenzione Node.js) e caricato normalmente da TypeScript:

interface RegistryAddon {
    readStringValue(keyPath: string, valueName: string): string | undefined;
}

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;

const sdkPath = registry.readStringValue(
    'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
    'InstallLocation'
);
console.log(`SDK installato in: ${sdkPath}`);

Limiti e considerazioni

Questa tecnica ha un limite importante: Native AOT non supporta la cross-compilazione. Per ogni piattaforma target (Windows x64, Linux x64, macOS ARM64…) è necessario un ambiente di build separato. In pratica, questo si risolve con pipeline CI che eseguono la build su runner del sistema operativo corrispondente.

Esiste anche un’alternativa di più alto livello, node-api-dotnet, che astrae molti dei dettagli mostrati qui e supporta scenari più complessi come l’esposizione di interi namespace .NET a JavaScript. L’approccio “thin wrapper” descritto in questo articolo è preferibile quando si vuole controllo totale e dipendenze minime.

Conclusioni

L’integrazione tra .NET Native AOT e N-API apre uno scenario interessante per i team che già lavorano con C# e devono interfacciarsi con l’ecosistema Node.js. Eliminare Python e node-gyp dal setup semplifica notevolmente l’ambiente di sviluppo e unifica le competenze necessarie intorno a un unico SDK.

Il risultato è codice nativo con prestazioni paragonabili al C++, scritto con la produttività e la type safety di C# moderno, deployabile su Windows, Linux e macOS.

---

Fonte: Writing Node.js addons with .NET Native AOT — Microsoft .NET Blog, Drew Noakes

Writing Node.js addons with .NET Native AOT - .NET Blog

The C# Dev Kit team replaced C++ Node.js addons with C# and Native AOT, removing a dependency on Python. This post walks through building a Node.js native addon entirely in C# using N-API, LibraryImport, and UnmanagedCallersOnly.

^{Drew Noakes (.NET Blog)}

(in)sicurezza digitale

2026-04-22 09:33:07

Violazione ANTS: un banale difetto IDOR espone 19 milioni di identità francesi in vendita sul dark web

Si parla di:
Toggle

Una vulnerabilità elementare di tipo IDOR (Insecure Direct Object Reference) sull’API del portale governativo francese ANTS ha consentito a un attore di minaccia di estrarre fino a 19 milioni di record contenenti dati anagrafici e di identità dei cittadini francesi. La vicenda, emersa pubblicamente il 21 aprile 2026, solleva interrogativi profondi sulla sicurezza delle infrastrutture digitali dello Stato francese e sulla protezione dei dati biometrici e documentali alla base del sistema di identità nazionale.

Cos’è ANTS e perché la violazione è così grave

L’Agence Nationale des Titres Sécurisés (ANTS), operativa sotto il Ministero dell’Interno francese, gestisce le domande e il ciclo di vita dei documenti d’identità ufficiali dei cittadini: carte d’identità nazionale, passaporti, patenti di guida e permessi di soggiorno. Il portale ants.gouv.fr costituisce il punto di accesso centralizzato attraverso cui milioni di francesi richiedono, rinnovano o tracciano i propri documenti d’identità. Una violazione di questa piattaforma non riguarda quindi dati di servizio generici: tocca direttamente le informazioni anagrafiche certificate dallo Stato, quelle stesse che alimentano i sistemi di identità digitale e i processi di verifica dell’identità.

La timeline: dall’intrusione alla divulgazione

La ricostruzione cronologica dell’incidente è la seguente:

• 15 aprile 2026: ANTS rileva internamente un incidente di sicurezza sul portale istituzionale e avvia le procedure di risposta agli incidenti.
• 16 aprile 2026: Un attore di minaccia che opera sotto lo pseudonimo breach3d pubblica su forum underground di hacking la rivendicazione dell’attacco, affermando di essere in possesso di un dataset di 18-19 milioni di record esfiltrati dalla piattaforma ANTS.
• 19-20 aprile 2026: Il dato viene segnalato da ricercatori di sicurezza e giornalisti specializzati che accedono ai forum underground e verificano i campioni forniti dall’attore.
• 21 aprile 2026: Il Ministero dell’Interno francese e ANTS confermano ufficialmente l’incidente, notificano il CNIL (Commission Nationale de l’Informatique et des Libertés), la Procura di Parigi e l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information).

Il vettore d’attacco: IDOR, una vulnerabilità imbarazzante

Secondo quanto riferito da fonti vicine all’indagine e dalle dichiarazioni dello stesso attaccante, il vettore di compromissione è stato un difetto di tipo IDOR (Insecure Direct Object Reference) sull’API del portale ANTS. Lo stesso breach3d ha descritto la vulnerabilità come “really stupid” — stupida nella sua semplicità — rivelando che era sufficiente modificare un identificatore numerico nelle richieste HTTP all’API per accedere ai record di qualsiasi altro utente registrato sulla piattaforma.

L’IDOR è una vulnerabilità classificata nel OWASP Top 10 da oltre vent’anni (A01:2021 – Broken Access Control). Si verifica quando un’applicazione espone riferimenti diretti a oggetti interni — come ID di database, file o record — senza verificare che l’utente richiedente abbia effettivamente l’autorizzazione ad accedere a quell’oggetto. In questo caso, l’API governativa francese non implementava controlli di autorizzazione adeguati: un utente autenticato poteva iterare sugli ID numerici degli account per raccogliere massivamente i dati di tutti gli utenti registrati. Il processo di esfiltrazione risulta quindi altamente automatizzabile con script elementari.

I dati esposti e le implicazioni per i cittadini

Il Ministero dell’Interno francese ha confermato che i dati potenzialmente esposti includono: nome e cognome, indirizzo email, data di nascita, identificativi di account univoci e credenziali di accesso (login ID). Per un sottoinsieme di utenti, potrebbero essere stati esposti anche l’indirizzo postale, il luogo di nascita e il numero di telefono. ANTS ha precisato che i documenti caricati sul portale (immagini di passaporti o patenti, ad esempio) non risultano compromessi e che i dati esfiltrati non consentono l’accesso diretto agli account.

Tuttavia, la combinazione di dati anagrafici certificati dallo Stato con informazioni di contatto apre scenari di abuso estremamente preoccupanti per i difensori:

• Phishing e spear-phishing di alta precisione: con nome completo, email, data di nascita e luogo di nascita, gli attaccanti possono costruire comunicazioni altamente credibili che si spacciano per corrispondenza ufficiale del governo francese o di istituti finanziari.
• Furto di identità e creazione di identità sintetiche: la combinazione di dati anagrafici verificati dallo Stato costituisce una base ideale per aprire conti bancari fraudolenti, richiedere prestiti o commettere frodi fiscali.
• Sextortion e social engineering: messaggi personalizzati che dimostrano conoscenza di dati specifici (luogo di nascita, data esatta) aumentano drasticamente la credibilità degli schemi di estorsione.
• Credential stuffing: gli indirizzi email associati agli account ANTS vengono tipicamente testati su altri servizi, sfruttando il riutilizzo delle password.

Il profilo dell’attore: breach3d

L’attore breach3d non è nuovo alla scena underground. Prima di questa rivendicazione aveva già pubblicato dataset di altre organizzazioni su forum frequentati da broker di dati e operatori criminali. Non ci sono elementi pubblici che permettano di attribuire l’attività a un gruppo state-sponsored o a una gang ransomware strutturata: il profilo appare più coerente con quello di un opportunista focalizzato sulla monetizzazione dei dati piuttosto che su obiettivi di intelligence. Il dataset sarebbe stato messo in vendita a un prezzo non divulgato pubblicamente.

La risposta istituzionale e le notifiche

ANTS ha comunicato che non è richiesta alcuna azione immediata da parte degli utenti, invitandoli tuttavia a mantenere alta la vigilanza nei confronti di messaggi sospetti. L’agenzia ha notificato l’incidente alla CNIL, alla Procura di Parigi e all’ANSSI, che coordineranno le indagini e valuteranno la conformità al GDPR (Regolamento Generale sulla Protezione dei Dati). La violazione, se confermata nelle proporzioni dichiarate da breach3d, configurerebbe uno degli incidenti più gravi mai registrati nell’ambito dei sistemi di identità statale europei.

Pavel Durov, fondatore di Telegram, ha pubblicamente commentato l’incidente sottolineando i rischi sistemici legati alla centralizzazione dei dati d’identità governativi su piattaforme web esposte a Internet, alimentando il dibattito sulla progettazione sicura dei portali di e-government.

Cosa possono fare i difensori

Per le organizzazioni che gestiscono portali ad alta sensibilità e per i team di sicurezza che devono valutare il rischio residuo per i propri utenti alla luce di questo dataset circolante, si raccomanda di:

• Implementare sistematicamente controlli di autorizzazione lato server su ogni endpoint API che restituisce dati associati a un identificatore: verificare sempre che l’utente autenticato sia il proprietario del record richiesto.
• Adottare test di sicurezza specifici per IDOR e Broken Access Control nei cicli di sviluppo (SAST, DAST, penetration testing con focus su API).
• Per le organizzazioni che gestiscono dipendenti o clienti francesi: alzare il livello di allerta anti-phishing e considerare campagne di sensibilizzazione mirate sull’utilizzo di questo tipo di dataset per attacchi personalizzati.
• Monitorare i propri indirizzi email aziendali su servizi di threat intelligence e breach monitoring per rilevare tempestivamente la comparsa del dataset in nuovi marketplace underground.
• Valutare l’abilitazione di autenticazione multi-fattore su tutti i servizi esposti che accettano email come username, poiché la disponibilità degli indirizzi email alimenta attacchi di account takeover.

La violazione ANTS è l’ennesima dimostrazione che le vulnerabilità più banali — note, documentate e prevenibili — continuano ad affliggere sistemi governativi critici. Una API senza controlli di accesso adeguati, su un portale che gestisce l’identità di decine di milioni di cittadini, rappresenta un rischio sistemico di proporzioni difficilmente accettabili in un’era in cui il furto d’identità digitale alimenta ecosistemi criminali globali.

(in)sicurezza digitale

2026-04-21 16:16:47

CyberAv3ngers e l’IRGC all’assalto delle infrastrutture critiche USA: sei agenzie federali confermano gli attacchi ai PLC Rockwell Automation

Il 7 aprile 2026, sei agenzie federali statunitensi — tra cui CISA, FBI e NSA — hanno pubblicato l’advisory congiunto AA26-097A, confermando che CyberAv3ngers, gruppo di cyberoffensiva direttamente controllato dall’IRGC-CEC (Islamic Revolutionary Guard Corps Cyber-Electronic Command) iraniano, ha condotto attacchi contro infrastrutture critiche americane sfruttando una vulnerabilità critica nei Programmable Logic Controller di Rockwell Automation. L’aspetto più preoccupante: per questa vulnerabilità non esiste alcuna patch del vendor.

Il gruppo: CyberAv3ngers e la struttura del comando IRGC

CyberAv3ngers è un threat group state-directed attivo almeno dal 2020, tracciato dalla comunità di threat intelligence con molteplici denominazioni: Storm-0784 (Microsoft), Bauxite (Dragos), Hydro Kitten, UNC5691 (Mandiant) e classificato da MITRE ATT&CK come G1027. Il gruppo opera come persona ufficiale dell’IRGC-CEC, distinguendosi per la focalizzazione sulle Operational Technology (OT) e i sistemi di controllo industriale (ICS), un dominio in cui pochi gruppi APT hanno sviluppato capacità analoghe.

La traiettoria evolutiva del gruppo è significativa: da attacchi opportunistici con credenziali di default su PLC Unitronics di fabbricazione israeliana nel 2023, alla distribuzione della piattaforma malware ICS custom IOCONTROL nel 2024, fino alla campagna 2026 contro i controller Rockwell Automation, che rappresenta un salto qualitativo nell’ambito delle capacità offensive ICS.

Il contesto geopolitico: rappresaglia cyber dopo gli attacchi del febbraio 2026

La campagna si inserisce in un contesto geopolitico estremamente teso. Il 28 febbraio 2026, USA e Israele hanno condotto un’operazione militare congiunta contro obiettivi iraniani, innescando una campagna di rappresaglia cyber multi-vettore che Unit 42 di Palo Alto Networks ha tracciato come cluster CL-STA-1128. In questo contesto, CyberAv3ngers ha intensificato le operazioni contro infrastrutture critiche americane, spostando il focus dai precedenti target israeliani verso obiettivi statunitensi.

CVE-2021-22681: la vulnerabilità senza patch al centro degli attacchi

Il vettore tecnico primario della campagna è CVE-2021-22681, una vulnerabilità di authentication bypass con CVSS score 9.8 che affligge i controller Logix di Rockwell Automation. La vulnerabilità permette a un attaccante di bypassare l’autenticazione e ottenere accesso ai PLC senza credenziali valide. Il problema strutturale: Rockwell Automation non ha rilasciato una patch, indicando invece misure di difesa in profondità come unica mitigazione disponibile.

I prodotti vulnerabili includono un ampio portfolio:

• RSLogix 5000 (versioni 16-20)
• Studio 5000 Logix Designer (versione 21 e successive)
• Famiglie di controller: CompactLogix, ControlLogix, GuardLogix, DriveLogix, SoftLogix

Secondo la scansione Cortex Xpanse di Palo Alto, risultano esposti su internet globalmente 5.600 indirizzi IP con servizi Rockwell Automation o Allen-Bradley SCADA, inclusi FactoryTalk e vari PLC — una superficie di attacco di proporzioni allarmanti.

Le TTPs operative: preparazione con FactoryTalk su VPS

L’analisi di Unit 42 rivela che gli attaccanti hanno adottato un approccio metodico nella preparazione. Con moderata confidenza, i ricercatori ritengono che CL-STA-1128 abbia installato il software FactoryTalk di Rockwell Automation su infrastruttura VPS per abilitare le proprie attività di exploitation, sviluppando internamente la capacità di interagire con il protocollo CIP (Common Industrial Protocol) prima di colpire i target reali. La mappatura delle porte utilizzate dai dispositivi esposti ha permesso al gruppo di identificare i target mediante pattern statici caratteristici dei prodotti Rockwell.

I settori colpiti confermati dall’advisory federale comprendono Water and Wastewater Systems (WWS), Energy e Government Services and Facilities. L’advisory CISA AA26-097A, primo caso in cui sei agenzie federali attribuiscono congiuntamente un’operazione all’IRGC, conferma interruzioni operative e perdite economiche in organizzazioni multiple.

Escalation della minaccia: dall’hacktivism all’OT warfare

La progressione di CyberAv3ngers illustra una tendenza preoccupante nel panorama delle minacce state-sponsored: la convergenza tra capacità IT e OT in un unico gruppo APT. Nelle prime operazioni del 2023, il gruppo si limitò a modificare i display HMI dei Unitronics PLC presso impianti idrici israeliani e americani, un’azione prevalentemente dimostrativa. Con IOCONTROL nel 2024, il gruppo ha sviluppato malware custom per dispositivi IoT e OT. La campagna del 2026, che sfrutta una vulnerabilità critica senza patch in uno dei vendor di automazione industriale più diffusi al mondo, rappresenta una capacità offensiva significativamente più matura.

Mitigazioni: nessuna patch disponibile, solo difesa in profondità

In assenza di una patch per CVE-2021-22681, le organizzazioni che utilizzano controller Rockwell Automation devono implementare le seguenti misure di difesa in profondità raccomandate dall’advisory federale:

• Segmentazione di rete: isolare i PLC e i sistemi OT in zone di rete separate, con firewall tra IT e OT, eliminando qualsiasi esposizione diretta a internet
• Isolamento delle engineering workstation: le workstation che comunicano con i PLC devono essere dedicate e segregate dalla rete corporate generale
• Abilitazione di CIP Security: configurare il protocollo CIP Security per autenticazione e cifratura delle comunicazioni tra EWS e PLC dove supportato
• Physical mode switch: impostare i PLC in modalità fisica protetta dove applicabile, impedendo modifiche al firmware via software
• Monitoraggio anomalie CIP-IP: deployare soluzioni di monitoraggio OT (es. Dragos, Claroty, Nozomi) in grado di rilevare download anomali e cambi di modalità sui PLC tramite protocollo CIP
• Rimozione dell’esposizione internet: verificare con Shodan o Censys la presenza di dispositivi Rockwell/Allen-Bradley esposti e rimuoverli immediatamente

Implicazioni strategiche

La campagna di CyberAv3ngers evidenzia la crescente militarizzazione del cyberspazio nelle operazioni di rappresaglia tra stati. La scelta di colpire infrastrutture idriche, energetiche e governative — settori con potenziale impatto diretto sulla popolazione civile — segnala una volontà di massimizzare l’effetto psicologico e operativo degli attacchi. Il fatto che Rockwell Automation non abbia rilasciato una patch per CVE-2021-22681 pone interrogativi seri sul modello di sicurezza dei vendor OT: in un settore dove i device lifecycle si misurano in decenni, l’assenza di aggiornamenti di sicurezza per vulnerabilità critiche è un rischio sistemico che va affrontato con urgenza a livello regolatorio.

Con 5.600 dispositivi Rockwell Automation esposti su internet a livello globale e nessuna patch in vista, la superficie di attacco rimane aperta. Le organizzazioni che operano infrastrutture critiche devono trattare l’advisory AA26-097A come una priorità assoluta e avviare immediatamente una revisione dell’esposizione OT.

Spcnet.it

2026-04-21 13:28:35

Primary Constructor e Dependency Injection in C# 12: vantaggi, insidie e quando usarli

Con C# 12, Microsoft ha introdotto i primary constructors per tutte le classi e le struct — non solo per i record come in precedenza. Per chi lavora quotidianamente con ASP.NET Core e il pattern di dependency injection, questa feature merita attenzione: riduce il boilerplate in modo significativo, ma nasconde un'insidia che è bene conoscere prima di adottarla sistematicamente.

Il problema: il boilerplate del costruttore classico

Chi ha scritto servizi ASP.NET Core sa bene come appare il costruttore tradizionale con dependency injection:

public class OrderService
{
    private readonly IOrderRepository _orderRepository;
    private readonly ILogger<OrderService> _logger;
    private readonly IEventBus _eventBus;
    private readonly IValidator<Order> _validator;

    public OrderService(
        IOrderRepository orderRepository,
        ILogger<OrderService> logger,
        IEventBus eventBus,
        IValidator<Order> validator)
    {
        _orderRepository = orderRepository;
        _logger = logger;
        _eventBus = eventBus;
        _validator = validator;
    }
}

Per ogni dipendenza: una dichiarazione di campo, un parametro nel costruttore, un'assegnazione nel corpo. Con quattro dipendenze, sono già dodici righe di puro scaffolding. In un servizio con sei o sette dipendenze, il costruttore diventa il blocco di codice più lungo della classe — senza contenere logica.

La soluzione con primary constructors

Con i primary constructors di C# 12, lo stesso servizio si scrive così:

public class OrderService(
    IOrderRepository orderRepository,
    ILogger<OrderService> logger,
    IEventBus eventBus,
    IValidator<Order> validator)
{
    public async Task<Order?> GetOrderAsync(Guid id)
    {
        logger.LogInformation("Fetching order {OrderId}", id);
        return await orderRepository.GetByIdAsync(id);
    }

    public async Task PlaceOrderAsync(Order order)
    {
        await validator.ValidateAndThrowAsync(order);
        await orderRepository.SaveAsync(order);
        await eventBus.PublishAsync(new OrderPlacedEvent(order.Id));
    }
}

I parametri del primary constructor diventano direttamente disponibili in tutta la classe senza dichiarazioni esplicite di campo. Il risultato è codice più snello, con meno rumore visivo e il focus immediato sulla logica di business.

L'insidia della mutabilità: perché Milan Jovanović era inizialmente scettico

Il motivo di resistenza di molti sviluppatori esperti è legittimo: i parametri del primary constructor non sono campi readonly. Il compilatore non impedisce la riassegnazione accidentale:

public class OrderService(IOrderRepository orderRepository)
{
    public void SomeMethod()
    {
        orderRepository = null!;  // Compila senza warning
    }
}

Con i campi privati readonly tradizionali, questo codice causa un errore di compilazione. Con i primary constructors, il compilatore lo accetta silenziosamente. In un servizio DI dove le dipendenze non dovrebbero mai essere rimpiazzate a runtime, questo è un rischio concreto in team di grandi dimensioni.

Mitigazione: assegnazione esplicita a readonly field

Quando la garanzia di immutabilità è critica, si può assegnare esplicitamente il parametro a un campo readonly:

public class CriticalService(IRepository repository)
{
    private readonly IRepository _repository = repository;

    // Da qui in poi si usa _repository, mai repository direttamente
}

Questo reintroduce parte del boilerplate, ma mantiene la sintassi più compatta per la firma del costruttore e garantisce l'immutabilità a livello compilatore.

Quando usare i primary constructors

La valutazione pragmatica è che i primary constructors offrono il massimo vantaggio nelle classi di servizio DI tipiche di ASP.NET Core, dove i parametri vengono usati ma raramente riassegnati. In questi scenari, il rischio di mutabilità accidentale è basso e i benefici di leggibilità sono immediati.

Vale la pena usarli anche per entity e value object dove i parametri di costruzione diventano proprietà read-only:

public class Order(Guid customerId, Money total)
{
    public Guid Id { get; } = Guid.NewGuid();
    public Guid CustomerId { get; } = customerId;
    public Money Total { get; } = total;
    public DateTime CreatedAt { get; } = DateTime.UtcNow;
}

Quando evitarli

Tre scenari in cui i primary constructors non sono la scelta giusta:

• Logica di validazione nel costruttore: se il costruttore deve eseguire guard clause o validazioni prima dell'assegnazione, il corpo esplicito del costruttore tradizionale è necessario.
• Multiple signature di costruttore: i primary constructors supportano una sola firma. Con overload multipli (es. per serializzazione), la sintassi tradizionale è l'unica opzione.
• Cinque o più dipendenze: se una classe richiede molte dipendenze, il problema non è la sintassi del costruttore ma il design della classe. Il segnale che suggerisce un refactoring verso interfacce più coese o il pattern Facade.

Conclusione: adottarli con consapevolezza

I primary constructors di C# 12 non sono una rivoluzione, ma un'evoluzione pragmatica del linguaggio. Per la maggior parte delle classi di servizio in ASP.NET Core, il tradeoff è favorevole: meno boilerplate, codice più leggibile, rischio di mutabilità basso nel contesto DI. L'importante è conoscere il comportamento del compilatore e scegliere consapevolmente quando la garanzia di readonly è effettivamente necessaria.

Come sempre con le feature di C#, il consiglio è adottarle dove migliorano la leggibilità del codice reale, non per seguire una moda sintattica.

Fonte originale: Why I Switched to Primary Constructors for DI in C# di Milan Jovanović.

Why I Switched to Primary Constructors for DI in C#

I resisted primary constructors for a while. They felt like a shortcut that would cost me later. But after using them across several projects, I'm sold, with one important caveat.

^{www.milanjovanovic.tech}

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