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.

Spcnet.it

2026-04-18 20:28:35

LINQ Max e i tipi valore nullable in C#: il comportamento inatteso che causa eccezioni a runtime

Chi usa LINQ in C# con una certa frequenza prima o poi si imbatte in un comportamento del metodo Max che, a prima vista, appare del tutto irrazionale: due chiamate sintatticamente quasi identiche producono risultati radicalmente diversi, e una delle due lancia un’eccezione a runtime su una sequenza vuota. Vediamo perché accade e come risolverlo.

Il problema: Max con proiezioni su tipi diversi

Consideriamo questo tipo record:

public record WithValues(string Label, int Number, DateTimeOffset Date);

Ora proviamo a chiamare Max su un array vuoto con tre proiezioni diverse:

WithValues[] empty = [];

string? maxLabel  = empty.Max(x => x.Label);   // Restituisce null
var     maxDate   = empty.Max(d => d.Date);     // Lancia InvalidOperationException
int?    maxNumber = empty.Max(x => x.Number);   // Lancia InvalidOperationException

La firma del metodo è:

public static TResult? Max<TSource, TResult>(
    this IEnumerable<TSource> source,
    Func<TSource, TResult> selector);

Il tipo di ritorno è dichiarato come TResult? — nullable. Eppure il comportamento cambia radicalmente in base a ciò che la funzione di proiezione restituisce.

La causa: come Max distingue i tipi internamente

Internamente, l’implementazione di Max usa un test per decidere come comportarsi su una sequenza vuota:

TResult val = default;
if (val == null)
{
    // Tipo reference o nullable: restituisce null per sequenze vuote
}
else
{
    // Tipo valore non nullable: lancia eccezione per sequenze vuote
}

Questo porta a tre comportamenti distinti:

• Tipi reference (string): default(string) è null, quindi il ramo “restituisce null” viene eseguito correttamente.
• Tipi valore non nullable (int, DateTimeOffset): i loro default non sono null, quindi viene eseguito il ramo che lancia InvalidOperationException.
• Tipi valore nullable (int?, DateTimeOffset?): default(int?) è null, quindi rientra nel primo ramo e restituisce null.

Perché questo design?

Il ragionamento alla base è comprensibile: per i tipi valore, restituire il valore di default per una sequenza vuota sarebbe ambiguo. Se Max su una lista vuota di interi restituisse 0, come distinguere tra “il massimo è zero” e “la lista era vuota”? L’eccezione rimuove questa ambiguità, ma lo fa in modo sorprendente data la firma del metodo.

Il problema di fondo è storico: C# ha sviluppato la nullabilità in tre fasi distinte che non si integrano uniformemente nel codice generico:

• I tipi reference erano sempre nullable (fin dalle origini del linguaggio).
• I tipi valore nullable (Nullable<T>, ovvero T?) sono stati introdotti in C# 2.0.
• Le nullable reference types (NRT) sono arrivate in C# 8.0 come feature opzionale.

La soluzione: cast esplicito al tipo nullable

La correzione è semplice: basta fare il cast esplicito della proiezione al tipo nullable corrispondente.

// Invece di:
var maxDate    = empty.Max(d => d.Date);
int? maxNumber = empty.Max(x => x.Number);

// Usare:
DateTimeOffset? maxDate    = empty.Max(d => (DateTimeOffset?)d.Date);
int?            maxNumber  = empty.Max(x => (int?)x.Number);

Il cast forza il compilatore a inferire TResult = DateTimeOffset? (o int?), il cui default è null, e Max segue quindi il percorso corretto, restituendo null invece di lanciare un’eccezione.

Alternativa: DefaultIfEmpty

Un’altra soluzione è preporre DefaultIfEmpty prima di Max:

int maxNumber = empty
    .Select(x => x.Number)
    .DefaultIfEmpty(0)
    .Max();

Questa alternativa è utile quando si vuole un valore di fallback esplicito invece di null, ma va usata con attenzione: il valore di default deve essere scelto consapevolmente per non introdurre ambiguità semantica nel risultato.

Quando questo si manifesta in produzione

Il problema diventa insidioso quando si lavora con sequenze filtrate dinamicamente che possono risultare vuote in certi contesti, o quando il codice viene testato sempre con dati non vuoti e crasha in produzione su edge case inaspettati. Una buona pratica difensiva è usare sempre il cast a tipo nullable quando si usa Max (o Min, che ha lo stesso comportamento) su tipi valore, a meno che non si abbia la certezza assoluta che la sequenza non sarà mai vuota.

Conclusioni

Il comportamento di LINQ.Max con i tipi valore è uno di quei casi in cui l’implementazione è tecnicamente coerente, ma la firma del metodo lascia intendere qualcosa di diverso da ciò che avviene a runtime. La regola da ricordare è semplice: se la proiezione restituisce un tipo valore non nullable e la sequenza potrebbe essere vuota, usare sempre un cast esplicito a T?. Un piccolo accorgimento che previene eccezioni difficili da diagnosticare in produzione.

---

Fonte originale: LINQ Max and nullable value types (Ian Griffiths, endjin.com) — tratto dal briefing Dew Drop del 17 aprile 2026

Dew Drop – April 17, 2026 (#4649) – Morning Dew by Alvin Ashcraft

Dew Drop – April 17, 2026 (#4649)

^{Alvin A. (Morning Dew by Alvin Ashcraft)}

(in)sicurezza digitale

2026-04-18 17:18:42

Operation PowerOFF: 21 paesi coordinati smantellano 53 piattaforme DDoS-for-hire e identificano 75.000 cyberattaccanti

Ventuno paesi hanno coordinato la più vasta azione globale mai condotta contro le piattaforme DDoS-for-hire: Operation PowerOFF, culminata il 13 aprile 2026 con il sequestro di 53 domini, l’arresto di 4 amministratori, l’emissione di 25 mandati di perquisizione e l’invio di comunicazioni di allerta a oltre 75.000 utenti identificati come clienti di servizi “booter”. Europol ha coordinato l’operazione insieme all’FBI, all’NCFTA e alle forze di polizia di Europa, America e Asia-Pacifico, acquisendo accesso a database con oltre 3 milioni di account criminali.

L’ecosistema dei booter: DDoS come servizio a 10 euro al mese

I servizi booter — chiamati anche stresser nel gergo del mercato underground — sono piattaforme commerciali che vendono potenza di fuoco DDoS a chiunque sia disposto a pagare una quota mensile, tipicamente tra i 10 e i 200 dollari. Il modello di business è quello di un SaaS criminale: interfacce web con dashboard intuitive, piani tariffari differenziati per banda e durata dell’attacco, e assistenza clienti. Le vittime sono target eterogenei — siti di e-commerce, server di gaming, infrastrutture governative locali, concorrenti aziendali — il denominatore comune è la disponibilità del pagante a causare interruzioni di servizio per denaro o vendetta.

Tecnicamente, i booter operano sfruttando due modelli di amplificazione: botnet di dispositivi IoT compromessi (router SOHO, telecamere IP, NAS) e reflection amplification tramite protocolli UDP vulnerabili — DNS, NTP, SSDP, memcached — che consentono di amplificare il traffico di attacco fino a 50.000x rispetto al volume inviato. La decentralizzazione e il frequente ricorso a frontend anonimi dietro CDN rendevano queste piattaforme particolarmente resilienti ai tentativi di takedown tradizionali.

Operazione PowerOFF: storia di un’escalation investigativa

PowerOFF non è nata il 13 aprile: è il risultato di anni di indagini parallele che Europol ha progressivamente coordinato in un’unica architettura operativa. La prima fase significativa risale al dicembre 2024, quando l’operazione aveva già portato al sequestro di 27 piattaforme — tra cui zdstresser.net, orbitalstress.net e starkstresser.net — con 3 arresti e l’identificazione di oltre 300 utenti. La seconda ondata, coordinata nell’aprile 2026, ha esteso la portata dell’operazione a livello globale, coinvolgendo per la prima volta paesi come Brasile, Thailandia e Giappone.

L’elemento innovativo della fase 2026 è stata l’approccio preventivo parallelo all’enforcement: mentre gli investigatori sequestravano server e domìni, un team specializzato lanciava una campagna di awareness mirata, rimuovendo oltre 100 URL pubblicitari dai risultati dei motori di ricerca che promuovevano servizi booter, e inviando messaggi di allerta direttamente sulle blockchain delle transazioni in criptovaluta usate per pagare i servizi — una tecnica nuova che segnala un’evoluzione nell’approccio investigativo alle piattaforme crypto-monetizzate.

75.000 allerte: la strategia della deterrenza scalabile

La novità più significativa di Operation PowerOFF 2026 non è il numero di domini sequestrati, ma la scelta strategica di non arrestare la stragrande maggioranza degli utenti identificati. Le autorità hanno inviato 75.000 comunicazioni personalizzate via email e posta ordinaria agli utenti dei servizi booter — molti dei quali sono giovani che non si percepiscono come criminali — spiegando le implicazioni legali delle loro azioni e le sanzioni previste. Questa strategia di deterrenza scalabile mira a modificare il comportamento prima che si consolidi in attività criminale conclamata.

L’accesso ai database con 3 milioni di account — ottenuto tramite le operazioni di sequestro dell’infrastruttura — ha permesso alle autorità di costruire un profilo dettagliato dell’ecosistema: età media degli utenti, distribuzione geografica, modelli di pagamento, target preferiti. Questi dati alimenteranno future indagini mirate sui soggetti recidivi o con profili di rischio elevato.

Paesi partecipanti e coordinamento internazionale

L’operazione ha visto la partecipazione di: Australia, Austria, Belgio, Brasile, Bulgaria, Danimarca, Estonia, Finlandia, Germania, Giappone, Lettonia, Lituania, Lussemburgo, Paesi Bassi, Polonia, Portogallo, Svezia, Thailandia, Regno Unito e Stati Uniti. Il coordinamento tecnico è stato gestito dall’EC3 di Europol (European Cybercrime Centre), con supporto dell’Eurojust per gli aspetti giuridizionali delle richieste di mutua assistenza internazionale (MLA). Per la prima volta, paesi tradizionalmente assenti da operazioni cyber-enforcement come Brasile e Thailandia hanno contribuito con azioni di sequestro locali — segnale di una maturazione del quadro normativo e investigativo globale.

Piattaforme disrupted: infrastruttura tecnica

# Tipologie di servizi smantellati
- Booter/stresser con interfaccia web (SaaS DDoS-for-hire)
- Layer 4 flood: UDP amplification (DNS, NTP, SSDP, memcached)
- Layer 7 HTTP flood su infrastruttura botnet IoT
- Servizi di anonimizzazione del pagamento (crypto mixer integration)

# Esempi di piattaforme sequestrate in operazioni precedenti
zdstresser.net
orbitalstress.net  
starkstresser.net

# Indicatori da monitorare
- Traffico UDP anomalo su porte 53, 123, 1900, 11211
- Elevato numero di SYN senza ACK su range IP distribuiti
- Picchi di amplification ratio >100x in NetFlow/IPFIX
- Query DNS flood con domain randomization (NXDOMAIN storm)

Implicazioni per i difensori e gli operatori di rete

Il takedown di 53 piattaforme non risolve strutturalmente il problema — nuovi servizi emergeranno, spesso ospitati in giurisdizioni meno cooperative. La risposta efficace per chi gestisce infrastrutture è combinare scrubbing center upstream con BGP blackholing d’emergenza e accordi preventivi con il proprio upstream provider per la gestione di volumetric attack. La vera svolta di PowerOFF è l’approccio sistemico: colpire non solo le piattaforme, ma anche la domanda (gli utenti) e il canale di acquisizione (pubblicità sui motori di ricerca). Se l’ecosistema booter viene reso meno accessibile e percepito come più rischioso, la domanda si riduce — e con essa la viabilità economica dei servizi stessi. Per le organizzazioni esposte ad attacchi DDoS frequenti, il momento è propizio per negoziare con i provider uplink accordi di DDoS Protection Service Level Agreement, mentre il mercato dei booter attraversa una fase di disruption e riorganizzazione.

Spcnet.it

2026-04-18 12:17:19

Visual Studio Code 1.117: agenti più potenti, permessi configurabili e nuove funzioni per gli sviluppatori

Visual Studio Code continua la sua evoluzione rapida e la versione 1.117, rilasciata ad aprile 2026, porta con sé una serie di miglioramenti significativi soprattutto per chi lavora con agenti AI, gestisce sessioni di sviluppo automatizzato o vuole un controllo più fine sui permessi degli strumenti agentico. Ecco una panoramica tecnica di tutto ciò che cambia.

Agenti e strumenti AI: più controllo e precisione

La funzionalità Run VS Code Command Agent Tool è stata aggiornata con il supporto per l’allowlisting di comandi specifici. Questo significa che è ora possibile definire una lista esplicita di comandi che un agente è autorizzato ad eseguire, riducendo la superficie di rischio nelle automazioni. Le approvazioni sono ora più granulari: invece di dare un via libera generico all’agente, l’operatore può specificare esattamente cosa è consentito.

Anche la Agent Sessions View ha ricevuto attenzione: le sessioni possono ora essere ordinate per data di creazione o di aggiornamento. Chi gestisce molte sessioni parallele troverà questa funzione molto utile per navigare tra sessioni attive e recenti.

Un’altra aggiunta pratica riguarda i messaggi in coda nella chat: è ora possibile modificare un messaggio già accodato prima che venga elaborato, tramite una nuova voce “Edit” nel menu contestuale. Questo evita di dover annullare l’intera sequenza per correggere un messaggio inviato per errore.

Miglioramenti al terminale e all’output automatico

VS Code 1.117 introduce un cambiamento interessante nel modo in cui vengono gestiti i comandi terminale in background. Il completamento di un comando eseguito in background viene ora notificato come notifica di sistema, invece di apparire solo come testo inline nell’interfaccia. Questo migliora l’accessibilità e rende più evidenti i completamenti che avvengono mentre si lavora in altre finestre.

Un’altra miglioria riguarda l’integrazione agente-terminale: quando un agente invia input a un terminale, l’output del terminale viene ora incluso automaticamente nel risultato dopo un breve ritardo. In pratica, l’agente non ha più bisogno di un turno aggiuntivo per “leggere” l’output del comando — lo riceve direttamente nel flusso di risposta. Questo riduce il numero di round-trip necessari nei workflow automatizzati.

VS Code ora riconosce anche Copilot CLI, Claude Code e Gemini CLI come tipi di shell nativi, migliorando l’integrazione e il rilevamento automatico per chi utilizza questi strumenti nel terminale integrato.

Gestione dei permessi: tre modalità di auto-approvazione

Uno degli aggiornamenti più rilevanti per i team che usano VS Code in ambienti agentico è il nuovo sistema di gestione dei permessi. Vengono introdotte tre modalità di auto-approvazione nell’Agent Host:

• Default Approvals: il comportamento standard, con richiesta esplicita di approvazione per ogni azione sensibile.
• Bypass Approvals: le approvazioni vengono saltate per azioni considerate sicure nel contesto attuale.
• Autopilot (Preview): modalità completamente automatica in cui l’agente opera senza interruzioni per l’approvazione.

La modalità Autopilot persiste tra le sessioni e può essere configurata come default tramite l’impostazione chat.permissions.default. Questa flessibilità permette agli sviluppatori di scegliere il livello di supervisione appropriato in base al contesto — più controllo in produzione, più automazione in ambienti di sviluppo controllati.

Supporto per sottoagenti e team di agenti

Il protocollo Agent Host ora supporta ufficialmente sottoagenti e team di agenti. Questo apre la strada a workflow multi-agente direttamente in VS Code, dove un agente orchestratore può delegare compiti specifici ad agenti specializzati. La funzionalità si integra con le sessioni worktree e git isolation a livello di sessione, garantendo che ogni sottoagente lavori in un ambiente isolato e riproducibile.

Copilot CLI aggiunge anche la generazione di nomi di branch significativi basati sul prompt dell’utente quando crea worktree per sessioni in background. Questo rende molto più semplice identificare a cosa corrisponde ogni branch nei workflow automatizzati.

Miglioramenti all’editor: JSDoc con immagini e hover su package.json

Sul lato editor, due aggiunte migliorano sensibilmente l’esperienza per gli sviluppatori JavaScript e TypeScript:

Le immagini nei commenti JSDoc, inclusi i tag HTML <img>, vengono ora renderizzate correttamente negli hover, nei dettagli di completamento e nell’aiuto alla firma. Chi documenta componenti con screenshot o diagrammi nei commenti apprezzerà questa miglioria.

Gli hover sulle dipendenze in package.json mostrano ora sia la versione attualmente installata che l’ultima versione pubblicata su npm. Questo rende immediato capire se un pacchetto è aggiornato senza dover uscire dall’editor.

Aggiornamenti per macOS

Su macOS, l’app Agents può ora aggiornarsi autonomamente (self-update), eliminando la necessità di intervento manuale per i rilasci futuri.

Conclusioni

VS Code 1.117 consolida e affina il modello di sviluppo agentico introdotto nelle versioni precedenti. Le novità più importanti riguardano la gestione granulare dei permessi, il supporto per team di agenti e i miglioramenti al flusso terminale, tutti elementi che migliorano la produttività nei workflow automatizzati. Se state usando VS Code come ambiente per sviluppo assistito da AI, questo aggiornamento è decisamente consigliato.

---

Fonte originale: Visual Studio Code 1.117 Release Notes (Visual Studio Code Team)

Visual Studio Code 1.117

Learn what's new in Visual Studio Code 1.117 (Insiders)

^{code.visualstudio.com}

(in)sicurezza digitale

2026-04-18 08:53:59

Operation Masquerade: l’FBI smantella la rete di router compromessi dall’intelligence militare russa APT28 per il furto di credenziali Microsoft 365

Il Dipartimento di Giustizia degli Stati Uniti ha annunciato lo smantellamento di una vasta rete di router domestici e aziendali compromessi dall’Unità 26165 del GRU russo — il gruppo noto come APT28, Forest Blizzard e Fancy Bear. L’operazione, denominata Operation Masquerade, ha neutralizzato un’infrastruttura che al picco contava oltre 18.000 indirizzi IP distribuiti in 120 paesi, utilizzata per intercettare credenziali Microsoft 365 di obiettivi militari, governativi e infrastrutture critiche.

Chi è APT28: l’unità fantasma del GRU

APT28 — conosciuto anche come Forest Blizzard, Fancy Bear, Sofacy Group, Pawn Storm e Sednit — è il braccio cyber dell’85° Centro Principale dei Servizi Speciali del GRU (sigla interna: 85th GTsSS), identificato dai servizi di intelligence occidentali come Unità 26165. Attivo almeno dal 2004, il gruppo ha condotto alcune delle campagne di cyberspionaggio più audaci della storia recente: dall’interferenza nelle elezioni presidenziali statunitensi del 2016 all’attacco al Bundestag tedesco, dal DNC all’Olimpiade invernale di Pyeongchang. La caratteristica distintiva di APT28 è la capacità di operare “below the radar”, sfruttando infrastrutture di terzi per rendere l’attribuzione più complessa.

La campagna: come APT28 ha trasformato router domestici in armi di spionaggio

La campagna documentata nell’advisory FBI (PSA260407) si articola in tre fasi distinte. Il punto di ingresso iniziale ha sfruttato una botnet criminale preesistente chiamata MooBot, già attiva su centinaia di router Ubiquiti EdgeRouter con credenziali di fabbrica predefinite (ubnt/ubnt). Successivamente, nel 2025, la campagna si è espansa verso i router TP-Link attraverso lo sfruttamento della vulnerabilità CVE-2023-50224. Nella fase di picco — dicembre 2025 — oltre 18.000 indirizzi IP unici in 120 paesi comunicavano attivamente con l’infrastruttura APT28.

Fase 1: Compromissione del router

Una volta ottenuto accesso ai dispositivi — tramite credenziali predefinite o vulnerabilità note — gli operatori di APT28 installavano un malware persistente capace di sopravvivere ai riavvii del dispositivo (richiedendo un factory reset completo per la rimozione). Il router compromesso veniva quindi arruolato come nodo proxy nell’infrastruttura C2 del gruppo.

Fase 2: DNS Hijacking e Adversary-in-the-Middle

Il cuore tecnico della campagna è il DNS hijacking a livello di router — una tecnica che opera al di sotto del layer applicativo, dove gli strumenti di endpoint security tipicamente non possono intervenire. APT28 modificava le impostazioni DHCP/DNS dei router compromessi, reindirizzando le query DNS verso resolver controllati dagli attori. Un sistema di filtraggio automatizzato analizzava le richieste DNS in transito: per i target di interesse, il resolver GRU restituiva record DNS fraudolenti — in particolare per domini che emulano Microsoft Outlook Web Access — equipaggiati con certificati SSL validi per non triggerare warning nel browser della vittima.

Fase 3: Furto di credenziali M365 e NTLMv2

Le vittime che tentavano di autenticarsi su Microsoft 365 venivano reindirizzate su pagine di phishing ad alta fedeltà. Script Python personalizzati sui router compromessi validavano le credenziali in tempo reale contro i server Microsoft. Il gruppo raccoglieva password in chiaro, token di autenticazione e NTLMv2 digest — particolarmente preziosi per attacchi di pass-the-hash e relay. Parallelamente, APT28 sfruttava anche CVE-2023-23397 (vulnerabilità di Outlook per la divulgazione di hash NTLM) contro obiettivi selezionati.

Target colpiti: militare, governo, infrastrutture critiche

Secondo le agenzie di intelligence coinvolte nell’advisory congiunto — FBI, NSA, NCSC britannico e omologhi europei — i settori primariamente presi di mira includono organizzazioni governative, militari, contractor della difesa e aziende tecnologiche. I paesi con obiettivi confermati includono Repubblica Ceca, Italia, Lituania, Polonia, Ucraina, Emirati Arabi Uniti e Stati Uniti. La presenza dell’Italia nella lista conferma l’interesse persistente del GRU verso obiettivi NATO nell’Europa meridionale.

Operation Masquerade: la risposta dell’FBI

Il Dipartimento di Giustizia ha ottenuto un’autorizzazione giudiziaria (court order) per condurre un’operazione tecnica sui router compromessi negli Stati Uniti. L’FBI ha sviluppato una serie di comandi inviati direttamente ai dispositivi per: raccogliere evidenze forensi sull’attività GRU, reimpostare le configurazioni DNS ai valori legittimi, e disabilitare i meccanismi di accesso non autorizzato. Si tratta di una delle poche operazioni di law enforcement in cui l’FBI ha utilizzato autorizzazioni legali per accedere attivamente a dispositivi privati compromessi — una strategia già impiegata nella disruption di Volt Typhoon e della botnet Qakbot.

Indicatori di Compromissione (IoC)

# Vulnerabilità sfruttate
CVE-2023-50224  - TP-Link Router - Arbitrary Code Execution
CVE-2023-23397  - Microsoft Outlook - NTLM Hash Disclosure

# Hardware primariamente compromesso
- Ubiquiti EdgeRouter (credenziali default: ubnt/ubnt)
- TP-Link SOHO Routers (vari modelli)

# Indicatori comportamentali
- Modifiche DNS/DHCP non autorizzate sulle interfacce LAN
- Traffico DNS verso resolver non configurati dall'utente
- Certificati SSL unexpected per domini M365/OWA
- Connessioni NTLMv2 verso IP non aziendali
- Presenza di script Python su filesystem router (via SSH/Telnet)

# Tecniche MITRE ATT&CK
T1584.001  - Compromise Infrastructure: Domains
T1557.003  - Adversary-in-the-Middle: DHCP Spoofing  
T1040     - Network Sniffing
T1110.001  - Brute Force: Password Guessing
T1566.002  - Phishing: Spearphishing Link

Cosa devono fare i difensori

La natura della minaccia — che opera a livello di infrastruttura di rete anziché su endpoint — la rende particolarmente insidiosa per le organizzazioni che non monitorano attivamente il traffico DNS. Le contromisure prioritarie includono: aggiornare il firmware di tutti i dispositivi SOHO, cambiare immediatamente le credenziali predefinite, disabilitare la gestione remota esposta a Internet, e implementare il DNS-over-HTTPS (DoH) o DNSSEC per resistere a manomissioni DNS. Per le organizzazioni con accesso remoto, è fondamentale imporre MFA phishing-resistant (FIDO2/passkey) su tutti i servizi M365, poiché token e password rubati tramite AitM diventano inutilizzabili senza il secondo fattore hardware. Il monitoraggio di anomalie NTLM — in particolare tentativi di autenticazione verso IP esterni — dovrebbe essere prioritario nei SIEM aziendali.

(in)sicurezza digitale

2026-04-17 13:43:48

Laptop farm DPRK smantellata: 9 anni a Kejia Wang, infiltrati in oltre 100 aziende USA e rubato codice ITAR a un defense contractor

Si parla di:
Toggle

• L’architettura dello schema: shell company, KVM e laptop farm
• Cifre, pene e recuperi
• Perché questa sentenza è uno spartiacque
• Segnali operativi per HR, IT e SOC
• Implicazioni per il mercato europeo

Il Dipartimento di Giustizia statunitense ha inflitto il 15 aprile 2026 le prime pene detentive significative per un operatore interno del cosiddetto schema “IT worker” nordcoreano: Kejia “Tony” Wang, 42 anni, è stato condannato a 108 mesi di reclusione; Zhenxing “Danny” Wang, 39 anni, a 92 mesi. I due newjerseyani hanno facilitato l’infiltrazione di lavoratori remoti DPRK in oltre 100 aziende americane — molte Fortune 500 — utilizzando identità rubate di almeno 80 cittadini statunitensi e gestendo dal proprio territorio decine di laptop aziendali per mascherare la geolocalizzazione dei tecnici di Pyongyang. Bottino complessivo per il regime: oltre 5 milioni di dollari, più il furto di file ITAR-controlled a un fornitore militare californiano.

L’architettura dello schema: shell company, KVM e laptop farm

La sentenza chiude una delle indagini più significative sulla campagna nordcoreana di generazione di valuta pregiata via lavoro IT remoto, un filone operativo che analisti e Tesoro USA tracciano almeno dal 2018 e che dopo la pandemia ha trovato nel “Great Remote Work” il proprio vettore ideale. Lo schema gestito dai due Wang si articolava su tre piani.

Piano uno: identità sintetica “domestica”. I cospiratori hanno registrato tre shell company statunitensi — Tony WKJ LLC, Hopana Tech LLC e Independent Lab LLC — con relativi siti web e conti bancari, per proiettare verso le aziende clienti l’illusione di un fornitore o candidato domestico legittimo. A questo si sommano le identità rubate: dati anagrafici, SSN e documenti di 80+ cittadini americani, usati per creare CV, profili LinkedIn e verifiche I-9 superficialmente credibili. Gli stipendi netti venivano incassati sui conti delle shell company e riciclati verso la Corea del Nord attraverso una catena di bonifici e criptovalute.

Piano due: laptop farm fisicamente residente negli USA. La vera innovazione operativa è qui. Le aziende vittima spedivano i computer aziendali all’indirizzo del finto dipendente statunitense. Zhenxing Wang ha ospitato decine di questi laptop nella propria abitazione nel New Brunswick, collegandoli a switch KVM-over-IP o soluzioni simili che consentivano ai lavoratori DPRK reali — fisicamente in Nord Corea, Cina o Russia — di controllarli da remoto come se stessero digitando davanti alla macchina. Dal punto di vista dei controlli aziendali, il traffico usciva da un ISP residenziale del New Jersey, l’IP VPN risultava US-based, gli orari di lavoro corrispondevano al fuso orientale: nessuno degli allarmi standard su geo-velocity o impossibile travel scattava. Kejia Wang ha supervisionato l’operazione gestendo la rete complessiva di laptop farm.

Piano tre: monetizzazione e spionaggio opportunistico. Oltre allo stipendio, i lavoratori DPRK sottraevano proprietà intellettuale quando l’occasione si presentava. In un caso documentato dalla procura, gli operativi nordcoreani hanno esfiltrato source code coperto dalle International Traffic in Arms Regulations (ITAR) da un defense contractor californiano — trattamento normativo riservato a tecnologie militari sensibili il cui trasferimento all’estero è soggetto a controllo federale. Un passaggio che trasforma uno schema di frode sul lavoro in un episodio di controspionaggio tecnologico.

Cifre, pene e recuperi

• Pena Kejia Wang: 108 mesi (9 anni). Guilty plea settembre 2025.
• Pena Zhenxing Wang: 92 mesi (7 anni e 8 mesi). Guilty plea gennaio 2026.
• Capi d’imputazione: cospirazione per frode telematica e cospirazione per riciclaggio di denaro.
• Periodo dell’operazione: 2021 – ottobre 2024.
• Aziende colpite: oltre 100, distribuite in 27 Stati e District of Columbia; fra queste, diverse Fortune 500.
• Identità rubate: almeno 80 cittadini USA.
• Ricavo generato per la DPRK: oltre 5 milioni di dollari.
• Danni economici alle aziende vittime: oltre 3 milioni di dollari in costi legali, investigazioni forensi e remediation.
• Compenso incassato dai facilitator USA: 696.000 dollari complessivi.
• Confisca ordinata: 600.000 dollari (due terzi già versati).

Nove ulteriori co-cospiratori risultano latitanti. Il Dipartimento di Stato ha emesso una taglia da 5 milioni di dollari per informazioni che portino all’identificazione e all’arresto dei soggetti fuggiti.

Perché questa sentenza è uno spartiacque

La campagna IT worker DPRK non è una novità per chi segue la threat intel: FBI, Treasury OFAC, Mandiant, SentinelOne, DTEX, Unit 42 e diversi ricercatori indipendenti ne parlano da anni. Ma le condanne in doppia cifra di anni di carcere, combinate alla confisca e alla ricompensa statale per i latitanti, segnano una discontinuità rispetto alla fase precedente, nella quale il ciclo tipico era identificazione → sanzione OFAC → rimozione da piattaforme freelance. Ora il DOJ sta dimostrando la capacità di smontare anche il nodo domestico — i facilitator americani senza i quali l’intera catena di laptop farm crolla.

Come ha sintetizzato Michael Barnhart, investigatore di DTEX che da anni traccia la materia, «non tutti gli IT worker nordcoreani sono hacker, ma ogni hacker nordcoreano è stato, o può essere, un IT worker». La frase coglie la funzione strategica dello schema: non semplice fraud, ma un bacino di accessi privilegiati ai sistemi target che, al momento opportuno, può essere riconvertito in operazioni di cyberspionaggio o di sabotaggio. Il furto ITAR al fornitore della difesa californiano ne è l’esempio paradigmatico.

Segnali operativi per HR, IT e SOC

Il modello DPRK costringe le aziende a ripensare i controlli di assunzione remota. Diverse segnalazioni convergenti di FBI e vendor di threat intel delineano pattern ricorrenti che i team di HR security e IT dovrebbero codificare:

• Video interview con volto non chiaro, ritardi audio anomali, rifiuto di accendere camera, uso di filtri AI di beauty/avatar.
• Indirizzi di consegna laptop in zone residenziali con elevata densità di precedenti indirizzi di altre assunzioni remote (pattern “laptop farm”).
• Orari di attività incoerenti con il fuso orario dichiarato, accessi VPN che sembrano US ma con fingerprint di sistema (timezone locale, lingua UI, layout tastiera) non coerenti.
• Utilizzo sistematico di VDI personali, RMM o sessioni RDP nidificate che introducono un hop aggiuntivo tra l’IP endpoint e il sistema aziendale.
• Richieste anomale di consegna del laptop a indirizzi diversi da quello di assunzione nei primi giorni.
• Pattern di pagamento verso piattaforme crypto o intermediari esteri anziché conti bancari personali.

Dal lato SOC, conviene integrare regole di detection che confrontino la geolocalizzazione IP dell’endpoint corporate con la timezone effettiva del sistema operativo e con i pattern di input (ritmo di digitazione, layout tastiera attiva): molte laptop farm sono state smascherate proprio da anomalie fra rete e sistema, non dalla sola analisi di rete.

Implicazioni per il mercato europeo

La giurisdizione della condanna è americana, ma il modello è globale. Diverse società europee — inclusi fornitori italiani di servizi IT — hanno già ammesso di aver assunto, in buona fede, lavoratori remoti che rispondevano al profilo DPRK. Il quadro regolatorio UE (NIS2, DORA per il finanziario) non prevede ancora controlli specifici sul rischio “insider nordcoreano”, ma le raccomandazioni FBI e del CISA restano applicabili anche al di qua dell’Atlantico e il CERT italiano ha già diffuso alert generici sul tema. Chi opera con infrastrutture critiche o tecnologie dual-use dovrebbe considerare la due diligence sui contractor remoti un controllo non negoziabile, al pari della verifica antimafia per i subappaltatori fisici.

Laptop farm DPRK smantellata: 9 anni a Kejia Wang, infiltrati in oltre 100 aziende USA e rubato codice ITAR a un defense contractor - (in)sicurezza digitale

Il DOJ ha inflitto le prime pene a doppia cifra di anni a facilitator statunitensi dello schema 'IT worker' nordcoreano.

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

informapirata

2026-03-18 20:07:50

Come trasferire un account Mastodon su Poliversity.it?

Siccome alcuni utenti ci chiedono come fare per trasferire il loro account mastodon tradizionale sulla nostra istanza potenziata, abbiamo scritto delle brevi note esplicative
informapirata.it/2026/03/18/co…

Come trasferire un account Mastodon su Poliversity.it?

Siccome alcuni utenti ci chiedono come fare per trasferire il loro account mastodon tradizionale sulla nostra istanza potenziata, abbiamo scritto delle brevi note…

^{informapirata}

Spcnet.it

2026-04-17 13:45:21

Azure MCP in Visual Studio 2022: 230+ strumenti Azure direttamente nell’IDE

Addio alle estensioni: Azure MCP è ormai integrato in VS2022

Fino a poco tempo fa, usare gli strumenti Azure MCP in Visual Studio 2022 richiedeva di cercare un’estensione dal Marketplace, installare un file VSIX, riavviare Visual Studio, e sperare che tutto funzionasse. Se qualcosa andava storto, dovevi disinstallare e reinstallare completamente.

Oggi, Microsoft ha integrato nativamente Azure MCP come parte del workload Azure in Visual Studio 2022. Niente più estensioni separate da gestire, niente più problemi di versione mismatch, un unico percorso di aggiornamento. Se hai già il workload Azure installato, accedi a 230+ strumenti Azure con un semplice click.

Cosa è cambiato realmente

La differenza è fondamentale: prima avresti visto questo flusso:

1. Aprire Visual Studio Marketplace
2. Cercare “GitHub Copilot for Azure (VS 2022)”
3. Scaricare e installare l’estensione VSIX
4. Riavviare Visual Studio
5. Sperare che tutto funzioni

Ora il flusso è semplicemente:

1. Avere il workload Azure installato (già incluso in tante installazioni di VS2022)
2. Abilitare il server Azure MCP una volta in Copilot Chat
3. Usare 230+ strumenti Azure direttamente nel tuo IDE

I vantaggi di questa integrazione

1. Zero attrito

Nessun passo di installazione aggiuntivo. Azure MCP arriva automaticamente quando aggiorni Visual Studio, esattamente come gli altri componenti del tuo IDE.

2. Aggiornamenti sincronizzati

La versione di Azure MCP Server viene aggiornata insieme a Visual Studio durante i rilasci regolari. Non ci sono più versioni non allineate tra l’estensione e l’IDE.

3. 230+ strumenti per 45 servizi Azure

Gli strumenti Azure MCP coprono praticamente l’intero ecosistema Azure, da servizi core come Compute e Storage a soluzioni avanzate come Cognitive Services e Machine Learning.

Cosa puoi fare con Azure MCP Tools

Imparare

Chiedi a Copilot Chat informazioni su servizi Azure, best practices, e pattern architetturali direttamente nell’IDE:

// In Copilot Chat:
"Come architettare un'applicazione scalabile su Azure per 1 milione di utenti?"
"Qual è la differenza tra Azure Service Bus e Azure Queue Storage?"

Progettare e sviluppare

Ricevi raccomandazioni su quali servizi Azure usare e genera configurazioni pronte per il tuo codice:

// Copilot suggerisce:
// "Per una web app ad alta concorrenza, consiglio Azure App Service con SQL Database
// e Redis Cache. Vuoi che generi il bicep template?"

Deployare

Provisiona risorse Azure e distribuisci l’applicazione senza lasciare Visual Studio:

// "Crea un'App Service su eastus con auto-scaling da 2 a 10 istanze"
// Copilot esegue i comandi Azure CLI direttamente

Troubleshooter

Accedi a log, verifica lo stato delle risorse, e diagnostica problemi in produzione:

// "Controlla gli ultimi errori nella mia Function App 'MyProcessorApp'"
// Copilot legge i log da Application Insights

Come iniziare

Prerequisiti

• Visual Studio 2022 (versione recente)
• Workload Azure installato
• GitHub Copilot Chat abilitato
• Credenziali Azure configurate localmente

Passaggi

1. Apri GitHub Copilot Chat in Visual Studio
2. Cerca la sezione “Tools” (Strumenti)
3. Abilita “Azure MCP Server”
4. Inizia a scrivere prompt relativi ad Azure

Casi d’uso reali per sviluppatori italiani

Startup e PMI con risorse IT limitate: Usare Copilot + Azure MCP elimina la necessità di un DevOps engineer separato per compiti di infrastruttura semplici.

Team già in Azure: Se usi già servizi come Azure App Service, SQL Database, o Azure Functions, gli strumenti MCP ti permettono di gestirli senza alternare tra Visual Studio e il portale Azure.

Development in Cloud: Con Azure MCP integrato, puoi debuggare, deployare, e troubleshootare applicazioni cloud interamente dall’IDE, migliorando la produttività.

Conclusione

L’integrazione nativa di Azure MCP in Visual Studio 2022 è un esempio di come Microsoft continua a eliminare frizioni dai workflow degli sviluppatori. Non è una feature entusiasmante sulla carta, ma nella pratica quotidiana risparmia tempo e riduce la complessità gestionale. Per qualsiasi team che sviluppa su Azure, abilitare Azure MCP in Copilot Chat dovrebbe essere una delle prime cose da fare.

Fonte: Microsoft Visual Studio Blog – Azure MCP Tools Now Ship Built Into Visual Studio 2022

Azure MCP tools now ship built into Visual Studio 2022 — no extension required - Visual Studio Blog

Azure MCP tools are now built into Visual Studio 2022 as part of the Azure development workload — no separate extension to find, install, or update.

^{Yun Jung Choi (Visual Studio Blog)}