Spcnet.it

2026-09-04 12:27:49

Microsoft Purview DSPM: come ridurre l’esposizione dei dati prima di attivare Copilot

Con l’adozione di Copilot che accelera dentro Microsoft 365, molti team IT si stanno scontrando con un problema che precede di anni l’AI generativa ma che l’AI generativa rende improvvisamente urgente: la sovraesposizione dei dati. File condivisi “a chiunque abbia il link” dimenticati su SharePoint anni fa, permessi ereditati mai ripuliti, cartelle OneDrive con dati finanziari accessibili a interi reparti. Finché a leggere quei file era un motore di ricerca aziendale poco usato, il rischio restava contenuto. Con un assistente AI che risponde a qualunque domanda pescando da tutto ciò a cui l’utente ha accesso, ogni permesso mal configurato diventa una potenziale fuga di informazioni istantanea. Microsoft Purview Data Security Posture Management (DSPM) nasce per rispondere proprio a questo scenario, e vale la pena capire cosa fa concretamente, prima di attivare Copilot su larga scala.

Cos’è DSPM e perché non è “un altro tool di compliance”

DSPM è il componente di Microsoft Purview dedicato a rispondere a quattro domande fondamentali sulla postura di sicurezza dei dati di un’organizzazione:

• Che dati abbiamo? — discovery e classificazione automatica
• Dove sono conservati? — mappatura di location e storage
• Chi può accedervi? — analisi dei pattern di accesso e permessi
• Come sono protetti? — valutazione delle policy di protezione applicate

A differenza di un tool di compliance tradizionale che verifica la conformità a una normativa in un dato momento, DSPM è pensato per essere continuo: monitora costantemente lo stato dei dati sensibili in Microsoft 365, Azure e alcune piattaforme di terze parti, e traccia se l’esposizione migliora o peggiora nel tempo attraverso un grafico di trend a 30 giorni sulla dashboard principale.

Il flusso operativo: discovery, assessment, remediation

DSPM lavora attraverso cinque fasi concettuali:

1. Discovery: individua informazioni sensibili — dati di payroll, codici fiscali, contratti, proprietà intellettuale, codice sorgente — usando classificatori integrati e sensitive information type basati su pattern matching (numeri di carte di credito, patenti, SSN, oltre a classificazioni personalizzate per record finanziari o contratti specifici dell’organizzazione)
2. Assessment: valuta lo stato di crittografia, l’applicazione di etichette di sensibilità e i rischi di condivisione eccessiva
3. Prioritizzazione: ordina i problemi rilevati per severità, in modo da affrontare prima gli elementi a rischio più alto
4. Remediation: applica azioni correttive — etichette di sensibilità, riduzione dei permessi, creazione di policy DLP
5. Monitoraggio continuo: verifica se l’esposizione dei dati migliora o peggiora nel tempo

Un punto tecnico che vale la pena chiarire subito, perché genera spesso confusione: DSPM individua l’esposizione, DLP la applica. DSPM è lo strumento di ricerca e scoperta — risponde a “dove abbiamo un problema” — mentre Data Loss Prevention è il livello che impone effettivamente restrizioni comportamentali una volta identificato il rischio. Non sono strumenti alternativi ma complementari, e DSPM può generare direttamente raccomandazioni per creare o affinare policy DLP.

Le funzionalità chiave

Data risk assessment

DSPM offre assessment predefiniti e personalizzabili che identificano contenuti sovraesposti, protezione inadeguata, etichette di sensibilità mancanti e permessi ad alto rischio. Quando questi problemi vengono confermati, DSPM può automatizzare passaggi di remediation come la rimozione di link di condivisione pubblici, l’applicazione di policy DLP, la revoca di permessi o l’applicazione di etichette di sensibilità — prima che l’incidente si verifichi, non dopo.

Rilevamento dei percorsi di esfiltrazione

Uno degli use case più concreti è la mappatura dei cosiddetti “exfiltration path”: dati sensibili condivisi esternamente, o informazioni business-critical protette da controlli di accesso deboli. DSPM consolida in questo ambito gli insight provenienti da quattro soluzioni Purview distinte: Data Loss Prevention, Insider Risk Management, Information Protection (etichette di sensibilità) e Data Security Investigations — offrendo così una vista unificata invece di quattro dashboard scollegate.

DSPM for AI: la componente più rilevante per chi sta adottando Copilot

Con l’estensione DSPM for AI, Microsoft ha aggiunto un livello di osservabilità specifico per gli agenti e le app AI, incluso Microsoft Agent 365. L’AI Observability Dashboard fornisce:

• Un inventario delle app e degli agenti AI in uso nell’organizzazione
• Attività registrata negli ultimi 30 giorni
• Il conteggio degli agenti considerati ad alto rischio
• Il numero totale di agenti che interagiscono con dati sensibili
• Una vista dettagliata per singolo agente e per policy di governance applicata

In pratica, prima di dare a Copilot (o a qualunque altro agente AI collegato al tenant) accesso ai dati aziendali, DSPM for AI permette di vedere quali repository quell’agente toccherebbe e con quale livello di rischio, invece di scoprirlo a posteriori tramite un incidente.

Attivazione: i setup task principali

La configurazione iniziale avviene dal Microsoft Purview portal, sotto DSPM > Actions > Setup tasks, dove ogni attività include istruzioni passo-passo, stato di completamento, tempo stimato e impatto previsto sugli utenti. I task principali sono:

Setup task	Cosa fa	Note
Attivazione Microsoft Purview Audit	Verifica che l’audit sia abilitato	Attivo di default sui tenant nuovi, va abilitato manualmente sui tenant esistenti
Onboarding dei dispositivi	Deploy su endpoint Windows	Necessario per la visibilità su siti AI di terze parti e per endpoint DLP
Estensione browser Purview	Deploy su Chrome/Edge	Richiesta per le policy DLP a livello di browser
Etichette di sensibilità	Crea etichette e policy predefinite	Solo se non già configurate nel tenant
Configurazione billing	Attiva il pay-as-you-go	Richiesta per alcune configurazioni avanzate
Integrazione con Sentinel	Collega il content hub	Funzionalità in preview

Un aspetto da verificare con attenzione prima del rollout è quello dei permessi: la documentazione ufficiale non elenca in modo esplicito i ruoli richiesti (Global Admin, Security Admin, Compliance Admin), quindi è opportuno validare con un tenant di test quali ruoli minimi servono per ciascun setup task, prima di assegnare permessi troppo ampi al team che gestirà DSPM in produzione.

Licensing: cosa aspettarsi

DSPM (in versione “classica”) è incluso nelle licenze Microsoft 365 E5 / E5 Compliance, mentre alcune funzionalità più avanzate — in particolare componenti di DSPM for AI e alcune configurazioni di billing pay-as-you-go — possono richiedere add-on o un modello di consumo separato. Prima di pianificare il rollout, vale la pena verificare la Microsoft Purview Licensing Guidance aggiornata, perché il pacchetto di funzionalità incluse per fascia di licenza è soggetto a modifiche frequenti.

DSPM non sostituisce la compliance tradizionale

Un’ultima precisazione utile per chi deve giustificare il progetto internamente: DSPM offre visibilità sul trattamento dei dati sensibili ed è un complemento prezioso agli strumenti di compliance tradizionali, ma non li sostituisce. Framework normativi (GDPR, ISO 27001, settoriali) richiedono comunque processi, documentazione e controlli dedicati. DSPM riduce il rischio operativo e dà visibilità continua, ma resta uno strumento di data security posture, non un motore di conformità normativa.

Quando ha senso adottarlo

DSPM è particolarmente utile per organizzazioni che:

• Stanno pianificando o hanno già distribuito Copilot su larga scala
• Gestiscono ambienti SharePoint/OneDrive di grandi dimensioni con anni di condivisioni stratificate
• Trattano dati regolamentati (finanziari, sanitari, PII in generale)
• Faticano a mantenere visibilità sulla governance dei dati a scala aziendale

Organizzazioni piccole, con esigenze di compliance minime e un perimetro dati contenuto, potrebbero non trarne un beneficio proporzionato al costo di licenza e all’impegno di configurazione iniziale.

Conclusione

Il messaggio di fondo di DSPM è semplice ma spesso trascurato: attivare Copilot senza prima aver mappato chi può accedere a cosa significa dare a un assistente AI estremamente efficiente nel trovare informazioni lo stesso identico perimetro di accesso — sbagliato — che esisteva già, solo molto più velocemente interrogabile. Per i team che gestiscono tenant Microsoft 365 di dimensioni medio-grandi, un ciclo di discovery e remediation con DSPM prima del rollout di Copilot non è un passaggio opzionale di “nice to have”, ma la differenza tra un’adozione AI controllata e un incidente di esposizione dati che si scopre solo dopo che è già successo.

Fonte originale: Microsoft Purview Data Security Posture Management Explained: How It Reduces Data Exposure Before Copilot – Petri IT Knowledgebase (Brien Posey). Approfondimenti tecnici da Microsoft Learn.

Microsoft Purview DSPM Explained for Copilot Readiness

AI readiness starts with data visibility. Microsoft Purview DSPM gives IT teams a way to find and reduce exposure before Copilot expands discovery.

^{Brien Posey (Petri IT Knowledgebase)}

Spcnet.it

2026-09-04 12:28:08

Cronologia Bash su Linux: HISTFILE, HISTTIMEFORMAT e scorciatoie per sistemisti

Chiunque amministri sistemi Linux passa gran parte della giornata dentro una shell, e la cronologia dei comandi (history) è probabilmente lo strumento più usato e meno conosciuto a fondo. Sappiamo tutti premere la freccia su o lanciare Ctrl+R, ma pochi sfruttano davvero le variabili che controllano cosa viene salvato, come viene formattato e come sincronizzarlo tra più terminali aperti in contemporanea. Vediamo come portare la gestione della cronologia Bash a un livello professionale, con configurazioni pronte per essere messe in produzione su server multi-utente.

Le variabili che governano la cronologia

Bash tiene traccia dei comandi in due posti distinti: la memoria della sessione corrente e il file su disco (di default ~/.bash_history). Questa distinzione è la fonte di gran parte della confusione quando si lavora con più terminali aperti, quindi vale la pena chiarirla subito con le variabili che la controllano.

HISTSIZE e HISTFILESIZE

HISTSIZE stabilisce quanti comandi restano in memoria durante la sessione attiva, mentre HISTFILESIZE determina quante righe vengono conservate nel file su disco. Sono due limiti indipendenti: si può avere una sessione “leggera” con poche centinaia di comandi in memoria ma un archivio storico molto più ampio su disco.

export HISTSIZE=10000
export HISTFILESIZE=20000

Impostare un valore negativo (o vuoto) rende la cronologia illimitata: sconsigliato su sistemi condivisi, dove un file di history che cresce senza controllo può diventare un problema sia di spazio che di sicurezza.

HISTFILE

HISTFILE indica dove viene scritta la cronologia. Il default è ~/.bash_history, ma è possibile ridirigerla altrove, ad esempio per tenere una history separata per progetto o per sessioni di audit:

export HISTFILE="$HOME/.bash_history_$(date +%Y%m)"

HISTTIMEFORMAT: i timestamp che quasi nessuno abilita

Per impostazione predefinita, history non mostra quando un comando è stato eseguito. Abilitare i timestamp con HISTTIMEFORMAT è probabilmente l’impostazione a più alto rapporto beneficio/sforzo di questo articolo, specialmente in fase di troubleshooting: sapere che un comando è stato lanciato tre minuti prima di un incidente è un’informazione preziosa.

export HISTTIMEFORMAT="%F %T  "

Con questa impostazione, history | grep nginx restituirà righe del tipo:

1042  2026-09-03 10:14:02  systemctl reload nginx

Un dettaglio tecnico da tenere a mente: il timestamp viene registrato internamente come epoch Unix ad ogni comando, ma diventa visibile solo se HISTTIMEFORMAT è impostato prima che i comandi vengano eseguiti. Se lo si abilita a metà sessione, i comandi precedenti non avranno un timestamp recuperabile.

HISTCONTROL: cosa non salvare

HISTCONTROL filtra cosa entra in cronologia:

• ignorespace – esclude i comandi che iniziano con uno spazio (utile per non salvare comandi con password o token inline)
• ignoredups – salta i duplicati consecutivi
• ignoreboth – combina entrambi i comportamenti precedenti
• erasedups – rimuove tutte le occorrenze precedenti di un comando ripetuto, non solo quelle consecutive

export HISTCONTROL=ignoreboth

Il trucco di ignorespace è particolarmente utile: basta digitare un comando con uno spazio iniziale (es. curl -H "Authorization: Bearer xyz..." ...) per evitare che token o credenziali finiscano nel file di history in chiaro.

HISTIGNORE: filtrare per pattern

HISTIGNORE permette di escludere dalla cronologia comandi ricorrenti e poco utili come ls, cd o pwd. Attenzione: i pattern ancorano l’inizio della riga e devono corrispondere all’intero comando, quindi vanno elencati esplicitamente anche gli argomenti comuni.

export HISTIGNORE="ls:ll:la:cd:cd -:pwd:exit:date:clear:history"

Le opzioni della shell: histappend e histverify

Due shopt completano la configurazione di base. La prima è quasi obbligatoria su qualunque sistema con più terminali:

shopt -s histappend

Senza histappend, Bash sovrascrive il file HISTFILE alla chiusura della shell con il contenuto della sessione corrente, perdendo i comandi salvati da altri terminali chiusi nel frattempo. Con histappend attivo, ogni sessione aggiunge in coda invece di sovrascrivere.

La seconda opzione utile è histverify, che intercetta le espansioni di history (come !! o !497) e le mostra sul prompt per una conferma, invece di eseguirle immediatamente:

shopt -s histverify

Questo piccolo accorgimento evita un classico incidente: digitare !42 pensando che sia un comando innocuo e scoprire, dopo l’esecuzione, che il comando numero 42 era un rm -rf lanciato ore prima in un altro contesto.

Sincronizzare la cronologia tra terminali multipli

Per chi lavora con molte finestre o sessioni tmux/screen aperte in parallelo, il comportamento di default di Bash è frustrante: ogni shell scrive la propria history solo alla chiusura, quindi i comandi digitati in un terminale non sono visibili negli altri finché non li si chiude esplicitamente.

La soluzione è agganciare la scrittura e la ricarica della history a PROMPT_COMMAND, che Bash esegue prima di ogni visualizzazione del prompt:

PROMPT_COMMAND="history -a; history -c; history -r${PROMPT_COMMAND:+; $PROMPT_COMMAND}"

Scomponendo la sequenza:

• history -a – accoda immediatamente su disco i nuovi comandi della sessione
• history -c – svuota la lista in memoria della sessione corrente
• history -r – ricarica in memoria l’intero file, inclusi i comandi scritti da altre sessioni

Il risultato: la freccia su e Ctrl+R attingono a una cronologia condivisa e aggiornata quasi in tempo reale tra tutti i terminali aperti. Il costo è un piccolo overhead ad ogni prompt, generalmente trascurabile salvo file di history molto grandi; in quel caso è preferibile una variante più leggera con history -n, che legge solo le righe nuove invece di ricaricare l’intero file:

PROMPT_COMMAND="history -a; history -n${PROMPT_COMMAND:+; $PROMPT_COMMAND}"

Comandi di gestione della history

Oltre alle variabili di ambiente, il builtin history offre diverse operazioni utili in amministrazione quotidiana:

# Mostra tutta la cronologia con numerazione
history

# Ultimi 20 comandi
history 20

# Cerca nella cronologia
history | grep nginx

# Scrive subito su disco la sessione corrente
history -a

# Elimina una riga specifica dalla memoria (es. riga 497)
history -d 497

# Elimina e persiste la rimozione sul file
history -d 497 && history -w

# Svuota completamente memoria e file
history -c && history -w

Per disabilitare temporaneamente la registrazione, ad esempio prima di digitare una password su un comando che non supporta variabili d’ambiente:

set +o history
# comandi non registrati qui
set -o history

Le scorciatoie da tastiera che valgono la pena imparare

Oltre al classico Ctrl+R per la ricerca incrementale, Bash espone un intero linguaggio di espansione della history, largamente sotto-utilizzato:

Scorciatoia	Funzione
!!	Ripete l’ultimo comando
!$	Ultimo argomento del comando precedente
!^	Primo argomento del comando precedente
!*	Tutti gli argomenti del comando precedente
!N	Esegue il comando numero N
!stringa	Ultimo comando che inizia con “stringa”
!stringa:p	Mostra il comando senza eseguirlo (preview)
^vecchio^nuovo	Sostituisce e rilancia l’ultimo comando
Alt+.	Richiama ciclicamente l’ultimo argomento dei comandi precedenti

!$ in particolare è utile più spesso di quanto sembri: dopo mkdir /var/log/miaapp, digitare cd !$ evita di riscrivere il percorso.

Ricerca interattiva avanzata con fzf

Per chi trova Ctrl+R limitante, fzf lo sostituisce con un fuzzy finder interattivo molto più potente:

sudo apt install fzf   # Debian/Ubuntu
eval "$(fzf --bash)"   # da aggiungere a ~/.bashrc

Una volta configurato, Ctrl+R apre un filtro interattivo con evidenziazione live: premendo Invio la prima volta il comando viene incollato sul prompt (non eseguito), permettendo di modificarlo prima del lancio effettivo.

Sicurezza: la history non è un controllo, è un log

Alcuni punti da tenere presenti quando si gestiscono cronologie su sistemi condivisi o in produzione:

• Il file di history dovrebbe avere permessi restrittivi: chmod 600 ~/.bash_history
• ignorespace nasconde un comando dalla history solo se lo spazio iniziale viene digitato manualmente: non è un meccanismo automatico
• File di history su NFS o directory sincronizzate (Dropbox, syncthing, ecc.) possono esporre comandi sensibili a più host
• La cronologia è auditabile dall’utente stesso ma non è un controllo di sicurezza: chiunque abbia accesso alla shell può disabilitarla con set +o history o cancellarla
• Per un audit trail affidabile in produzione, la history di Bash va affiancata (non sostituita) da strumenti dedicati come auditd o da logging centralizzato della sessione shell

Configurazione completa consigliata

Riassumendo tutto quanto visto in un blocco pronto per ~/.bashrc:

# Configurazione History Bash
HISTSIZE=10000
HISTFILESIZE=20000
HISTTIMEFORMAT="%F %T  "
HISTCONTROL=ignoreboth
HISTIGNORE="ls:ll:la:cd:cd -:pwd:exit:date:clear:history"

shopt -s histappend
shopt -s histverify

# Sincronizza la cronologia tra terminali dopo ogni comando
PROMPT_COMMAND="history -a; history -c; history -r${PROMPT_COMMAND:+; $PROMPT_COMMAND}"

Dopo averla incollata, applicarla con:

source ~/.bashrc

Conclusione

La cronologia di Bash è uno di quegli strumenti che si usano per anni senza mai configurarli davvero. Pochi minuti spesi su HISTTIMEFORMAT, HISTCONTROL e la sincronizzazione via PROMPT_COMMAND trasformano un log grezzo e volatile in uno strumento di troubleshooting affidabile, specialmente su server dove si lavora regolarmente da più sessioni contemporanee. Per chi gestisce ambienti multi-utente, vale la pena ricordare che la history resta comunque uno strumento lato client: per l’audit reale servono log centralizzati indipendenti dalla volontà dell’utente.

Fonte originale: Master Linux Bash History with historyctl, HISTFILE, and Shortcuts – LinuxBlog.io

Master Linux Bash History with historyctl, HISTFILE, and Shortcuts | LinuxBlog.io

Bash history does a lot more than scroll up. Learn how to configure HISTSIZE, timestamps, multi-terminal sync, and search shortcuts to get real productivity gains at the command line.

^{Hayden James (LinuxBlog.io)}

(in)sicurezza digitale

2026-09-04 12:30:49

GoCaracal: Dark Caracal nasconde il comando e controllo dentro un contratto Ethereum

Si parla di:
Toggle

Quando un centro operativo di comando e controllo viene sequestrato o messo offline dalle forze dell’ordine, per la maggior parte dei malware è la fine della partita. Non per GoCaracal. Il nuovo impianto scritto in Go attribuito a Dark Caracal, il gruppo di cyberspionaggio legato ai servizi di sicurezza libanesi, ha risolto il problema in un modo che gli analisti definiscono “operativamente elegante”: quando il server primario non risponde, il malware si rivolge a un nodo pubblico della rete Ethereum, legge un indirizzo aggiornato da uno smart contract e riprende a comunicare come se nulla fosse successo. Nessun dominio da riregistrare, nessun IP da far circolare sui forum: basta una transazione sulla blockchain.

Chi è Dark Caracal

Dark Caracal non è un nome nuovo nel panorama del cyberspionaggio. Il gruppo, con un’attribuzione a confidenza media al Lebanese General Directorate of General Security, è attivo almeno dal 2012 ed è stato documentato per la prima volta pubblicamente nel 2018 in una ricerca congiunta di Lookout ed EFF che ne svelò le operazioni contro giornalisti, avvocati, attivisti, militari e istituzioni governative in decine di Paesi. Da allora l’infrastruttura si è spostata più volte, ma la firma resta riconoscibile: il malware Windows Bandook, sviluppato originariamente da un attore commerciale libanese, riutilizzato in campagne mirate con loader Delphi e lure a tema documentale.

Negli ultimi mesi il gruppo ha spostato l’attenzione verso l’America Latina, con un’infezione confermata ai danni di un operatore delle telecomunicazioni in Venezuela nel giugno 2026 e tracce correlate — con confidenza da bassa a moderata — in Brasile, Ecuador, Cile, Colombia, El Salvador e Uruguay. Il vettore d’ingresso è coerente con il modus operandi storico del gruppo: email di phishing a tema fiscale e finanziario, in lingua spagnola, con allegati SVG che nascondono un URL abbreviato codificato in Base64.

Un framework a due velocità

GoCaracal esiste in due varianti, sviluppate secondo una timeline che gli analisti di Arctic Wolf hanno ricostruito in quattro fasi tra gennaio e luglio 2026. La prima è una versione “lightweight”, pensata per il primo insediamento: usa un protocollo a pacchetti personalizzato cifrato con AES-GCM, effettua host profiling, scarica payload aggiuntivi ed esegue shell remote e shellcode injection. La seconda, “estesa”, è il vero e proprio impianto di spionaggio a lungo termine: conta 34 gestori di comandi distinti che coprono raccolta di credenziali dai browser (Chrome, Brave, Firefox), keylogging, accesso desktop remoto via WebRTC, funzionalità proxy SOCKS5 per il movimento laterale e meccanismi di persistenza basati su registro di sistema.

Il payload della catena d’infezione arriva tipicamente come archivio 7-Zip distribuito da un’infrastruttura di staging — nei casi osservati, il dominio getpdfdigital[.]cloud — che eroga un eseguibile con nome esca del tipo tf-oficina004a9.exe. Un dettaglio che conferma quanto Dark Caracal continui a puntare su ingegneria sociale a basso costo piuttosto che su exploit costosi: la sofisticazione del gruppo non è nella fase di delivery, ma in ciò che succede dopo che la vittima ha già cliccato.

BulletproofC2: la resilienza scritta sulla blockchain

La parte più interessante, dal punto di vista tecnico, è il meccanismo di fallback introdotto nell’estate 2026. Quando i tentativi di connessione ai server C2 primari falliscono ripetutamente, l’impianto interroga direttamente un nodo RPC pubblico della rete Ethereum ed esegue una chiamata eth_getStorageAt su uno smart contract battezzato dagli analisti BulletproofC2, distribuito il 20 maggio 2026. Il contratto funge da semplice registro: memorizza uno o più indirizzi di server di backup, che l’operatore può aggiornare in qualsiasi momento inviando una transazione dal proprio wallet.

Il vantaggio per l’attaccante è evidente. Un dominio C2 può essere sequestrato da un registrar, un IP può essere bloccato da un provider di hosting, ma uno smart contract su Ethereum è immutabile una volta deployato, pubblicamente leggibile da chiunque disponga di un nodo RPC (anche gratuito) e non richiede infrastruttura dedicata per essere consultato — il traffico si confonde con il normale rumore di fondo delle applicazioni Web3. Per un difensore, distinguere una query legittima a un nodo Ethereum da una chiamata di un impianto malevolo che cerca il proprio server di backup è tutt’altro che banale, specialmente in ambienti aziendali dove il traffico verso provider RPC pubblici non è insolito.

Non è la prima volta che un gruppo criminale sperimenta con la blockchain per la resilienza del C2 — tecniche simili, note come “dead drop resolver” basati su blockchain, sono state osservate in passato in campagne di crimine informatico più ampio — ma l’adozione da parte di un attore di cyberspionaggio state-adjacent come Dark Caracal segna un salto di maturità operativa che vale la pena monitorare da vicino.

Due righe per i difensori

Per i team di detection, la lezione principale è che il blocco dei soli indicatori di rete tradizionali (domini, IP) non basta più contro attori che dispongono di un canale di ripristino fuori dal controllo di chiunque non sia l’operatore. Le raccomandazioni pratiche includono:

• Bloccare o ispezionare in sandbox gli allegati SVG nelle email in ingresso, specialmente se contengono URL codificati in Base64 o reindirizzamenti verso domini di recente registrazione;
• Monitorare le comunicazioni verso endpoint RPC pubblici di Ethereum (Infura, Alchemy, nodi self-hosted) da host che non hanno ragione di interagire con la blockchain, e in particolare chiamate eth_getStorageAt ripetute verso lo stesso indirizzo di contratto;
• Applicare le regole YARA pubblicate da Arctic Wolf per la variante lightweight e integrare gli hash SHA-256 noti nei propri strumenti EDR;
• Rafforzare la formazione degli utenti su phishing a tema fiscale/finanziario, il vettore d’ingresso preferito dal gruppo da oltre un decennio;
• Per le organizzazioni in America Latina — settore telecomunicazioni in particolare — innalzare il livello di allerta e verificare retroattivamente i log DNS per le risoluzioni verso i domini di staging noti.

Il set completo di indicatori di compromissione, incluse le regole YARA aggiornate, è riservato ai clienti di Arctic Wolf; di seguito riportiamo gli indicatori resi pubblici.

Indicatori di compromissione (IoC)

# Hash SHA-256
GoCaracal (lightweight): 1E499C815146124C4A6D2B48C99068B980AD74E1A2CFD16013F8D75A9425A0CA
GoCaracal (lightweight): 77F7AD29F4A8037EE5F38D3D87FB91CFD97CB8F7FA7883EDF3FCE506DF5200C0
GoCaracal (extended):    8C03D072DF2E1BF14B0C00A8AB99834138C8B69F301849BF09CB44394E916015
Delphi loader:           0A6DA70548F14834ACB8960689A589B48FF422F8385AE445A281AAB77045FE22

# Domini C2 / staging
getpdfdigital[.]cloud
getpdf[.]digital
visualizarpdf[.]online
contabilidad[.]icu
soportedigital[.]cloud
documentodigital[.]cloud
gestionadocs[.]me

# IP C2 (selezione)
109.120.187.217
109.172.95.121
138.124.112.213
138.124.14.130
176.124.220.153
185.125.101.181
185.96.80.110
185.96.80.54
193.233.245.52

# Smart contract Ethereum (fallback C2)
Contratto:  BulletproofC2
Indirizzo:  0x03D605f13A74Bfb6149078122FcF62BD6d8799d8
Deploy:     20 maggio 2026
Wallet operatore: 0x7D321FE277f8c25aaC14aF1BA3Fc34953242052F

# Payload noto
tf-oficina004a9.exe (archivio 7-Zip)

Fonti: Arctic Wolf, The Hacker News, SC World, Security Affairs.

offline

^{insicurezzadigitale.com}