Spcnet.it

2026-04-25 19:12:54

.NET 10 su Ubuntu 26.04 “Resolute Raccoon”: installazione, container e Native AOT

Ubuntu 26.04 LTS, nome in codice Resolute Raccoon, è disponibile e porta con sé una delle novità più attese per gli sviluppatori .NET su Linux: .NET 10 è il runtime ufficiale incluso nel repository standard. In questo articolo esploriamo come installare .NET 10, come aggiornare le immagini container esistenti e come sfruttare Native AOT per ottenere binari ultra-compatti con avvio in pochi millisecondi.

Perché .NET e Ubuntu insieme

La collaborazione tra Microsoft e Canonical non è nuova: ogni nuovo Ubuntu LTS porta con sé l’ultimo .NET LTS come toolchain ufficialmente supportata. Ubuntu 26.04 non fa eccezione: .NET 10 è direttamente installabile via APT senza configurare PPA aggiuntive. Per chi lavora in ambienti enterprise o vuole un’infrastruttura stabile e aggiornabile tramite il gestore pacchetti di sistema, questo è un vantaggio non trascurabile.

È comunque possibile installare anche .NET 8 e .NET 9 tramite PPA dedicata, per chi ha applicazioni su versioni precedenti.

Installazione rapida

L’installazione di .NET 10 su Ubuntu 26.04 è immediata:

sudo apt update
sudo apt install dotnet-sdk-10.0

Nessun repository aggiuntivo, nessuna chiave GPG da configurare manualmente. Il package manager si occupa di tutto. Per verificare la versione installata:

dotnet --version
# 10.0.105

Eseguire C# direttamente da stdin

Una delle funzionalità meno note ma molto utile per script e automazione è la possibilità di passare codice C# direttamente a dotnet run via stdin, usando i file-based apps:

dotnet run - << 'EOF'
using System.Runtime.InteropServices;
Console.WriteLine($"Hello {RuntimeInformation.OSDescription} from .NET {RuntimeInformation.FrameworkDescription}");
EOF
# Hello Ubuntu Resolute Raccoon from .NET .NET 10.0.5

Questo pattern è particolarmente utile negli script di sistema e nei workflow CI/CD dove si vuole eseguire logica .NET senza creare un progetto completo.

Novità rilevanti di Ubuntu 26.04 per .NET

Ubuntu 26.04 introduce tre cambiamenti che impattano direttamente gli stack .NET in produzione:

• Linux 7.0: il team .NET avvierà test su questo kernel non appena disponibili VM nel laboratorio. Le prime build sono già in CI.
• Post-Quantum Cryptography: Ubuntu 26.04 spinge su questo fronte e .NET 10 include già il supporto agli algoritmi post-quantum, quindi la compatibilità è garantita.
• Rimozione di cgroup v1: nessun problema per .NET, che supporta cgroup v2 da diversi anni. Tuttavia, chi usa container con immagini molto datate o configurazioni cgroup v1 dovrà verificare la compatibilità.

Container: aggiornare da noble a resolute

Le immagini ufficiali per .NET 10 sono già disponibili con il tag resolute. Aggiornare un Dockerfile esistente è questione di un semplice sed:

sed -i "s/noble/resolute/g" Dockerfile.chiseled

Esempio di build e avvio con limiti di risorse:

docker build --pull -t aspnetapp -f Dockerfile.chiseled .
docker run --rm -it -p 8000:8080 -m 50mb --cpus .5 aspnetapp

Le varianti Chiseled (immagini minimali senza shell e strumenti non necessari) sono disponibili anche per resolute, con le stesse caratteristiche di sicurezza della versione noble.

Nota importante: i container ereditano il kernel dell’host. Un container resolute su un host Ubuntu 24.04 userà il kernel 6.x dell’host, non Linux 7.0. Tenere presente questa distinzione in fase di planning.

Native AOT: binari compatti e avvio in 3ms

Native AOT (NAOT) è una delle funzionalità più potenti di .NET 10 per scenari server e CLI. Su Ubuntu 26.04, il pacchetto dedicato è dotnet-sdk-aot-10.0:

apt install -y dotnet-sdk-aot-10.0 clang

Pubblicando una semplice applicazione console come NAOT si ottiene un binario da circa 1.4 MB, pronto all’esecuzione senza runtime installato:

dotnet publish app.cs
du -h artifacts/app/*
# 1.4M  artifacts/app/app
# 3.0M  artifacts/app/app.dbg

Le performance di avvio sono notevoli:

time ./artifacts/app/app
# real 0m0.003s

3 millisecondi. Per confronto, un’applicazione .NET classica JIT può richiedere 100-500ms di warm-up in scenari tipici. Native AOT è la scelta ideale per CLI tools, Lambda functions, microservizi ad avvio freddo e sidecar container.

Per applicazioni web, lo stesso approccio funziona con <PublishAot>true</PublishAot> nel .csproj:

dotnet publish
# Produce: releasesapi (13MB) + releasesapi.dbg (32MB)

Considerazioni pratiche per il team di sviluppo

Per chi gestisce pipeline CI/CD con Ubuntu, questo rilascio semplifica notevolmente la gestione delle dipendenze: non è più necessario configurare feed Microsoft o repository aggiuntivi per .NET 10. L’intero stack è aggiornabile tramite apt upgrade come qualsiasi altro pacchetto di sistema.

Per i team che usano container come base di sviluppo standardizzata, aggiornare il tag da -noble a -resolute nei Dockerfile è sufficiente per passare alla nuova LTS. È comunque raccomandato verificare la compatibilità con la propria configurazione cgroup se si usano orchestratori come Kubernetes con configurazioni custom.

Conclusione

Ubuntu 26.04 LTS consolida ulteriormente la posizione di Linux come piattaforma di prima classe per .NET. L’integrazione diretta nel repository APT, il supporto alle immagini Chiseled, la compatibilità post-quantum e le performance eccezionali di Native AOT fanno di questo rilascio un upgrade significativo per chiunque sviluppi o distribuisca applicazioni .NET su Linux.

Fonte: What’s new for .NET in Ubuntu 26.04 – Richard Lander, Microsoft .NET Blog

What's new for .NET in Ubuntu 26.04 - .NET Blog

Ubuntu 26.04 (Resolute Raccoon) ships today with .NET 10. Here's how to install .NET 10 from the archive, use the new -resolute container tags, build Native AOT apps, and install .NET 8 and 9 from the dotnet-backports PPA.

^{Richard Lander (.NET Blog)}

Spcnet.it

2026-04-25 12:31:12

File RDP non fidati dopo la patch Windows di Aprile 2026: come firmarli con PowerShell

Chi gestisce ambienti Windows aziendali potrebbe aver notato, nelle ultime settimane, che i propri utenti si trovano davanti a finestre di avviso insolite quando aprono i file .rdp. Non si tratta di un malfunzionamento: è una modifica intenzionale introdotta da Microsoft con le patch cumulative di aprile 2026, in risposta a una vulnerabilità di sicurezza sfruttata attivamente.

In questo articolo analizziamo cosa è cambiato, perché è cambiato e soprattutto come adeguare i propri ambienti per continuare a usare i file RDP in modo fluido e sicuro.

La vulnerabilità alla base del cambiamento: CVE-2026-26151

Le patch cumulative KB5083769 (Windows 11) e KB5082200 (Windows 10) introducono nuove protezioni per i file di connessione Remote Desktop (.rdp). La motivazione è la CVE-2026-26151, una vulnerabilità di spoofing RDP sfruttata attivamente in ambienti reali.

Il gruppo russo APT29 (noto anche come Cozy Bear), legato all’SVR (servizio di intelligence estero russo), ha distribuito file .rdp malevoli tramite campagne di phishing mirate. Questi file, apparentemente innocui, erano in grado di:

• Redirigere unità locali e periferiche verso sistemi remoti controllati dagli attaccanti
• Modificare silenziosamente le impostazioni di connessione
• Ingannare gli utenti inducendoli a connettersi a sistemi non previsti
• Esfiltrare credenziali e dati locali

I file RDP sono da sempre un vettore di attacco sottovalutato: non sono eseguibili nel senso tradizionale del termine, quindi gli utenti tendono a fidarsi di essi, ma possono comunque influenzare in modo significativo il comportamento di una sessione remota.

Cosa cambia concretamente

Con le nuove patch, Windows tratta i file .rdp non firmati digitalmente come non attendibili per impostazione predefinita. Le conseguenze pratiche sono:

• La prima volta che si apre un file .rdp dopo l’aggiornamento, compare un “educational dialog” che spiega i rischi dei file RDP e del phishing
• Aprendo un file non firmato, appare un avviso con banner “Caution: Unknown remote connection” e il campo Publisher impostato a “Unknown publisher”
• Alcune funzionalità (come la redirezione degli appunti o delle unità locali) possono essere bloccate o richiedono conferma esplicita ad ogni uso

Nota importante: queste restrizioni si applicano solo ai file .rdp. Chi si connette digitando manualmente l’hostname nel client mstsc.exe o tramite riga di comando con mstsc /v:hostname non vedrà alcun avviso aggiuntivo.

Come risolvere: la firma digitale dei file RDP

La soluzione raccomandata da Microsoft è firmare digitalmente i file .rdp con un certificato di code signing attendibile. Una volta firmato, Windows può verificare l’autenticità e l’integrità del file, eliminando gli avvisi e ripristinando le funzionalità complete.

Lo strumento nativo per la firma è rdpsign.exe, incluso in Windows. Il comando base è:

rdpsign.exe /sha256 <thumbprint_certificato> <percorso_file.rdp>

Esempio pratico:

rdpsign.exe /sha256 A1B2C3D4E5F6... "C:\RDP\ServerAziendale.rdp"

Qualsiasi modifica al file dopo la firma invalida la firma stessa, garantendo l’integrità del documento.

Quale certificato usare?

Esistono tre opzioni principali, ciascuna adatta a scenari diversi:

• Certificato self-signed: gratuito, utile per ambienti di test o reti interne piccole. Deve essere distribuito manualmente su ogni macchina client come certificato attendibile.
• Certificato da Enterprise CA (Active Directory): la scelta ideale per ambienti di dominio. I certificati emessi dalla CA aziendale sono automaticamente attendibili su tutte le macchine domain-joined. Nessun costo aggiuntivo se si dispone già di una PKI interna.
• Certificato commerciale (DigiCert, ecc.): la scelta per ambienti con utenti esterni o macchine non domain-joined. Attendibile di default su tutti i sistemi Windows, ma comporta un costo annuale.

In alternativa, Microsoft Azure offre il servizio Trusted Signing, integrato con Entra ID e RBAC, come soluzione economica e moderna rispetto ai certificati commerciali tradizionali.

Automatizzare la firma con PowerShell: RDPFileSigner.ps1

Michael Morten Sonne ha rilasciato uno script PowerShell open-source chiamato RDPFileSigner.ps1 che automatizza l’intero flusso, dalla creazione del certificato alla firma, verifica e integrazione con Windows Explorer. Lo script è disponibile su GitHub.

Le principali modalità operative:

# Setup iniziale: crea/riusa il certificato, lo installa nei trust store
# e registra il menu contestuale per i file .rdp
.\RDPFileSigner.ps1

# Firmare un singolo file
.\RDPFileSigner.ps1 -Sign -RdpFile "C:\RDP\Server.rdp"

# Firmare tutti i file .rdp in una cartella (incluse sottocartelle)
.\RDPFileSigner.ps1 -Sign -RdpFolder "C:\RDP" -Recurse

# Usare un certificato Enterprise CA
.\RDPFileSigner.ps1 -Setup -CertTemplate "CodeSigning"

# Importare un certificato commerciale da .pfx
.\RDPFileSigner.ps1 -Setup -ImportPfxPath "C:\Certs\commercial.pfx"

# Verificare la firma su tutti i file in una cartella con report CSV
.\RDPFileSigner.ps1 -Verify -RdpFolder "C:\RDP" -ExportCsvPath "C:\Report\rdp-status.csv"


Lo script supporta anche la registrazione di un Scheduled Task che controlla automaticamente una cartella ogni 5 minuti e firma tutti i file .rdp presenti: utile quando i file vengono generati dinamicamente da soluzioni PAM o portali helpdesk:

.\RDPFileSigner.ps1 -TaskRegister -WatchFolder "C:\RDP" -CertThumbprint "A1B2C3..."


La modalità -Verify effettua una verifica crittografica completa: ricostruisce il blob firmato originale, decodifica la firma PKCS#7 incorporata nel file e invoca CheckSignature() per rilevare qualsiasi modifica post-firma. Il codice di uscita 2 in caso di firme non valide lo rende utilizzabile in pipeline CI/CD o script di monitoraggio.

Disabilitare temporaneamente le protezioni (sconsigliato)

Microsoft ha documentato un workaround tramite registro di sistema per disabilitare temporaneamente le nuove protezioni, ma lo sconsiglia esplicitamente e potrebbe rimuovere questo supporto in aggiornamenti futuri:

HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client
Nome: RedirectionWarningDialogVersion
Tipo: REG_DWORD
Valore: 1


Questa opzione non dovrebbe mai essere usata in produzione: bypassa una protezione pensata per contrastare attacchi reali e già sfruttati attivamente.

Raccomandazioni operative

Al di là della firma digitale, è buona pratica cogliere l’occasione per rivedere più in generale la gestione dei file RDP nell’organizzazione:

• Evitare la distribuzione via email: preferire portali interni attendibili o soluzioni di Remote Desktop Gateway
• Ridurre le redirections al minimo necessario: ogni redirezione abilitata è una potenziale superficie di attacco
• Formare gli utenti: spiegare il significato degli avvisi e quando è sicuro procedere evita la “warning fatigue”
• Automatizzare il rinnovo dei certificati: integrare la firma nel processo di generazione dei file RDP per non dover intervenire manualmente a ogni scadenza

Conclusioni

La modifica introdotta con le patch di aprile 2026 non è un bug né una scelta arbitraria: è la risposta di Microsoft a una vulnerabilità concretamente sfruttata da attori di threat intelligence statali. Per i team IT, il percorso più corretto è implementare la firma digitale dei file RDP, scegliendo il tipo di certificato più adatto al proprio ambiente.

Chi gestisce ambienti di dominio troverà probabilmente nella Enterprise CA la soluzione più rapida e senza costi aggiuntivi. Chi ha utenti esterni o macchine non domain-joined dovrebbe valutare Azure Trusted Signing come alternativa economica ai certificati commerciali tradizionali.

Fonte: Your RDP files are now untrusted after the April 2026 Windows Patch – Sign them with PowerShell (Sonne’s Cloud Blog)

Artifact Signing documentation

Artifact Signing is a Microsoft fully managed end-to-end signing solution for partner developers. The service is currently in public preview.

^{learn.microsoft.com}

(in)sicurezza digitale

2026-04-25 12:33:32

StealTok: 130.000 utenti spiati da 12 estensioni browser mascherate da downloader TikTok

Dodici estensioni browser, distribuite su Chrome e Microsoft Edge, si sono rivelate un’infrastruttura di spionaggio sofisticata che ha silenziosamente compromesso oltre 130.000 utenti. La campagna, denominata StealTok dai ricercatori di LayerX Security, ha sfruttato la popolarità dei downloader di video TikTok per introdurre spyware in grado di raccogliere dati ad alta entropia dai dispositivi delle vittime.

Una campagna costruita sulla fiducia

Il meccanismo più insidioso di StealTok non risiede nelle sue capacità tecniche, ma nella sua strategia di infiltrazione. Le estensioni malevole si comportavano esattamente come promesso per i primi 6-12 mesi dalla pubblicazione sugli store ufficiali: scaricavano video TikTok senza watermark in modo impeccabile, alcune guadagnando persino il badge “Featured” nei marketplace di Chrome e Edge. Solo dopo aver accumulato una base utenti significativa e instaurato un rapporto di fiducia, le estensioni attivavano il payload malevolo.

Questa tattica di “dormienza prolungata” rappresenta un’evoluzione significativa rispetto alle tradizionali estensioni malware che manifestano comportamenti sospetti fin dall’installazione. Il periodo di latenza ha permesso agli operatori di StealTok di eludere i controlli automatizzati dei marketplace e le revisioni manuali, che generalmente si concentrano sul comportamento immediatamente successivo all’installazione.

Meccanismo di attivazione e infrastruttura C2

Una volta superato il periodo di dormienza, le estensioni stabiliscono connessioni con server di comando e controllo (C2) per scaricare configurazioni dinamiche remote. Questo approccio consente agli attori malevoli di modificare il comportamento delle estensioni in tempo reale, aggiornare le istruzioni di raccolta dati senza richiedere aggiornamenti dello store, e rendere l’analisi forense più complessa poiché il codice malevolo non risiede staticamente nell’estensione stessa.

L’infrastruttura di supporto mostrava segnali chiari di operazione organizzata: molti domini presentavano pattern di typosquatting, come “trafficreqort” invece di “trafficreport” o “tiktak” al posto di “tiktok”, indicando una pianificazione deliberata per evitare blacklist automatiche basate su reputazione del dominio.

Raccolta dati e device fingerprinting

Una volta attivato il modulo spyware, le estensioni avviavano una raccolta sistematica di telemetria del dispositivo. Il profilo costruito su ogni vittima includeva: pattern di navigazione web e contenuti scaricati, impostazioni di sistema come timezone e lingua del browser, dati del dispositivo come lo stato della batteria, informazioni sull’ambiente di esecuzione per rilevare sandbox o ambienti di analisi.

L’utilizzo di dati ad alta entropia — come la combinazione di timezone, lingua, risoluzione dello schermo e stato della batteria — è una tecnica di fingerprinting avanzata in grado di identificare univocamente un dispositivo anche in assenza di cookie o identificatori espliciti. Questa tecnica è tipicamente associata a operatori sofisticati interessati a costruire profili duraturi degli utenti piuttosto che a semplici furti di credenziali.

Le estensioni compromesse

LayerX Security ha identificato almeno 12 estensioni coinvolte nella campagna, con circa 12.500 installazioni ancora attive al momento della scoperta. Le più diffuse erano le seguenti:

• TikTok Video Keeper — ~60.000 installazioni (Chrome)
• Mass TikTok Video Downloader — ~30.000 installazioni
• Video Downloader for TikTok — ~20.000 installazioni
• TikTok Downloader – Save Videos, No Watermark — ~10.000 installazioni

Google ha rimosso le estensioni identificate dal Chrome Web Store. Microsoft Edge Add-ons ha adottato misure analoghe. Tuttavia, gli operatori della campagna hanno dimostrato resilienza, ricreando estensioni con nomi e aspetti leggermente modificati riutilizzando lo stesso codebase condiviso — una tattica che suggerisce un’operazione ben strutturata con capacità di recupero rapido.

Contesto e attribuzioni

La campagna StealTok si inserisce in un trend preoccupante di abuso degli store di estensioni browser come vettore di attacco. A differenza degli attacchi tradizionali che richiedono l’exploit di vulnerabilità, le estensioni malware sfruttano i permessi esplicitamente concessi dall’utente. Un’estensione browser, per sua natura, ha accesso privilegiato al traffico web, ai contenuti delle pagine, e potenzialmente alle credenziali inserite nei form.

La tecnica della dormienza prolungata era già stata osservata in operazioni precedenti legate a broker di dati e reti pubblicitarie opache, ma raramente applicata con questa scala e questa sistematicità. Il fatto che le estensioni abbiano ottenuto badge “Featured” ufficiali evidenzia le limitazioni dei processi di review degli store, che dipendono in parte da segnali comportamentali nel breve periodo.

Indicatori di compromissione (IoC)

Domini C2 identificati (typosquatting pattern):
- trafficreqort[.]com
- tiktak-download[.]com
- tiktok-vid-dl[.]com

Estensioni Chrome rimosse (ID parziali noti):
- TikTok Video Keeper
- Mass TikTok Video Downloader  
- Video Downloader for TikTok
- TikTok Downloader – Save Videos, No Watermark

Comportamenti sospetti da monitorare:
- Connessioni HTTP/HTTPS verso domini non correlati all'uso dichiarato
- Richieste fetch() verso endpoint di configurazione dinamica post-installazione
- Accesso a navigator.getBattery() e navigator.language in estensioni di download video

Consigli per i difensori

Per le organizzazioni, è consigliabile implementare policy di gestione delle estensioni browser tramite soluzioni MDM/EDR che blocchino l’installazione di estensioni non approvate dall’IT, monitorare il traffico di rete generato dai browser verso domini non categorizzati, e adottare strumenti di browser security come quelli offerti da vendor specializzati (LayerX, Island, Talon) in grado di analizzare il comportamento runtime delle estensioni. Per gli utenti individuali, la regola fondamentale rimane quella di limitare al minimo il numero di estensioni installate, privilegiare solo quelle di vendor riconoscibili con track record verificabile, e rivedere periodicamente i permessi concessi.

(in)sicurezza digitale

2026-04-24 18:17:28

GopherWhisper: il nuovo APT cinese che spia il governo mongolo nascondendo il C2 in Slack, Discord e Outlook

ESET Research ha scoperto GopherWhisper, un nuovo gruppo APT allineato alla Cina attivo dal novembre 2023, specializzato nello spionaggio di istituzioni governative in Mongolia. La particolarità operativa che distingue questo attore: utilizza Discord, Slack e le bozze di Microsoft Outlook come canali di command-and-control, rendendo il traffico malevolo praticamente indistinguibile dalle normali comunicazioni aziendali.

Scoperta e attribuzione: 12 sistemi governativi mongoli compromessi

La ricerca pubblicata da ESET il 23 aprile 2026 rivela che GopherWhisper ha compromesso almeno 12 sistemi appartenenti a un’istituzione governativa mongola, con attività iniziata nel novembre 2023. La telemetria raccolta ha permesso ai ricercatori di recuperare migliaia di messaggi degli operatori direttamente dai server Discord e Slack compromessi, grazie al recupero di token API inclusi nel codice dei backdoor.

L’attribuzione alla Cina si basa su più elementi convergenti: l’analisi dei timestamp dei messaggi Slack e Discord mostra che il grosso delle comunicazioni avviene tra le 8:00 e le 17:00, perfettamente allineato con il China Standard Time (UTC+8). I metadati di configurazione dell’utente Slack configurato dagli operatori riportano inoltre il fuso orario cinese. ESET stima che le vittime complessive siano potenzialmente decine, ma non ha informazioni sulla loro geolocalizzazione o settore.

L’arsenale: sette tool, quattro backdoor, un’infrastruttura C2 distribuita

GopherWhisper si distingue per la proliferazione di strumenti personalizzati — sette in totale, quattro dei quali sono backdoor distinte. Questa ridondanza suggerisce un’organizzazione con risorse sufficienti per sviluppare e mantenere un ecosistema malware parallelo, probabilmente con team distinti per componente.

LaxGopher — Backdoor Go via Slack

Backdoor scritta in Go che usa Slack come canale C2. Esegue comandi tramite cmd.exe, pubblica i risultati su un canale Slack configurato e può scaricare payload aggiuntivi. La comunicazione avviene attraverso le API ufficiali di Slack, rendendola quasi impossibile da rilevare a livello di firewall senza ispezione applicativa.

RatGopher — Backdoor Go via Discord

Backdoor analoga a LaxGopher ma che usa Discord come infrastruttura C2. Riceve messaggi da un server Discord privato, esegue comandi, pubblica i risultati sui canali configurati e gestisce upload/download da file[.]io. L’uso di due piattaforme separate (Slack e Discord) per backdoor distinte è probabilmente una strategia di ridondanza operativa.

BoxOfFriends — Backdoor via bozze Outlook

La backdoor più sofisticata dal punto di vista della tradecraft: gestisce il C2 attraverso bozze email di Microsoft 365 Outlook. Le istruzioni vengono scritte come bozze sul server di posta — mai inviate — e recuperate dal backdoor. Questa tecnica sfrutta il fatto che il traffico HTTPS verso i server Microsoft è quasi universalmente consentito e ignorato dagli strumenti di monitoraggio. È una variante della tecnica nota come “draft-based C2”, già osservata in alcuni APT mediorientali.

SSLORDoor — Backdoor C++ con raw socket

Backdoor scritta in C++ che comunica su porta 443 attraverso connessioni raw socket con OpenSSL BIO. A differenza dei backdoor Go che usano servizi cloud legittimi, SSLORDoor comunica direttamente con infrastruttura C2 controllata dall’attaccante. Supporta enumerazione di drive, operazioni su file e esecuzione di comandi via cmd.exe.

CompactGopher — Strumento di esfiltrazione

Tool Go-based di raccolta e esfiltrazione file, deployato da LaxGopher. Filtra i file di interesse per estensione, li comprime in ZIP, li cifra con AES-CFB-128 e li esfiltra su file[.]io. Le estensioni target sono documentali: .doc, .docx, .jpg, .xls, .xlsx, .txt, .pdf, .ppt, .pptx.

FriendDelivery e JabGopher

FriendDelivery è una DLL malevola che funge da loader e injector per BoxOfFriends. JabGopher è un injector generico del toolkit. Entrambi i componenti svolgono funzioni di supporto nell’ecosistema GopherWhisper, gestendo il deployment e l’iniezione dei backdoor principali.

Living off Trusted Services: la nuova frontiera dell’evasione APT

La scelta di Discord, Slack e Outlook come canali C2 non è casuale: rappresenta l’evoluzione della tecnica “Living off the Land” applicata ai servizi cloud. Invece di abusare di tool di sistema Windows legittimi, GopherWhisper abusa di servizi cloud enterprise affidabili il cui traffico è quasi impossibile da bloccare senza interrompere le operazioni aziendali normali.

L’approccio crea un problema fondamentale per i difensori: bloccare Discord o Slack a livello di firewall è tecnicamente fattibile, ma spesso politicamente impraticabile in organizzazioni che li usano quotidianamente. Rilevare il C2 richiede quindi un’analisi comportamentale del traffico verso questi servizi — pattern anomali di accesso, frequenza, orari e dimensioni dei payload.

Indicatori di compromissione

## GopherWhisper IoC (fonte: ESET Research, aprile 2026)
## IoC completi disponibili su: github.com/eset/malware-ioc

## Strumenti identificati
LaxGopher     - Go backdoor, C2: Slack API
RatGopher     - Go backdoor, C2: Discord API  
BoxOfFriends  - Go backdoor, C2: Microsoft Outlook drafts (M365)
SSLORDoor     - C++ backdoor, C2: raw socket port 443
CompactGopher - Go exfil tool, upload: file[.]io (AES-CFB-128)
FriendDelivery - DLL loader/injector per BoxOfFriends
JabGopher      - Injector generico

## Estensioni file target (CompactGopher)
.doc .docx .jpg .xls .xlsx .txt .pdf .ppt .pptx

## Caratteristiche di attribuzione
- Orari operativi: 08:00-17:00 CST (UTC+8)
- Locale configurato: China Standard Time
- Vittime confermate: istituzione governativa Mongolia (gen 2025)
- Attività iniziale: novembre 2023

Consigli per i difensori

GopherWhisper solleva sfide difensive specifiche legate all’abuso di servizi cloud legittimi:

• Monitoraggio del traffico verso servizi di messaggistica: Implementare analisi comportamentale del traffico verso Discord, Slack e Microsoft 365. Pattern anomali — accessi notturni, frequenza insolita, grandi upload su file.io — possono indicare attività C2.
• Controllo degli accessi alle API di servizi cloud: Gestire e monitorare i token API delle piattaforme aziendali. Un’applicazione non autorizzata che accede alle API Slack o Discord dall’interno della rete è un segnale di allarme.
• Ispezione delle bozze email: La tecnica “draft-based C2” via Outlook è particolarmente insidiosa poiché non genera traffico SMTP. Considerare soluzioni DLP (Data Loss Prevention) in grado di ispezionare le bozze nei sistemi di posta enterprise.
• EDR con visibilità sulle chiamate Go runtime: I backdoor Go presentano pattern di comportamento riconoscibili a livello di runtime. Assicurarsi che le soluzioni EDR abbiano firma e behavioral detection per payload Go-based.
• Blocco dei servizi di file-sharing anonimi: Limitare o monitorare il traffico verso file[.]io e servizi analoghi nelle reti governative e critiche. Questi servizi sono raramente necessari per operazioni aziendali legittime.

Il report completo di ESET Research è disponibile su WeLiveSecurity, con indicatori di compromissione pubblicati nel repository GitHub ufficiale di ESET.

Spcnet.it

2026-04-24 09:03:20

Azure Developer CLI: scrivere gli hook in Python, TypeScript e .NET

L’Azure Developer CLI (azd) è lo strumento open-source di Microsoft pensato per accompagnare lo sviluppatore dall’ambiente locale fino al deployment su Azure. Tra le sue funzionalità più apprezzate, il sistema degli hook permette di iniettare logica personalizzata nei punti chiave del ciclo di vita: prima del provisioning, dopo il deployment, e così via. Fino a poco tempo fa, però, questa logica doveva essere scritta esclusivamente in Bash o PowerShell, costringendo chi lavora in Python o TypeScript a un cambio di contesto non sempre gradito.

Con il rilascio più recente di azd, questo limite è stato rimosso: gli hook possono ora essere scritti in Python, JavaScript, TypeScript e .NET, oltre ai già supportati Bash e PowerShell. La selezione del linguaggio avviene automaticamente in base all’estensione del file, senza configurazione aggiuntiva.

Cosa sono gli hook in azd

Gli hook sono script eseguiti automaticamente da azd in corrispondenza di eventi specifici nel workflow:

• preprovision: prima che venga eseguito il provisioning dell’infrastruttura
• postprovision: dopo il provisioning
• predeploy / postdeploy: prima e dopo il deployment dell’applicazione

Si definiscono nel file azure.yaml con il blocco hooks:, specificando il percorso allo script da eseguire. azd si occupa autonomamente di rilevare il runtime appropriato, installare le dipendenze e lanciare lo script.

Come usare gli hook in Python

Per un hook Python, è sufficiente creare il file .py e, nella stessa directory o in una directory padre, un file requirements.txt o pyproject.toml. azd individuerà automaticamente il file di dipendenze, creerà un virtual environment e installerà i pacchetti necessari prima di eseguire lo script.

Struttura tipica:

hooks/
├── setup.py
└── requirements.txt

Configurazione in azure.yaml:

hooks:
  preprovision:
    run: ./hooks/setup.py

È possibile personalizzare il nome del virtual environment tramite il blocco config:

hooks:
  preprovision:
    run: ./hooks/setup.py
    config:
      virtualEnvName: .venv

Hook in JavaScript e TypeScript

Per gli hook JavaScript e TypeScript, azd cerca un file package.json nella stessa directory o in una directory padre. Esegue automaticamente npm install (o il package manager specificato nella configurazione) e lancia lo script.

Per TypeScript, la novità più interessante è che non serve un tsconfig.json né una fase di compilazione separata: azd utilizza npx tsx per eseguire il file TypeScript direttamente.

hooks/
├── seed.ts
└── package.json

hooks:
  postdeploy:
    run: ./hooks/seed.ts
    config:
      packageManager: pnpm   # npm | pnpm | yarn

Hook in .NET e C#

Per i progetti .NET sono supportate due modalità distinte:

• Project mode: se nella directory dello script (o in una padre) è presente un file .csproj, .fsproj o .vbproj, azd esegue automaticamente dotnet restore e dotnet build.
• Single-file mode: a partire da .NET 10, i file .cs standalone vengono eseguiti direttamente con dotnet run script.cs, senza necessità di un progetto.

hooks/
├── migrate.cs
└── migrate.csproj   # opzionale su .NET 10+

hooks:
  postprovision:
    run: ./hooks/migrate.cs
    config:
      configuration: Release   # Debug | Release
      framework: net10.0

Funzionalità avanzate

Override della directory di lavoro

Se la root del progetto e la posizione dello script differiscono, si può usare il campo dir per specificare la working directory:

hooks:
  preprovision:
    run: main.py
    dir: hooks/preprovision

Override esplicito del linguaggio

Se l’estensione è assente o ambigua, è possibile forzare il runtime con il campo kind:

hooks:
  preprovision:
    run: ./hooks/setup
    kind: python

Formato misto e override per piattaforma

Si possono combinare hook in linguaggi diversi e specificare script differenti per Windows e sistemi POSIX:

hooks:
  preprovision:
    run: ./hooks/setup.py
  predeploy:
    windows:
      run: ./hooks/build.ps1
    posix:
      run: ./hooks/build.sh
  postdeploy:
    run: ./hooks/seed.ts
  postprovision:
    run: ./hooks/migrate.cs

Come aggiornare azd

Per assicurarsi di avere questa funzionalità disponibile, è sufficiente aggiornare azd all’ultima versione:

azd update

Per una nuova installazione, è possibile seguire la guida ufficiale di installazione.

Conclusioni

Il supporto multi-linguaggio per gli hook di azd rappresenta un miglioramento concreto per i team che lavorano con stack tecnologici eterogenei. Non dover più mantenere script shell separati per la logica di deployment è un risparmio reale di complessità, soprattutto nei progetti .NET o Python dove gran parte della base di codice esistente può essere riutilizzata direttamente negli hook.

La gestione automatica delle dipendenze (virtual env per Python, npm install per JS/TS, dotnet restore per .NET) elimina ulteriore boilerplate, rendendo l’integrazione trasparente. Chi già usa azd nel proprio workflow troverà questa novità immediatamente utile; chi non lo ha ancora esplorato può partire dalla documentazione ufficiale e dalla galleria di template.

Fonte: Write azd hooks in Python, JavaScript, TypeScript, or .NET – Azure SDK Blog

Write azd hooks in Python, JavaScript, TypeScript, or .NET

Azure Developer CLI (azd) hooks now support Python, JavaScript, TypeScript, and .NET scripts alongside Bash and PowerShell, with automatic dependency installation and virtual environment management.

^{Kristen Womack (Azure SDK Blog)}

(in)sicurezza digitale

2026-04-24 09:05:59

fast16: il framework di cybersabotaggio pre-Stuxnet riemerso dai tool segreti NSA dei ShadowBrokers

Si parla di:
Toggle

SentinelLABS ha riportato alla luce un framework di cybersabotaggio completamente sconosciuto, denominato fast16, i cui componenti core risalgono al 2005: almeno cinque anni prima di Stuxnet. La scoperta rimette in discussione la cronologia del cyberwarfare a livello statale e solleva interrogativi inquietanti sull’affidabilità dei sistemi di calcolo ad alta precisione nelle infrastrutture critiche.

Un fantasma nei tool NSA: la connessione ShadowBrokers

La storia di fast16 inizia nel 2017, quando il gruppo ShadowBrokers pubblicò una serie di tool offensivi attribuiti alla NSA, tra cui un documento denominato “Territorial Dispute”. Quello schema elencava framework malware di cui la NSA era a conoscenza — o che aveva prodotto — e che i suoi operatori non avrebbero dovuto interferire. Tra le voci appariva un riferimento criptico a “fast16”, rimasto inspiegato per quasi un decennio.

È stato il ricercatore di SentinelLABS Juan Andrés Guerrero-Saade, insieme al collega Vitaly Kamluk, a riconnettere i puntini: dopo anni di oscurità, Guerrero-Saade ha identificato un campione reale del framework, scoprendo che non si trattava di un semplice rootkit, ma di un sistema sofisticato di cybersabotaggio con capacità di auto-propagazione all’interno di reti chiuse.

Architettura tecnica: Lua VM, kernel driver e alterazione floating-point

fast16 è composto da due componenti principali che collaborano in modo sinergico:

• fast16.sys — Un kernel driver con avvio a livello boot (boot-start), in grado di operare a basso livello nel sistema operativo prima che qualsiasi software di sicurezza si inizializzi. Il driver è responsabile del patching in-memory degli eseguibili target e dell’introduzione di sottili errori nei calcoli in virgola mobile (floating-point).
• svcmgmt.exe — Un “service carrier” riutilizzabile che incorpora una virtual machine Lua. Questa scelta architetturale è notevole: si tratta del primo utilizzo documentato di una Lua VM embedded in malware offensivo, datato 2005, anticipando tecniche poi riutilizzate in framework come Sandman APT decenni dopo. Il design rende il payload modulare e facilmente aggiornabile senza modificare il componente carrier.

Il meccanismo di sabotaggio è di raffinata sottigliezza: invece di bloccare o distruggere i sistemi target, fast16 introduce errori minimi ma sistematici nei calcoli ad alta precisione. L’obiettivo non è il crash, ma risultati scientifici falsati che possono essere impossibili da distinguere da errori di progettazione o calibrazione. Fast16 include inoltre meccanismi di propagazione worm-style per diffondersi trasversalmente all’interno di una facility, garantendo che lo stesso driver corrotto raggiunga tutte le workstation rilevanti.

I target: LS-DYNA, PKPM e il programma nucleare iraniano

Il framework è stato progettato per colpire specifiche categorie di software di simulazione ad alta precisione:

• LS-DYNA — Software di analisi agli elementi finiti (FEA) ampiamente usato per modellare dinamiche fisiche complesse, inclusi problemi legati alla ricerca nucleare e ai sistemi d’arma. Scienziati iraniani risultano averlo impiegato in contesti ricollegabili al programma nucleare nazionale.
• PKPM — Suite di ingegneria strutturale molto diffusa in Cina e nel mondo accademico, utilizzata per simulazioni nell’industria delle costruzioni e dell’ingegneria avanzata.
• MOHID (Modelo Hidrodinâmico) — Framework di modellazione idrodinamica per sistemi acquatici, rilevante in ambiti di ricerca scientifica applicata.

La presenza di LS-DYNA nella lista dei target è particolarmente significativa: il software è stato usato da ricercatori iraniani in attività compatibili con lo sviluppo di armamenti convenzionali e non convenzionali. Questo ha portato i ricercatori a ipotizzare che fast16 potrebbe essere stato impiegato come operazione offensiva contro il programma nucleare iraniano — non distruggendo centrifughe come Stuxnet, ma falsando i risultati delle simulazioni a monte della progettazione.

Stuxnet aveva un precursore: implicazioni geopolitiche e strategiche

Stuxnet, scoperto nel 2010 e datato operativamente intorno al 2007-2008, è stato a lungo considerato il capostipite del cyberwarfare industriale: il primo malware a causare danni fisici reali in impianti industriali attraverso il sabotaggio di sistemi SCADA Siemens. La scoperta di fast16 sposta l’asticella indietro di almeno cinque anni.

Questa linea temporale suggerisce che le capacità di cybersabotaggio offensivo a livello statale — in particolare quelle attribuite agli USA o ai loro alleati contro il programma nucleare iraniano — erano molto più mature e avanzate di quanto si ritenesse pubblicamente. fast16 non sostituisce Stuxnet nella narrativa, ma ne diventa il precursore logico: un primo tentativo di alterare i calcoli scientifici a monte, prima che si optasse per il sabotaggio diretto delle centrifughe.

Kamluk ha espresso preoccupazioni esplicite sulle implicazioni più ampie: se un framework capace di introdurre errori floating-point non rilevabili esisteva già nel 2005, quante altre operazioni analoghe potrebbero essere rimaste silenti in sistemi critici globali per anni o decenni?

Componenti principali e indicatori tecnici

## Componenti fast16 (SentinelLABS, aprile 2026)

Componente         | Tipo                      | Funzione
-------------------|---------------------------|----------------------------------
fast16.sys         | Kernel driver (boot-start)| Patching in-memory + errori FP
svcmgmt.exe        | Service carrier + Lua VM  | Loader modulare riutilizzabile
[payload Lua]      | Script Lua embedded       | Logica di sabotaggio e targeting

## Software target identificati
- LS-DYNA (FEA, fisica nucleare/balistica)
- PKPM (ingegneria strutturale)
- MOHID (idrodinamica)

## Connessione ShadowBrokers
- Documento: "Territorial Dispute" (2017 leak)
- Indicazione: tool marcato come "da non toccare" per operatori NSA
- Implicazione: fast16 era già monitorato dalla NSA prima del 2017

Consigli per i difensori

La scoperta di fast16 ha implicazioni pratiche per chi opera in ambienti ad alta criticità scientifica o industriale:

• Integrità dei risultati di calcolo: Implementare meccanismi di verifica crociata (cross-validation) per simulazioni ad alta precisione, specialmente in ambiti nucleari, aerospaziali e infrastrutturali. Un attaccante sofisticato non distruggerà i vostri sistemi — li renderà inaffidabili in modo silenzioso.
• Monitoraggio dei driver kernel: Rivedere le policy di controllo dei driver con avvio boot-start. Strumenti come Windows Driver Signature Enforcement e Secure Boot sono parzialmente efficaci, ma un attaccante con accesso fisico o supply chain può aggirarli.
• Audit di supply chain del software scientifico: Il software di simulazione specialistico è spesso distribuito attraverso canali meno controllati rispetto al software commerciale mainstream. Verificare l’integrità degli installer e monitorare comportamenti anomali a runtime.
• Threat hunting retrospettivo: Considerare l’eventualità che tecniche analoghe a fast16 siano già presenti in ambienti critici. La firma “Territorial Dispute” è pubblica dal 2017 — è il momento di verificare.

La ricerca di SentinelLABS su fast16 è disponibile nel blog ufficiale di SentinelOne Labs e rappresenta un contributo fondamentale alla comprensione storica e tecnica del cyberwarfare offensivo a livello statale.

(in)sicurezza digitale

2026-04-24 06:42:14

Contagious Interview diventa un worm: Void Dokkaebi trasforma 750 repository in vettori auto-propaganti contro gli sviluppatori

Si parla di:
Toggle

Le campagne di cyberspionaggio nordcoreane basate su finti colloqui di lavoro hanno una storia lunga: da almeno il 2023 il cluster noto come Contagious Interview, attribuito al gruppo Famous Chollima (tracciato da Trend Micro come Void Dokkaebi, da altri come DeceptiveDevelopment, Gwisin Gang o Wagemole), ha ripetutamente adescato sviluppatori occidentali promettendo posizioni in startup cripto e AI. L’ultima iterazione documentata da Trend Micro nell’aprile 2026 fa un passo qualitativo in avanti che cambia la natura della minaccia: la campagna ha smesso di essere un attacco mirato sviluppatore-per-sviluppatore ed è diventata una vera infezione worm-like della supply chain del software, con propagazione automatica attraverso l’ecosistema Git/VS Code.

Nel solo mese di marzo 2026, i ricercatori hanno identificato più di 750 repository infetti, oltre 500 configurazioni VS Code task weaponized e 101 istanze del tool di commit-tampering usato dal gruppo. Quando una vittima clona un repository compromesso e lo apre in VS Code, il malware si avvia automaticamente e — soprattutto — riesce a infettare a sua volta i repository che lo sviluppatore toccherà in seguito, innescando una cascata di contaminazione attraverso fork, contributi downstream e template condivisi.

Da Famous Chollima a Void Dokkaebi: la continuità operativa DPRK

Void Dokkaebi è una delle diverse sotto-unità che negli ultimi anni hanno reso la Corea del Nord uno degli avversari più attivi sul fronte del furto di criptovalute e del cyberspionaggio economico. Il nome «dokkaebi» richiama una figura del folklore coreano: uno spirito burlone capace di trasformarsi, metafora apt per un attore che continua a riciclare lo stesso modus operandi cambiando i nomi di fantasia, i finti marchi aziendali e le tecniche di consegna del payload. Il filone «Contagious Interview» è stato negli anni associato anche a famiglie di malware come BeaverTail (JavaScript infostealer), InvisibleFerret (Python backdoor), OtterCookie e, più recentemente, a varianti compilate in Go per espandere la compatibilità cross-platform.

Parallelamente, una seconda campagna DPRK — tracciata come HexagonalRodent — ha sottratto oltre 12 milioni di dollari a sviluppatori web attirati con finte offerte LinkedIn, usando la stessa infrastruttura di consegna basata su BeaverTail e InvisibleFerret. L’ipotesi operativa degli analisti è che i cluster condividano infrastruttura e codice base, con team distinti focalizzati rispettivamente su spionaggio tecnologico e monetizzazione diretta via cripto.

Il lure: da colloquio tecnico a code-review test

Il vettore iniziale resta coerente con la narrazione storica: un finto recruiter si rivolge alla vittima su LinkedIn, Upwork, Freelancer o piattaforme di recruiting specializzate in Web3/cripto. L’offerta è attraente — compensi alti, lavoro da remoto, meeting su Google Meet o Discord — e culmina in un «test tecnico» che chiede allo sviluppatore di clonare un repository e «risolvere un bug» o estendere una feature. È in questa fase che Void Dokkaebi ha inserito la novità sostanziale: il repository non si limita a contenere un payload JavaScript eseguito al npm install, ma distribuisce due vettori complementari progettati per coprire gli scenari operativi di qualsiasi sviluppatore moderno.

I due vettori: .vscode/tasks.json e JavaScript iniettato

Il primo vettore sfrutta un file .vscode/tasks.json ben costruito, con una task configurata per l’esecuzione automatica all’apertura della cartella (tramite proprietà runOptions folderOpen). Questo meccanismo è nativo di Visual Studio Code ed è controllato dal sistema di Workspace Trust: quando un utente apre un repository e lo segna come «trusted» — comportamento comune tra sviluppatori pressati — le task si eseguono senza ulteriori avvisi. Gli attaccanti hanno inoltre imparato a nascondere la cartella .vscode nelle viste più comuni, anche tramite commit-tampering che la omette dai diff presentati a UI-level.

Il secondo vettore è JavaScript direttamente iniettato nel codice del progetto. Si tratta di payload offuscato che si attiva alla build o all’esecuzione del progetto, indipendentemente dall’IDE in uso. La ridondanza è deliberata: se lo sviluppatore usa JetBrains, Neovim o Sublime invece di VS Code, il JavaScript di progetto scavalca il primo vettore. Se l’utente evita di eseguire il codice ma apre solo la cartella in VS Code, la task interviene. In entrambi i casi, l’esecuzione del malware è garantita.

Commit tampering: il tool che rende invisibili i file malevoli

Uno degli aspetti più ingegnosi dell’evoluzione 2026 è l’uso sistematico di un tool custom che Trend Micro ha ritrovato in 101 istanze operative. Il tool manipola i commit per nascondere i file malevoli (tipicamente la cartella .vscode) dalle viste di GitHub, GitLab e dai client grafici più usati, mentre i file restano fisicamente presenti nel tree al momento del clone. La tecnica sfrutta la differenza tra come i sistemi Git mostrano la history rispetto a come checkoutano lo stato: un reviewer umano che scorre i diff su GitHub può non vedere nulla di sospetto, ma uno sviluppatore che fa git clone si trova il payload sul disco.

La propagazione worm-like tra repository

Quando il payload viene eseguito, oltre alla fase di furto credenziali tipica di BeaverTail e InvisibleFerret (dump di browser-stored passwords, wallet cripto, file SSH, token cloud), il malware scansiona la workspace locale dello sviluppatore alla ricerca di repository Git aperti. Ove possibile, iniezione e commit-tampering vengono replicati nei repository upstream dello sviluppatore, trasformando la vittima in un untwitting maintainer di nuovi vettori. Ogni sviluppatore che contribuisce al repository infetto diventa il potenziale paziente zero della prossima ondata. È il tratto che giustifica la parola «contagious» nel nome del cluster: il contagio non è più una metafora narrativa, è l’architettura tecnica dell’operazione.

Staging C2 su blockchain pubbliche

Per ostacolare le operazioni di takedown, Void Dokkaebi ospita parte della logica C2 e della distribuzione dei payload su Tron, Aptos e Binance Smart Chain. Smart contract e transazioni pubbliche diventano canali di delivery praticamente incancellabili: le autorità possono sanzionare indirizzi o bloccare domini, ma non possono cancellare dati già scritti su una blockchain permanente. La stessa tecnica era stata osservata in campagne precedenti (tra cui EtherHiding del cluster UNC5342), e qui viene integrata nell’infrastruttura di staging per la fase di second-stage download.

Indicatori di Compromissione

== IP C2 Void Dokkaebi (aprile 2026) ==
136.0.9.8
198.105.127.210
23.27.202.27
154.91.0.196
23.27.20.143
85.239.62.36
83.168.68.219
166.88.4.2
23.27.120.142

== Famiglie malware associate ==
BeaverTail        (JavaScript infostealer)
InvisibleFerret   (Python backdoor)
OtterCookie       (loader recente, varianti Go)

== Artefatti sospetti nei repository ==
.vscode/tasks.json con runOptions = "folderOpen" e comandi curl/wget
Commit che modificano tree ma non diff visibili (commit tampering)
Cartelle hidden (.vscode, .run, .idea) con script non giustificati dal contenuto

== Infrastruttura di staging ==
Smart contract su Tron, Aptos, Binance Smart Chain usati come C2 resilienti

Implicazioni e consigli pratici per i difensori

La nuova postura di Void Dokkaebi mette in discussione alcune assunzioni base della difesa dello sviluppatore. Non basta più non eseguire codice sconosciuto: anche la sola apertura di un repository in VS Code può essere sufficiente a compromettere la workstation. In più, la scala raggiunta (750 repository infetti in un mese) rende plausibile che un team stia inconsapevolmente clonando contenuti malevoli durante normali attività di ricerca, valutazione tecnica o contributo open source.

• Workspace Trust disabilitato per default: impostare VS Code a chiedere esplicitamente il trust ad ogni apertura, con preferenza per l’apertura in modalità restricted.
• Ambienti effimeri per il codice non fidato: ogni repository proveniente da recruiter, colloqui o contatti esterni andrebbe clonato ed eseguito dentro VM isolate, devcontainer o dev sandbox (GitHub Codespaces, Gitpod) usa-e-getta senza credenziali cloud montate.
• Segregazione dei token: mai tenere gh auth token, credenziali AWS/Azure/GCP o wallet cripto sulla stessa workstation usata per esperimenti su codice esterno.
• Monitoraggio commit: verificare periodicamente i commit dei repository personali per la comparsa di cartelle .vscode, .run, .idea non previste; strumenti come git fsck e hook pre-commit possono intercettare task injection.
• Code-signing enforcement per script di build critici e pipeline di rilascio.
• Awareness sul pattern «colloquio tecnico»: ogni richiesta di clonare un repository durante una fase di colloquio è oggi un segnale di rischio elevato, a prescindere dalla credibilità apparente del recruiter.

Lo snodo strategico è che il lure di Void Dokkaebi punta esattamente alle vittime più fragili dell’ecosistema tech: freelance in cerca di nuove opportunità, sviluppatori Web3 con wallet personali carichi di token, ingegneri AI con accesso a modelli e infrastruttura cloud. Per la Corea del Nord, ogni workstation compromessa è tre obiettivi in uno: liquidità in cripto, accesso a supply chain software, e un trampolino per campagne di spionaggio più ampie. La svolta contagious di aprile trasforma ogni nuova vittima in un potenziale super-spreader — e rende l’operazione una delle minacce più silenziosamente pervasive del 2026 contro la community open source.

Spcnet.it

2026-04-23 15:01:47

Addio byte[]: allocazioni a costo zero in .NET Framework con ReadOnlySpan

Uno dei pattern di ottimizzazione più semplici e meno conosciuti nel mondo .NET è la sostituzione dei campi static readonly byte[] con proprietà static ReadOnlySpan<byte>. Andrew Lock, noto per le sue analisi approfondite su ASP.NET Core e il runtime, ha pubblicato un articolo che conferma un dettaglio fondamentale: questa tecnica funziona anche su .NET Framework, basta il pacchetto NuGet System.Memory. Zero allocazioni, zero costo di startup, nessuna pressione sul garbage collector.

Il problema: allocazioni “gratuite” che non lo sono

Consideriamo un pattern che troviamo in quasi tutte le librerie che manipolano dati binari: signature di file, magic number, header fissi, tabelle di lookup. Tipicamente si scrive:

public static class MyStaticData
{
    private static readonly byte[] ByteField = new byte[] { 1, 2, 3, 4 };
}

Sembra innocuo: un singolo array, allocato una volta sola al caricamento del tipo. Ma in un processo con migliaia di tipi simili — pensiamo a un parser di formati immagine, a una libreria di crittografia, a un framework web — queste allocazioni si sommano. Ogni array è un oggetto gestito: richiede header, richiede tracciamento GC, occupa spazio sulla Gen 2 (perché sopravvive per sempre) e aumenta i tempi di startup.

La soluzione: ReadOnlySpan<byte> come proprietà

La trasformazione è quasi meccanica:

public static class MyStaticData
{
    private static ReadOnlySpan<byte> ReadOnlySpanProp => new byte[] { 1, 2, 3, 4 };
}

Sintatticamente sembra che stiamo allocando un array ogni volta che accediamo alla proprietà. In realtà è esattamente il contrario: il compilatore C# riconosce questo pattern e incorpora i byte direttamente nei metadati dell’assembly, costruendo lo span con un puntatore a quei dati. Non viene mai eseguito newarr.

L’IL generato mostra chiaramente la magia:

IL_0000: ldsflda      int32 '<PrivateImplementationDetails>'::'...'
IL_0005: ldc.i4.4
IL_0006: newobj       instance void valuetype [System.Memory]System.ReadOnlySpan`1<unsigned int8>::.ctor(void*, int32)
IL_000b: ret

I dati vivono in una sezione di sola lettura dell’assembly; lo span viene costruito on-the-fly con pointer + length. È essenzialmente gratuito.

Letterali UTF-8: lo stesso trucco, più ergonomico

A partire da C# 11 (.NET 7), la stessa ottimizzazione si ottiene con i letterali UTF-8:

private static ReadOnlySpan<byte> Utf8Hello => "Hello world"u8;

Il suffisso u8 istruisce il compilatore a codificare la stringa direttamente in UTF-8 nell’assembly. Molto utile per header HTTP, prefissi di protocollo, marker di formato binari — tutti casi in cui storicamente si manteneva una byte[] statica generata da Encoding.UTF8.GetBytes.

I vincoli da rispettare

L’ottimizzazione non si applica in modo uniforme. Vale solo per i tipi a byte singolo:

• byte[]
• sbyte[]
• bool[]

Per gli altri tipi primitivi (int, long, double…) entra in gioco l’endianness: su .NET 7 e successivi c’è RuntimeHelpers.CreateSpan<T>() che la gestisce in modo trasparente, ma su .NET Framework il compilatore emette codice che cache l’array in un campo statico alla prima chiamata. Ancora efficiente, ma non zero-alloc.

Il secondo vincolo è che tutti i valori devono essere costanti a compile-time:

// Anti-pattern: alloca a ogni accesso
private static readonly byte One = 1;
private static ReadOnlySpan<byte> Bad => new byte[] { One, 2, 3, 4 };

Qui One è un campo, non una costante, quindi il compilatore deve costruire l’array a runtime. La differenza tra const byte e static readonly byte diventa improvvisamente importante.

Il terzo vincolo è usare ReadOnlySpan<T>, mai Span<T>:

// Sbagliato: alloca un array mutabile a ogni accesso
private static Span<byte> MutSpan => new byte[] { 1, 2, 3, 4 };

Uno Span<byte> potrebbe essere scritto, e modificare dati immutabili condivisi sarebbe catastrofico. Il compilatore quindi non applica l’ottimizzazione.

Il supporto su .NET Framework

Questa è la parte più interessante: il trucco funziona su .NET Framework 4.6.2+ semplicemente referenziando il pacchetto System.Memory:

<ItemGroup>
  <PackageReference Include="System.Memory" Version="4.6.3" />
</ItemGroup>

La ragione è che l’ottimizzazione è una feature del compilatore, non del runtime: serve solo che ReadOnlySpan<T> esista come tipo, e il pacchetto System.Memory lo fornisce. Chi mantiene librerie multi-target può quindi applicare questa ottimizzazione senza creare codice condizionale #if NET6_0_OR_GREATER.

Collection expressions: la rete di sicurezza

Su C# 12 e successivi le collection expressions offrono protezione a compile-time:

// Compila e non alloca
private static ReadOnlySpan<byte> Safe => [1, 2, 3, 4];

// Errore CS9203 — il compilatore rifiuta
private static Span<byte> Dangerous => [1, 2, 3, 4];

L’errore CS9203 è un salvavita: impedisce di assegnare una collection expression a un tipo Span<T> in contesti static, perché il risultato sarebbe condivisibile e mutabile. Su .NET Framework o su versioni di C# precedenti questa protezione non esiste, quindi serve attenzione in fase di code review.

Quando applicarla nel codice reale

Le candidate ideali sono costanti binarie che vivono in campi static readonly byte[]: magic number (PNG, ZIP, PDF), prefissi protocollari, tabelle di sostituzione, chiavi di test fisse, certificati embedded. Il refactoring è meccanico e non cambia l’API pubblica della classe se la visibility è private.

Attenzione invece ai metodi che accettano byte[]: non possiamo passare uno ReadOnlySpan<byte> a un’API che richiede un array. In questi casi la scelta è tra riscrivere il consumer per accettare ReadOnlySpan<byte> (preferibile) o mantenere l’array tradizionale. Molte API del BCL sono già state aggiornate negli ultimi anni: Stream.Write, HashAlgorithm.ComputeHash, Encoding.GetString accettano tutti ReadOnlySpan<byte> in overload moderni.

Conclusione

Cambiare static readonly byte[] in static ReadOnlySpan<byte> => è uno di quei refactoring che riducono allocazioni e startup con una modifica locale a costo zero. Funziona anche su .NET Framework, quindi vale la pena considerarla durante la manutenzione di codice legacy — un punto che spesso sfugge perché l’ecosistema associa Span<T> esclusivamente a .NET moderno.

Fonte: Removing byte[] allocations in .NET Framework using ReadOnlySpan<T> di Andrew Lock.

Removing byte[] allocations in .NET Framework using ReadOnlySpan

In this post I describe how to remove static byte[] allocations, even on .NET Framework, by using Span, look at the associated IL, and discuss the risks

^{Andrew Lock (Andrew Lock | .NET Escapades)}

(in)sicurezza digitale

2026-04-23 12:32:05

Checkmarx nel mirino di TeamPCP: l’immagine Docker ufficiale di KICS trojanizzata per esfiltrare i segreti dell’infrastruttura

Si parla di:
Toggle

Il 22 aprile 2026 Docker, Inc. ha rilevato attività sospette sul repository ufficiale checkmarx/kics e ha allertato i ricercatori di Socket. L’analisi ha confermato il peggiore degli scenari per un vendor di security scanner: le immagini Docker ufficiali dello strumento open source KICS (Keeping Infrastructure as Code Secure) erano state sostituite con versioni trojanizzate, progettate per generare, cifrare ed esfiltrare i report di scansione completi insieme a token cloud, credenziali GitHub e chiavi SSH di ogni pipeline CI/CD che le eseguiva. Poche ore dopo, l’account @pcpcats rivendicava l’operazione: «Thank you OSS distribution for another very successful day at PCP inc.»

Non è la prima volta che Checkmarx finisce nel mirino di TeamPCP. A marzo 2026 lo stesso gruppo aveva compromesso due workflow GitHub Actions di Checkmarx e plugin distribuiti tramite OpenVSX, colpendo nella stessa ondata anche Trivy e LiteLLM. L’attacco di aprile rappresenta però un salto qualitativo: non si limita più al codice sorgente o agli action, ma colpisce direttamente i binary artifact distribuiti ufficialmente dal vendor, trasformando uno strumento che gli ingegneri installano proprio per cercare vulnerabilità in un vettore di furto di segreti su scala globale.

Che cos’è KICS e perché è un bersaglio ideale

KICS è uno scanner open source per Infrastructure-as-Code mantenuto da Checkmarx, ampiamente integrato nelle pipeline CI/CD per rilevare misconfiguration in Terraform, CloudFormation, Ansible, Kubernetes manifests e Dockerfile. Per sua stessa natura, viene eseguito con accesso di lettura all’intero repository, ai file di configurazione, ai secret dell’ambiente di build e spesso alle credenziali cloud a breve durata emesse dal provider di CI. Compromettere KICS significa ottenere, per ogni installazione infetta, una vista privilegiata sui crown jewels della pipeline.

Il vettore Docker Hub: tag sovrascritti e un v2.1.21 fantasma

Gli attaccanti hanno sovrascritto tag esistenti del repository checkmarx/kics — tra cui alpine, latest, debian, v2.1.20 e v2.1.20-debian — e hanno introdotto un tag v2.1.21 che non corrisponde ad alcun rilascio ufficiale del progetto. Questa tecnica è particolarmente insidiosa: ogni sistema che effettua docker pull checkmarx/kics:latest o che aggiorna l’immagine di base nei workflow di CI scarica silenziosamente la versione compromessa, senza allarmi da parte dei tool di dipendency scanning che si fidano del nome del repository ufficiale.

Il binario ELF di KICS all’interno dell’immagine è stato modificato per mantenere la funzionalità legittima (la scansione si completa senza errori, non ci sono segnali visibili di compromissione nei log) e aggiungere in parallelo una routine di raccolta dati che genera un report di scansione non censurato, lo cifra e lo invia a un endpoint esterno. In pratica, i file di configurazione che contengono password, token e connection string — normalmente redatti dai report pubblici di KICS — vengono esportati in chiaro verso l’infrastruttura dell’attaccante.

L’estensione VS Code e il payload mcpAddon.js

La campagna non si ferma alle immagini Docker. Socket ha identificato malware anche nelle estensioni Checkmarx per Visual Studio Code pubblicate sul marketplace Microsoft e su OpenVSX. Le versioni compromesse sono checkmarx.cx-dev-assist@1.17.0 e @1.19.0, oltre a checkmarx.ast-results@2.63.0 e @2.66.0 (la 1.18.0 risulta pulita, con il malware temporaneamente rimosso nel ciclo di release).

Il meccanismo è chirurgico: gli attaccanti hanno iniettato un commit retrodatato (68ed490b) nel repository Checkmarx/ast-vscode-extension contenente un file di circa 10 MB in modules/mcpAddon.js. Il modulo viene stageed per l’esecuzione runtime tramite l’interprete Bun, una scelta che riduce la probabilità di rilevazione rispetto all’esecuzione tradizionale in Node.js e permette di eseguire codice JavaScript con minore scrutinio da parte degli EDR endpoint.

Cosa ruba realmente mcpAddon.js

Il payload è un infostealer di caratura operativa avanzata. Esegue comandi nativi sulla macchina della vittima per raccogliere un dossier completo di credenziali:

• Token di autenticazione GitHub tramite gh auth token
• Credenziali AWS dai file di configurazione standard
• Token Azure tramite az account get-access-token e azd auth token
• Configurazioni Google Cloud tramite gcloud config config-helper
• Token npm dai file .npmrc dell’utente
• Chiavi SSH e file di configurazione
• File di configurazione di Claude Code e di altri MCP client
• Variabili d’ambiente selezionate del processo

L’inclusione esplicita dei file di configurazione MCP è un segnale che TeamPCP sta mappando non solo le supply chain tradizionali, ma anche l’ecosistema emergente degli agenti AI — che a loro volta conservano token per molteplici servizi di terze parti.

Esfiltrazione via repository GitHub pubblici: l’ingegno del «vocabolario Dune»

L’aspetto più creativo dell’operazione riguarda l’esfiltrazione. Invece di esfiltrare direttamente verso un C2 facilmente bloccabile, il malware crea repository GitHub pubblici con nomi casuali costruiti dal pattern <word>-<word>-<3 digits>, attingendo a un vocabolario ispirato all’universo di Dune — «gesserit», «melange», «fedaykin», «ornithopter», «atreides», «sandworm». Ogni repository ospita tre file: envelope con il payload cifrato, key con la chiave di decifratura (a sua volta cifrata), e token con un identificativo che lega il furto alla vittima.

I messaggi di commit incorporano token aggiuntivi secondo il pattern «LongLiveTheResistanceAgainstMachines:<encoded>», uno slogan ricorrente nel folklore di TeamPCP. Questa architettura rende la rilevazione molto più complessa: il traffico di esfiltrazione è indistinguibile dal normale uso di GitHub da parte di sviluppatori.

Il workflow format-check.yml e l’abuso di toJSON(secrets)

Nell’operazione di marzo, TeamPCP aveva già dimostrato padronanza dei GitHub Actions: il workflow maligno .github/workflows/format-check.yml sfruttava l’espressione ${{ toJSON(secrets) }} per serializzare tutti i segreti del repository e dell’organizzazione in un artefatto JSON scaricabile per 90 giorni. È una tecnica di supply chain attack elegante e sottovalutata, perché non richiede di esfiltrare alcunché verso infrastruttura esterna: GitHub stesso ospita il bottino, che diventa scaricabile con le sole credenziali dell’attaccante.

Propagazione npm via token rubati

Una volta ottenuti i token npm delle vittime, il malware cerca automaticamente pacchetti scrivibili interrogando l’endpoint /-/org/<user>/package e, in fallback, effettua ricerche con https://registry.npmjs.org/-/v1/search?text=maintainer:<user>&size=250. La logica è quella classica dei self-replicating npm worm già osservati in campagne come Shai-Hulud: ogni sviluppatore colpito diventa un potenziale vettore per nuove pubblicazioni malevoli.

Indicatori di Compromissione

== Hash ==
mcpAddon.js
  SHA256  24680027afadea90c7c713821e214b15cb6c922e67ac01109fb1edb3ee4741d9
  SHA1    2b12cc5cc91ec483048abcbd6d523cdc9ebae3f3
  MD5     d47de3772f2d61a043e7047431ef4cf4

kics (ELF binary trojanizzato)
  SHA256  2a6a35f06118ff7d61bfd36a5788557b695095e7c9a609b4a01956883f146f50
  SHA1    250f3633529457477a9f8fd3db3472e94383606a
  MD5     e1023db24a29ab0229d99764e2c8deba

== Docker tag compromessi (checkmarx/kics) ==
alpine, latest, debian, v2.1.20, v2.1.20-debian, v2.1.21 (fake)

== Index manifest digest ==
sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d  (alpine/v2.1.20/v2.1.21)
sha256:222e6bfed0f3bb1937bf5e719a2342871ccd683ff1c0cb967c8e31ea58beaf7b  (debian variants)
sha256:a0d9366f6f0166dcbf92fcdc98e1a03d2e6210e8d7e8573f74d50849130651a0  (latest)

== Estensioni VS Code / OpenVSX ==
checkmarx.cx-dev-assist  1.17.0, 1.19.0   (malevole)
checkmarx.ast-results    2.63.0, 2.66.0   (malevole)

== C2 ==
audit.checkmarx[.]cx/v1/telemetry
94[.]154[.]172[.]43

== Pattern repository di staging ==
<word>-<word>-<3 digits> (vocabolario Dune: gesserit, melange, fedaykin,
ornithopter, atreides, sandworm, ...) con file envelope/key/token

== Pattern commit message ==
LongLiveTheResistanceAgainstMachines:<encoded>

Implicazioni e raccomandazioni

Il caso Checkmarx/KICS è un promemoria brutale: gli strumenti di security scanner sono essi stessi componenti della supply chain, spesso eseguiti con privilegi elevati dentro le pipeline più sensibili dell’organizzazione. Per chi gestisce ambienti che integrano KICS o altri scanner Checkmarx:

• Verificare le versioni pullate di checkmarx/kics negli ultimi 30 giorni e confrontare i digest con quelli pubblicati ufficialmente dal vendor dopo la rimediation.
• Effettuare il pin delle immagini Docker a digest SHA invece che a tag mutabili come latest o alpine.
• Controllare i log GitHub per workflow artefacts di dimensione anomala, in particolare quelli generati da workflow che referenziano toJSON(secrets).
• Ruotare tutti i token GitHub, npm, AWS, Azure e GCP che potrebbero essere stati esposti a sviluppatori con cx-dev-assist o ast-results nelle versioni compromesse.
• Monitorare la creazione di repository GitHub pubblici corrispondenti al pattern Dune descritto sopra.
• Bloccare o allertare sulle connessioni verso audit.checkmarx.cx (dominio di lookalike non legittimo di Checkmarx).

Il doppio colpo di TeamPCP a Checkmarx in meno di due mesi suggerisce che il gruppo conserva un accesso persistente o ricorrente agli ambienti di build del vendor, o quantomeno che alcune delle credenziali rubate nella prima ondata non sono state completamente invalidate. La security community attende risposte più dettagliate dal vendor su come il tag Docker ufficiale sia stato sovrascritto e su quale catena di fiducia debba essere ricostruita per i clienti che hanno integrato KICS nelle proprie pipeline negli ultimi mesi.