404 Media

2026-05-08 15:50:03

'The Biggest Student Data Privacy Disaster in History': Canvas Hack Shows the Danger of Centralized EdTech

Thursday afternoon, millions of students at thousands of universities and K-12 schools were locked out of Canvas, a piece of catch-all education technology software that has become the de facto core of many classes. ShinyHunters, a ransomware group, hacked Canvas’s parent company and apparently stole “billions” of messages and accessed more than 275 million individuals’ data, according to the hacking group. The group also locked students out of Canvas.

Later Thursday, Instructure, which makes Canvas, was able to mostly put Canvas back online; it is not clear if the company paid a ransom or not. The breach demonstrates the danger in centralizing the educational and personal data of millions of students in a single service. Canvas is essentially a portal where teachers post assignments and lectures, have discussion boards, and students can message with each other and their teachers and connect with other pieces of education tech software.

Instructure noted on an incident update page that the stolen data includes “certain personal information of users at affected organizations. That includes names, email addresses, student ID numbers, and messages among Canvas users.” Instructure also noted that it was breached twice—once on April 29 and again on Thursday.

Soon after the hack, I called up Ian Linkletter, a digital librarian specializing in emerging education tech, to talk about the implications of the breach. Linkletter has worked in education tech for 20 years and over the last few years has become known for exposing privacy concerns in Proctorio, a remote test proctoring software that rose to prominence during the early days of the COVID-19 pandemic. Linkletter was sued by Proctorio but eventually the case was dropped.

Linkletter told me the Canvas hack is “the biggest student data privacy disaster in history” in part because of its scale and the sensitive nature of what was stolen. This is my conversation with Linkletter, which has been lightly condensed.

404 Media: What do we know about the hack so far?
Linkletter: At about 1:20 PM [Pacific, Thursday], people started posting screenshots to Reddit of this breach message that they got. Some institutions were cautioning people to change their passwords if they were logged in, right now it just seems like people are in panic mode, some senior administration at schools are in meetings talking about whether they need to cancel finals next week. It’s just the implications are on everything because schools are reliant on this learning management system for everything—communications, grading, finals, everything.

In your email to me, you said you've worked in EdTech for 20 years and you said this is the biggest student data privacy disaster in history. I'm curious what sort of made you frame it that way.
I supported Blackboard [a similar piece of tech] way back in the day and I supported Canvas from about 2017 to 2022 when I worked at the University of British Columbia. And what I was there for when we switched to Canvas in 2017 was the shift from like these scrappy little self-hosted learning management system apps that would be on Canadian servers to this centralized, all eggs-in-one basket faith in a U.S. tech company. This idea that our data would be just as safe with them as it was when we had it. And because this move to the cloud happened so suddenly about 10 years ago, all of a sudden data got centralized. The only way that I can think of that this type of hack where everything went down, where so much was stolen would be if Instructure had access to everybody's data, which doesn't seem necessary. For it to be just so widespread across every customer is something that, like, [we’ve] never seen before.

Because the contents of messages got leaked, it’s really easy for phishing attacks to get customized. Like, Canvas got hacked [...] and continuing our conversation type of thing, you can get some really personal information from people. And that's also new.

I can also imagine messages between students and teachers to be pretty sensitive.
I supported instructors that used Canvas. And so I would hear these stories like, and they're on like the professor’s subreddit and stuff too, like students are telling you that people died [to explain absences]. There's personal circumstances, medical circumstances, accessibility accommodations, disputes, sexual assault allegations, like all sorts of stuff would be getting reported to the instructor using Canvas. If that information is out across hundreds of millions of people, there's a lot of harm that's going to happen.

What will you be kind of monitoring as this plays out?
My biggest concern right now is monitoring the institutional response. I feel very strongly that students should have been warned about this like days ago. And it just took this second hack where students got something in their face notifying them that really made schools respond. So I believe that students need to be warned or else they're going to get harmed. And the longer schools wait to tell students about what’s going on, even the little that they know, the more stress and chaos and potential risk to student privacy and safety is at stake.

He got sued for sharing public YouTube videos; nightmare ended in settlement

Librarian vows to stop invasive ed tech after ending lawsuit with Proctorio.

^{Ashley Belanger (Ars Technica)}

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)