ACN, allerta phishing su consegna pacchi. Come mitigare i rischi

1 year ago 189

Il CSIRT Italiano avverte gli utenti italiani e le organizzazioni sull’escalation di attacchi phishing su consegna pacchi. Ecco come possono far fronte a questa tipologia attivando le seguenti misure aggiuntive.

È stata recentemente rilevata dal CIRT una nuova ondata di campagne di email di phishing a tema corrispondenza, che sfrutta nomi e riferimenti a marchi noti operanti nel settore delle spedizioni.

L’email (Figura 1), scritta in italiano, sembrerebbe inviata ad una lista di distribuzione opportunamente predisposta, stando al contenuto del campo “A”:

All’interno della stessa è presente un’immagine che, facendo leva sulla nota dicitura della compagnia di spedizioni “DHL”, notifica la mancata consegna di una corrispondenza, inducendo l’utente a dar seguito alla comunicazione e cliccare sull’unico pulsante presente in calce:

Cliccando sul pulsante “CONFERMARE” contenuto nel corpo della mail, si viene reindirizzati su una landing page:

hXXps://vibeslogics[.]info/<MD5>

dove l’ultima parte dell’URL – in formato hash – è verosimilmente utilizzata dall’attaccante per ricondurre la vittima all’email di origine.

All’interno di tale pagina è presente una schermata che informa l’utente della presenza di un messaggio presumibilmente relativo alla consegna di un pacco:

Dalle analisi del dominio “vibeslogics[.]info” si evidenzia inoltre che – allo stato dell’arte – la pagina principale restituisce il codice di errore HTML “404” (contenuto non trovato) e che lo stesso sia stato registrato di recente, avvalorando il fine di utilizzo per scopi malevoli.

Qualora dato seguito al link “Conferma”, alla vittima sarà presentato il medesimo codice di tracciamento fasullo presente nell’email e una serie di informazioni – volte ad aumentare la presunta leggittimità della spedizione – per pianificare la consegna della giacenza (Figura 4), quali:

  • modalità di ricezione del pacco: ritiro a domicilio o di persona;
  • luogo di ritiro: a casa o lavoro (nel caso della prima scelta);
  • giorno di ritiro: feriali o weekend.

Successivamente verrà notificato all’utente il riepilogo contenente l’importo da pagare per perfezionare la consegna e un nuovo pulsante che avvierà (Figura 4 – in basso a destra) la raccolta dei relativi dati anagrafici.

La vittima verrà, quindi, reindirizzata verso domini selezionati casualmente, riferibili a siti di ecommerce opportunamente predisposti e/o precedentemente compromessi.

Le relative URL risultano avere la seguente struttura:

hXXps://bestproductsforall[.]net/c/<alfanumerico{8}>?s1=<hash{31}>&s2=<INT{3}>&s3=<INT{4}>&offer_id=<INT{4}>&first=&last=&country=&zip=&city=&address=&email=&phone=#rafl

mentre le informazioni anagrafiche richieste (Figura 5) risultano essere:

  • nome
  • cognome
  • CAP
  • città
  • nazione
  • numero di cellulare
  • indirizzo email

Tali informazioni, qualora immesse e confermate, verranno inviate tramite richiesta POST all’URL:

hXXps://bestproductsforall[.]net/c/<alfanumerico{8}>/register?_luuid=<UUID>

mentre la vittima sarà reindirizzata verso una nuova landing page, alla URL:

hXXps://aromascent[.]club/r/<alfanumerico{17}/<UUID>/payment?token=<BASE64>&_luuid=<UUID>&_sid=<BASE64>

Nel corso dell’analisi è stato osserato che la URL demandata alla raccolta delle informazioni inerenti alle carte di credito cambia di volta in volta, mentre non risulta variare la struttura grafica.

Tale evidenza sembrerebbe confermare l’utilizzo di siti che adottano la stessa tipologia di tecnologia (CMS, framework, ecc.) e che potrebbero essere stati compromessi a seguito del rilevamento di una vulnerabilità nota o tramite l’utilizzo di credenziali di amministrazione precedentemente esfiltrate.

È interessante notare come i parametri token _sid contengano rispettivamente due JSON codificati in BASE64 e aventi la seguente struttura:

{
"iv":<base64>,
"value":<base64>,
"mac":<SHA256>,
"tag":""
}

Tali dettagli sembrerebbero rimandare ai parametri impiegati dal framework php lecito denominato Laravel, utilizzati per decifrare un messaggio, tramite un APP_KEY non nota e opportunamente generata dal framework, unitamente all’algoritmo di cifratura AES.

In quest’ultima landing page è richiesto alla vittima di inserire i riferimenti della propria carta di credito (Figura 6):

Qualora dato seguito, le informazioni verranno inviate, tramite richiesta di tipo POST, alla URL:

hXXps://eu-prod.oppwa[.]com/v1/checkouts/<MD5>.prod01-vm-tx01/payment

Infine, verrà chiesto alla vittima di confermare l’acquisto inserendo un codice relativo al secondo fattore di autenticazione (Figura 7), facendo leva sui loghi della banca corrispondenti al numero della carta di credito immesso:

Ai fini dell’analisi, sono stati inseriti dettagli di una carta di credito inesistente che ha portato alla generazione del seguente messaggio d’errore da parte del precedente sito web (bestproductsforall[.]net):

Ciò farebbe, quindi, supporre che il sistema effettui un controllo sulla validità della carta di credito immessa, ottenendo una serie di informazioni relative all’Istituto bancario in base al codice di 16 cifre inserito restituendo, a prescindere, la medesima pagina d’errore di cui sopra.

Azioni di mitigazione

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

  • evitare di inserire i propri estremi bancari su portali di cui non si conosce l’affidabilità;
  • verificare scrupolosamente i mittenti delle email ricevute e la relativa attendibilità;
  • nel caso in cui si fossero inseriti gli estremi della propria carta di credito contattare quanto prima il proprio Istituto bancario al fine di richiedere il blocco della carta utilizzata.
Read Entire Article