(in)sicurezza digitale

2026-05-10 10:07:02

Silver Fox lancia ABCDoor: spear phishing con loader Rust personalizzato contro India e Russia, nuova backdoor Python in campo

Tra dicembre 2025 e febbraio 2026, il gruppo APT di matrice cinese noto come Silver Fox ha lanciato due ondate coordinate di spear phishing contro organizzazioni in India e Russia, sfruttando esche a tema fiscale costruite ad hoc per ciascun paese. Il vettore tecnico è un loader Rust modificato — una versione bespoke del framework open source RustSL — che distribuisce ValleyRAT (aka Winos 4.0) insieme a una backdoor Python finora inedito, denominato ABCDoor. La ricerca è stata pubblicata da Kaspersky Securelist e ripresa da The Hacker News il 4 maggio 2026. Più di 1.600 email di phishing sono state registrate tra inizio gennaio e inizio febbraio, con organizzazioni impattate nei settori industriale, consulenza, retail e trasporti.

Il profilo di Silver Fox: doppio binario tra cybercrime e spionaggio

Silver Fox è un gruppo APT cinese attivo almeno dal 2024, documentato inizialmente per campagne contro obiettivi in Cina, poi espanso verso Taiwan, Giappone, India e Russia. Secondo l’analisi di S2W, il gruppo ha sviluppato un «dual-track operational model» che conduce simultaneamente attività opportunistiche su larga scala — tipiche del cybercrime finanziario — e operazioni di spionaggio più mirate. L’adozione di lure personalizzate per ciascun paese bersaglio, con riferimenti puntuali ai sistemi fiscali locali, indica un livello di intelligence preliminare coerente con un’operazione state-sponsored o comunque sostenuta da risorse significative.

La catena d’attacco: phishing, RustSL, ValleyRAT, ABCDoor

Fase 1 — Delivery via phishing fiscale

Le email di phishing impersonano comunicazioni ufficiali dell’Income Tax Department of India (dicembre 2025) e successivamente dell’equivalente russo (gennaio 2026). Il messaggio contiene un PDF allegato con due link cliccabili che reindirizzano al download di un archivio ZIP o RAR ospitato su abc.haijing88[.]com. All’interno dell’archivio si trova un eseguibile che si maschera da PDF. In alcune varianti della campagna di dicembre, il codice malevolo è stato incorporato direttamente nell’allegato email, saltando il redirect esterno.

Fase 2 — RustSL loader: geofencing e anti-analysis

L’eseguibile è una versione modificata di RustSL, un framework open source per shellcode loader e bypass degli antivirus scritto in Rust. Silver Fox ha personalizzato il codice sorgente pubblicamente disponibile su GitHub, aggiungendo funzionalità non presenti nell’originale:

• Geofencing per paese: la versione originale di RustSL supporta solo la Cina come paese bersaglio; la variante Silver Fox estende la lista a India, Indonesia, Sud Africa, Russia e Cambogia (con versioni successive che aggiungono il Giappone). Il loader verifica la geolocalizzazione prima di procedere, abortendo l’esecuzione in caso di mismatch.
• Rilevamento di VM e sandbox: controlli ambientali standard per ostacolare l’analisi dinamica in ambienti di ricerca.
• Phantom Persistence: una variante del loader utilizza una tecnica di persistenza documentata per la prima volta nel giugno 2025 come «Phantom Persistence». Il meccanismo intercetta il segnale di shutdown del sistema, blocca la normale sequenza di spegnimento e forza un riavvio simulando un aggiornamento applicativo. Al successivo avvio dell’OS, il loader viene eseguito automaticamente.

# Infrastruttura C2 identificata
abc.haijing88[.]com          — hosting archivi payload
login-module.dll_bin         — componente core C2 di ValleyRAT
# Country list RustSL personalizzato (pre-19 gennaio 2026)
IN, ID, ZA, RU, KH
# Versioni successive aggiungono:
JP

Fase 3 — ValleyRAT (Winos 4.0)

Il payload crittografato scompattato da RustSL è ValleyRAT, noto anche come Winos 4.0, un framework malware modulare già utilizzato da Silver Fox in campagne precedenti. Il componente core, denominato login-module.dll_bin, gestisce le comunicazioni C2, l’esecuzione di comandi remoti e il recupero ed esecuzione di moduli aggiuntivi. È su questo layer modulare che viene distribuito ABCDoor.

Fase 4 — ABCDoor: la nuova backdoor Python

ABCDoor è una backdoor Python finora inedita, presente nell’arsenale di Silver Fox dal 19 dicembre 2024 e utilizzato in attacchi a partire da febbraio-marzo 2025. Viene distribuita come modulo personalizzato di ValleyRAT, dopo un secondo controllo di geofencing che filtra ulteriormente il target. Le capacità operative documentate da Kaspersky includono:

• Persistenza e aggiornamento/rimozione autonomo del backdoor
• Cattura di screenshot
• Controllo remoto di mouse e tastiera
• Operazioni sul file system (lettura, scrittura, esecuzione)
• Gestione dei processi di sistema
• Esfiltrazione del contenuto degli appunti (clipboard)
• Comunicazione C2 via HTTPS con server esterno

In varianti più recenti, osservate a partire da novembre 2025, ABCDoor viene distribuito anche tramite un loader JavaScript distribuito all’interno di archivi SFX (self-extracting) contenuti in ZIP allegati a email di phishing — un vettore alternativo che non richiede RustSL come intermediario.

Distribuzione geografica e settori impattati

Il maggior numero di attacchi è stato rilevato in India, Russia e Indonesia, seguiti da Sud Africa e Giappone. I settori più colpiti nelle ondate di gennaio-febbraio 2026 sono stati industriale, consulenza, retail e trasporti. La scelta di bersagliare contemporaneamente India e Russia — paesi con rapporti complessi con la Cina sia a livello diplomatico che commerciale — suggerisce un obiettivo di intelligence economica e politica piuttosto che un’operazione puramente finanziaria.

Connessione con campagne precedenti

Silver Fox aveva già utilizzato ValleyRAT in campagne precedenti, tipicamente contro obiettivi in Asia orientale. L’introduzione di RustSL come loader — con personalizzazioni sofisticate del codice sorgente open source — e la comparsa di ABCDoor come modulo aggiuntivo indicano un’evoluzione significativa delle capacità tecniche del gruppo. La tecnica di Phantom Persistence, che sfrutta il meccanismo di Windows per gli aggiornamenti che richiedono riavvio, è particolarmente interessante per la sua capacità di sopravvivere ai controlli di startup standard.

IoC e indicatori di compromissione

# Dominio C2 principale
abc.haijing88[.]com
# File chiave da monitorare
login-module.dll_bin        — componente core ValleyRAT C2
RustSL variants             — loader con geofencing integrato
# Pattern comportamentali (Phantom Persistence)
- Intercettazione segnale WM_QUERYENDSESSION/WM_ENDSESSION
- Registrazione come "pending file rename operation" al riavvio
- Esecuzione al boot mascherata da aggiornamento applicativo
# Vettore email
- Mittente che impersona Income Tax Department (India) o equivalente russo
- Allegato PDF con link a haijing88[.]com
- Archivio ZIP/RAR con eseguibile che simula PDF

Due righe per i difensori

• Bloccare il dominio abc.haijing88[.]com nei proxy web e nei firewall di uscita.
• Monitorare il comportamento di shutdown: processi che intercettano WM_QUERYENDSESSION o modificano PendingFileRenameOperations nel registry durante lo shutdown sono indicatori forti di Phantom Persistence.
• Email gateway: filtrare allegati PDF con link a domini registrati di recente e archivi SFX annidati in ZIP. Le esche fiscali sono stagionali ma prevedibili.
• EDR con visibilità sulle tecniche LotL: ABCDoor usa funzioni di sistema standard per operazioni di file system e controllo remoto; rilevarlo richiede behavioral analytics e non solo firma.
• Sandboxing con geolocalizzazione autentica: il geofencing di RustSL aborta in ambienti non corrispondenti ai paesi target. Sandbox configurate con IP di geolocalizzazione neutri potrebbero non triggerare il payload. Usare VPN con IP indiano, russo o indonesiano per l’analisi dinamica.

La campagna Silver Fox conferma una tendenza in atto: i gruppi APT cinesi stanno diversificando geograficamente i propri bersagli ben oltre i tradizionali obiettivi in Asia orientale, e stanno investendo nello sviluppo di tooling personalizzato — loader Rust bespoke, backdoor Python inediti, tecniche di persistenza innovative — che rende inefficaci le soluzioni di detection basate esclusivamente su signature statiche.

(in)sicurezza digitale

2026-05-09 17:44:54

Salt Typhoon nella PA italiana: Sistemi Informativi di IBM violata per due settimane, il cyberspionaggio cinese entra nella supply chain dello Stato

Nelle prime ore del 3 maggio 2026, la notizia di un’intrusione ai danni di Sistemi Informativi — la società romana controllata al 100% da IBM Italia — ha attraversato le redazioni in modo fulmineo. Dietro all’attacco, secondo le ricostruzioni convergenti di più fonti e con la pista ancora aperta per le autorità inquirenti, ci sarebbe probabilmente, voce poi smentita, Salt Typhoon: il gruppo APT riconducibile all’apparato di sicurezza della Repubblica Popolare Cinese, già responsabile della violazione di nove operatori telecom statunitensi tra cui AT&T e Verizon. Questa volta, però, il bersaglio non è un’infrastruttura straniera: è il cuore tecnologico della Pubblica Amministrazione italiana. Doveroso ricordare che al momento, per quanto comunicato dall’azienda e per la posizione di IBM, l’attacco ha avuto successo per Sistemi Informativi SRL, senza colpire la supply chain sensibile e strategica che adesso andremo ad analizzare. Questo significa che i sistemi IBM al di fuori di Sistemi Informativi restano non coinvolti. Ma vediamo di che perimetro stiamo parlando.

Chi è Sistemi Informativi e perché è un bersaglio critico

Fondata nel 1979 e con sede a Roma, Sistemi Informativi opera come system integrator nei segmenti più sensibili della trasformazione digitale italiana. Tra i suoi committenti figurano INPS, INAIL, diversi ministeri, banche, operatori delle telecomunicazioni, aziende del comparto energetico e numerosi soggetti impegnati nelle iniziative del Piano Nazionale di Ripresa e Resilienza, dalla sanità digitale al cloud nazionale. Con circa 800 dipendenti, la società rappresenta uno snodo critico: compromettere un solo integrator di questa portata significa, in linea di principio, ottenere visibilità su contratti pubblici, credenziali di accesso, dati di milioni di cittadini, configurazioni di rete e dipendenze applicative di enti distanti per missione e per settore.

È esattamente il tipo di superficie d’attacco che le campagne di cyberspionaggio statale ricercano da anni. Non il rumore dell’esfiltrazione massiva, ma la visibilità silenziosa su un ecosistema intero.

La timeline dell’incidente

L’intrusione sarebbe avvenuta circa due settimane prima della sua scoperta e rivelazione pubblica, fissando l’inizio della compromissione intorno alla metà di aprile 2026. Una finestra temporale coerente con il modus operandi di Salt Typhoon, che predilige la persistenza silenziosa e l’esfiltrazione progressiva dei dati all’azione rumorosa e distruttiva tipica del ransomware.

• 3 maggio 2026: la testata Repubblica.it pubblica l’anticipazione dell’attacco. Il sito ufficiale di Sistemi Informativi risulta irraggiungibile.
• Sera del 3 maggio: IBM diffonde un comunicato ufficiale confermando l’intrusione, l’attivazione dei protocolli di incident response e il coinvolgimento di specialisti interni ed esterni. I sistemi sono stati stabilizzati, i servizi ripristinati.
• 3-4 maggio: il Ministro per la Pubblica Amministrazione Paolo Zangrillo dichiara che «tutti gli attori istituzionali competenti stanno portando avanti le procedure previste dalla normativa» e che ACN ha avviato ogni azione necessaria per definire origine e impatto dell’attacco.
• 5-6 maggio 2026: la Procura Antiterrorismo di Roma, coordinata dal procuratore Francesco Lo Voi, apre un fascicolo ipotizzando il reato di accesso abusivo a sistema informatico.
• 6 maggio: IBM fornisce un comunicato aggiuntivo precisando: «Ad oggi, non riteniamo che questa attività sia attribuibile a Salt Typhoon». La pista resta però aperta per gli investigatori.

Il profilo di Salt Typhoon: alias, TTP e campagne note

Salt Typhoon — tracciato anche come OPERATOR PANDA, RedMike, UNC5807, GhostEmperor, Earth Estries (Trend Micro), UNC2286 (Mandiant) e FamousSparrow (ESET) — è un cluster di attività malevole documentato nel joint advisory AA25-239A pubblicato dalla CISA il 27 agosto 2025, sottoscritto da NSA, FBI, Department of Defense Cyber Crime Center e partner internazionali tra cui l’Italia. L’advisory riconduce il cluster a tre aziende tecnologiche cinesi ritenute fornitrici del Ministero per la Sicurezza dello Stato e dell’Esercito Popolare di Liberazione: Sichuan Juxinhe Network Technology, Beijing Huanyu Tianqiong Information Technology e Sichuan Zhixin Ruijie Network Technology.

L’attribuzione formale data l’inizio delle operazioni almeno al 2021, mentre le prime ricostruzioni dell’industria ne collocano l’attività già al 2019. I settori bersaglio privilegiati sono le telecomunicazioni, la pubblica amministrazione, i trasporti, il comparto alberghiero e la difesa. La logica operativa è quella della raccolta di intelligence di lungo periodo, non dell’estorsione finanziaria: non distruggere, ma sapere, e sapere a lungo.

Vettori d’attacco e strumenti

Il joint advisory CISA chiarisce un aspetto tecnico rilevante: Salt Typhoon non utilizza in modo sistematico falle zero-day, ma sfrutta vulnerabilità CVE pubblicamente note e già corrette dai vendor, in danno di organizzazioni che non hanno applicato gli aggiornamenti. Tra le vulnerabilità prioritariamente sfruttate:

CVE-2024-21887 / CVE-2023-46805 — Ivanti Connect Secure e Policy Secure
CVE-2024-3400              — Palo Alto Networks PAN-OS GlobalProtect
CVE-2023-20198 / CVE-2023-20273 — Cisco IOS XE
CVE-2018-0171              — Cisco IOS e IOS XE

Sul versante del payload, il gruppo ricorre a utility come JumbledPath, capace di catturare il traffico di rete su dispositivi Cisco compromessi attraverso catene di jump host, e impiega tecniche Living off the Land (LotL) in cui l’attività malevola si confonde con il traffico legittimo prodotto da strumenti già presenti sul target. In Europa, Darktrace ha documentato nell’ottobre 2025 un’intrusione contro un grande operatore telecom europeo ottenuta sfruttando CVE su Citrix NetScaler Gateway, con movimento laterale verso host Citrix VDA, mascheramento tramite SoftEther VPN e installazione del backdoor SNAPPYBEE via DLL sideloading.

Supply chain della PA: il vero punto debole strutturale

L’episodio italiano si inserisce in un pattern consolidato. Negli ultimi due anni, gli attori statali ostili hanno spostato il fuoco dai bersagli finali ai loro fornitori tecnologici. Compromettere un fornitore unico che funge da snodo per decine di clienti istituzionali è un investimento offensivo di altissima resa. La PA italiana è esposta a una concentrazione di rischio strutturale: il numero ridotto di system integrator in grado di gestire progetti di scala nazionale crea un punto di accumulo della fiducia che, se compromesso, propaga la violazione attraverso l’intera filiera senza ulteriori intrusioni dirette.

I contratti pubblici raramente prevedono requisiti di sicurezza commisurati al ruolo strategico del fornitore: clausole di security by design, audit indipendenti, threat hunting continuo, segmentazione di rete tra ambienti di clienti diversi, gestione strutturata delle identità privilegiate. Il caso Sistemi Informativi imporrà, con ogni probabilità, una revisione profonda di queste pratiche per i fornitori di soggetti essenziali e importanti ai sensi della NIS2.

NIS2 e D.Lgs. 138/2024: il primo banco di prova reale

L’incidente cade nel primo quadrimestre di piena operatività del nuovo regime di notifica degli incidenti significativi introdotto dalla NIS2, recepita con il D.Lgs. 138/2024 e pienamente vigente dal 1° gennaio 2026. I soggetti essenziali e importanti devono trasmettere al CSIRT Italia una pre-notifica entro 24 ore dall’evidenza dell’incidente, una notifica completa entro 72 ore e una relazione finale entro un mese. Il caso Sistemi Informativi è il primo banco di prova di rilievo nazionale per l’intero sistema: come vengono gestiti gli adempimenti, con quale coordinamento tra ACN, Garante e operatori, con quali tempi e con quale trasparenza diventerà un precedente operativo per il sistema.

Salt, Volt, Flax: la pressione cinese sull’Europa è sistemica

L’incidente non è un episodio isolato: è il segmento europeo di una pressione sistemica articolata su più fronti. Salt Typhoon si concentra sull’intercettazione delle comunicazioni e sulla raccolta di intelligence presso carrier e fornitori IT. Volt Typhoon mira a posizionare implant nelle infrastrutture critiche civili statunitensi in una logica di prepositioning per scenari di crisi. Flax Typhoon, sanzionato dall’OFAC, costruisce botnet di dispositivi compromessi utilizzabili a copertura di ulteriori operazioni. La sovrapposizione delle tre campagne disegna un’architettura di pressione nella quale spionaggio, sabotaggio potenziale e infrastruttura offensiva convivono e si rafforzano reciprocamente.

Indicazioni pratiche per i difensori

• Patch management aggressivo sui perimeter device: le CVE sfruttate da Salt Typhoon sono note e corrette. La finestra di esposizione si chiude solo applicando gli aggiornamenti. Priorità assoluta a Ivanti, Palo Alto PAN-OS, Cisco IOS XE.
• Network segmentation e Zero Trust: in ambienti multi-cliente come quelli degli integrator, la segmentazione rigida tra tenant è l’unico modo per contenere il movimento laterale post-compromissione.
• Threat hunting sulle appliance perimetrali: rilevare JumbledPath e tecniche LotL richiede visibilità sul traffico di rete a livello di dispositivo, non solo sugli endpoint. NetFlow, logging di sistema e behavioral analytics sono prerequisiti.
• Revisione dei contratti con fornitori strategici: includere requisiti minimi di sicurezza, diritto di audit e obblighi di incident notification con tempistiche allineate alla NIS2.
• Condivisione di threat intelligence con CSIRT Italia: segnalare tempestivamente IoC e pattern d’attacco contribuisce alla difesa collettiva del sistema-Paese.

L’attacco di Salt Typhoon a IBM Italia non si misura soltanto dalla quantità di dati eventualmente esfiltrati, che resta a oggi non quantificabile. Il suo significato è strategico: conferma che la frontiera dell’attacco si è spostata sui fornitori unici di servizi pubblici, che i vettori d’ingresso più produttivi restano le appliance perimetrali con CVE pubblicate ma non corrette, e che la persistenza silenziosa — non il ransomware — è la firma delle operazioni che contano davvero.

Spcnet.it

2026-05-08 18:24:40

CQRS senza MediatR: implementare Command e Query handler in .NET con il DI container

Per anni, aprire un nuovo progetto .NET significava quasi automaticamente aggiungere una dipendenza: dotnet add package MediatR. La libreria di Jimmy Bogard è diventata così sinonimo di CQRS nell’ecosistema .NET che molti sviluppatori faticavano a distinguere il pattern dall’implementazione.

Poi MediatR è passato a una licenza commerciale. Ogni team che aveva costruito la propria architettura intorno ad essa si è trovato a fare la stessa domanda: abbiamo davvero bisogno di questa libreria?

Questo articolo non è una critica a MediatR né al suo autore — la libreria ha plasmato il modo in cui una generazione di sviluppatori .NET pensa agli handler, alle pipeline e alla separazione delle responsabilità. Il cambio di licenza è semplicemente un’opportunità per guardare cosa c’è sotto, e rendersi conto di quanto poco richieda realmente una libreria esterna.

Cos’è davvero CQRS

Command Query Responsibility Segregation ha due componenti fondamentali:

• Commands: modificano lo stato. Hanno effetti collaterali. Possono restituire un risultato, ma il loro scopo primario è modificare il sistema.
• Queries: leggono lo stato. Non hanno effetti collaterali. Restituiscono dati e nient’altro.

È tutto qui. Il dispatcher, gli handler, i pipeline behavior sono dettagli implementativi. Nessuno di essi richiede una libreria. Il DI container di .NET ha già tutto il necessario per implementare CQRS in modo pulito e testabile.

L’astrazione minima

Si parte con due famiglie di interfacce: una per i command, una per le query.

// Interfacce marker — esistono solo per il sistema di tipi
public interface ICommand { }
public interface ICommand<TResult> { }
public interface IQuery<TResult> { }

// Handler
public interface ICommandHandler<TCommand>
    where TCommand : ICommand
{
    Task HandleAsync(TCommand command, CancellationToken ct = default);
}

public interface ICommandHandler<TCommand, TResult>
    where TCommand : ICommand<TResult>
{
    Task<TResult> HandleAsync(TCommand command, CancellationToken ct = default);
}

public interface IQueryHandler<TQuery, TResult>
    where TQuery : IQuery<TResult>
{
    Task<TResult> HandleAsync(TQuery query, CancellationToken ct = default);
}


Cinque interfacce. Zero dipendenze esterne. Il compilatore verifica la relazione tra command, query e i relativi handler. Le interfacce marker ICommand e IQuery non sono decorazione: sono il contratto che rende sicuro il tipo nel dispatcher e nelle scansioni dell’assembly.

Un command e un handler concreti

public record CreateOrder(string CustomerEmail, List<OrderLine> Lines) 
    : ICommand<OrderId>;

public class CreateOrderHandler : ICommandHandler<CreateOrder, OrderId>
{
    private readonly IOrderRepository _orders;
    private readonly IEventBus _events;

    public CreateOrderHandler(IOrderRepository orders, IEventBus events)
    {
        _orders = orders;
        _events = events;
    }

    public async Task<OrderId> HandleAsync(CreateOrder command, CancellationToken ct = default)
    {
        var order = Order.Create(command.CustomerEmail, command.Lines);
        await _orders.SaveAsync(order, ct);
        await _events.PublishAsync(new OrderCreated(order.Id), ct);
        return order.Id;
    }
}


E una query:

public record GetOrderById(Guid OrderId) : IQuery<OrderDto?>;

public class GetOrderByIdHandler : IQueryHandler<GetOrderById, OrderDto?>
{
    private readonly IOrderReadModel _reads;

    public GetOrderByIdHandler(IOrderReadModel reads) => _reads = reads;

    public Task<OrderDto?> HandleAsync(GetOrderById query, CancellationToken ct = default)
        => _reads.GetByIdAsync(query.OrderId, ct);
}


Il Dispatcher

Il dispatcher risolve l’handler corretto per un dato command o query e lo invoca. Esiste affinché i chiamanti non debbano iniettare ogni handler individualmente: iniettano un unico dispatcher e inviano messaggi attraverso di esso.

public interface ICommandDispatcher
{
    Task SendAsync(ICommand command, CancellationToken ct = default);
    Task<TResult> SendAsync<TResult>(ICommand<TResult> command, CancellationToken ct = default);
}

public class CommandDispatcher : ICommandDispatcher
{
    private readonly IServiceProvider _provider;

    public CommandDispatcher(IServiceProvider provider) => _provider = provider;

    public Task SendAsync(ICommand command, CancellationToken ct = default)
    {
        var handlerType = typeof(ICommandHandler<>).MakeGenericType(command.GetType());
        dynamic handler = _provider.GetRequiredService(handlerType);
        return handler.HandleAsync((dynamic)command, ct);
    }

    public Task<TResult> SendAsync<TResult>(ICommand<TResult> command, CancellationToken ct = default)
    {
        var handlerType = typeof(ICommandHandler<,>)
            .MakeGenericType(command.GetType(), typeof(TResult));
        dynamic handler = _provider.GetRequiredService(handlerType);
        return handler.HandleAsync((dynamic)command, ct);
    }
}


Registrazione nel DI container

La registrazione automatica di tutti gli handler si fa con Scrutor (o manualmente per progetti piccoli):

services.AddScoped<ICommandDispatcher, CommandDispatcher>();
services.AddScoped<IQueryDispatcher, QueryDispatcher>();

// Con Scrutor: scansione automatica degli handler
services.Scan(scan => scan
    .FromAssemblyOf<CreateOrderHandler>()
    .AddClasses(c => c.AssignableTo(typeof(ICommandHandler<>)))
        .AsImplementedInterfaces()
        .WithScopedLifetime()
    .AddClasses(c => c.AssignableTo(typeof(ICommandHandler<,>)))
        .AsImplementedInterfaces()
        .WithScopedLifetime()
    .AddClasses(c => c.AssignableTo(typeof(IQueryHandler<,>)))
        .AsImplementedInterfaces()
        .WithScopedLifetime());


Pipeline behavior senza magia

Uno degli aspetti più apprezzati di MediatR è la pipeline dei behavior: logging, validazione, transazioni. Si replicano con il pattern Decorator, che il DI container di .NET supporta nativamente.

public class LoggingCommandHandlerDecorator<TCommand, TResult>
    : ICommandHandler<TCommand, TResult>
    where TCommand : ICommand<TResult>
{
    private readonly ICommandHandler<TCommand, TResult> _inner;
    private readonly ILogger _logger;

    public LoggingCommandHandlerDecorator(
        ICommandHandler<TCommand, TResult> inner,
        ILogger<LoggingCommandHandlerDecorator<TCommand, TResult>> logger)
    {
        _inner = inner;
        _logger = logger;
    }

    public async Task<TResult> HandleAsync(TCommand command, CancellationToken ct = default)
    {
        _logger.LogInformation("Executing {CommandType}", typeof(TCommand).Name);
        var result = await _inner.HandleAsync(command, ct);
        _logger.LogInformation("Completed {CommandType}", typeof(TCommand).Name);
        return result;
    }
}


Uso diretto nelle Minimal API

In contesti semplici o con Minimal API, il dispatcher può essere saltato del tutto: si inietta l’handler direttamente nell’endpoint.

app.MapPost("/orders", async (
    CreateOrder command,
    ICommandHandler<CreateOrder, OrderId> handler,
    CancellationToken ct) =>
{
    var id = await handler.HandleAsync(command, ct);
    return Results.Created($"/orders/{id}", id);
});


Questa scelta rende esplicita la dipendenza e semplifica i test dell’endpoint.

Errori comuni da evitare

CQRS non significa due database. Il pattern separa le responsabilità concettuali, non impone necessariamente read model separati o database distinti. Partire con un unico database va benissimo.

I command non contengono logica di business. Sono semplici DTO. La logica vive negli handler e nel domain model.

Gli handler non chiamano altri handler. Se un handler ha bisogno dei servizi di un altro, si estrae la logica comune in un servizio di dominio condiviso.

I command non sono DTO di input dell’API. Separare i modelli di input HTTP dai command protegge il core applicativo dai cambiamenti del contratto HTTP.

Quando MediatR ha ancora senso

Se il progetto usa già MediatR con licenza valida, non c’è fretta di migrare. Se si ha un’applicazione molto grande con decine di behavior cross-cutting complessi, MediatR offre un ecosistema di plugin testato. Per nuovi progetti o migrazioni obbligate, l’implementazione hand-rolled è spesso più semplice da capire e mantenere.

Conclusione

CQRS è un pattern di separazione concettuale, non una libreria. Il DI container di .NET fornisce tutto il necessario per implementarlo in modo pulito, testabile e privo di dipendenze esterne non necessarie. Il cambio di licenza di MediatR è stata l’occasione per molti team di riscoprire quanto poco codice ci voglia per ottenere gli stessi benefici architetturali.

Fonte: CQRS Without MediatR: Hand-Rolled Command and Query Handlers in .NET — Adrian Bailador

CQRS Without MediatR: Hand-Rolled Command and Query Handlers in .NET

MediatR went commercial and half the .NET world started looking for an exit. The good news: CQRS was never about MediatR. Here's how to build clean, tes...

^{adrianbailador.github.io}

(in)sicurezza digitale

2026-05-08 18:21:50

Cyberspionaggio iranian-nexus contro l’Oman: 12 ministeri colpiti, 26.000 record esfiltrati, server C2 lasciato aperto negli Emirati

Un server di staging lasciato in bella vista su internet ha permesso ai ricercatori di Hunt.io di ricostruire un’intera operazione di cyberspionaggio contro il governo dell’Oman. Dietro l’attacco si intravede la firma di un attore con nexus iraniano: 12 ministeri colpiti, oltre 26.000 record di cittadini esfiltrati, e un arsenale di strumenti personalizzati che punta direttamente al Ministero della Giustizia di Muscat.

Il server lasciato aperto: come è stata scoperta l’operazione

La maggior parte degli operatori offensivi ha cura di mantenere il proprio server di staging fuori dalla visibilità pubblica. Questo no. Il server all’indirizzo 172.86.76[.]127, un VPS RouterHosting con sede negli Emirati Arabi Uniti, è stato individuato dagli scanner AttackCapture di Hunt.io l’8 aprile 2026 sulla porta 8000, con una seconda directory esposta sulla porta 8002 catturata il 10 aprile. L’open directory conteneva in chiaro toolkit d’attacco, codice C2, session log, e dati esfiltrati — un errore operativo che ha aperto una finestra eccezionale sull’intera campagna.

L’IP risolve in un unico dominio: dubai-10.vaermb[.]com, registrato in maggio 2025 tramite NameSilo. Il pattern di naming suggerisce l’esistenza di infrastruttura aggiuntiva — un cluster denominato dubai-# sullo stesso ASN che ospita media iraniani della diaspora contraffatti e diversi domini .ir, fornendo un utile contesto geopolitico sull’operatore.

I bersagli: dodici entità governative omanite

La prima directory (porta 8000) rivelava la fase di ricognizione e initial access, con tentativi contro almeno quattro entità governative omanite. La seconda directory (porta 8002), con 211 file e 17 sottodirectory per un totale di 110 MB, rappresentava l’ambiente operativo del C2 — strutturato, organizzato per funzione, con cartelle dedicate per ogni obiettivo.

L’analisi degli script Python nella cartella /scripts/gov.om/ ha permesso di mappare i target all’interno dell’ecosistema governativo omanita:

• Ministero della Giustizia e degli Affari Legali (mjla.gov.om) — Target primario, con webshell deployata su mersaltest.mjla.gov[.]om
• Royal Oman Police — Portal eVisa (evisa.rop.gov.om): brute force su credenziali
• Royal Fleet of Oman — Server mail (mail.rfo.gov.om): sfruttamento ProxyShell
• Tax Authority of Oman — Server mail (email.taxoman.gov.om): sfruttamento ProxyShell
• State Audit Institution — Piattaforma formativa SAILMS: brute force
• Ulteriori ministeri inclusi: Autorità per l’Aviazione Civile, Ufficio del Pubblico Ministero, Ministero delle Finanze

La catena di attacco: webshell, ProxyShell e SQL escalation

L’accesso iniziale al Ministero della Giustizia è avvenuto con ogni probabilità sfruttando CVE-2025-32372, una vulnerabilità SSRF in DotNetNuke (DNN) nelle versioni precedenti alla 9.13.8 — il CMS su cui girano i portali ministeriali omaniti. Gli undici script Python dedicati al MJLA referenziano tutti in modo hardcoded la webshell health_check_t.aspx tramite il percorso /Portals/0/, la directory di storage predefinita di DNN.

La seconda webshell recuperata direttamente dal server C2, denominata hc2.aspx, è un classico web shell ASP.NET che accetta comandi tramite il parametro c ed esegue tramite cmd.exe, restituendo l’output come testo plain. In assenza di parametri, esegue automaticamente whoami /all && hostname && ipconfig — restituendo identità, hostname e configurazione di rete.

Contro i server Microsoft Exchange della Royal Fleet e della Tax Authority, gli operatori hanno utilizzato la catena ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207). Per il pivot e l’escalation all’interno della rete MJLA, gli script evidenziano l’uso di tecniche di privilege escalation su SQL Server e di un payload a esecuzione riflessa (reflective execution variant).

Il README.txt trovato sul server C2 — denominato “VPS C2 – 172.86.76[.]127” — conteneva porte listener, template per reverse shell, comandi di esfiltrazione e path SCP che puntavano a /opt/c2/loot/. Questo documento suggerisce che il server UAE fosse solo uno dei nodi di un’infrastruttura più ampia non ancora identificata.

I dati esfiltrati: giustizia, identità e segreti di Stato

L’entità dell’esfiltrazione è significativa sia quantitativamente che qualitativamente. Dal Ministero della Giustizia sono stati estratti:

• Oltre 26.000 record utente dall’applicazione DotNetNuke del MJLA, inclusi indirizzi email del personale e credenziali
• Dati di casi giudiziari attivi e storici
• Decisioni di commissioni governative e dati di certificazione di esperti
• Hive del registro Windows (SAM e SYSTEM) — che contengono gli hash delle password di sistema, utilizzabili per ulteriori movimenti laterali

I session log presenti sul server C2 confermano sessioni operative attive fino al 10 aprile 2026, dimostrando che la compromissione era ancora in corso al momento della scoperta da parte di Hunt.io.

L’attribuzione: il nexus iraniano e la continuità delle operazioni

Hunt.io non attribuisce esplicitamente la campagna a un gruppo specifico, ma i marker sono coerenti con attori Iranian-nexus. Nel 2025, un gruppo allineato all’Iran e collegato al Ministero dell’Intelligence e della Sicurezza (MOIS) aveva compromesso una mailbox del Ministero degli Affari Esteri omanita a Parigi, utilizzandola come launchpad per inviare email di spear phishing ad ambasciate e organizzazioni internazionali nel mondo. La campagna attuale inverte il vettore: questa volta l’Oman non è la piattaforma di lancio, ma il bersaglio diretto, con focus specifico su dati giudiziari, sistemi di immigrazione e identità dei cittadini.

L’infrastruttura adiacente sullo stesso ASN — che ospita media iraniani della diaspora contraffatti e domini .ir — aggiunge contesto alla collocazione geopolitica dell’operatore. Il pattern di targeting (sistemi giudiziari, forze dell’ordine, finanze pubbliche) è coerente con le priorità di intelligence degli apparati statali iraniani nei confronti dei paesi del Golfo.

Due righe per i difensori

Il caso dell’Oman illustra due lezioni critiche per i team di difesa. Prima di tutto, la gestione dell’infrastruttura di staging è essa stessa una superficie di attacco: server di C2 male configurati possono esporre l’intera operazione e fornire preziosi indicatori ai difensori. In secondo luogo, la longevità delle vulnerabilità come ProxyShell — pubblicamente nota dal 2021 — dimostra che molte organizzazioni governative non dispongono di processi di patching adeguati per i sistemi esposti a internet.

Per le organizzazioni che operano in settori sensibili nei paesi del Golfo o che collaborano con entità governative omanite, si raccomanda di verificare immediatamente le versioni di DotNetNuke deployate, controllare la presenza di webshell nei path /Portals/0/ dei CMS DNN, e monitorare la comunicazione verso l’IP 172.86.76[.]127 e il dominio dubai-10.vaermb[.]com.

Indicatori di Compromissione (IoC)

# Iranian-Nexus Oman Government Intrusion - IoC
## Infrastructure
IP: 172.86.76[.]127 (RouterHosting VPS, UAE)
Domain: dubai-10.vaermb[.]com (registrato 2025-05-04, NameSilo)
Cluster: dubai-[N].vaermb[.]com (additional nodes suspected)
C2 path: /opt/c2/loot/
## Targets Compromised
mersaltest.mjla.gov[.]om (primary C2 access point, Ministry of Justice)
evisa.rop.gov[.]om (Royal Oman Police)
mail.rfo.gov[.]om (Royal Fleet of Oman)
email.taxoman.gov[.]om (Tax Authority of Oman)
sailms.gov[.]om (State Audit Institution)
## Webshells
health_check_t.aspx (deployed on MJLA DNN portal, /Portals/0/)
hc2.aspx (recovered from C2 server)
## C2 Files
c2_fixed.py
c2_fixed_v2.py
README.txt (infrastructure reference document)
proxyshell_01.sh
evisa_cookies.txt
## Vulnerabilities Exploited
CVE-2025-32372 - DotNetNuke SSRF (versions before 9.13.8)
CVE-2021-34473 - ProxyShell (Microsoft Exchange)
CVE-2021-34523 - ProxyShell (Microsoft Exchange)
CVE-2021-31207 - ProxyShell (Microsoft Exchange)
## Tunneling Tool
Chisel (encrypted tunnel through firewalls, components in /payloads)
## MITRE ATT&CK TTPs
T1190 - Exploit Public-Facing Application (DNN SSRF, ProxyShell)
T1505.003 - Web Shell
T1003.002 - OS Credential Dumping: SAM (registry hives SAM+SYSTEM)
T1059 - Command Scripting (Python scripts, cmd.exe via webshell)
T1083 - File and Directory Discovery
T1119 - Automated Collection
T1020 - Automated Exfiltration
## Last Active Session
April 10, 2026 (C2 log timestamps)

Elena Rossini

2026-05-08 05:29:40

W Social uncovered: the reality behind the hype

In January my corner of the social web was abuzz with the surprising announcement at Davos of a new social network: W Social, which aspires to be an alternative to X, based in Europe, with "identity verification to fight disinformation." Its goal? To foster social sovereignty for European citizens, away from the control and influence of U.S. tech behemoths.

There was a lot of ambiguity surrounding the announcement with implications that this may be an initiative driven by European politicians. Was the European Commission involved? Would governments be funding a new social platform for European citizens that required ID verification? It was hard to tell.

Meanwhile, many European newspapers, blogs, radio and TV stations covered this announcement extensively, with great enthusiasm - day after day for what seemed like a full week. Most of the reporting seemed to be a simple rehashing of a press release.

It took me about 5 minutes of research to start uncovering some really surprising elements. The contrast between the media hype and the reality was so jarring, that I decided to start collecting evidence and share what I found in a blog post.

With my article today I aim to share the reality behind the hype, doing the work that journalists should have done at the beginning.

⚠️
Disclaimer:

This article represents my personal opinions, commentary, and conclusions formed through independent research using publicly available sources. Any characterizations, interpretations, or inferences are presented as opinion, not as statements of objective fact. Readers are encouraged to review the referenced materials and draw their own conclusions.

Why should YOU care?

World events from the past two years have pushed a lot of European leaders to start reassessing Europe's dependence on American tech infrastructure.

European politicians and policy experts have started holding meetings to discuss "Trusted European Platforms (TEPs) to strengthen Europe’s strategic autonomy." W Social is being mentioned in these discussions:

Sovereign Democracy & Trusted European Platforms: starting!
Sovereign Democracy & Trusted European Platforms: starting!
Stars4MediaStars4Media Project

I understand that doing due diligence requires time and technical expertise.

I would like to collect in this post all the evidence I found of why I personally don't think W Social is a solution for Europe’s digital sovereignty.

If anything, we should exercise critical thinking, follow the money and analyze who has control over social media platforms. It is no coincidence that tech oligarchs in the U.S. have been on a media purchasing spree, scooping up newspapers, TV stations and social media networks - especially in the past 4 years. Controlling the flow of information is a potent thing - and we should be very careful of whom we give that power to.

A word from the author

Before we get started, why should you listen to me?

Well, I have been very active on decentralized social networks for four years now, championing these online spaces over centralized offerings by Big Tech platforms.

I have been invited to speak about my views and experiences at Journées du Logiciel Libre in Lyon, PublicSpaces in Amsterdam, Berlin Fediverse Day, Social Media Strategies in Bologna and this past month I gave a talk at the Ministry of Culture in Paris and delivered the opening keynote at 2MR in Hamburg.
a photo of me on stage at Social Media Strategies in Bologna, Italy - next to Niccolò Venerandi and morloi
In addition to my advocacy, I have been self-hosting my own social media platforms (GoToSocial, PeerTube and Pixelfed instances) and I’ve set up essential services like NextCloud… purposefully using domain name registrars, web and VPS hosting companies based in Europe.

The topics of open social networks, FOSS alternatives to Big Tech platforms and European cloud infrastructure are my bread and butter.

I have been alarmed by the hype around the launch of W Social and all the inaccuracies in news reports. Thus my speaking up.

Issue no.1: How W Social ignored existing European initiatives

People in my circles discussed the announcement of W Social with disbelief and a touch of anger. At launch, the official website of W Social showcased a world map, with icons of American tech platforms (Bluesky, Facebook, Instagram, LinkedIn, Reddit, Snapchat, TikTok US, Whatsapp, X and YouTube) superimposed over the map of the United States; then over Russia you can see the logos of OK and Vkontakte, over China there is QQ, TikTok, WeChat and Weibo, and over India there is ShareChat. A circle is drawn around Europe... but there are no icons inside. The message: W Social is here to fill that void and provide a European social network.
a screenshot of the initial landing page for W Social on January 21st 2026
This provoked the ire of many of my friends and fellow Fediverse netizens - because decentralized social media platforms like Mastodon and PeerTube originated in Europe; the Fediverse has over 12 million users. Omitting this felt like a strange choice. Even the European Commission has an active Mastodon account: on their own server, with over 154,000 followers!

European Commission (@EUCommission@ec.social-network.europa.eu)
3.58K Posts, 10 Following, 154K Followers · News and information from the European Commission. A project to foster our presence in the fediverse and support our commitment to European social media platforms based on open source technology. 🇪🇺 Official Mastodon account as verified by the official EU domain in our server’s address (https://europa.eu).
European Commission on Mastodon

While most people focused their frustration on that omission, I thought of something else entirely: for months I had been hearing about the development of Eurosky, based on Bluesky's ATproto.

A mission statement, from Eurosky's website (a note: I grabbed this text in January and the page has since changed. But you can see the original courtesy of the Internet Archive):

Eurosky is building the future of social media - open, pluralistic, and made in Europe. We believe social media should serve our economies and societies, not monopolies. Eurosky is a public-interest infrastructure project that puts control in the hands of users, businesses, and European society. By combining European cloud infrastructure with open standards and democratic governance, we’re creating a new ecosystem where innovation thrives, moderation is transparent, and no single company or country can dictate the rules.

a screenshot of Eurosky's website from late January 2026
By reading articles about W Social, you could easily think journalists were discussing Eurosky. The two platforms are so eerily similar in their stated goals, that when I heard that a new European social platform was launching to rival X, when I read it was called "W Social" my first thought was that Eurosky must have rebranded and changed its name. After all, it was supposed to launch in January 2026 and the announcement of W Social was made in Davos on January 20th 2026.

Oh no. They are two completely different initiatives.

Here is what Robin Berjon - one of the architects of Eurosky - had to say about W Social:
a screenshot of a post by Robin Berjon of Eurosky
While the two initiatives share similar goals, their execution could not be more different.

Eurosky has been slowly and carefully planned out, online and behind the scenes. Its website is sleek and professional, with extensive information explaining what the project is about, team bios, a timeline of objectives. When French and German political leaders met in Berlin in November 2025 at the Summit on European Digital Sovereignty to discuss European tech sovereignty plans, Eurosky team members organized their own conference in Berlin as a "side event", in order to show policy makers what they were working on. This is a very well prepared team of experts.

By contrast, if you visited the website of W Social on its launch day, all you had was a rudimentary landing page with a map of Europe and the invitation to enter an invite code. Any 14-year-old with an hour to spare and a free Canva account could have designed something more professional looking.

Now the page has been updated with a slightly sleeker design for its landing page but it is still lacking any content (as of May 7th, 2026):
the landing page of W social on May 7, 2026
W Social's announcement at Davos felt very rushed, with minimal preparation just to get the word out there about their plans and get a leg up in the news cycle about European platforms as alternatives to Big Tech offerings from Silicon Valley.

With work on Eurosky being well under way (they eventually opened migrations to their server from Bluesky in February), I kept wondering: "Why? What is the point of W Social, another European fork of Bluesky?" And then everything clicked: maybe W Social is banking on mandatory age verification for European users in order to use social media. This could be their "leg up" over Eurosky: the need for an official government ID to open an account and use it.

Issue no.2: W Social's bungled attempt to conceal they are using Bluesky's AT Protocol

How will W Social work? Which technology will it employ to power its revolutionary European social network?

You would think journalists would ask these questions.

Sadly, that wasn't the case.

Online sleuths discovered the page stage.wsocial.eu that revealed WSocial is none other than a fork of Bluesky, thus based on ATProto.

Developers typically test out platforms on a staging website before launching or going in production... the staging page for W Social was exactly like the Bluesky login page. If you clicked on the "x" to close that preview window, you would see a Bluesky feed:

screenshots putting the landing page of Bluesky and the staging page for W Social side by side...
a screenshot of W social's early feed from the staging page. basically a Bluesky feed
That page was active for a few days: if you shared a link to it from Signal for example - like I did - you would see a preview card with the Bluesky logo. So much for calling out Bluesky and conflating it with other Big Tech offerings by Meta and ByteDance.

Additional proof: the URL dev-pds.wsocial.eu which showed the ATproto logo and stated "this is an AT Protocol Personal Data Server" (the two URLs have since been migrated):

This Scooby-Doo unmasking meme shared by DoktorZjivago on Mastodon is a perfect illustration for this:

I'm guessing that after catching some flack online – regarding their high aspirations of having a European tech stack but picking the American Bluesky and their protocol – someone in charge of W Social commanded that their staging website scrap all evidence of ATproto.

So the stage.wsocial.eu webpage a few days after the official announcement looked like this:

Issue no.3: W Social's cavalier attitude towards online security

Did you notice anything wrong in the previous screenshot?

Well, the operation scrapping of all Bluesky branding resulted in the loss of the page's SSL certificate.

This is a LOGIN page into their system.

Why is it bad? Well, when you type a password into a webpage that doesn't have a working SSL certificate, the connection between your browser and the website is unencrypted. That means the password travels as plain text across the Internet.

Did I mention that W Social's value proposition is verified identity and they will require a government ID to create an account? They are asking for your most sensitive data... and yet have a cavalier attitude towards security.

On announcement week, Tom Casavant shared these messages on Bluesky about W Social and its dev-pds.wsocial.eu page (I'm sharing this with Tom's permission):

How bad is this?

Potentially catastrophic if the wrong person could so easily gain access into their system.

Am I theorizing about things that may never happen? Sure. But we should all be very careful about the organizations we trust with our most sensitive data. A few months ago a Discord data breach exposed the government IDs of 70,000 users:

Discord Data Breach - 1.5 TB of Data and 2 Million Government ID Photos Extorted
Discord has confirmed a significant data breach that exposed sensitive user information after an attacker compromised a third-party customer service provider.
CybersecurityNewsGuru Baran

Now, I have heard through the grapevines (and read confirmation in the press - more on this later) that W Social hired a team of software engineers and now have more than 20 employees, so I think they are taking things more seriously. Still, their early blunders were really shocking to me.

Issue no.4: the founders or: who are we trusting with our communications?

W Social is being built by a Swedish company called W Social AB, which is a subsidiary of We Don't Have Time, a climate-focused media platform. The W Social project is led by Anna Zeiter, a Swiss privacy expert who previously served as Chief Privacy Officer at eBay for more than a decade; she holds a PhD in law from the University of Hamburg. Not the typical background for a tech founder.
a screenshot of Anna Zeiter's profile as it appears on Bluesky
According to an article on Impact Loop, W Social received 2.5 million Euros in funding and has a team of 25 people. Its board of advisors includes very powerful, well-connected people in the world of business and politics, including Cristina Caffarra (chair of EuroStack), Elizabeth Denham (former UK Information Commissioner), Sandrine Dixson-Declève (Honorary President of the Club of Rome), Yariv Adan (former Head of AI at Google), Pär Nuder (former Swedish Minister of Finance), Marc Placzek (former CPO at PayPal) and Philipp Rösler (former German vice-chancellor).

At Davos, Zeiter was interviewed during a We Don't Have Time segment and had a chance to talk about her intentions for the platform - the video was posted on X, but I am using the alternate site nitter.net to display it (so you won't need an X account to see it):

Direct link: nitter.net/WeDontHaveTime/stat…

Zeiter said:

Everything is data-driven. Ten years ago we said 'data is the new oil', right now we say 'high quality data is the new oil.' And this is what we are seeing, that competitors in the U.S. and China are using a lot of personal data to analyze, to target... and also sometimes to manipulate users. We want to be different in that respect. Of course, we want to respect GDPR and other European laws because we are run, built and governed in Europe and we would also like to give back to the users. We like to give for example, the face identification process, we want to make sure that users can govern their own data and also their own algorithms, so that users can really choose: "do I want to stay in my filter bubble?" or "do I want to see a little bit more of what is going on in society?" or "do I want to have the full spectrum?"

This is their pitch: a social media platform with a pick-your-own algorithm, that requires government ID to sign up.

What I take issue with here is the sentence "we are run, built and governed in Europe." Why hide that they are using the ATproto infrastructure to operate? Theirs is not a novel, completely original, built from the ground up platform. It is based on Bluesky's ATproto. And yet, this protocol has never been mentioned in any interviews.

Software engineer Maho Pacheco theorized:

I have strong suspicions about why W selected ATproto instead of Activity Pub. Basically there is more power in the biggest actors, a more "centralized" control, to ban/shadow-ban/censure and pull the plug. In other words it is more impactful when Bluesky sidebanned someone or some community than if mastodon.social would do it. The firehose/relay is a the biggest point of control. So in my opinion it is more interesting for investors to create a platform that can be controlled, even if it is just to introduce ads or control the discourse. Technically is because setting-up/supporting/maintaining the firehose/relay layer is very expensive. Every single message would flow through there; creating the biggest firehose in Europe is such a power. So, it is easier to be controlled, and very unlikely to be replicated by other entities.

Issue no. 5: lack of transparency

Following their surprise announcement at Davos, there were dozens of news reports in newspapers, radio shows and TV news shows about this "new European network that will replace X" - with strong implications that it may be an official initiative by the European Union.
a screenshot showing articles about W Social on Google News
This went on for TEN DAYS - with zero fact checking by media organizations or corrections by the W Social founders.

The first news organization to fact check and debunk the myth of official involvement by the European Union was Euronews. In a segment for The Cube (which you could watch here), journalist James Thomas said:

Claims are spreading online like wildfire that the European Union is setting up its own social media platform to rival X. These posts have spread primarily on X itself, with thousands of views and say that taxpayers money will be used to set up W as an alternative to Elon Musk's platform. Some posts describe it as a state-run censorship platform that has receive funding from the European executive, but these claims are misleading. A European Commission spokesperson told The Cube that the EU is not launching, funding or operating any social media platform. There is no European-backed projected called "W".

This came ten days too late, with dozens of news reports legitimizing W as an official European alternative to X.

Let's do some role-playing here: if I were to launch a privately funded project that received extensive media coverage in newspapers, on the radio and TV, but with reports wrongly claiming that the government was behind it... well, the first thing I would do would be to contact journalists to rectify the mistake. I may even put text on my website to correct the assumptions.

W did not do that. I will always remember their silence on this.

I am not sure I can fully trust an initiative that lacked clarity and honesty on two crucial points:

• hiding that they are a fork of Bluesky;
• not correcting wrong claims about their origins, letting people believe that they are part of a European Union initiative - whereas in reality they are a private venture, funded by private investors.

And then there is the thorny issue of their required ID verification, the erosion of privacy and the end of internet anonymity. Em wrote an excellent article pointing out the problems with age verification laws for social media users - it is a must read and covers many of the reasons why government IDs to use social media is a very bad idea:

Age Verification Wants Your Face, and Your Privacy
Age verification laws forcing platforms to restrict access to content online have been multiplying in recent years. The problem is, implementing such measure necessarily requires identifying each user accessing this content, one way or another. This is bad news for your privacy.
Privacy GuidesEm

The Electronic Frontier Foundation also has a superb piece about this topic:

10 (Not So) Hidden Dangers of Age Verification
It’s nearly the end of 2025, and half of the US and the UK now require you to upload your ID or scan your face to watch “sexual content.” A handful of states and Australia now have various requirements to verify your age before you can create a social media account.Age-verification laws may sound…
Electronic Frontier FoundationRindala Alajaji

Final Thoughts

I have a lot more to say about this but I realize that in this post-literate era I have already written a very long post that will take time to read and fully digest. I will stop here - for now. W Social is set to launch tomorrow May 9th on Europe Day. As it happened when it was first announced in January, it is likely to receive a lot of uncritical, superficial press coverage. Please exercise critical thinking and try to look at the reality behind its hype. And if you are not familiar with open social networks, please take a look at a better option: the Fediverse.

Thanks for being here,

Elena

---

💓 Did you enjoy this post? Share it with a friend!
👫 Follow me on Mastodon. All my other links are available here: elena.social
💌 If you'd like to say hi, my contact information is here
✏️ If this post resonated with you, leave a comment!

Elena Rossini | Contact Form

Contact Elena Rossini: use the contact form on this page to get in touch with Elena – interview requests, speaking gigs, freelance assignments...

^{Elena Rossini}