Sintesi

Questo CSIRT ha recentemente analizzato i meccanismi di una sofisticata campagna di phishing, caratterizzata da codice offuscato progettato per sottrarre informazioni sensibili alle potenziali vittime, che interagisce attivamente con un server di comando e controllo (C2) al fine di aumentare la credibilità dell’attacco.

Descrizione e potenziali impatti

Questo CSIRT ha recentemente analizzato i meccanismi di una sofisticata campagna di phishing, veicolata tramite un link verso un documento da visionare tramite il servizio lecito PDFfiller (Figura 1) .

Il documento in questione si presenta come un presunto file PDF (Figura 2), apparentemente legittimo, che per essere visualizzato richiede un’autenticazione da parte dell’utente.

A tal fine, viene proposto alla vittima un link che la indirizza verso una pagina di login malevola (Figura 3), progettata per simulare un ambiente di autenticazione lecito e carpire le credenziali di accesso.

La suddetta schermata di login contiene del codice JavaScript offuscato volto a sottrarre informazioni sensibili agli utenti che, una volta eseguito, interagisce attivamente con un server di comando e controllo (C2), il quale guida dinamicamente il comportamento della pagina, nel tentativo di aumentare la credibilità dell’attacco attraverso risposte contestuali e flussi simulati di autenticazione.

Di seguito è riportata un’analisi dei meccanismi utilizzati per eseguire il payload malevolo.

Analisi del codice offuscato

Il codice della landing page di login presenta un payload offuscato diviso in 2 parti: la prima deputata a verificare che non vi siano controlli di debug attivi: in caso positivo l’utente verrà reindirizzato verso un noto sito di eCommerce. In caso contrario il codice prosegue con l’esecuzione della seconda parte (Figura 3) che contiene la logica malevola.

La decodifica avviene a runtime e prevede la concatenazione del contenuto di più variabili contenenti ognuna una porzione in Base64 del payload cifrato finale.

Le variabili hj e pp contengono rispettivamente il vettore di inizializzazione ( IV ) e la chiave AES di decrittazione.

L’algoritmo prevede prima la decodifica del payload da Base64 e successivamente la decrittazione tramite AES; infine converte l’array di byte decifrati in una stringa UTF-8 per ottenere il codice HTML/JavaScript in chiaro (Figura 5), pronto per essere eseguito durante le fasi di rendering della pagina.

Proseguendo l’analisi del codice deoffuscato, è stato individuato un secondo stadio di offuscamento: il testo contiene un ulteriore payload incorporato, codificato in Base64 (Figura 6).

Questa parte contiene il core del payload che contiene la logica di esecuzione e comunicazione con il C2.

Analisi del Core

Il payload analizzato rappresenta un kit di phishing avanzato che combina interfacce predefinite, un server C2 e offuscamento multi-stadio per massimizzare l’efficacia dell’attacco. La strategia server-side consente di variare in tempo reale l’esperienza dell’utente, mostrando schermate diverse e adattando il comportamento del sito in base alle risposte ricevute, come richieste OTP, errori, blocchi temporanei o redirect finali. Tutti gli scenari e le logiche necessarie per il furto di credenziali sono già incorporati nel codice, rendendo il phishing credibile e difficile da rilevare con analisi statiche.

Di seguito un elenco delle peculiarità analizzate:

1.1 Simulazione di interfacce di login

• Genera interfacce di login opportunamente predisposte, che ripropongono loghi e riferimenti di servizi legittimi (Microsoft, Okta, GoDaddy, Apple o Netflix).
• Implementa animazioni e transizioni per aumentare la credibilità e l’autenticità dell’interfaccia.

1.2 Raccolta ed esfiltrazione delle credenziali

• Le credenziali inserite dall’utente vengono cifrate localmente con AES (modalità CBC) usando una chiave statica definita nel codice (1234567890123456).
• I dati cifrati vengono successivamente inviati al server C2 tramite richieste HTTP di tipo POST (Figura 7).
• Il server C2 risponde con payload cifrati che il client decodifica localmente e che contengono istruzioni per veicolare il flusso di esecuzione (vds punto 1.3).

1.3 Interazione avanzata e scenari predefiniti

• Il codice contiene scenari predefiniti già integrati: login fallito, richiesta OTP, verifica e-mail/telefono, blocco account, redirect finale,
• Ogni possibile risposta del server (es. otp sent, approved, error, protectaccount) attiva una sezione specifica del comportamento già presente nella pagina HTML.
• Il portale simula vari metodi di autenticazione: OTP via SMS, app Authenticator, chiamate vocali, ecc.

1.4 Evasione e offuscamento

• Le URL generate per la comunicazione verso il C2 sono dinamiche e casuali, rendendo più difficile il rilevamento automatico delle richieste POST.
• Il codice rileva le caratteristiche del browser per adattare comportamenti e interfacce.
• Sono presenti strumenti che controllano i dati inseriti dall’utente per verificare se contengono domini presenti in una lista nera, impedendo così l’elaborazione di input provenienti da determinati siti.

2. Tracciamento, telemetria e temporizzazione

• Il client tiene traccia se l’utente ha già visitato la pagina tramite la variabile pagevisitedalready; se è la prima visita invia un evento pagevisit con btoa(userAgent) al server per identificare utenti unici.
• Sono presenti timer di disconnessione: dopo un periodo di inattività, il portale mostra messaggi come “ We didn’t hear from you ” o “ Try again later ” per simulare timeout e aumentare la pressione psicologica.
• Sono altresì previsti messaggi di errore simulati: “ Too many attempts ”, “ We didn’t hear from you ”, “ account locked ” – utilizzati per esortare l’utente a riprovare, fornire ulteriori dati o variare il canale di autenticazione.
• Infine, è previsto anche un meccanismo di blocco temporaneo a seguito di troppi tentativi. Vengono visualizzate schermate che simulano il blocco dell’account, utili a persuadere la vittima nel seguire istruzioni aggiuntive (es. fornire e-mail alternativa, telefono, ecc.).

3. Tipologie di interfacce presenti nel codice

• PDF mode (uname_pdf, sections_pdf): simula di ambienti documentali, utile per phishing legato a documenti da visualizzare o firmare.
• DOC mode (uname_doc, sections_doc): simula un ambiente tipo Microsoft Word/Office.
• Live mode (*_live): fornisce interfacce dinamiche per prodotti Microsoft, quali MS 365 e Outlook, con flussi di autenticazione avanzati (OTP, Authenticator).
• Standard mode (uname, pwd, otp): mostra un’interfaccia generica, utilizzata in contesti non specifici.

Azioni di mitigazione

Gli utenti e le organizzazioni possono far fronte a questa tipologia di attacchi verificando scrupolosamente le e-mail ricevute e attivando le seguenti misure aggiuntive:

• fornire periodiche sessioni di formazione finalizzate a riconoscere il phishing diffidando da comunicazioni inattese;
• non accedere a collegamenti internet o a relativi contenuti esterni se non si è certi dell’affidabilità della risorsa;
• accertarsi della legittimità dei siti che richiedono l’inserimento dei propri dati d’accesso;
• abilitare l’autenticazione a più fattori (MFA) su tutti gli account aziendali e personali per ridurre l’impatto di eventuali credenziali compromesse;
• utilizzare soluzioni di filtraggio e-mail avanzate che analizzano allegati, link e domini sospetti prima che raggiungano l’utente finale;
• monitorare e bloccare domini e URL sospetti a livello di firewall o proxy, riducendo la possibilità di comunicazioni con server di phishing;
• verificare la presenza di certificati SSL/TLS validi sui siti di login e diffidare di quelli privi o scaduti;
• isolare e analizzare link o allegati sospetti in sandbox o ambienti controllati prima di aprirli;
• implementare alerting e log centralizzati per rilevare tentativi di accesso non autorizzati o comportamenti anomali degli utenti;
• aggiornare costantemente software e browser per ridurre il rischio di sfruttamento di vulnerabilità note.