Libraesva : nuova ondata di campagne malware EXCEL 4.0 che abusano della funzione macro FORMULA

Estratto , tradotto, da un articolo di :
Rodolfo Saccani / Responsabile ricerca e sviluppo sicurezza @ Libraesva
L’articolo originale lo puoi trovare qui

MVBA è stato introdotto in Excel 5.0. Prima di allora Excel aveva solo macro XLM, che sono ancora supportate oggi.

Le macro XLM consentono di scrivere codice immettendo istruzioni direttamente nelle celle, proprio come le normali formule. In realtà sono chiamati macro-formule.

[omissis]

Ci sono alcune dichiarazioni tra queste macro-formule che consentono l’esecuzione di codice dannoso, queste sono denominate EXEC, RUN e CALL. Il mese scorso, nell’aprile 2020, è circolata un’ondata di malware che abusa di queste chiamate.

A maggio abbiamo visto una nuova ondata che apparentemente abusava ancora delle macro XLM ma senza chiamare EXEC, RUN o CALL. Al momento in cui li abbiamo ottenuti, la maggior parte di questi campioni aveva un tasso di rilevamento pari a 0 su virustotal, quindi sembra che valga la pena investigarli.

[omissis]

Alcuni di questi file stavano usando trucchi aggiuntivi per confondere l’analisi, come mettere le macro in fogli “nascosti”. Alcuni hanno usato fogli “molto nascosti”, altri sono stati protetti con la password “VelvetSweatshop” (che è un trucco usato da Microsoft per definire documenti di sola lettura). C’è anche una grande variabilità nei nomi dei file e nelle campagne e-mail. Non perderò tempo con questi dettagli e andrò subito al punto.

[omissis]

[Dall’analisi dei campioni , si e’ visto che tutti hanno in comune] l’abuso della macro-formula FORMULA. La denominazione ricorsiva può creare confusione, quindi lasciatemi fornire un po ‘di chiarimenti: proprio come qualsiasi altra istruzione formula (come IF o SUM per esempio), l’istruzione FORMULA può essere inserita in una cella sotto forma di formula. Questa affermazione particolare sembra essere denominata FORMULA stessa.

Cosa fa questa dichiarazione FORMULA? Immette una formula nella cella attiva (o in un riferimento). Fondamentalmente ciò che viene dato come parametro a questa chiamata diventa una fomula.

Generazione indiretta di formule se lo desideri e, sì, è pericoloso come sembra.

[omissis]

Questo è fondamentalmente il comportamento di questi campioni dannosi: creano una formula raccogliendo dati da molte celle diverse e apportando alcune trasformazioni. Quindi applicano la formula usando l’istruzione FORMULA.FILL (o una delle sue varianti, vedi il riferimento alle funzioni collegato sopra se sei interessato).

Il testo esatto del FORMULA è costruito in fase di esecuzione e ciò garantisce l’offuscamento che sembra essere efficace dato il punteggio zero o molto basso ottenuto da questi campioni su Virustotal.

[omissis]

Non siamo interessati a retroingegnerizzare ogni campione per scoprire i dettagli del comportamento. Come società di sicurezza della posta elettronica ci concentriamo sui metodi e sugli strumenti utilizzati dagli aggressori piuttosto che sulla specifica variante di malware.

Il nostro compito è bloccare queste minacce sul gateway, sappiamo che l’approccio del riconoscimento di elementi dannosi noti non è efficace e pertanto ci concentriamo sulla rimozione degli strumenti utilizzati dagli aggressori.

La filosofia del nostro sandbox QuickSand è più simile a un firewall: quando i nostri sistemi vedono un modello come questo, non si preoccupano davvero del reverse engineering del comportamento reale, non si preoccupano nemmeno di riconoscere se si tratta di una variante di malware nota o uno nuovo.

Che sia diretto o indiretto, non è consentito alcun modo di eseguire materiale per i documenti consegnati via e-mail. Questo approccio è meno soggetto all’evasione ed è proattivo: blocca le varianti attuali e future, note e sconosciute.

Il basso tasso di rilevamento di questi campioni su virustotal e su molti servizi di sandboxing basati sulla virtualizzazione conferma che, per essere efficace con le minacce in continua evoluzione, questo è un approccio migliore.

Estratto , tradotto, da un articolo di :
Rodolfo Saccani / Responsabile ricerca e sviluppo sicurezza @ Libraesva
L’articolo originale lo puoi trovare qui

16 Maggio 2020

Subscription Bombing

Subscription Bombing è una nuova tecnica per generare messaggi non desiderati (“spam”).

La tecnica consiste nel completare (con metodi automatici) migliaia di form di registrazione o di richiesta di informazioni, che generano automaticamente delle mail dirette all’indirizzo che è stato inserito all’interno il form. E’ sufficiente compilare il form, utilizzando l’indirizzo email della vittima per fargli recapitare migliaia di email in contemporanea.

I siti a rischio sono quelli che non usano dei metodi per individuare i form compilati con sistemi automatici, con meccanismi con il CAPTCHA.

Per i sistemi antispam tutti questi messaggi sono legittimi, perché generati da sistemi perfettamente regolari, arrivano ciascuno dal server corretto e molte volte rispettano anche il record SPF.
Se l’utente avesse usato realmente il proprio indirizzo email ed effettuato quella registrazione oppure compilato il modulo per la richiesta di informazioni quella mail è richiesta e deve arrivare.

Questo genere di attacco ha due vittime:

  • il proprietario del sito web che rischia di finire in qualche blacklist pubblica, ad esempio Spamhaus è molto attenta a questo fenomeno e comunque si ritrova nel database un numero elevato di iscrizioni o richieste fittizie.
  • il proprietario della mail che si ritrova la casella invasa di messaggi di posta non desiderati e rischia fra i tanti messaggi di non notare qualche messaggio di posta importante.

Questo genere di attacco comporta un fenomeno che potremmo definire “fumogeno digitale“. Supponiamo che l’attaccante abbia le nostre credenziali del conto PayPal e sia pronto ad effettuare un trasferimento di denaro. Gli resta il problema di sopprimere i messaggi di posta verso il nostro indirizzo che potrebbero allarmarci. Con un attacco del genere fra i migliaia di messaggi non desiderati che potrebbero arrivare alla casella in contemporanea il messaggio di PayPal che ci indica l’avvenuto trasferimento potrebbe anche passare inosservato, considerato che sono frequentementi i messaggi di phishing con oggetto PayPal.

argonavislab

Argonavis ed i suoi esperti in sicurezza informatica sono a tua disposizione per darti supporto ed aiutarti a proteggere la tua azienda dai rischi informatici.

Richiedi Informazioni

12 Marzo 2017

Rilasciato LibraESVA 4.0

E’ stata rilasciata la versione 4.0 di LibraESVA.

libraesva

La nuova versione include correzione a problemi noti, nuove funzionalità e migliorie a funzionalità esistenti.

Problemi Corretti

– Corretto problema che causava il blocco del servizio HTTPD
– Corretto un errore che duplicava le whitelist
– Corretto un problema sul rilascio di archivi annidati nella funzione “Dangerous content release override”
– Corretto un errore sul job di Backup
– Corretto un problema sul wizard del Cluster
– Corretto un problema su Rule Score Override
– Migliorato il supporto ad UTF-8 nelle Custom Spam Rules
– Corretto un problema che si verificava durante l’aggiunta di un dominio
– Corretto un problema sulla configurazione di SSL in apache
– Corretto un problema sulle blacklist
– Corretto un problema sul download del Maillog
– Migliorate le prestazioni di LocalRBL
– Corretto un problema sul rilascio di archivi protetti da Password
– Corretto un problema sulle API per ISP

Nuove Funzionalità

– Nuova interfaccia Web
– Aggiunta la nuova funzionalità URL Sandbox
– Aggiunta High Availability Distributed
– Aggiunto un nuovo plugin Graymail
– Aggiunto il supporto ai certificati Crittografici
– Aggiunta l’azione Forward per i messaggi clean
– Filechecks archive è attivato per tutti i domini
– La richiesta di rilascio del messaggio dalla quarantena viene notificato all’amministratore
– Le impostazioni di Clean Messages sono state separate dalle impostazioni di Quarantine Retention
– Aggiunto il filtro Bounced emails nelle funzioni di ricerca
– Nuove funzionaiità offerte dalle API
– Aggiunta l’opzione SMTP Delay warning
– File con estensione .jar vengono bloccati di default
– Motore di scansione aggiornato
– Aggiunta la possibilità di vedere lo stato di aggiornamento dei compomenti di Libra Esva

Tutti i clienti LibraESVA sono incoraggiati a procedere all’aggiornamento.

NOTE: Questo aggiornamento può impiegare oltre 5 minuti di tempo per completarsi e richiede il riavvio del sistema al termine.
Prima di installare l’aggiornamento è buona prassi effettuare uno snapshot della macchina virtuale.

L’aggiornamento è scaricabile all’indirizzo: http://docs.libraesva.com/download/libra-esva-3-6-5-0-to-3-7-0-0-upgrade-script

I tecnici certificati su LibraESVA di Argonavis sono a tua disposizione per darti supporto tecnico o commerciale su LibraESVA

Richiedi Informazioni

14 Settembre 2016

MTA Queue come scegliere la durata del Lifetime

MTA Queue Lifetime è il numero di giorni che un messaggio che non è stato consegnato a business-man-1002781_1920causa di un errore temporaneo, deve rimanere in coda di consegna, in modo che quando il sistema del destinatario riprende a funzionare possiamo consegnare il messaggio.

Come dicevamo nell’articolo riferito alla configurazione di LibraESVA il valore di default di 5 giorni è stabilito dal RFC 5321 che regola gli standard di funzionamento del protocollo SMTP, ma che per esigenze particolari LibraESVA ci permette di estenderlo o ridurlo.

La modifica di un parametro definito da un RFC non andrebbe mai fatta, perché rende il comportamento del nostro sistema inatteso ed incomprensibile, tuttavia ci sono dei pro e dei contro da analizzare, sia nel ridurre che nell’estendere questo tempo.

Riducendo il parametro MTA Queue Lifetime abbassiamo la dimensione delle code di consegna e di conseguenza l’impiego di risorse della macchina ma corriamo il rischio di non consegnare dei messaggi di posta nel caso il servizio non venisse ripristinato per tempo.

Aumentando il parametro MTA Queue Lifetime, abbiamo maggiori probabilità che il servizio venga ripristinato e quindi riuscire a consegnare effettivamente il messaggio, ma aumentiamo la dimensione della coda, aumentiamo le risorse impegnate sulla macchina (visto che avvengono continui tentativi di consegna) ed infine non notifichiamo per molto tempo al mittente che il messaggio che ha spedito non è stato consegnato pur essendo stato accettato.

26 Agosto 2016

LibraESVA configurare il tempo di permanenza in coda di un messaggio

LibraESVA permette all’utente esperto di personalizzare il comportamento della propria appliance, anche in aspetti molto avanzati del sistema di gestione del flusso delle email.

L’elemento fondamentale del sistema, detto Mail Transfert Agent (MTA) è quel componente che si occupa di ricevere i messaggi e consegnarli al server destinatario. Di questo componente è possibile effettuare una configurazione avanzata.

libraesva mta

Quando LibraESVA non riesce a consegnare il messaggio a causa di un errore temporaneo (ad esempio il server di destinazione non è disponibile) questo messaggio rimane in coda di consegna per un periodo massimo stabilito dai parametri MTA Queue Lifetime.

Il valore di default di 5 giorni è stabilito dal RFC 5321 che regola gli standard di funzionamento del protocollo SMTP, tuttavia per esigenze particolari LibraESVA ci permette di estenderlo o ridurlo. Questa operazione è tuttavia sconsigliata ed andrebbe effettuata solo in casi eccezionali e per il periodo strettamente necessario a risolvere l’emergenza.

24 Agosto 2016