(in)sicurezza digitale

2026-04-30 08:39:54

LAPSUS$ colpisce Checkmarx: 95 GB di codice sorgente su dark web e la supply chain dei tool di sicurezza nel mirino

Quando a essere violato è uno dei principali vendor di sicurezza applicativa — uno strumento usato per rilevare vulnerabilità nel codice altrui — le implicazioni si estendono ben oltre l’azienda stessa. Il gruppo LAPSUS$ ha pubblicato sul dark web 95 gigabyte di dati riservati di Checkmarx, inclusi codice sorgente, chiavi API e credenziali di database. È l’ultimo capitolo di una campagna supply chain orchestrata da un attore noto come TeamPCP, che da settimane sta sistematicamente compromettendo l’ecosistema degli strumenti di sviluppo e sicurezza.

Cosa è stato esfiltrato

Il 25 aprile 2026, LAPSUS$ ha rivendicato pubblicamente l’attacco a Checkmarx, pubblicando un archivio di circa 95 GB che include codice sorgente dei repository GitHub privati dell’azienda (tra cui componenti di KICS, il motore open source per la scansione di configurazioni cloud e IaC), un database dei dipendenti con informazioni personali e credenziali interne, chiavi API per servizi di terze parti e integrazioni, e credenziali di database MongoDB e MySQL dell’ambiente di sviluppo.

Checkmarx ha confermato l’autenticità del dump in un advisory pubblicato il 26 aprile, precisando che i repository GitHub compromessi sono separati dall’ambiente di produzione per i clienti e che nessun dato cliente è stato esposto direttamente. Tuttavia, la presenza di chiavi API e credenziali nei file esfiltrati amplia significativamente la superficie di attacco potenziale.

Il vettore: la campagna supply chain TeamPCP

L’accesso ai sistemi di Checkmarx non è stato ottenuto tramite un attacco diretto, ma attraverso la compromissione della supply chain di sviluppo software. La data del breach originale è il 23 marzo 2026, quando TeamPCP ha iniettato codice malevolo in componenti dell’ecosistema Checkmarx disponibili pubblicamente. Le immagini Docker KICS ufficiali su Docker Hub sono state sostituite con versioni trojanizzate contenenti uno stealer di credenziali: gli sviluppatori che le utilizzavano nelle pipeline CI/CD scaricavano automaticamente il malware. Parallelamente, due estensioni VS Code correlate a Checkmarx pubblicate su marketplace sono state compromesse con funzionalità di esfiltrazione che operavano silenziosamente in background.

Il nome TeamPCP emerge anche in connessione con le 73 estensioni malicious su Open VSX scoperte a fine aprile, suggerendo una campagna coordinata e ad ampio raggio contro l’intero ecosistema degli strumenti DevSecOps. Il modello è chiaro: compromettere prima gli strumenti che gli sviluppatori di sicurezza usano quotidianamente, per poi risalire — tramite le credenziali rubate — ai sistemi più preziosi.

Chi è LAPSUS$

LAPSUS$ è un gruppo di cybercrime con una storia operativa peculiare: composto prevalentemente da giovani hacker (diversi dei quali minorenni all’epoca degli attacchi), il gruppo si è distinto tra il 2021 e il 2022 per una serie di operazioni ad alto profilo contro Nvidia, Samsung, Okta, Microsoft e Uber, utilizzando principalmente tecniche di social engineering e SIM swapping piuttosto che exploit tecnici sofisticati. Dopo una serie di arresti nel 2022-2023, il gruppo sembrava smantellato. La ricomparsa nel 2026, questa volta sfruttando l’infrastruttura supply chain di TeamPCP come vettore di accesso iniziale, dimostra una capacità di adattamento e riorganizzazione che rende LAPSUS$ una minaccia ancora attiva.

Timeline dell’incidente

• 23 marzo 2026: TeamPCP compromette le immagini Docker KICS e le estensioni VS Code; furto delle credenziali Checkmarx GitHub
• Fine marzo – inizio aprile 2026: esfiltrazione massiva dei 95 GB di repository privati
• 25 aprile 2026: LAPSUS$ pubblica il data dump sul dark web e rivendica l’attacco
• 26 aprile 2026: Checkmarx pubblica un advisory confermando la violazione e bloccando l’accesso al repository compromesso
• 29 aprile 2026: il dump viene diffuso pubblicamente in forum accessibili, aumentando il rischio di sfruttamento secondario delle chiavi API esposte

Implicazioni per gli utenti Checkmarx e i team DevSecOps

La violazione di Checkmarx solleva preoccupazioni su più livelli. In primo luogo, l’esposizione del codice sorgente dei motori di analisi potrebbe consentire ad attori malevoli di identificare potenziali vulnerabilità nelle logiche di scanning, aprendo la porta ad attacchi che bypassano o manipolano i risultati dell’analisi statica del codice. In secondo luogo, i team che hanno utilizzato immagini Docker KICS o le estensioni VS Code compromesse tra marzo e aprile 2026 devono considerarsi potenzialmente compromessi e procedere con un’indagine forensica.

Indicatori di Compromissione e azioni immediate

# Immagini Docker KICS compromesse (periodo a rischio: 23/03 - 26/04/2026)
checkmarx/kics:latest  # verificare hash con: docker inspect --format='{{.Id}}' checkmarx/kics:latest
checkmarx/kics:v1.7.x  # controllare con advisory ufficiale Checkmarx
# Credenziali da ruotare immediatamente se si è usato KICS Docker nel periodo a rischio:
# - Token GitHub con accesso ai repository
# - Chiavi API Checkmarx
# - Credenziali MongoDB/MySQL condivise con l'ambiente di sviluppo
# - Segreti nelle pipeline CI/CD (GitHub Actions, GitLab CI, Jenkins)
# Verifica estensioni VS Code compromesse:
# Controllare l'elenco completo nel security advisory ufficiale su checkmarx.com/blog/checkmarx-security-update-april-26/
# Log da analizzare per pull sospetti (pipeline CI/CD):
# grep -r "checkmarx/kics" .github/workflows/ .gitlab-ci.yml Jenkinsfile

Consigli per i difensori

L’attacco a Checkmarx è emblematico di una tendenza sempre più preoccupante: i tool di sicurezza stessi diventano vettori di attacco. È necessario verificare i log delle pipeline CI/CD tra il 23 marzo e il 26 aprile 2026 per identificare eventuali pull di immagini Checkmarx da Docker Hub. Qualsiasi segreto memorizzato nell’ambiente di sviluppo deve essere considerato compromesso e sostituito immediatamente. Le estensioni VS Code Checkmarx vanno rimosse e reinstallate da sorgenti verificate e firmate. Il monitoraggio del dark web nei prossimi mesi è raccomandato: i 95 GB esfiltrati contengono informazioni che potrebbero essere sfruttate per attacchi secondari a lungo termine.

Più in generale, questo incidente sottolinea l’urgenza di adottare il principio del least privilege nelle pipeline CI/CD: i processi automatizzati non dovrebbero avere accesso a credenziali di produzione. L’isolamento degli ambienti — sviluppo, staging, produzione — e la firma crittografica delle immagini container (tramite strumenti come Cosign e la policy enforcement con Kyverno o OPA) limitano significativamente il blast radius di compromissioni simili. Quando a essere attaccato è chi produce gli strumenti di difesa, l’unica risposta efficace è l’architettura zero-trust applicata anche all’infrastruttura DevSecOps.

reporter

2026-04-30 14:50:05

In un piccolo borgo di montagna della provincia di Caserta, la Messa domenicale scivola inevitabilmente nel grottesco. Davanti a una ventina di fedeli, un parroco ultraottantenne celebra la liturgia segnato da evidenti decadimenti cognitivi dovuti all’età: perde costantemente il segno nel messale, sfoglia le pagine avanti e indietro in stato di confusione, conclude l’omelia per poi ricominciarla daccapo, intrappolato in un loop temporale che dilata il rito a dismisura. La scena è resa ancora più critica dal rifiuto ostinato di qualsiasi aiuto. Diaconi e parrocchiani provano a intervenire, a suggerire il passo successivo o a semplificare la cerimonia, ma il parroco respinge ogni assistenza, mosso da un orgoglio ferito o da una piena incomprensione della realtà. È l’immagine della solitudine di un clero anziano lasciato a se stesso: la Curia, stretta dalla morsa della carenza vocazionale che svuota i seminari italiani, non ha forze fresche da inviare nelle piccole parrocchie periferiche e mantiene in servizio uomini ben oltre le loro capacità psicofisiche. La memoria a breve termine cede, l’orientamento si perde e il sacro diventa involontariamente teatro dell’assurdo. Questo non è un caso isolato, ma il sintomo estremo di una Chiesa che, nelle aree interne del Sud, fatica a garantire la dignità del rito e il benessere spirituale dei fedeli. Mentre le statistiche vaticane confermano il crollo delle ordinazioni in Europa, nei borghi come questo la fede resiste, ma la celebrazione rischia di diventare una prova di resistenza insostenibile, dove la devozione si scontra con l’incapacità di chi dovrebbe guidarla. La soluzione non può essere l’abbandono a se stessi di parroci malati, ma richiede un ripensamento coraggioso della presenza ecclesiale nelle aree che si spopolano, prima che il grottesco soffochi definitivamente il sacro.

caserta24ore.blogspot.com/2026…

@caffeitalia @fediverso @fedinews

Caserta. Chiesa, quando la carenza di vocazioni trasforma la Messa in una commedia grottesca

Sito ufficiale della testata giornalistica caserta24ore.it fondata nel 1999, posta elettronica redazione@caserta24ore.it

^{Redazione (Blogger)}

(in)sicurezza digitale

2026-04-30 15:30:41

Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise

Il 29 aprile 2026, il gruppo TeamPCP ha compromesso i pacchetti npm ufficiali di SAP in quello che i ricercatori di Wiz hanno battezzato “Mini Shai-Hulud”: un attacco alla supply chain enterprise di estrema rilevanza che ha preso di mira gli ambienti di sviluppo e CI/CD di organizzazioni che utilizzano il Cloud Application Programming Model (CAP) e Cloud MTA di SAP. L’operazione si distingue per la sofisticazione del meccanismo di esfiltrazione e per la capacità di rubare credenziali da praticamente ogni sistema cloud aziendale utilizzato dagli sviluppatori colpiti.

SAP nell’occhio del ciclone: perché questa supply chain attack è critica

SAP è il backbone ERP di migliaia di aziende enterprise globali. Il suo Cloud Application Programming Model (CAP) è il framework ufficiale per costruire applicazioni cloud-native su SAP Business Technology Platform. Una compromissione dei pacchetti npm di SAP CAP non è, quindi, un attacco a una libreria open source di nicchia: è un’iniezione di malware nel cuore degli ambienti di sviluppo enterprise, con accesso diretto a credenziali di produzione, segreti CI/CD e infrastrutture cloud di organizzazioni Fortune 500.

La finestra temporale dell’attacco è stata precisa e calcolata: le versioni malevole dei pacchetti SAP sono state pubblicate su npm il 29 aprile 2026 tra le 09:55 UTC e le 12:14 UTC — un arco di circa due ore e mezza. Questo tipo di timing suggerisce un’operazione pianificata per massimizzare la finestra di esposizione prima che i team di sicurezza potessero reagire, sfruttando le ore mattutine dei fusi orari europei e americani durante le quali i sistemi CI/CD eseguono build automatizzate.

Anatomia dell’attacco: da preinstall script a credential stealer

Il meccanismo di attacco sfrutta una caratteristica legittima del registry npm: gli script preinstall, che vengono eseguiti automaticamente ogni volta che un pacchetto viene installato come dipendenza. I ricercatori di Socket e Wiz hanno ricostruito la catena di infezione in tre fasi distinte.

Fase 1 — Bootstrap con Bun: Lo script preinstall esegue un loader chiamato setup.mjs che scarica da GitHub il runtime JavaScript Bun. L’utilizzo di Bun anziché Node.js è un’indicazione tattica: Bun è meno monitorato dai tool di sicurezza aziendali ed è più difficile da rilevare in ambienti enterprise dove Node.js è già whitelistato. Questo scaricamento di un binary non verificato è di per sé sufficiente per classificare il pacchetto come malevolo.

Fase 2 — Execution payload offuscato: Il runtime Bun viene utilizzato per eseguire un payload denominato execution.js, pesantemente offuscato. Il payload implementa logiche di raccolta credenziali e meccanismi anti-analisi per complicare il reverse engineering.

Fase 3 — Esfiltrazione crittografata: I dati rubati vengono cifrati con una chiave RSA pubblica hardcoded nel malware e caricati su repository GitHub pubblici creati sull’account della stessa vittima — con la descrizione ironica “A Mini Shai-Hulud has Appeared” (riferimento al verme del deserto di Dune). Questa tecnica di esfiltrazione tramite GitHub è particolarmente insidiosa poiché il traffico verso github.com è raramente bloccato nelle reti aziendali.

Tipologia di credenziali rubate

Il credential stealer è progettato per aspirare qualsiasi segreto accessibile nell’ambiente dello sviluppatore o del pipeline CI/CD:

• Token GitHub e npm — accesso ai repository e alle pipeline di deploy
• GitHub Actions secrets — credenziali iniettate nei workflow di CI/CD
• Chiavi SSH — accesso diretto a server e infrastruttura
• Credenziali cloud: AWS (access key + secret), Azure (service principal), Google Cloud Platform (service account JSON), Kubernetes (kubeconfig)
• Segreti CI/CD in memoria — variabili d’ambiente caricate nei processi attivi al momento dell’esecuzione

Attribuzione a TeamPCP: la chiave RSA come firma digitale

Wiz attribuisce l’operazione a TeamPCP con alta confidenza. L’elemento chiave è la riutilizzazione della stessa chiave RSA pubblica per cifrare i dati esfiltrati — la medesima chiave impiegata in precedenti compromissioni di librerie attribuite allo stesso gruppo. È un errore operativo significativo da parte degli attaccanti: la chiave di cifratura diventa di fatto una firma identificativa che collega tutte le campagne dello stesso operatore.

TeamPCP non è un nuovo arrivato nel panorama degli attacchi alla supply chain npm. Il gruppo ha già condotto operazioni simili contro altre librerie, dimostrando un interesse sistematico per l’ecosistema JavaScript enterprise e un pattern operativo consolidato: compromissione di pacchetti legittimi e ad alta fiducia, payload multistadio con downloader, esfiltrazione tramite servizi cloud legittimi.

Il pattern più ampio: tre supply chain attack in 48 ore

L’attacco ai pacchetti SAP non è avvenuto in isolamento. GitGuardian ha documentato come nelle stesse 48 ore abbiano colpito campagne analoghe su npm (il pacchetto tanstack contraffatto che esfiltrava file .env), PyPI e Docker Hub — suggerendo un’intensificazione coordinata delle operazioni di supply chain attack verso l’ecosistema di sviluppo software nel suo complesso. Questo tipo di attività “a grappolo” potrebbe indicare un mercato underground più attivo, o una risposta a opportunità specifiche emerse nell’ecosistema open source.

Indicatori di Compromissione (IoC)

# Pacchetti SAP npm compromessi (versioni malevole - 29 aprile 2026)
# Pubblicati tra 09:55 UTC e 12:14 UTC

# Indicatori infrastrutturali:
# - Loader: setup.mjs (scarica Bun runtime da GitHub)
# - Payload: execution.js (offuscato, eseguito via Bun)
# - Chiave RSA pubblica condivisa con altre campagne TeamPCP

# Pattern di esfiltrazione:
# - Dati caricati su repository GitHub pubblici della vittima
# - Descrizione repository: "A Mini Shai-Hulud has Appeared"
# - Dati cifrati con RSA prima dell'upload

# File target:
.env
.env.local
.env.production
~/.ssh/id_rsa
~/.aws/credentials
~/.kube/config

# Riferimenti:
# Socket: https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack
# Wiz: https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm
# BleepingComputer: https://www.bleepingcomputer.com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/

Raccomandazioni immediate per i difensori

Chi utilizza pacchetti SAP CAP o Cloud MTA nel proprio ambiente di sviluppo deve agire immediatamente su più fronti. Il primo passo è verificare le versioni installate nei propri progetti e disinstallare qualsiasi versione pubblicata il 29 aprile 2026: eseguire npm audit e confrontare le versioni con il changelog ufficiale SAP. In secondo luogo, è necessario trattare tutte le credenziali presenti negli ambienti di sviluppo e CI/CD come potenzialmente compromesse: ruotare token GitHub, chiavi AWS/Azure/GCP, credenziali npm e kubeconfig.

A livello organizzativo, questo attacco riporta all’attenzione la necessità di implementare policy di Software Composition Analysis (SCA) nei pipeline CI/CD, con blocco automatico di pacchetti che eseguono script preinstall o scaricano binary da sorgenti esterne. L’adozione di soluzioni come Socket, Wiz o Snyk per il monitoraggio in real-time delle dipendenze npm rappresenta oggi una misura non più opzionale per chi gestisce ambienti enterprise basati su Node.js.

Fonti: Socket Research Team, Wiz Security Blog, BleepingComputer, GitGuardian Blog — 29-30 aprile 2026.

Trames Venenosus

2026-03-31 22:02:52

Buongiorno.

Ecco qui altri #consiglidifollow, suddivisi per argomento.
Non sono elenchi esaustivi: condivido gli account che mi è capitato d'incontrare per caso e che piacciono a me.

Terzo elenco: Didattica, Università, Ricerca.

(aggiornamento 29 aprile 2026)

@aiucd
@alx
@andreapetrocchi
@anfibolo
@ArchaeoBasti
@bot
@brembs
@danielatafani
@drfrededison
@emama
@Fbrzvnrnd
@Galessandroni
@giuseppeliparipa
@gzornetta
@johncormier
@lisavag
@lucianofloridi
@luciomarinelli
@mattblaze
@maupao
@mcp
@michael_w_busch
@myrornaskrig
@natbardey
@neuralreckoning
@ninawillburger
@overholt
@paolabonacini
@petergleick
@poliversity
@quantumquia
@scuola
@simonezanella
@stefano_taccone
@SteveThompson
@stspataro
@sundogplanets
@ulaulaman
@waltertross
@wikimediaitalia
@wolfgangcramer

Spcnet.it

2026-04-30 08:42:52

Azure Data Studio è in pensione: migra il tuo workflow Azure SQL su VS Code in 10 minuti

Se stai ancora aprendo Azure Data Studio per lavorare con Azure SQL, è arrivato il momento di fare il passo. Azure Data Studio (ADS) è andato ufficialmente in pensione il 6 febbraio 2025, e il supporto è terminato il 28 febbraio 2026. Microsoft ha indicato Visual Studio Code con l’estensione MSSQL come percorso ufficiale consigliato.

Questa guida ti aiuta a ripristinare rapidamente la produttività in VS Code: importare il setup esistente, recuperare le scorciatoie familiari come F5, e far funzionare SQL Database Projects per gestire le modifiche allo schema con sicurezza.

Perché questa migrazione conta per gli sviluppatori Azure SQL

Eseguire query è solo una parte del lavoro. La maggior parte dei team ha bisogno di workflow ripetibili per la revisione delle modifiche allo schema, la validazione in CI, e i deployment più sicuri. SQL Database Projects supporta questo stile di lavoro con “schema as code”, build validation, e un’esperienza di pubblicazione guidata direttamente in VS Code.

Rispetto ad Azure Data Studio, VS Code offre:

• Un ecosistema di estensioni molto più ricco e aggiornato
• Integrazione nativa con GitHub Copilot per l’assistenza SQL
• Supporto per SQL database in Microsoft Fabric
• Un editor più potente con refactoring, IntelliSense avanzato, e integrazione Git integrata

Step 1: Installa gli strumenti SQL essenziali per VS Code

Dalla Marketplace di VS Code, installa questi tre componenti:

Estensione MSSQL

Il tuo principale strumento per query, connessioni e workflow con il database. Cerca “SQL Server (mssql)” nel VS Code Marketplace. Questa estensione gestisce le connessioni ai server SQL Server, Azure SQL Database, Azure SQL Managed Instance e SQL database in Microsoft Fabric.

SQL Database Projects

Aggiunge il sistema di progetto e il workflow di build/publish per “schema as code”. Cerca “SQL Database Projects” nel Marketplace. Con questa estensione puoi organizzare oggetti SQL in un progetto versionabile, validare la struttura del database prima del deploy, e pubblicare in modo controllato.

.NET 8 SDK

SQL Database Projects dipende dal .NET SDK per la build. Installalo da dotnet.microsoft.com prima del primo build. L’estensione ti avviserà se manca, ma averlo pronto evita un riavvio aggiuntivo.

Step 2: Importa il tuo setup ADS esistente

L’estensione MSSQL include un ADS Migration Toolkit che trasferisce le tue connessioni salvate, i gruppi di connessioni, le impostazioni e i binding dei tasti in un unico flusso guidato. Apri l’estensione e segui il wizard.

Ripristinare F5 come abitudine muscolare

Se sei abituato a premere F5 per eseguire una query in Azure Data Studio, installa l’estensione MSSQL Database Management Keymap. Aggiunge i binding di tasti in stile ADS, incluso F5 per eseguire una query. Per l’elenco completo, consulta la documentazione “Customize keyboard shortcuts”.

Step 3: Configurare SQL Database Projects end-to-end

Questa è la parte che rende il workflow davvero solido. Segui questi passaggi nell’ordine:

1. Crea o apri un progetto SQL

Apri una cartella di progetto SQL esistente in VS Code, oppure creane uno nuovo tramite i comandi SQL Database Projects nell’editor. I file .sqlproj sono compatibili con SSDT, quindi puoi aprire progetti esistenti direttamente.

2. Esegui prima la build

Il primo traguardo deve essere una build pulita. Confermare che la toolchain è configurata correttamente prima di tentare un deploy è fondamentale. Eventuali errori di sintassi o riferimenti mancanti emergono qui, non in produzione.

3. Pubblica tramite il Publish Dialog

Fai clic destro sul progetto nel pannello Database Projects, seleziona Publish, configura il target, controlla il deployment script generato, e seleziona Publish per deployare.

La preview dello script è il punto che rende questo workflow affidabile per uso serio: vedi esattamente quale T-SQL verrà eseguito sul database prima che accada. Niente sorprese.

Problemi comuni e soluzioni

.NET SDK non trovato: Se la prima build non completa, verifica che il .NET SDK sia installato e che VS Code riesca a trovarlo. Questo è il problema più comune al primo avvio.

Target platform mismatch: Se il comportamento di publish è diverso da quello atteso, controlla il target platform del progetto nelle impostazioni .sqlproj. Molti problemi di publish dipendono dalla configurazione del progetto, non dal database in sé.

Lavorare con SQL database in Microsoft Fabric

La stessa configurazione VS Code si applica a SQL database in Microsoft Fabric, con un’aggiunta: inizia dal portale Fabric per collegare il database a Git prima di aprire il progetto localmente in VS Code. Questo garantisce che il file di progetto sia configurato correttamente per Fabric.

Item templates: per chi arriva da SSDT

Se vieni da SSDT, i template di elementi in SQL Database Projects generano stub consistenti per tabelle, stored procedure, view e altri oggetti comuni. Fai clic destro sul progetto nel pannello Database Projects e seleziona Add Item per iniziare.

Primi passi consigliati

Prova questo ciclo completo con qualsiasi schema di database piccolo:

1. Crea o apri un SQL project
2. Esegui la build
3. Pubblica con script preview abilitato
4. Apporta una modifica allo schema, ricompila, e pubblica di nuovo

Dopo questo ciclo, il workflow ti sembrerà naturale come quello di Azure Data Studio — con in più la potenza dell’ecosistema VS Code.

Conclusione

Azure Data Studio ha avuto la sua era, ma VS Code con l’estensione MSSQL è oggi il tool ufficiale e più potente per lavorare con Azure SQL. L’importazione del setup esistente richiede pochi minuti grazie all’ADS Migration Toolkit, e SQL Database Projects porta il workflow di schema management a un livello superiore rispetto a quanto era possibile in ADS.

Chi lavora con Azure SQL, SQL Server, o SQL database in Microsoft Fabric troverà in VS Code un ambiente più ricco e costantemente aggiornato. La transizione vale lo sforzo.

Fonte originale: Azure Data Studio is retired: Move your Azure SQL workflow to VS Code in 10 minutes — Iqra Shaikh, Microsoft Azure SQL Dev Corner (27 aprile 2026)

Azure Data Studio is retired: Move your Azure SQL workflow to VS Code in 10 minutes - Azure SQL Dev Corner

Azure Data Studio (ADS) retired on February 6, 2025, and support ended on February 28, 2026. The recommended path forward is Visual Studio Code with the MSSQL extension. If you used ADS daily, this guide gets you productive quickly in VS Code.

^{Iqra Shaikh (Azure SQL Dev Corner)}

Spcnet.it

2026-04-30 08:43:30

Il pulsante di emergenza: revoca immediata dei token in .NET 10 con Duende IdentityServer

Immagina questo scenario da incubo: il telefono di un cliente bancario viene rubato, l’app mobile è già autenticata, e il ladro ha pieno accesso al suo conto. Il supporto riceve la chiamata disperata. Ogni secondo conta. Quanto tempo ci vuole per revocare quella sessione attiva e mettere al sicuro i fondi?

Se stai usando JWT self-contained standard, la risposta onesta potrebbe essere “fino a un’ora”, a seconda della durata di validità del token. Non è accettabile. Vediamo come i Reference Token ti forniscono un vero pulsante di emergenza per queste situazioni, e come configurarli con Duende IdentityServer in .NET 10.

Il problema dei JWT self-contained

I JWT self-contained sono il cavallo di battaglia dell’autorizzazione moderna. Trasportano tutte le claim di cui un’API ha bisogno direttamente nel token. Nessuna query al database, nessuna chiamata al provider di identità. L’API valida la firma, controlla la scadenza, e il gioco è fatto. È elegante e performante.

Ma questa natura self-contained è un’arma a doppio taglio. Una volta emesso un JWT, il provider di identità non ha più nulla da dire su di esso. Il token è valido fino a quando la claim exp non dice il contrario, tipicamente 5-60 minuti. Se un dispositivo viene rubato, un account compromesso, o una minaccia rilevata, non puoi revocare quel token. Sei costretto ad aspettare che scada.

Per molte applicazioni questo compromesso è accettabile. Per ambienti ad alta sicurezza come banking, sanità o sistemi governativi, è un gap che non puoi permetterti.

Reference Token: premere il pulsante

I Reference Token ribaltano il modello. Invece di incorporare tutte le claim direttamente nel token, IdentityServer memorizza il contenuto del token lato server nel suo persisted grant store e consegna al client un identificatore opaco (un “handle”). Quando un’API riceve questo handle, chiama l’endpoint di introspection di IdentityServer per validare il token e recuperare le claim.

Questo cambia tutto. Poiché i dati del token risiedono sul server, puoi cancellarli in qualsiasi momento. La revoca è immediata. La prossima volta che l’API chiama l’endpoint di introspection, riceve "active": false, e l’accesso viene negato. Niente attese di scadenza, niente token obsoleti in circolazione.

Il compromesso? Ogni chiamata API richiede un round-trip verso l’endpoint di introspection. Per API pubbliche su scala internet, è una preoccupazione. Per servizi interni e ambienti ad alta sicurezza, è un prezzo ragionevole per la capacità di staccare la spina istantaneamente.

Configurare i Reference Token in IdentityServer

Passare a Reference Token per un client richiede una singola riga di configurazione. Quando definisci il client in Duende IdentityServer, imposta la proprietà AccessTokenType:

new Client
{
    ClientId = "banking_app",
    ClientSecrets = { new Secret("secret".Sha256()) },
    AllowedGrantTypes = GrantTypes.Code,

    // Questa è la riga chiave
    AccessTokenType = AccessTokenType.Reference,

    AllowOfflineAccess = true,
    RedirectUris = { "https://banking.example.com/signin-oidc" },
    AllowedScopes = { "openid", "profile", "accounts.read", "transfers.write" }
};

I token emessi per questo client saranno ora handle opachi invece di JWT self-contained.

Configurare l’API per l’introspection

La tua API deve sapere come validare questi token opachi. Invece del (o in aggiunta al) classico JWT validation, configuri l’introspection OAuth 2.0. Prima, definisci un API Resource con un secret:

new ApiResource("banking_api")
{
    Scopes = { "accounts.read", "transfers.write" },
    ApiSecrets = { new Secret("api_secret".Sha256()) }
};

Poi nel Program.cs della tua API, registra l’handler di introspection:

builder.Services.AddAuthentication("token")
    .AddOAuth2Introspection("token", options =>
    {
        options.Authority = "https://identity.banking.example.com";
        options.ClientId = "banking_api";
        options.ClientSecret = "api_secret";
    });

Se devi supportare sia JWT che Reference Token (magari durante una migrazione), puoi registrare entrambi gli handler e usare il forwarding per instradare i token a quello corretto:

builder.Services.AddAuthentication("token")
    .AddJwtBearer("token", options =>
    {
        options.Authority = "https://identity.banking.example.com";
        options.Audience = "banking_api";
        options.TokenValidationParameters.ValidTypes = ["at+jwt"];
        options.ForwardDefaultSelector = Selector.ForwardReferenceToken("introspection");
    })
    .AddOAuth2Introspection("introspection", options =>
    {
        options.Authority = "https://identity.banking.example.com";
        options.ClientId = "banking_api";
        options.ClientSecret = "api_secret";
    });

Revocare un token

Quando quella chiamata disperata arriva, il tuo sistema di supporto (o una pipeline automatica di rilevamento minacce) può revocare il token immediatamente usando l’endpoint di revocation di IdentityServer, che implementa la RFC 7009:

using Duende.IdentityModel.Client;

var client = new HttpClient();
var result = await client.RevokeTokenAsync(new TokenRevocationRequest
{
    Address = "https://identity.banking.example.com/connect/revocation",
    ClientId = "banking_app",
    ClientSecret = "secret",
    Token = stolenAccessToken
});

if (result.IsError)
{
    logger.LogError("Token revocation failed: {Error}", result.Error);
}

Una volta revocato, il token viene rimosso dal persisted grant store. La prossima richiesta di introspection da qualsiasi API confermerà che il token non è più attivo. L’accesso è tagliato.

Non dimenticare: dovresti anche revocare il refresh token dell’utente per impedire al client di ottenere silenziosamente un nuovo access token:

await client.RevokeTokenAsync(new TokenRevocationRequest
{
    Address = "https://identity.banking.example.com/connect/revocation",
    ClientId = "banking_app",
    ClientSecret = "secret",
    Token = refreshToken
});

Nota: sia l’introspection che la revocation emettono eventi di audit che puoi usare per implementare log di audit nei settori regolamentati.

Quando usare i Reference Token

I Reference Token non sono un sostituto universale dei JWT. Brillano in scenari specifici:

• La revoca immediata è un requisito imprescindibile (banking, sanità, sistemi compliance-driven)
• Comunicazione service-to-service interna dove il round-trip di introspection è trascurabile
• Operazioni ad alto rischio dove il beneficio di sicurezza supera il costo in performance

Per API pubbliche su larga scala dove la latenza di revoca è accettabile, i JWT self-contained con breve durata rimangono una scelta solida. Puoi anche mixare i due approcci: Reference Token per client sensibili e JWT per quelli a minor rischio, tutto all’interno dello stesso deployment IdentityServer.

Conclusione

Ogni architettura di sicurezza implica compromessi. I JWT self-contained scambiano la revocabilità per la performance. I Reference Token scambiano la performance per il controllo. Per gli ambienti dove “aspetta che scada” non è una risposta accettabile, i Reference Token con Duende IdentityServer ti forniscono un vero pulsante di emergenza.

L’implementazione è semplice: una proprietà sul client, un handler di introspection sull’API, e una chiamata di revocation quando devi staccare la spina. Quando accadono incidenti di sicurezza — e accadranno — sarai felice di averlo configurato.

Fonte originale: The Emergency Stop Button – Implementing Immediate Token Revocation in .NET 10 — Khalid Abuhakmeh, Duende Software (28 aprile 2026)

The Emergency Stop Button - Implementing Immediate Token Revocation in .NET 10

Learn how to implement an immediate 'emergency stop' button for compromised sessions using Reference Tokens and Duende IdentityServer in .NET 10.

^{Khalid Abuhakmeh (Duende Software)}

(in)sicurezza digitale

2026-04-30 08:41:34

GLITTER CARP e SEQUIN CARP: la Cina spia giornalisti e attivisti con phishing mirato e OAuth abuse

Si parla di:
Toggle

Il Citizen Lab dell’Università di Toronto ha pubblicato un rapporto dettagliato che svela due distinti gruppi di hacker allineati con la Repubblica Popolare Cinese — denominati GLITTER CARP e SEQUIN CARP — responsabili di una campagna sistematica di sorveglianza digitale e phishing contro giornalisti investigativi, attivisti uiguri, tibetani, taiwanesi e hongkonghesi. La ricerca, condotta in collaborazione con l’International Consortium of Investigative Journalists (ICIJ), rappresenta un’ulteriore conferma della pervasività della repressione digitale transnazionale (DTR) orchestrata da Pechino.

Il contesto: la repressione digitale transnazionale della Cina

La Cina ha una lunga storia di persecuzione dei propri oppositori all’estero. Dagli anni ’90, le autorità di Pechino hanno minacciato, intimidito e fisicamente attaccato cittadini cinesi residenti all’estero che esprimevano dissenso verso il Partito Comunista. Nel corso dei decenni, la platea dei bersagli si è ampliata per includere esponenti delle diaspore tibetana, uigura, taiwanese e hongkonghese — i cosiddetti “Cinque Veleni” secondo la terminologia del CCP — oltre ai praticanti del Falun Gong e ai giornalisti che ne documentano le attività.

Il rapporto del Citizen Lab (Report No. 193, pubblicato il 27 aprile 2026) analizza come questa repressione si sia evoluta verso un modello di Military-Civil Fusion: attacchi state-sponsored eseguiti da contractor civili privati, con una netta divisione del lavoro tra i vari gruppi coinvolti. GLITTER CARP e SEQUIN CARP rappresentano due nodi distinti di questa rete, con TTP differenti ma finalità complementari.

GLITTER CARP: phishing massivo e furto di credenziali email

GLITTER CARP è attivo almeno dall’aprile 2025 e conduce una campagna di phishing ad ampio spettro, ma chirurgicamente mirata in termini di selezione delle vittime. Il gruppo ha colpito il World Uyghur Congress, lo Uyghur Human Rights Project (UHRP), TibCERT (la rete di risposta agli incidenti per la comunità tibetana), il media taiwanese Watchout e numerosi attivisti individuali come Carmen Lau, figura di spicco dell’attivismo hongkonghese.

Le tecniche adottate rivelano un’accurata preparazione operativa. In un caso emblematico, l’attivista uiguro-canadese Mehmet Tohti ha ricevuto un messaggio apparentemente proveniente da un noto regista uiguro, con una richiesta di visionare un documentario in anteprima. Il link non conduceva ad alcun video, ma a una pagina di login Google contraffatta. Il Citizen Lab ha inoltre identificato l’uso sistematico di tracking pixel nascosti nelle email di phishing, per verificare che il messaggio venisse aperto prima di procedere con la fase successiva dell’attacco.

L’infrastruttura di GLITTER CARP è stata documentata anche da Proofpoint, che ha osservato il riuso degli stessi domini e delle stesse identità impersonate in attacchi contro molteplici target. Il Citizen Lab ha identificato oltre cento domini correlati, alcuni dei quali probabilmente impiegati in operazioni non ancora rese pubbliche. L’obiettivo primario del gruppo sembra essere l’accesso iniziale ad account email, suggerendo un contratto specializzato all’interno del sistema Military-Civil Fusion che delega la compromissione dei dispositivi ad altri attori.

SEQUIN CARP: OAuth abuse e spionaggio dei giornalisti ICIJ

SEQUIN CARP opera con metodologie più sofisticate e ha come bersaglio principale i giornalisti dell’ICIJ impegnati nell’indagine “China Targets” — un progetto che documenta le pratiche di repressione transnazionale del CCP. La giornalista Scilla Alecci, coordinatrice del progetto, è stata oggetto di almeno tre tentativi di compromissione tra giugno 2025 e marzo 2026.

Il vettore d’attacco distintivo di SEQUIN CARP è il phishing OAuth: anziché rubare password, il gruppo induce le vittime a concedere autorizzazioni di accesso a email e calendario a un’applicazione di terze parti apparentemente legittima. Questa tecnica è particolarmente insidiosa perché:

• Non richiede la conoscenza della password della vittima
• Il token OAuth mantiene l’accesso anche dopo un cambio di password
• L’accesso persiste finché la vittima non revoca manualmente il permesso dall’elenco delle app autorizzate
• Le attività di lettura delle email non lasciano tracce nei log di accesso tradizionali

Per rendere credibili i propri approcci, SEQUIN CARP costruisce personas elaborate basate su narrative reali. In un caso, gli attaccanti hanno impersonato Bai Bin, un ex funzionario di un tribunale di Pechino la cui storia era già stata riportata da media cinesi, usando la sua identità per avvicinare la giornalista Alecci con una richiesta di informazioni apparentemente plausibile. Nonostante le capacità tecniche avanzate, il gruppo ha commesso errori operativi significativi che hanno permesso al Citizen Lab di tracciarne l’infrastruttura.

Attribuzione e implicazioni geopolitiche

Il Citizen Lab valuta con alta confidenza che entrambi i gruppi operino in favore della Repubblica Popolare Cinese, inserendosi nel pattern più ampio di repressione digitale transnazionale documentato negli ultimi anni. La coesistenza di due attori distinti con TTP differenti ma target sovrapposti suggerisce un ecosistema di contractor specializzati che risponde a mandati governativi specifici — un modello coerente con il sistema Military-Civil Fusion del governo cinese.

Proofpoint aveva già documentato attività correlate a GLITTER CARP contro altri soggetti legati agli interessi di Pechino, rafforzando l’ipotesi di una campagna coordinata e continuativa piuttosto che di operazioni episodiche. La duplice attenzione sull’ICIJ — con due attori separati che perseguono strategie diverse — evidenzia quanto l’organizzazione e i suoi giornalisti siano percepiti come minacce significative dalla leadership cinese.

Indicatori di Compromissione (IoC)

# Infrastruttura GLITTER CARP (domini impersonation identificati dal Citizen Lab)
# Categorie principali di impersonation:
# - Servizi Google (login, accounts, security-alerts)
# - Pagine ICIJ false
# - Profili di attivisti noti impersonati

# Tattiche SEQUIN CARP - OAuth Abuse
# Endpoint di autorizzazione OAuth abusati per accesso persistente a Gmail
# Tipologia di permessi richiesti: mail.read, calendar.readonly
# Vettore: email di spear-phishing con link a pagina di consent OAuth fake

# Tracking pixel:
# - Pixel nascosti nelle email per confermare apertura messaggio
# - Utilizzati come trigger per avanzamento attacco

# Referenza report completo:
# https://citizenlab.ca/research/how-chinese-actors-use-impersonation-and-stolen-narratives-to-perpetuate-digital-transnational-repression/

Come proteggersi: raccomandazioni per i difensori

Il Citizen Lab fornisce indicazioni pratiche per chi opera in ambienti ad alto rischio. In primo luogo, è fondamentale effettuare revisioni periodiche delle applicazioni OAuth autorizzate nel proprio account Google o Microsoft, revocando immediatamente qualsiasi accesso non riconosciuto o non più necessario. L’uso di chiavi di sicurezza hardware (FIDO2/WebAuthn) come secondo fattore di autenticazione rappresenta la misura più efficace contro i tentativi di phishing tradizionali, poiché il token fisico non può essere replicato su siti contraffatti.

Per i giornalisti e gli attivisti ad alto rischio, il Citizen Lab raccomanda l’adozione di strumenti come Access Now’s Digital Security Helpline e una formazione specifica sui pattern di spear-phishing legati alla repressione cinese. La verifica dell’identità dei contatti attraverso canali alternativi prima di cliccare su qualsiasi link — anche apparentemente proveniente da persone conosciute — rimane la misura preventiva più critica in questo contesto operativo.

Fonte primaria: Citizen Lab Report No. 193, “Tall Tales: How Chinese Actors Use Impersonation and Stolen Narratives to Perpetuate Digital Transnational Repression”, 27 aprile 2026. In collaborazione con ICIJ.