macfranc

2026-04-14 09:09:09

In queste ore si sta verificando un attacco per rubare gli account agli utenti Mastodon. Ecco cosa sapere per evitare le truffe su Mastodon e nel Fediverso con la guida di @FediTips

Il post è stato ripubblicato sul gruppo @fediverso

Come in qualsiasi altro social network, anche su Mastodon e nel più ampio Fediverso potresti imbatterti in truffatori. Ecco come individuarli e cosa fare in caso di dubbio.

1. Truffa: "Abbiamo bisogno che tu verifichi il tuo account"
2. Truffa: "Vogliamo pagarti per i post / instaurare una collaborazione / offrirti una ricompensa"
3. Truffa: "Si prega di modificare temporaneamente l'indirizzo email del proprio account"

• Cosa devo fare se vedo un post truffaldino?
• Dovrei vergognarmi se sono caduto vittima di una truffa?

NB: questa guida è una traduzione della pagina realizzata da @FediTips

[SEGUE]

How to avoid scammers on Mastodon and the Fediverse | Fedi.Tips – An Unofficial Guide to Mastodon and the Fediverse

An unofficial guide to using Mastodon and the Fediverse

^{FediTips (Fedi.Tips - An Unofficial Guide to Mastodon and the Fediverse)}

(in)sicurezza digitale

2026-04-14 08:10:24

APT35 e la Cyber Guerra Parallela: come l’Iran aveva già compromesso ogni paese colpito nell’Operazione Epic Fury

Si parla di:
Toggle

• La notte del 28 Febbraio: quando la guerra digitale diventa fisica
• APT35 e la dottrina della Pre-Posizione
• Il modello di conflitto a tre fasi
• L’ecosistema APT iraniano: non solo APT35
• Infrastruttura di attacco: offuscamento multi-livello
• Vulnerabilità sfruttate: un catalogo di CVE note
• Il significato strategico: un nuovo standard di conflitto ibrido
• Indicazioni per i difensori

Prima che i missili iraniani illuminassero il cielo di sette nazioni, un’altra guerra era già in corso nelle reti digitali di quei paesi. L’analisi della campagna condotta da APT35 rivela come il gruppo legato all’IRGC avesse sistematicamente compromesso le infrastrutture critiche di ogni paese successivamente colpito dall’Operazione Epic Fury, trasformando la cyber intelligence in un componente integrale della dottrina militare iraniana.

La notte del 28 Febbraio: quando la guerra digitale diventa fisica

Il 28 febbraio 2026, Stati Uniti e Israele hanno lanciato l’Operazione Epic Fury (denominata “Operazione Roaring Lion” dalla parte israeliana): oltre 1.250 obiettivi colpiti nelle prime 48 ore, infrastrutture nucleari iraniane distrutte, connettività internet dell’Iran ridotta all’1-4% dei livelli normali in quello che è stato definito il più grande cyberattacco della storia. Ma ciò che i rapporti di intelligence successivi hanno rivelato è ancora più preoccupante: l’Iran non si trovava impreparato. Per mesi, forse anni, i suoi gruppi APT affiliati all’IRGC e al MOIS avevano già mappato, compromesso e pre-posizionato capacità offensive nelle reti digitali di ogni paese che avrebbe poi colpito.

APT35 e la dottrina della Pre-Posizione

APT35 — conosciuto anche come Charming Kitten, Phosphorus, Magic Hound e Mint Sandstorm — è il gruppo cyber più rappresentativo dell’IRGC Intelligence Organisation (Unit 1500, Department 40), attivo almeno dal 2014. La sua caratteristica distintiva non è la sofisticazione tecnica delle singole operazioni, ma la pazienza strategica: operazioni di ricognizione prolungate, accesso silenzioso mantenuto per mesi o anni prima di un’attivazione.

Secondo le analisi di CloudSek e dei ricercatori di IT Nerd, APT35 aveva documentabilmente compromesso infrastrutture nei seguenti paesi prima dei bombardamenti:

• Giordania: accesso ai dati dell’aviazione civile e al Ministero della Giustizia
• Emirati Arabi Uniti: sistemi di aviazione e asset governativi a Dubai
• Arabia Saudita: documenti governativi e infrastrutture energetiche; il malware Shamoon ha distrutto circa 15.000 workstation nel settore energetico saudita prima delle operazioni cinetiche
• Kuwait, Bahrain, Qatar: attività di ricognizione e targeting operativo
• Israele: sistemi industriali e infrastrutture civili

Il modello di conflitto a tre fasi

L’analisi degli eventi suggerisce un modello di conflitto ibrido strutturato in tre fasi sequenziali, ormai consolidato nella dottrina iraniana:

• Fase 1 — Ricognizione estesa e silenziosa: compromissione di sistemi internet-facing (Exchange Server, VPN, Fortinet FortiOS), installazione di webshell, tunneling nascosto, raccolta di intelligence su reti, persone e infrastrutture critiche
• Fase 2 — Degradazione pre-cinetica: attivazione di malware wiper (come Shamoon) per distruggere workstation, esfiltrazione di documenti strategici, interruzione di servizi prima degli attacchi fisici
• Fase 3 — Coordinamento post-attacco: entro 24 ore dall’avvio delle operazioni militari, creazione di un “Electronic Operations Room” che ha coordinato oltre 60 gruppi hacktivist per colpire contemporaneamente infrastrutture governative, finanziarie e critiche

L’ecosistema APT iraniano: non solo APT35

APT35 non ha operato in isolamento. Il Tenable Research ha identificato 12 gruppi APT iraniani attivi nelle settimane e mesi precedenti l’Operazione Epic Fury, coordinati attraverso strutture parallele:

Gruppi IRGC-affiliati: Pioneer Kitten (Fox Kitten, UNC757), Imperial Kitten (Tortoiseshell, TA456), CyberAv3ngers — quest’ultimo specializzato nel targeting di sistemi OT e PLC nei sistemi idrici. Gruppi MOIS-affiliati: APT34/OilRig (nuova infrastruttura per attacchi ed esfiltrazione), MuddyWater/Mango Sandstorm (picco di attività nella rete nel settembre 2025, con server distribuiti in Russia, Estonia e UK), Banished Kitten/Void Manticore (usa la persona Handala, wiper-focused). Gruppi IRGC-IO: APT42 (credential harvesting tramite social engineering). Gruppi IRGC-CEC: Cotton Sandstorm (revival della persona Altoufan Team).

Infrastruttura di attacco: offuscamento multi-livello

Particolarmente sofisticata è stata l’architettura di infrastruttura impiegata per mascherare l’attribuzione. Netcrook ha documentato uno schema di offuscamento a tre livelli:

• Livello base: ISP iraniani (Sefroyek Pardaz Engineering) come punto di origine
• Bulletproof hosting: ALEXHOST in Moldova e RouterHosting LLC nel Wyoming (USA) come nodi intermedi
• Shell company layer: società fittizie come Cloudblast (registrata negli USA, operativa a Dubai) e UltaHost (registrazioni UK/USA) per la gestione dell’infrastruttura front-end

Questa architettura ha reso estremamente complessa l’attribuzione rapida e le azioni legali di takedown durante le operazioni.

Vulnerabilità sfruttate: un catalogo di CVE note

Il documento Tenable elenca 67 CVE sfruttate dai gruppi iraniani, incluse vulnerabilità ben note mai patchate da molte organizzazioni. Tra le più critiche:

# CVE sfruttate dai gruppi APT iraniani (selezione)
CVE-2021-26855  # Microsoft Exchange Server - ProxyLogon SSRF
CVE-2021-26858  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-26857  # Microsoft Exchange - insecure deserialization
CVE-2021-27065  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-44228  # Apache Log4j2 - Log4Shell RCE
CVE-2022-40684  # Fortinet FortiOS/FortiProxy - authentication bypass
CVE-2020-3153   # Cisco ASA - path traversal
# Malware famiglie associate
BellaCiao        # RAT/implant IRGC (codice sorgente esposto in leak)
Sagheb RAT       # Remote Access Trojan IRGC
Shamoon          # Wiper distruttivo (energia, Arabia Saudita)
# Malware ICS/OT
Custom PLC malware targeting Rockwell Automation (CyberAv3ngers)

Il significato strategico: un nuovo standard di conflitto ibrido

La vicenda dell’Operazione Epic Fury e della sua dimensione cyber non è semplicemente la cronaca di un conflitto mediorientale. È la dimostrazione concreta di come le operazioni cyber siano diventate componenti integrali — non accessorie — della dottrina militare degli stati autoritari. Il pre-posizionamento di APT35 nelle reti dei paesi bersaglio anni prima delle operazioni fisiche stabilisce un precedente: in futuri conflitti, qualsiasi attore statale disporrà presumibilmente di “porte di accesso” già aperte nelle infrastrutture avversarie.

Per i difensori occidentali, la lezione è chiara: la minaccia non inizia il giorno in cui i missili vengono lanciati. Inizia quando un webshell silenzioso viene installato su un server Exchange non patchato da sei mesi.

Indicazioni per i difensori

• Patch immediata dei sistemi internet-facing: Exchange, FortiOS, Cisco ASA, Log4j sono ancora vettori attivi
• Audit degli accessi amministrativi: verificare account privilegiati, in particolare su sistemi OT/ICS
• Webshell hunting: scansione proattiva per webshell su server web esposti, soprattutto su CMS e sistemi legacy
• Validazione della copertura di detection: testare le soluzioni EDR/XDR contro BellaCiao, Sagheb RAT e le tecniche di tunneling documentate
• Monitoraggio per nuova infrastruttura hacktivist: i gruppi come Handala e CyberAv3ngers si riorganizzano rapidamente dopo le operazioni

APT35 e la Cyber Guerra Parallela: come l'Iran aveva già compromesso ogni paese colpito nell'Operazione Epic Fury - (in)sicurezza digitale

Prima che i missili iraniani illuminassero il cielo di sette nazioni, i gruppi APT dell'IRGC avevano già compromesso silenziosamente le infrastrutture critiche di quei paesi.

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

macfranc

2026-04-14 09:10:29

1) Esempio di truffa: "Abbiamo bisogno che tu verifichi il tuo account" - Torna al primo messaggio

Qualcuno che si spaccia per un amministratore di un server Mastodon inventa una scusa per richiedere la verifica dell'account, magari sostenendo che l'utente abbia compiuto un'azione sospetta. Successivamente, fornisce un link su cui cliccare per inserire i dati della carta di credito o altre informazioni personali. Non cliccare su questo link e non fornire alcuna informazione: si tratta di una truffa.

Nessun amministratore legittimo ti chiederà mai di verificare il tuo account. Su Mastodon esiste un sistema di verifica, ma è completamente facoltativo e non prevede di cliccare su link sospetti o di fornire dati personali.

@fediverso

[SEGUE]♲ @macfranc@poliversity.it:

In queste ore si sta verificando un attacco per rubare gli account agli utenti Mastodon. Ecco cosa sapere per evitare le truffe su Mastodon e nel Fediverso con la guida di @FediTips

Il post è stato ripubblicato sul gruppo @fediverso

Come in qualsiasi altro social network, anche su Mastodon e nel più ampio Fediverso potresti imbatterti in truffatori. Ecco come individuarli e cosa fare in caso di dubbio.

1. Truffa: "Abbiamo bisogno che tu verifichi il tuo account"
2. Truffa: "Vogliamo pagarti per i post / instaurare una collaborazione / offrirti una ricompensa"
3. Truffa: "Si prega di modificare temporaneamente l'indirizzo email del proprio account"

• Cosa devo fare se vedo un post truffaldino?
• Dovrei vergognarmi se sono caduto vittima di una truffa?

NB: questa guida è una traduzione della pagina realizzata da @FediTips

[SEGUE]

How do I verify my account on Mastodon and the Fediverse? | Fedi.Tips – An Unofficial Guide to Mastodon and the Fediverse

An unofficial guide to using Mastodon and the Fediverse

^fedi.tips

Spcnet.it

2026-04-14 07:46:54

Il Pattern Saga in .NET con Wolverine: gestire workflow distribuiti a lungo termine

Nei sistemi distribuiti, la gestione di processi di business che si estendono su più servizi e nel tempo rappresenta una delle sfide più complesse. Il Pattern Saga nasce proprio per risolvere questo problema: coordinare una sequenza di operazioni distribuite in modo affidabile, garantendo la consistenza dei dati anche in caso di errori parziali.

In questo articolo esploriamo come implementare il Pattern Saga in .NET utilizzando Wolverine, un framework moderno che semplifica notevolmente la gestione di messaggi e workflow complessi grazie al suo approccio convention-driven.

Cos’è il Pattern Saga?

Il Pattern Saga è un meccanismo di gestione delle transazioni distribuite che sostituisce le transazioni ACID tradizionali nei sistemi a microservizi. Invece di eseguire una sequenza di operazioni come un’unica transazione atomica, la saga suddivide il processo in una serie di passi indipendenti, ciascuno con la propria logica di compensazione in caso di fallimento.

Il principio fondamentale è semplice: se un passo fallisce o va in timeout, la saga esegue la logica di compensazione invece di lasciare il sistema in uno stato inconsistente. Questo approccio è particolarmente utile per processi di lunga durata come:

• Onboarding di nuovi utenti con email di verifica
• Processi di ordine e pagamento in e-commerce
• Workflow di approvazione multi-step
• Processi di provisioning di risorse cloud

Perché Wolverine?

Wolverine è un framework per .NET che adotta un approccio convention-driven alla messaggistica e ai workflow. A differenza di soluzioni come MassTransit o Rebus, Wolverine gestisce automaticamente routing dei messaggi, persistenza dello stato e correlazione, senza richiedere un’estesa configurazione tramite DSL per state machine.

Le principali dipendenze per iniziare sono:

WolverineFx (5.16.2)
WolverineFx.Postgresql (5.16.2)
WolverineFx.RabbitMQ (5.16.2)

Configurazione del progetto

La configurazione di Wolverine richiede pochi passaggi. Nell’entry point dell’applicazione, si configura il framework per utilizzare RabbitMQ come message broker e PostgreSQL per la persistenza dello stato:

builder.Host.UseWolverine(options =>
{
    options.UseRabbitMqUsingNamedConnection("rmq")
        .AutoProvision()
        .UseConventionalRouting();

    options.Policies.DisableConventionalLocalRouting();
    options.PersistMessagesWithPostgresql(connectionString!);
});

Dettagli importanti di questa configurazione:

• AutoProvision(): crea automaticamente exchange e code in RabbitMQ
• UseConventionalRouting(): instrada i messaggi in base ai nomi dei tipi
• DisableConventionalLocalRouting(): forza tutti i messaggi attraverso RabbitMQ
• PersistMessagesWithPostgresql(): archivia stato della saga e messaggi; crea una tabella per saga con serializzazione JSON

Definizione dei messaggi

Ogni passo della saga è rappresentato da un messaggio. Definiamo tutti i tipi di messaggio per un processo di onboarding utente:

public record SendVerificationEmail(Guid UserId, string Email);
public record VerificationEmailSent(Guid Id);
public record VerifyUserEmail(Guid Id);
public record SendWelcomeEmail(Guid UserId, string Email, string FirstName);
public record WelcomeEmailSent(Guid Id);
public record OnboardingTimedOut(Guid Id) : TimeoutMessage(5.Minutes());

Il record OnboardingTimedOut estende TimeoutMessage di Wolverine: questo fa sì che il messaggio venga consegnato automaticamente dopo 5 minuti, eliminando la necessità di scheduler esterni per gestire i timeout.

Implementazione della classe Saga

La saga viene implementata come una classe che estende Saga. Lo stato viene mantenuto come proprietà della classe:

public class UserOnboardingSaga : Saga
{
    public Guid Id { get; set; }
    public string Email { get; set; } = string.Empty;
    public string FirstName { get; set; } = string.Empty;
    public string LastName { get; set; } = string.Empty;
    public bool IsVerificationEmailSent { get; set; }
    public bool IsEmailVerified { get; set; }
    public bool IsWelcomeEmailSent { get; set; }
}

Il metodo Start: avvio della saga

Il metodo statico Start è il factory method che inizia la saga. Restituisce una tupla contenente l’istanza della saga, il comando iniziale e il messaggio di timeout pianificato:

public static (
    UserOnboardingSaga,
    SendVerificationEmail,
    OnboardingTimedOut) Start(
        UserRegistered @event,
        ILogger<UserOnboardingSaga> logger)
{
    var saga = new UserOnboardingSaga
    {
        Id = @event.Id,
        Email = @event.Email,
        FirstName = @event.FirstName,
        LastName = @event.LastName,
    };

    return (
        saga,
        new SendVerificationEmail(saga.Id, saga.Email),
        new OnboardingTimedOut(saga.Id));
}

Wolverine persiste automaticamente la saga e consegna tutti i messaggi restituiti. Elegante e senza boilerplate.

Metodi Handle: gestione degli eventi

I metodi Handle elaborano i messaggi in arrivo. Se restituiscono void, aggiornano solo lo stato; se restituiscono un messaggio, causano l’invio del passo successivo:

public void Handle(VerificationEmailSent @event, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Email di verifica inviata per l'utente {UserId}", Id);
    IsVerificationEmailSent = true;
}

public SendWelcomeEmail Handle(VerifyUserEmail command, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Email verificata per l'utente {UserId}", Id);
    IsEmailVerified = true;
    return new SendWelcomeEmail(Id, Email, FirstName);
}

public void Handle(WelcomeEmailSent @event, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Onboarding completato per l'utente {UserId}", Id);
    IsWelcomeEmailSent = true;
    MarkCompleted(); // Elimina lo stato dal database
}

Gestione del timeout e compensazione

Il timeout è un cittadino di prima classe in Wolverine. Se l’utente non verifica l’email entro 5 minuti, il handler del timeout gestisce la compensazione:

public void Handle(OnboardingTimedOut timeout, ILogger<UserOnboardingSaga> logger)
{
    if (IsEmailVerified)
    {
        logger.LogInformation(
            "Timeout ignorato - email già verificata per {UserId}", Id);
        return;
    }

    logger.LogWarning(
        "Onboarding scaduto per {UserId} - email non verificata", Id);
    MarkCompleted();
}

Gestione dei messaggi “orfani” con NotFound

Wolverine richiede la gestione esplicita del caso in cui arrivi un messaggio per una saga già terminata, tramite metodi statici NotFound:

public static void NotFound(VerifyUserEmail command, ILogger<UserOnboardingSaga> logger)
{
    logger.LogWarning("VerifyEmail ricevuto ma la saga {Id} non esiste più", command.Id);
}

public static void NotFound(OnboardingTimedOut timeout, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Timeout per la saga già completata {Id}", timeout.Id);
}

Correlazione dei messaggi e gestione della concorrenza

Wolverine correla automaticamente i messaggi alle istanze della saga cercando nell’ordine: attributo [SagaIdentity], proprietà {SagaTypeName}Id, oppure proprietà Id. Non è necessaria alcuna configurazione esplicita per i casi standard.

Per la concorrenza, Wolverine applica di default il controllo di concorrenza ottimistico: quando più messaggi per la stessa saga arrivano contemporaneamente, uno riesce mentre gli altri vengono ritentati automaticamente. Attenzione: non invocare IMessageBus.InvokeAsync() all’interno dei handler della stessa saga, ma usare sempre i messaggi in cascata (valori di ritorno) per evitare problemi con dati obsoleti.

Opzioni di persistenza

Wolverine supporta tre strategie per la persistenza dello stato della saga:

• Lightweight Storage: serializza lo stato come JSON in tabelle dedicate per saga, zero configurazione ORM
• Marten: archivia le saghe come documenti con concorrenza ottimistica e ID fortemente tipizzati
• Entity Framework Core: mappa le saghe su tabelle queryabili, abilitando commit in singola transazione con altri dati

Il flusso completo

Il percorso “happy path” dell’onboarding segue questi passi:

1. L’evento UserRegistered attiva il metodo Start()
2. Viene creata l’istanza della saga, inviato SendVerificationEmail e pianificato OnboardingTimedOut
3. VerificationEmailSent aggiorna lo stato della saga
4. VerifyUserEmail ricevuto, viene inviato in cascata SendWelcomeEmail
5. WelcomeEmailSent completa il workflow, la saga viene eliminata

Se VerifyUserEmail non arriva entro 5 minuti, OnboardingTimedOut gestisce la compensazione e termina la saga.

Conclusione

Wolverine offre un approccio sorprendentemente pulito all’implementazione del Pattern Saga in .NET. La scelta convention-driven elimina gran parte del boilerplate tipico di altri framework, consentendo di concentrarsi sulla logica di business. La gestione automatica di persistenza, routing e correlazione dei messaggi, unita al supporto nativo per timeout e compensazione, lo rende una scelta solida per workflow distribuiti complessi.

Per i team che lavorano con architetture a microservizi in .NET, Wolverine merita certamente una valutazione approfondita come alternativa moderna ai pattern tradizionali di orchestrazione.

Fonte originale: Implementing the Saga Pattern With Wolverine — Milan Jovanović

Implementing the Saga Pattern With Wolverine

Long-running business processes don't fit neatly into a single request. Wolverine's Saga support gives you a convention-based approach to orchestrating workflows in .NET - with built-in timeout handling and compensation.

^{www.milanjovanovic.tech}

(in)sicurezza digitale

2026-04-13 13:43:24

La catena di fornitura software colpita: come CPUID è stata compromessa per distribuire il RAT stealer STX

Nel mese di aprile 2026, i ricercatori di sicurezza hanno identificato un attacco di supply chain sofisticato ai danni di CPUID, l’azienda dietro i popolarissimi tool di monitoraggio hardware CPU-Z e HWMonitor. Gli attaccanti hanno compromesso i server dell’azienda e reindirizzato i download ufficiali verso versioni malware. Per il corso di sei ore, gli utenti che scaricavano CPU-Z e HWMonitor dai siti ufficiali ricevevano un Remote Access Trojan precedentemente non documentato denominato STX RAT.

Questo incidente exemplifica una tendenza crescente nel panorama delle minacce informatiche: gli attaccanti hanno capito che il modo più efficace per ottenere una penetrazione di massa non è attaccare i singoli utenti, ma compromettere i software publisher e i loro canali di distribuzione. Se il software che stai scaricando oggi da un sito ufficiale contiene malware, la fiducia nella sicurezza della catena di distribuzione software crolla completamente.

Anatomia dell’attacco: come gli attaccanti hanno compromesso CPUID

A differenza di molti attacchi di supply chain che richiedono il compromesso dei sistemi di build e signing di un’azienda, gli attaccanti dietro questo incidente hanno adottato un approccio più mirato. Invece di cercare di infettare i binari finali di CPU-Z o HWMonitor (che sono firmati digitalmente), gli attaccanti hanno compromesso un’API secondaria utilizzata da CPUID per servire i link di download sul proprio sito web.

Modificando questa API, gli attaccanti hanno reindirizzato le richieste degli utenti verso file malevoli ospitati su Cloudflare R2. Le vittime pensavano di scaricare il software legittimo direttamente dal sito CPUID, ma ricevevano invece il malware. Non è stata trovata alcuna evidenza che gli attaccanti abbiano compromesso il processo di compilazione, il sistema di signing dei binari, o i server di controllo della versione di CPUID.

Il malware: STX RAT e le sue capacità

STX RAT è stato nominato da eSentire per la sua caratteristica firma tecnica: l’utilizzo consistente del byte STX come magic byte per prefisso nei messaggi diretti al command-and-control (C2).

Capacità di infostealer

Browser e credenziali web:

• Estrazione di password, cookie, e dati di autofill da Firefox, SeaMonkey, e browser basati su Chromium (Chrome, Edge, Brave, ecc.)
• Bypass potenziale di Application-Bound Encryption (ABE) sulle credenziali crittografate di Windows

Portafogli di criptovalute:

• Furto di chiavi private da Litecoin-Qt, Electrum, e altri wallet desktop
• Accesso a file di configurazione che contengono seed phrase o wallet backup

Credenziali client FTP:

• Estrazione di dati di accesso da FileZilla, WinSCP, e altri client FTP

Remote Desktop nascosto (HVNC)

Una capacità particolarmente insidiosa di STX RAT è il supporto per hidden VNC (Virtual Network Computing). Questo permette all’attaccante di:

• Avviare una sessione desktop virtuale nascosta che non è visibile agli utenti locali
• Controllare il mouse e la tastiera tramite l’API SendInput di Windows
• Eseguire applicazioni e navigare nel filesystem senza alcun indicatore visibile all’utente locale
• Accedere ai dati sensibili mentre l’utente legittimo è offline

I comandi supportati includono “starthvnc”, “keypress”, “mouseinput”, “mousewheel”, e “switchdesktop”, fornendo una suite completa di controllo remoto.

Tattica di delivery: DLL Sideloading

Il vettore di consegna del malware utilizza una tecnica classica pero ancora efficace: DLL sideloading (also known as DLL hijacking). Quando un utente scaricava il file trojanizzato da HWMonitor, conteneva:

• HWMonitor_x64.exe – Un file con nome legittimo (il binario vero di HWMonitor)
• CRYPTBASE.dll – Una DLL malevola che l’eseguibile legittimo carica automaticamente

Poiché Windows segue un ordine di ricerca delle DLL specifico, quando HWMonitor_x64.exe cerca di caricare CRYPTBASE.dll, trova prima la versione malevola nella stessa directory. Questo causa l’esecuzione del codice dell’attaccante con gli stessi privilegi dell’applicazione legittima.

Indicatori tecnici e infrastruttura C2

C2 Server: 95.216.51.236
Malware: STX RAT
Compromesso: 9-10 aprile 2026
Download malevoli: CPU-Z, HWMonitor versioni x64 e x86
DLL sideload: CRYPTBASE.dll

Il malware STX RAT è configurato per contattare il C2 all’indirizzo IP 95.216.51.236. Al primo contatto, il malware invia un messaggio di “introduzione” contenente: nome dell’host, nome utente, versione OS, status amministrativo, RAM disponibile, e elenco antivirus installati.

Inoltre, eSentire ha documentato che STX RAT supporta il routing del traffico C2 attraverso Tor per garantire anonimato, rendendo la tracciatura della comunicazione estremamente difficile.

Impatto e distribuzione

Kaspersky ha identificato oltre 150 vittime dirette dell’incidente CPUID. La distribuzione geografica mostra una concentrazione in Brasile, Russia, e Cina, con settori colpiti che includono: retail e e-commerce, manufacturing, consulting, telecomunicazioni, e agricoltura.

Il fatto che utenti in settori critici siano stati infetti suggerisce che STX RAT potrebbe essere utilizzato sia per cyber-spionaggio che per estorsione, poiché il malware combina capacità di reconnaissance (infostealing) con accesso remoto completo (HVNC).

Timeline dell’incidente

• 9 aprile 2026, ~15:00 UTC: Gli attaccanti modificano l’API di CPUID, reindirizzando i download
• 10 aprile 2026, ~10:00 UTC: CPUID scopre l’anomalia e ripristina l’API
• 10 aprile 2026: eSentire pubblica analisi tecnica del malware
• 13 aprile 2026: Kaspersky fornisce dati sulla distribuzione geografica

Raccomandazioni per le organizzazioni

• Verifica dell’integrità: Implementare processi di verifica dell’hash per tutti i software scaricati, anche da fonti ufficiali.
• Sandboxing: Eseguire software appena scaricati in ambienti virtuali isolati prima dell’installazione.
• Monitoraggio DLL loading: Implementare EDR in grado di rilevare il caricamento inusuale di DLL.
• Blocco C2: Aggiungere 95.216.51.236 alle blocklists firewall immediate.
• Credential rotation: Ruotare credenziali per chi ha scaricato HWMonitor/CPU-Z tra 9-10 aprile.
• Threat intelligence: Adottare YARA rules da eSentire per rilevare STX RAT in memoria.

Conclusione

L’incidente CPUID dimostra che la sicurezza della catena di distribuzione software non è negoziabile. Anche i siti ufficiali di società legittime possono essere compromessi. I defender devono adottare un mindset di “zero trust” verso qualsiasi software e implementare verifiche multi-strato di integrità e autenticità prima dell’esecuzione.