(in)sicurezza digitale

2026-04-19 15:27:47

SmokedHam e UNC2465: il backdoor dei ransomware operator che si nasconde nei tool IT più usati dagli amministratori

Se siete amministratori di sistema e avete cercato su Google uno strumento come PuTTY, RVTools o Remote Desktop Manager nelle ultime settimane, potreste aver incontrato un annuncio pubblicitario che conduceva a una versione modificata del software, contenente un backdoor. È la tecnica di malvertising che il gruppo criminale UNC2465 ha affinato nel tempo, e che Orange Cyberdefense ha documentato in una nuova serie di attacchi condotti nel 2026 contro organizzazioni europee.

Chi è UNC2465: dai ex affiliati DarkSide agli operator Qilin

UNC2465 è un cluster di attività tracciato da Mandiant fin dal 2019. Il gruppo ha guadagnato notorietà come affiliato del ransomware DarkSide — lo stesso che colpì Colonial Pipeline nel 2021 causando una crisi energetica negli Stati Uniti. Dopo lo scioglimento di DarkSide, UNC2465 ha mantenuto la propria operatività affiliandosi con LockBit e, più recentemente, con Qilin (noto anche come Agenda ransomware), uno dei gruppi ransomware in più rapida crescita nel panorama della cybercriminalità organizzata.

Ciò che distingue UNC2465 da molti altri attori del crimine informatico è la sofisticazione operativa: il gruppo non si affida a exploit zero-day, ma a una combinazione di malvertising, trojanizzazione di software legittimo e tecniche di blending con attività normali — incluso l’uso di bossware commerciale legale per mascherare le proprie azioni malevole.

Il vettore: annunci di ricerca malevoli per tool IT

La campagna documentata da Orange Cyberdefense nel febbraio-aprile 2026 si basa su un meccanismo collaudato: acquistare spazi pubblicitari su motori di ricerca come Google e Bing per intercettare le ricerche di strumenti IT ampiamente utilizzati da system administrator e IT manager. I tool impersonati includono:

• PuTTY e KiTTY — client SSH tra i più usati al mondo
• RVTools — tool di inventario VMware indispensabile in ambienti virtualizzati
• Remote Desktop Manager — gestore di sessioni RDP diffusissimo
• Zoho Assist — software di supporto remoto
• Total Commander — file manager Windows
• Advanced IP Scanner — scanner di rete molto popolare

Il meccanismo è infido perché gli amministratori di sistema sono abituati a scaricare questi tool di frequente, spesso su nuove macchine, e la fiducia nel brand del software abbassa la guardia. Un click sull’annuncio — che compare sopra i risultati organici — porta a un dominio malevolo con un installer visivamente identico all’originale.

Anatomia di SmokedHam: il backdoor che evolve continuamente

Il payload distribuito tramite gli installer trojanizzati è SmokedHam (tracciato da ConnectWise anche come Parcel RAT), un backdoor basato su PowerShell e C# attivo dalla fine del 2019. Nelle versioni più recenti, SmokedHam è stato snellito rispetto alle prime varianti: la funzionalità di screen capture è stata rimossa e il keylogger è presente ma disattivato. L’obiettivo primario del backdoor, nella fase attuale, è quello di stabilire un canale C2 persistente e ricevere comandi PowerShell da eseguire.

Questa semplicità apparente è in realtà una scelta strategica: un backdoor minimale è più difficile da rilevare. La complessità dell’attacco viene delegata agli strumenti post-exploitation che vengono scaricati successivamente.

Il flusso di attacco dettagliato

L’installer NSIS (Nullsoft Scriptable Install System) scaricato dalla vittima esegue simultaneamente due operazioni: installa il software legittimo (per non insospettire l’utente) e avvia silenziosamente la catena di compromissione.

• I file vengono estratti in C:\ProgramData\LogConverter\
• La persistenza viene stabilita tramite una chiave di registro Run che punta a Microsoft.NodejsTools.PressAnyKey.lnk — un abuso di un binario legittimo di Visual Studio (LOLBin)
• PowerShell esegue comandi offuscati per caricare SmokedHam direttamente in memoria (fileless)
• Il backdoor contatta i propri server C2 nascosti dietro Cloudflare Workers e endpoint AWS, rendendo il traffico indistinguibile da comunicazioni legittime verso cloud provider

Il bossware come copertura: la tecnica più insidiosa

Una delle caratteristiche più originali di UNC2465, segnalata dal CERT di Orange Cyberdefense, è l’uso di software di monitoraggio dei dipendenti — il cosiddetto bossware — per mimetizzare le proprie attività malevole. Tool come ControlioNet e Teramind, normalmente impiegati dai datori di lavoro per monitorare la produttività, vengono installati dagli attaccanti sui sistemi compromessi. Poiché questi software sono commerciali, firmati e spesso già presenti nelle whitelist aziendali, le loro comunicazioni di rete e le loro funzioni (screenshot, keylogging, accesso remoto) non vengono flaggate come anomale.

In questa maniera, UNC2465 può condurre ricognizione prolungata, esfiltrare credenziali e preparare il terreno per il ransomware finale rimanendo sotto il radar per settimane o mesi.

Indicatori di compromissione (IoC)

# Domini C2 SmokedHam/Parcel RAT (Cloudflare Workers)
cloud-9cd9.wtf-system.workers[.]dev
cdn-adv.systems-scanner.workers[.]dev
cdn-cloude.extended-system.workers[.]dev
# Pattern comune: cdn-*.workers[.]dev con nomi che imitano CDN legittimi

# Directory di installazione sospetta
C:\ProgramData\LogConverter\

# Persistenza via registro
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  → Microsoft.NodejsTools.PressAnyKey.lnk

# LOLBin abusato
Microsoft.NodejsTools.PressAnyKey.exe (legittimo ma usato come launcher)

# Installer firmato sospetto
Firma: LLC DIAPROM (distribuito su domini che imitano siti ufficiali)

# Bossware da monitorare se non autorizzato
ControlioNet, Teramind

Raccomandazioni per i difensori

La campagna UNC2465 pone sfide particolari perché prende di mira esattamente le persone che si occupano di sicurezza e amministrazione dei sistemi. Ecco le contromisure più efficaci:

• Download dai soli siti ufficiali: abituare tutti gli amministratori a scaricare tool esclusivamente dai siti ufficiali o tramite package manager interni verificati. Mai dal primo risultato di un motore di ricerca
• Blocco degli annunci nei browser aziendali: implementare un ad-blocker a livello di DNS (Pi-hole, NextDNS, filtering proxy) per eliminare il vettore primario di questa campagna
• Application allowlisting: garantire che solo software approvato possa essere eseguito, prevenendo l’installazione di bossware non autorizzato
• Monitoraggio Cloudflare Workers: alert su connessioni verso domini *.workers.dev non presenti nelle baseline del traffico aziendale
• Verifica degli hash prima dell’esecuzione: confrontare gli hash SHA-256 degli installer con quelli pubblicati dai vendor prima dell’installazione
• EDR con analisi comportamentale: rilevare l’abuso di LOLBin come Microsoft.NodejsTools.PressAnyKey.exe e l’esecuzione di PowerShell offuscato

UNC2465 rappresenta un caso di studio esemplare su come i gruppi criminali di alto livello combinino tecniche di accesso iniziale mutuate dal cybercrime di massa (malvertising) con operazioni post-compromise da APT. L’obiettivo finale — il ransomware — arriva solo dopo un lungo periodo di radicamento silenzioso nella rete bersaglio. La prevenzione deve quindi concentrarsi sul vettore iniziale: un download sbagliato può compromettere un’intera infrastruttura.

Spcnet.it

2026-04-19 12:31:45

AOT-Friendly DTO Mapping in .NET: Source Generators al posto della reflection

Con l’adozione crescente di NativeAOT e il trimming in .NET, uno dei nodi critici per molti progettisti è la gestione del mapping tra oggetti: le librerie classiche come AutoMapper si basano pesantemente sulla reflection a runtime, che è incompatibile con la compilazione Ahead-of-Time. In questo articolo esploreremo ElBruno.AotMapper, una libreria che risolve il problema spostando la generazione del codice di mapping a compile time grazie ai Roslyn Source Generators.

Il problema: reflection e AOT non vanno d’accordo

Quando si compila un’applicazione .NET con PublishAot=true oppure si abilita il trimming aggressivo, il runtime non può più analizzare dinamicamente i tipi come farebbe normalmente. Le librerie che usano System.Reflection per scoprire proprietà e invocare setter al volo — come AutoMapper nella sua configurazione classica — provocano errori in fase di esecuzione o vengono tagliate dal trimmer.

Le alternative tradizionali per chi vuole restare AOT-compatible sono:

• Scrivere il mapping a mano (tedioso e soggetto a errori)
• Usare Mapster con configurazione esplicita (verbosa)
• Affidarsi a Source Generators che generano il codice prima della compilazione

ElBruno.AotMapper percorre la terza strada: usa un Source Generator basato su Roslyn per emettere metodi di estensione fortemente tipizzati già al momento del build, con zero reflection a runtime.

Come funziona: Source Generators al posto della reflection

I Roslyn Source Generators sono componenti che vengono eseguiti durante la compilazione e possono produrre file C# aggiuntivi. In questo caso, il generator analizza le vostre classi annotate con attributi specifici e genera automaticamente i metodi di mapping corrispondenti.

I vantaggi concreti di questo approccio:

• Gli errori di mapping emergono in fase di compilazione, non a runtime
• Zero overhead da reflection: il codice generato è codice C# diretto, ottimizzabile dal JIT o dall’AOT compiler
• Compatibilità completa con NativeAOT e applicazioni trimmate
• Il codice generato è visibile e debuggabile (potete ispezionarlo nelle cartelle di build)

Installazione

La libreria si divide in due package NuGet distinti:

# Attributi e interfacce core
dotnet add package ElBruno.AotMapper

# Il Source Generator (solo per il progetto che contiene i DTO)
dotnet add package ElBruno.AotMapper.Generator

Il Generator va aggiunto come PrivateAssets="all" in genere, per evitare che la dipendenza si propaghi ai progetti dipendenti:

<PackageReference Include="ElBruno.AotMapper.Generator" Version="x.y.z">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>

Utilizzo degli attributi di mapping

Mapping base con [MapFrom]

Il caso più semplice: due classi con le stesse proprietà. Si annota il DTO destinazione con [MapFrom] specificando il tipo sorgente:

// Entità del dominio
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public DateTime CreatedAt { get; set; }
}

// DTO di risposta annotato
[MapFrom(typeof(Product))]
public class ProductDto
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
}

Il Source Generator analizza questo codice e genera automaticamente un metodo di estensione. Dopo la compilazione potrete usarlo così:

var product = await dbContext.Products.FindAsync(id);
var dto = product.ToProductDto(); // Metodo generato, zero reflection

Rimappatura di proprietà con [MapProperty]

Quando i nomi delle proprietà non corrispondono tra sorgente e destinazione, si usa [MapProperty] per indicare esplicitamente il mapping:

[MapFrom(typeof(User))]
public class UserSummaryDto
{
    public int Id { get; set; }

    [MapProperty(nameof(User.FirstName))]
    public string Nome { get; set; } = string.Empty;  // Diverso da FirstName

    [MapProperty(nameof(User.LastName))]
    public string Cognome { get; set; } = string.Empty;
}

Ignorare proprietà con [MapIgnore]

Per escludere campi sensibili o non necessari:

[MapFrom(typeof(User))]
public class PublicUserDto
{
    public int Id { get; set; }
    public string UserName { get; set; } = string.Empty;

    [MapIgnore]
    public string? PasswordHash { get; set; }  // Non verrà mappato
}

Conversioni custom con [MapConverter]

Per logiche di conversione non banali, si implementa IMapConverter<TSource, TDestination>:

public class PriceToStringConverter : IMapConverter<decimal, string>
{
    public string Convert(decimal source) => source.ToString("C2");
}

[MapFrom(typeof(Product))]
public class ProductDisplayDto
{
    public string Name { get; set; } = string.Empty;

    [MapConverter(typeof(PriceToStringConverter))]
    public string FormattedPrice { get; set; } = string.Empty;
}

Integrazione in un Minimal API ASP.NET Core

Il package AspNetCore della libreria facilita l’integrazione con Dependency Injection. Ecco un esempio completo di endpoint:

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<AppDbContext>(...);

var app = builder.Build();

app.MapGet("/products/{id}", async (int id, AppDbContext db) =>
{
    var product = await db.Products.FindAsync(id);
    if (product is null) return Results.NotFound();

    // ToProductDto() è un metodo generato dal Source Generator
    return Results.Ok(product.ToProductDto());
});

app.Run();

Quando si pubblica con dotnet publish -r win-x64 -p:PublishAot=true, il codice di mapping generato viene incluso senza problemi perché è codice C# statico, non reflection dinamica.

Considerazioni pratiche

La libreria è indicata soprattutto per chi:

• Sta migrando applicazioni verso NativeAOT o vuole abilitare il trimming
• Sviluppa microservizi con startup time critico (AOT avvia le app molto più velocemente)
• Preferisce avere errori di mapping evidenziati a compile time
• Vuole ispezionare il codice generato per capire esattamente cosa succede

La libreria è ancora in evoluzione (work-in-progress secondo l’autore), quindi prima di adottarla in produzione è consigliabile valutare alternative mature come Mapperly, anch’essa basata su Source Generators e con una community più consolidata. Detto questo, ElBruno.AotMapper è un ottimo punto di partenza per capire come funziona il mapping AOT-friendly e i Source Generators in generale.

Conclusione

Il passaggio a NativeAOT e al trimming in .NET è una tendenza inesorabile, specialmente per applicazioni cloud-native e microservizi che richiedono avvio rapido e footprint ridotto. Le librerie di mapping basate su reflection appartengono a un’era che sta tramontando: i Source Generators sono il futuro, e ElBruno.AotMapper mostra come si possa risolvere un problema pratico quotidiano — il mapping DTO — con questo approccio moderno.

Se volete esplorare ulteriormente l’argomento, la documentazione ufficiale di Roslyn Source Generators è disponibile su Microsoft Learn, e il progetto di riferimento industriale è Mapperly.

---

Fonte originale: AOT-Friendly DTO Mapping in .NET – El Bruno

🗺️ AOT-Friendly DTO Mapping in .NET

Hi! So, I’ve been away from any scenario that involves and needs data mapping, until I get to OpenClawNet. So I got to the point that I need to map my entities to DTOs? I read this a lot >…

^{elbruno (El Bruno)}

Spcnet.it

2026-04-19 09:12:09

Command Pattern in C#: guida completa con undo, redo e Dependency Injection

Il Command Pattern è uno dei design pattern comportamentali più utili nel mondo dello sviluppo software. In C#, la sua implementazione è particolarmente elegante e consente di costruire sistemi robusti con funzionalità di undo/redo, accodamento di operazioni e logging senza intaccare la logica di business. In questo articolo vedremo come implementarlo passo dopo passo, con esempi concreti e consigli pratici per applicazioni reali.

Cos’è il Command Pattern?

Il Command Pattern incapsula una richiesta come un oggetto autonomo, separando chi la emette da chi la esegue. Questo consente di parametrizzare i client con richieste diverse, accodare operazioni, supportare il rollback e costruire sistemi di macro o audit trail. In parole semplici: invece di chiamare direttamente un metodo, si crea un oggetto che “sa come” eseguire quella chiamata, e lo si passa all’esecutore.

I casi d’uso più classici includono:

• Editor di testo o grafica con undo/redo illimitato
• Sistemi di workflow con operazioni reversibili
• Transaction scripts in architetture DDD
• Logging e auditing di operazioni critiche
• Macro recording nelle applicazioni di produttività

I componenti del pattern

Un’implementazione corretta del Command Pattern in C# prevede quattro attori principali:

• ICommand: l’interfaccia contrattuale che definisce Execute(), Undo() e una proprietà descrittiva
• Receiver: la classe che contiene la logica di business effettiva, ignara del pattern
• Concrete Command: le implementazioni di ICommand, che catturano i parametri in costruzione e delegano al Receiver
• Invoker: gestisce la coda di esecuzione e le stack di undo/redo

Implementazione passo dopo passo

Step 1: definire l’interfaccia ICommand

Il contratto deve essere minimale. Tutti i dati necessari all’esecuzione viaggiano dentro il comando stesso, non vengono passati ai metodi:

public interface ICommand
{
    string Description { get; }
    void Execute();
    void Undo();
}

La scelta di metodi senza parametri è deliberata: favorisce l’immutabilità del comando dopo la costruzione e impedisce il condizionamento da stato esterno.

Step 2: creare il Receiver

Il Receiver contiene la logica reale. Non sa nulla di comandi, stack o undo. È testabile in isolamento:

public class TextDocument
{
    private readonly List<string> _lines = new();

    public IReadOnlyList<string> Lines => _lines.AsReadOnly();

    public void AddLine(string text) => _lines.Add(text);

    public void RemoveLine(int index)
    {
        if (index >= 0 && index < _lines.Count)
            _lines.RemoveAt(index);
    }
}

Step 3: implementare i Concrete Commands

Ogni comando cattura i propri dati al momento della costruzione e implementa sia Execute che Undo. Notare che lo stato necessario per l’undo viene salvato durante Execute:

public sealed class AddLineCommand : ICommand
{
    private readonly TextDocument _document;
    private readonly string _text;

    public string Description => $"Aggiungi riga: "{_text}"";

    public AddLineCommand(TextDocument document, string text)
    {
        _document = document ?? throw new ArgumentNullException(nameof(document));
        _text = text ?? throw new ArgumentNullException(nameof(text));
    }

    public void Execute() => _document.AddLine(_text);

    public void Undo() => _document.RemoveLine(_document.Lines.Count - 1);
}

public sealed class RemoveLineCommand : ICommand
{
    private readonly TextDocument _document;
    private readonly int _index;
    private string? _removedText;

    public string Description => $"Rimuovi riga {_index}";

    public RemoveLineCommand(TextDocument document, int index)
    {
        _document = document;
        _index = index;
    }

    public void Execute()
    {
        // Salviamo lo stato per poter fare undo
        _removedText = _document.Lines[_index];
        _document.RemoveLine(_index);
    }

    public void Undo()
    {
        if (_removedText is not null)
            _document.AddLine(_removedText);
    }
}

Il punto critico è la cattura dello snapshot in Execute(): RemoveLineCommand ricorda il testo rimosso prima di cancellarlo, rendendo possibile il ripristino.

Step 4: costruire l’Invoker con history

L’Invoker mantiene due stack: uno per l’undo e uno per il redo. Quando si esegue un nuovo comando, la redo stack viene svuotata per evitare storie ramificate incoerenti:

public class CommandInvoker
{
    private readonly Stack<ICommand> _undoStack = new();
    private readonly Stack<ICommand> _redoStack = new();

    public void ExecuteCommand(ICommand command)
    {
        command.Execute();
        _undoStack.Push(command);
        _redoStack.Clear(); // Nuova azione invalida il redo
    }

    public bool CanUndo => _undoStack.Count > 0;
    public bool CanRedo => _redoStack.Count > 0;

    public void Undo()
    {
        if (!CanUndo) return;
        var cmd = _undoStack.Pop();
        cmd.Undo();
        _redoStack.Push(cmd);
    }

    public void Redo()
    {
        if (!CanRedo) return;
        var cmd = _redoStack.Pop();
        cmd.Execute();
        _undoStack.Push(cmd);
    }

    public IEnumerable<string> GetHistory() =>
        _undoStack.Select(c => c.Description);
}

Step 5: Macro Commands (Composite)

Il Command Pattern si combina naturalmente con il Composite Pattern per costruire macro che raggruppano più operazioni atomiche:

public sealed class MacroCommand : ICommand
{
    private readonly IReadOnlyList<ICommand> _commands;

    public string Description => $"Macro ({_commands.Count} operazioni)";

    public MacroCommand(IEnumerable<ICommand> commands)
    {
        _commands = commands.ToList();
    }

    public void Execute()
    {
        foreach (var cmd in _commands)
            cmd.Execute();
    }

    public void Undo()
    {
        // L'undo avviene in ordine inverso
        for (int i = _commands.Count - 1; i >= 0; i--)
            _commands[i].Undo();
    }
}

Step 6: integrazione con Dependency Injection

In applicazioni .NET moderne, il pattern si integra perfettamente con il DI container di ASP.NET Core:

// Program.cs
builder.Services.AddSingleton<TextDocument>();
builder.Services.AddSingleton<CommandInvoker>();
builder.Services.AddTransient<DocumentCommandFactory>();

// Factory per creare comandi on-demand
public class DocumentCommandFactory
{
    private readonly TextDocument _document;

    public DocumentCommandFactory(TextDocument document)
    {
        _document = document;
    }

    public ICommand AddLine(string text) => new AddLineCommand(_document, text);
    public ICommand RemoveLine(int index) => new RemoveLineCommand(_document, index);
}

I componenti longevi (TextDocument, CommandInvoker) sono Singleton; i comandi vengono creati on-demand tramite factory e rimangono short-lived.

Errori comuni da evitare

Chi si avvicina al Command Pattern per la prima volta tende a commettere questi errori:

• Logica nel comando invece che nel Receiver: i comandi devono orchestrare, non implementare. La logica di business appartiene al Receiver, dove può essere testata in isolamento.
• Mancato snapshot dello stato per l’undo: se dimenticate di catturare lo stato prima dell’esecuzione, l’undo diventa impossibile o inaffidabile.
• Stato condiviso tra comandi: ogni comando deve essere autosufficiente. Lo stato mutabile condiviso porta a bug sottili quando i comandi vengono eseguiti in ordine diverso.
• Undo implementato in modo forzato: per operazioni genuinamente non reversibili (come l’invio di un’email), meglio lanciare un’eccezione o documentare esplicitamente il limite, piuttosto che fingere un undo inesistente.

Conclusione

Il Command Pattern è uno strumento potente e sottovalutato. Quando il vostro sistema ha bisogno di storico operazioni, undo/redo, accodamento differito o audit trail, questo pattern vi offre una soluzione elegante e testabile. La separazione netta tra Receiver (logica) e Command (orchestrazione) rende il codice mantenibile anche su larga scala.

Se state sviluppando con C# e .NET, consideratelo ogni volta che la vostra architettura richiede operazioni reversibili o la composizione di azioni complesse.

---

Fonte originale: How to Implement Command Pattern in C# – DevLeader.ca

How to Implement Command Pattern in C#: Step-by-Step Guide

Learn how to implement command pattern in C# with a step-by-step guide covering command interfaces, concrete commands, invokers, and undo/redo support.

^{Nick Cosentino (Dev Leader)}

(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.