Sintesi

Sono state recentemente osservate numerose campagne di phishing che sfruttano l’ingegneria sociale per esortare le potenziali vittime ad eseguire codice malevolo all’interno del proprio sistema operativo tramite la funzione “incolla”.

Descrizione e potenziali impatti

Sono state recentemente osservate numerose campagne di phishing che sfruttano l’ingegneria sociale per esortare le potenziali vittime ad eseguire codice malevolo all’interno del proprio sistema operativo tramite la funzione “incolla”.

Analisi del vettore iniziale

Il vettore di attacco iniziale consiste nella compromissione preliminare di portali web attestati sul territorio nazionale; le evidenze raccolte confermano che, nei casi analizzati, le piattaforme vulnerabili erano basate su CMS WordPress.

Gli attori malevoli sfruttano vulnerabilità note presenti nel core del CMS, nei plugin o nei temi utilizzati, oppure ottengono accesso compromettendo interfacce di amministrazione impropriamente esposte su Internet e protette da meccanismi di autenticazione insufficienti e/o da credenziali deboli.

Qualora consultata la risorsa compromessa, la tecnica, denominata “ Clickfix” , consiste nel presentare alla potenziale vittima, prima della landing page attesa, una schermata di verifica opportunamente predisposta. Tale interfaccia, progettata per simulare i comuni sistemi di controllo “anti-bot” o notifiche di errore del browser, ha lo scopo di guidare l’utente nel compiere una sequenza di azioni manuali sul proprio sistema operativo (Figura 1).

Meccanismo di esecuzione iniziale

La peculiarità della tecnica risiede nell’automazione del caricamento del payload negli appunti di sistema: all’apertura della pagina compromessa richiesta, uno script offuscato provvede a inserire nella clipboard dell’utente una stringa contenente comandi malevoli, tipicamente codificata in Base64 e/o formattata come istruzione PowerShell (Figura 2).

Il processo di infezione si articola attraverso una sequenza di azioni coordinate volte a trasformare l’utente nell’esecutore materiale dell’attacco. A quest’ultimo viene fornita un’istruzione precisa: utilizzare la combinazione di tasti Windows + R per richiamare la finestra di dialogo ” Esegui “, strumento nativo del sistema operativo solitamente preposto a scopi amministrativi.

Successivamente, il messaggio a video sfrutta la fiducia instaurata nella vittima inducendola a utilizzare la combinazione CTRL + V direttamente all’interno del campo di testo della finestra appena aperta. Tale azione determina l’inserimento della stringa descritta in precedenza, che verrà eseguita istantaneamente alla pressione del tasto “Invio” o al clic sul pulsante “OK”. Tale meccanismo avvia la catena d’infezione, finalizzata all’elusione dei sistemi di difesa tramite il caricamento del malware direttamente in memoria (fileless) e instaurando un canale di comunicazione verso i server di Comando e Controllo degli attaccanti.

Primo Stadio

Il codice in Figura 2 contiene una funzione per la decodifica e l’esecuzione in memoria di un secondo script PowerShell, volto ad istanziare un ulteriore processo al fine di prelevare un payload da un’infrastruttura remota (Figura 3).

ll payload acquisito presenta un’architettura deliberatamente complessa, caratterizzata da un pesante offuscamento e dall’inserimento di codice ridondante ( junk code ) volti a inibire l’analisi statica e a eludere il rilevamento da parte degli strumenti di sicurezza (Figura 4).

Il codice agisce come un Loader di primo livello con funzione di Staging . Il suo scopo non è l’attacco diretto, ma l’evasione delle difese tramite l’offuscamento del vettore d’ingresso.

Il cuore del meccanismo risiede in uno shellcode embedded , a sua volta ulteriormente offuscato, che funge da ponte logico. In fase di esecuzione, il codice ricompone dinamicamente in memoria le stringhe frammentate per eludere l’analisi statica dei motori AV/EDR. Una volta ricostruito l’ambiente necessario, lo shellcode viene decifrato ed eseguito per iniettare il payload di secondo livello, completando la transizione verso l’infezione effettiva (Figura 5).

Secondo Stadio

La struttura del codice dello shellcode, identificato come uno Stager custom , evidenzia una logica difensiva granulare volta a neutralizzare i sistemi di rilevamento prima di stabilire la connessione verso il Command & Control (C2) per il recupero e l’iniezione del payload finale. Tale architettura subordina l’attivazione della catena infettiva al superamento di rigidi controlli di conformità ambientale, garantendo la sopravvivenza del vettore solo in contesti ritenuti sicuri.

Tra le peculiarità dello shellcode si evidenziano:

• Defense Evasion (AMSI Bypass): il codice implementa una tecnica di memory patching diretta contro la libreria amsi.dll. Mediante la risoluzione dinamica delle API e la de-offuscazione delle stringhe interne, il codice individua l’indirizzo in memoria della funzione AmsiScanBuffer e ne sovrascrive il prologo (i primi byte). Questa operazione inibisce preventivamente la scansione di Windows Defender, rendendo il processo invisibile e garantendo l’esecuzione indisturbata del download del payload successivo;
• Anti-Virtualization: il binario esegue istruzioni a basso livello per la verifica delle risorse hardware. Il processo viene terminato immediatamente ove si rilevi un ambiente tipico da sandbox (es. meno di 2 processori logici o memoria RAM inferiore a 4GB );
• Execution & Staging: il vettore opera come stager di prima fase , con il compito di validare l’ambiente di esecuzione e preparare il passaggio allo stadio successivo della catena d’infezione. Completati i controlli preliminari, il componente stabilisce una comunicazione con l’infrastruttura remota in attesa di ricevere, decifrare ed eseguire in memoria il payload finale , identificato come l’infostealer Acreed (Figura 6).

Stadio finale

Acreed Stealer presenta le seguenti peculiarità:

• Infostealer a scopo finanziario , progettato per la raccolta automatizzata di informazioni sensibili.
• Focalizzazione sui browser web , con particolare interesse per credenziali, cookie di sessione e dati di autofill.
• Capacità di sottrazione dell’identità digitale completa , utile per il bypass dei meccanismi MFA.
• Targeting di dati ad alto valore , inclusi wallet di criptovalute ed estensioni browser dedicate.
• Raccolta di informazioni di sistema , impiegate per profilare e classificare le vittime.
• Esfiltrazione centralizzata dei dati verso infrastrutture remote controllate dall’attaccante.
• Assenza di persistenza avanzata , con ciclo operativo rapido e orientato all’abbandono dell’host.
• Distribuzione come payload di secondo livello , tipicamente veicolato tramite stager personalizzati.

Criticità e superficie di esposizione

Il caso trattato rimarca i rischi legati all’esposizione di servizi applicativi direttamente sulla rete Internet senza garantire un’adeguata protezione tramite misure di sicurezza e aggiornamenti costanti. Sistemi accessibili pubblicamente, ove non correttamente configurati o mantenuti, costituiscono un vettore privilegiato per gli attaccanti, che possono sfruttare vulnerabilità note, configurazioni errate o di default, per ottenere un punto di accesso nella rete dell’organizzazione.

Questi scenari sono stati ampiamente trattati nell’ambito del bollettino BL01/250626/CSIRT-ITA , che metteva in evidenza come la presenza di tali elementi incrementi la superficie di esposizione e il rischio di compromissione.

Questa campagna ha visto lo sfruttamento di diverse istanze WordPress 6.x, per la distribuzione dei payload intermedi e del malware finale.

Le vulnerabilità presenti in tali istanze associate ai seguenti identificativi CVE:

• CVE-2024-31211
• CVE-2024-4439
• CVE-2024-31111
• CVE-2025-58674

unitamente a meccanismi di autenticazione non adeguati, hanno presumibilmente facilitato l’accesso non autorizzato ai portali, permettendo agli attaccanti di caricare codice malevolo, compromettendo così la sicurezza dei sistemi coinvolti e ampliando la portata dell’infezione.

Azioni di Mitigazione

Gli utenti e le organizzazioni possono far fronte a questa tipologia di attacchi attivando le seguenti misure preventive:

• fornire periodiche sessioni di formazione finalizzate a riconoscere il phishing, diffidando in particolare dalle comunicazioni non attese che invitano ad aprire allegati e/o link sospetti;
• non accedere a collegamenti internet o a relativi contenuti esterni se non si è certi dell’affidabilità della risorsa;
• evitare di prelevare ed eseguire file (lnk, exe, bat, js, vbs, ecc.) pdf o documenti contenenti macro se non si è certi della loro liceità;
• evitare di eseguire, tramite shell, codice di dubbia provenienza;
• mantenere un processo di patch management automatizzato per il CMS (e relativi plugin/temi), assicurando l’applicazione tempestiva di tutte le patch di sicurezza non appena vengono rilasciate;
• limitare l’esposizione diretta di endpoint critici (wp-login.php, xmlrpc.php) tramite firewall applicativo (WAF), regole di accesso basate su IP e CAPTCHA.

Azioni di risposta agli incidenti

Qualora si riscontrino evidenze di avvenuta compromissione sui propri sistemi, si raccomanda agli utenti e alle organizzazioni di attuare le seguenti azioni:

• collezionare eventuali evidenze, quali processi/servizi in esecuzione su dispositivi target, log di rete e log di autenticazione considerati non convenzionali;
• porre in isolamento e/o offline gli host potenzialmente interessati dalla compromissione;
• ripristinare gli host compromessi ad un’immagine precedente consistente (dopo aver espletato le necessarie attività forensi);
• resettare gli account degli utenti interessati dalla compromissione;
• segnalare tempestivamente a questo CSIRT, tramite il portale https://segnalazioni.acn.gov.it/ l’evento occorso.