Introduzione
Disclaimer: tutto ciò che viene mostrato in questo post è stato eseguito esclusivamente su una macchina virtuale, utilizzando la Flare VM, in un ambiente isolato e sicuro.
L'obiettivo di questo post è analizzare un attacco di phishing reale, recuperando il maggior numero di indizi possibili e riuscendo a risalire alla catena di attacco completa. La mail che vedrete qui sotto è reale, ricevuta da me.
Si vede chiaramente che è una mail di phishing: il mittente ha un indirizzo lunghissimo e l'oggetto della mail non ha senso. Il primo passo è analizzare gli header della mail, che ci daranno informazioni importanti su tutti i mail server in cui la mail è passata, il mittente reale, da dove è partita ecc.
FASE 1: Analisi degli header della mail
Estrazione e importazione
Scarichiamo il messaggio originale e importiamolo in un lettore di testo.
Le prime cose da analizzare sono:
Return-Path: <Return@virtualization-governance-synthesis.netpulse.com.bunnyvalents.com>
Reply-To: Non presente
From: "francesco1995" <pulrtxlcunrige.32484135341275@nrfxbh.5egeai.5piaz6.us>- From: Il mittente dichiarato, facilissimo da falsificare (infatti hanno usato la parte iniziale della mia mail)
- Return-Path: È il server al quale ritorna la mail se il destinatario è irraggiungibile, più difficile da falsificare rispetto al From
Se analizziamo il From ci accorgiamo subito che la mail è stata generata presumibilmente da un bot: `pulrtxlcunrige.32484135341275@nrfxbh.5egeai.5piaz6.us`.
Anche la mail nel Return-Path presenta dei domini reali messi a caso senza un senso logico: `Return@virtualization-governance-synthesis.netpulse.com.bunnyvalents.com`.
Analisi dei campi Received
Analizziamo adesso tutti i campi Received.
Io da terminale su Arch uso:
grep "^Received:" path/to/mail.eml
Lo faccio da terminale perché è più pulito. Una cosa importante: i Received si leggono dal basso verso l'alto. Il Received più in basso equivale all'inizio del viaggio, mentre quello più in alto all'arrivo.
Hop 1: Sailthru (email marketing)
Received: from nj1-madbrick.flt (172.18.20.7) by njmta-53.sailthru.comLa mail parte proprio da qui. Sailthru.com è un provider di email marketing. Quindi possiamo già dire che l'attaccante non ha usato un server privato ma bensì un servizio di email marketing.
Hop 2: Rete interna Sailthru
Received: from njmta-53.sailthru.com (173.228.155.53) by dailybeast-a.sailthru.comLa mail continua e passa ad un altro nodo interno della rete che fa sempre parte di Sailthru.
Hop 3: Server esterno dell'attaccante
Received: from mashment.site (dicut.org. [81.7.16.33])Qui finalmente usciamo da Sailthru. Questo server esterno `[81.7.16.33]` è colui che ha spedito la mail a Gmail. Non sappiamo ancora se questo dominio appartiene all'attaccante o no, ma lo salviamo per dopo.
Hop 4: Conferma Gmail
Received: by 2002:a05:6124:6901:b0:44a:dc95:9b08Il quarto passaggio non ci interessa: è solo la conferma da parte di Gmail di aver ricevuto la mail.
SPF e DKIM
SPF (Sender Policy Framework)
spf=passSPF è una lista che il dominio pubblica per dire quali indirizzi IP sono autorizzati a spedire mail a suo nome.
Pass significa: l'IP `81.7.16.33` è esplicitamente autorizzato dal dominio `virtualization-governance-synthesis.netpulse.com.bunnyvalents.com` a spedire a suo nome.
Non è una firma "buona": è solo che se l'attaccante controlla quel dominio può mettere il suo IP nella lista SPF. Cioè: SPF passa perché l'attaccante ha scritto la regola.
DKIM (DomainKeys Identified Mail)
dkim=permerrorDKIM è una firma crittografica: il dominio di invio mette una chiave pubblica nel DNS e firma ogni mail con quella privata. Gmail verifica: firma valida = mail legittima.
permerror (permanent error) significa: la firma non si può verificare — il dominio `nrfxbh.5egeai.5piaz6.us` non ha la chiave pubblica nel DNS.
In pratica: la firma DKIM è decorativa, messa lì per apparire, ma non c'è nulla dietro.
A questo punto ci sarebbero altri campi nell'header da analizzare ma in questo caso non danno altri indizi significativi, quindi procediamo con quello che abbiamo trovato prima di aprire il link che l'attaccante ha inviato.
FASE 2: Infrastruttura
Abbiamo visto che la mail è stata spedita da questo IP: `81.7.16.33`.
Il server è ospitato in Germania presso EUserv, un hosting provider tedesco che vende servizi di VPS a basso prezzo ed anche gratuiti.
Su quell'IP ci sono registrati due domini: `mashment.site` (~3 mesi) e `dicut.org` (~8 mesi). Visitando gli URL si capisce subito che sono siti di copertura: entrambi i domini sono identici e sono riempiti con link che rimandano al sito del New York Times.
Inserendo l'IP del VPS su Shodan.io escono fuori un sacco di vulnerabilità: il sistema non è aggiornato ed utilizza tecnologia di 10 anni fa. Basterebbero pochi minuti per avere accesso completo al server e magari leggere i file di log degli accessi, ma pur trattandosi di un truffatore, questo è illegale.
FASE 3: Catena di redirect
Quello che possiamo fare è procedere cliccando il link presente nella mail e vedere cosa succede, ovviamente usando una VM.
Questo è il link (non cliccare):
http://storage.googleapis.com/sd6514s6589dsd/22.html#/vcxvcx.html?syv=1x16a8322d2b7132_vl_inter.k0jsm46s7wq-18ge411.9w0mo9e.wyzUmdvNDZzN3dxLTE4Z2U0MTE0m4NPaPrima però scarichiamo la pagina con curl per vedere il contenuto.
All'interno troviamo solo un redirect e l'URL viene modificato. Viene usato nella mail questo link di Google Cloud Storage per dare maggiore fiducia, ma appena la vittima clicca il link avviene subito un redirect. Siccome questi attacchi sono noti per avere molti redirect, conviene aprire il link direttamente in Burp Suite.
Cliccando avanti e seguendo la catena di redirect si arriva al momento di pagare.
La catena completa è composta da 13 hop: da Google Cloud Storage fino a `secure.privacy-nest.net`. Perché tanti redirect? Per antiscreenshot (i servizi di scanning perdono traccia dopo pochi hop), evasione (ogni hop verifica se il visitatore è un bot)
FASE 4: Il meccanismo
A questo punto siamo arrivati alla pagina finale. Non rimane altro che compilare i campi con dati finti ed intercettare il traffico con Burp Suite.
La pagina mostra "Activate your protection" e offre un finto servizio ad-blocking a €9.95/mese. L'email diceva che il mio iCloud era bloccato, ma qui mi viene chiesto di abbonarmi ad un ad-blocker. L'esca di iCloud serve unicamente a convogliare traffico raggirato verso un form di incasso per attivare abbonamenti ricorrenti non desiderati.
FASE 5: Esfiltrazione dati con Burp Suite
POST 1: Carta di credito → RocketGate
Inserendo dati finti e intercettando con Burp, il primo POST va a RocketGate, un payment processor legittimo.
L'attaccante ha usato un servizio RocketGate per attivare un abbonamento mensile. Questo permette loro di modificare l'importo, gestire gli addebiti o creare nuove transazioni.
Giusto per dare un'idea della portata di questi attacchi: se cerchiamo RocketGate su Google, i suggerimenti sono tutti su come cancellare un'iscrizione.
POST 2: Token + fingerprint → server dell'attaccante
Andando avanti possiamo vedere che viene inviata una seconda richiesta POST con il token di RocketGate al server dell'attaccante.
Oltre al token, vengono inviati anche dati come email, nome, cognome e un fingerprint del browser. Il fingerprinting serve a tracciare la vittima anche se cambia email e a bloccare i ricercatori.
GET callback: RocketGate notifica l'attaccante
Quando il pagamento fallisce, RocketGate chiama il server dell'attaccante con tutti i dati.
In questo modo l'attaccante riceve customer ID, account ID e tutti i dati della transazione. Privacy-nest.net è il punto di raccolta dati dell'attaccante.
FASE 6: Chi è PrivacyNest
Il sito è legittimo ed offre un servizio, con sede legale in Romania (Metric Index S.R.L.). Però non gode di una buona reputazione.
Ha solo una stella su 5 su Trustpilot e ogni recensione dice la stessa cosa: truffa!
Il sito si smentisce da solo: è un rivenditore di licenze
Analizzando il codice HTML del sito (Ctrl+U) emergono dettagli che nell'interfaccia non vengono mostrati. I siti moderni come questo sono costruiti in Next.js: tutti i testi viaggiano dentro blocchi JSON nei tag <script> e vengono renderizzati solo quando servono, quindi il sorgente grezzo spesso rivela più di ciò che mostra l'UI.
Nei Termini e Condizioni (articolo 2.2) si legge:
The Provider acts as a reseller and facilitator of the Licensed Software offered under the Privacy-Nest brand. The Provider does not develop the Licensed Software.
Tradotto: Metric Index S.R.L. non sviluppa alcun software, è un rivenditore di licenze. E sono le FAQ stesse del sito a rivelare chi è il produttore vero: nella sezione "Installation & Activation", alla domanda "How do I install Cyber Privacy Suite?", la risposta dice testualmente "Download the installer from ShieldApps' official site".
Il prodotto finale è quindi Cyber Privacy Suite di ShieldApps, affiancato da uno storage IDrive e da un upsell chiamato "Toolpower+" (€9.95/mese): nella homepage, sezione bundle, compaiono proprio i pulsanti "Install Cyber Privacy Suite" e "Install IDrive Cloud Storage". Dai Termini emergono anche i prezzi reali dell'abbonamento: €19.95 o €29.95 al mese a seconda dell'offerta, con rinnovo automatico.
Riassumendo la catena economica completa:
Mail finta "iCloud bloccato" (spam)
↓
privacy-nest.net → Metric Index S.R.L., Bucarest [il reseller]
↓
licenze Cyber Privacy Suite (ShieldApps) + IDrive storage
↓
abbonamento ricorrente incassato tramite RocketGateL'esca Apple serve solo a giustificare il click; ciò che arriva dopo è l'incasso di un abbonamento a un prodotto che non c'entra nulla con iCloud.
Conclusione
L'attacco analizzato non è un semplice furto di credenziali, ma una campagna di Brand Impersonation Phishing che alimenta uno schema di Subscription Trap. L'esca di iCloud serve unicamente a convogliare traffico raggirato verso un form di incasso per attivare abbonamenti ricorrenti non desiderati.
Il nome preciso di questo modello economico è subscription trap scamware: un reseller (qui Metric Index S.R.L.) rivende licenze di software reale ma poco conosciuto (Cyber Privacy Suite di ShieldApps), e riempie il funnel con spam di brand impersonation. Dietro lo spam però non c'è una misteriosa organizzazione criminale: sono singoli utenti che si iscrivono alle campagne di affiliazione (le reti CPA mettono a disposizione l'offerta, il link tracciato con il proprio sub-id e la commissione per ogni abbonamento venduto) e poi cercano traffico con qualunque mezzo — mail false di rinnovo, popup scareware, messaggi SMS. Ogni vittima che completa l'abbonamento vale la commissione all'affiliato che ha generato il lead: chi ha più fantasie nel costruire l'esca, più guadagna.