Allerta da Kaspersky per gli utenti italiani di WhatsApp

 

Tratto da LineaEDP
Autore: Redazione LineaEDP – 13/01/2021
 

Kaspersky rileva una nuova truffa di phishing rivolta agli utenti italiani che sfrutta WhatsApp per carpire i loro dati bancari

 

 

I ricercatori di Kaspersky hanno rilevato una nuova truffa che vede come protagonista WhatsApp, la nota applicazione di messaggistica istantanea utilizzata da oltre due miliardi di persone in 180 Paesi.

La nuova truffa, rivolta agli utenti italiani di WhatsApp, è stata inizialmente rilevata il 30 dicembre 2020 ed è ancora attiva.

Il metodo usato è un classico schema di phishing: l’utente riceve una e-mail in cui viene avvisato che il proprio account WhatsApp è prossimo alla scadenza e viene dunque invitato a rinnovare la registrazione entro 24 ore per evitare di perdere messaggi, foto e video condivisi. Per completare l’operazione, l’utente può pagare tramite carta di credito il rinnovo del servizio per 1 fino a 5 anni, inserendo il codice della propria carta e altre informazioni riservate come CVC e password-3D-secure.

Lo scopo di questa truffa è, infatti, carpire i dati bancari degli utenti.

Il phishing è un’attività relativamente semplice e a basso costo e i criminali informatici continuano a farne ampio uso. Secondo quanto emerso dal report di Kaspersky, infatti, nel terzo trimestre del 2020 la quota media di spam nel traffico postale globale è stata del 48,91%, mentre il sistema Anti-Phishing di Kaspersky da solo ha impedito 103.060.725 tentativi di reindirizzare gli utenti verso pagine fake.

Per proteggersi dal phishing, i ricercatori di Kaspersky raccomandano di:

  • Verificare che i messaggi provengano da fonti affidabili
  • Non cliccare i link da e-mail o messaggi sospetti
  • Verificare l’autenticità dei siti web visitati
  • Installare una soluzione di sicurezza con database aggiornati che includano la conoscenza delle più recenti risorse di phishing e spam.

Per informazioni sulle soluzioni Kaspersky: dircom@argonavis.it

14 Gennaio 2021

LibraESVA azioni da intraprendere su un messaggio di spam

LibraESVA è un sistema estremamente elastico che permette di personalizzare e configurare quali azioni da intraprendere quando viene ricevuto un messaggio di spam.

Le azioni possibili sono:

  • Store: Conserva una copia nella quarantena per un periodo fissato dalla policy, permettendo durante questo periodo la consultazione ed il rilascio.
  • Deliver: Consegna il messaggio al destinatario.
  • Modifica l’oggetto del messaggio: Aggiunge la stringa {Spam?} all’inizio dell’oggetto del messaggio.
  • Notifica: Notifica al mittente che il messaggio è stato bloccato
  • Cancella: Il messaggio viene definitivamente cancellato e non sarà più possibile consultarlo o rilasciarlo.
  • Respingi: Il messaggio viene respinto al mittente, indicando nel messaggio di errore la presenza di spam nel messaggio.
  • Inoltro: Il messaggio viene inoltrato ad un indirizzo da specificare.
  • Converti HTML in testo: Converte la parte HTML del messaggio in linee di testo, rendendo visibili eventuali tentativi di frode.
  • Allega originale: Il messaggio originale viene trasformato in un allegato.
  • Modifica header: Aggiunge una stringa alle intestazioni del messaggio

libraesva azioni spam

E’ possibile combinare diverse azioni, ad esempio Deliver + Modifica l’oggetto del messaggio, permette di ricevere il messaggio con l’oggetto modificato.

Le azioni sono distinte fra le due soglie di Spam dove cè qualche possibilità di trovare dei falsi positivi ed allora è possibile creare delle policy meno restrittive, rispetto ai messaggi di Hi-Spam che hanno totalizzato un punteggio molto elevato e sono da considerarsi messaggi sicuramente di spam.

5 Settembre 2015

Backscattering

Il backscatter è il termine utilizzato per indicare la diffusione di messaggi di mancato recapito di un messaggio di spam originato da altri, ma utilizzando l’indirizzo email della vittiamo come mittente.

Questo genere di messaggio viene generato perché l’indirizzo email a cui lo spammer, a tentato di inviare il messaggio non esiste, o comunque il server che gestisce quel dominio non è stato in grado di consegnare il messaggio che aveva accettato in precedenza (per approfondire reject vs bounce)

Il problema fondamentale è che il protocollo SMTP impone ad un server che ha ricevuto un messaggio e che per qualsiasi ragione non è stato in grado di consegnarlo, di generare una mail di errore, per avvertire il mittente. Quindi bloccare o limitare questi messaggi sarebbe una violazione del protocollo, vale a dire che la soluzione è molto peggiore del problema.

La chiave per arrivare ad una soluzione è nel passaggio “un server che ha ricevuto un messaggio” infatti il problema si supera evitando che il nostro server riceva (reject) messaggi che non è in grado di recapitare. Il messaggio si intende ricevuto, nel momento in cui viene permessa la trasmissione della parte DATA del messaggio, di conseguenza basterebbe verificare prima di permettere la trasmissione l’esistenza dell’indirizzo per ridurre notevolmente il rischio di backscatter.

Una domanda legittima è del perché devo preoccuparmi di non inviare messaggi che sono richiesti dal protocollo.
Le motivazioni sono:

  1. Perché è molto fastidioso per chi riceve il messaggio ritrovarsi la casella inondata di messaggi di ritorno per email che non sono mai stati inviati.
  2. Perché è altissimo il rischio di finire in RBL e vedersi rifiutata la maggior parte della posta inviata dal server.
  3. Perché il nostro server dovrebbe lavorare per smistare posta che non potrà consegnare e di conseguenza utilizzerà risorse e banda per messaggi inutili.

Zimbra permette di difendersi dal backscatter, il controllo dei recipient si attiva con i seguenti comandi

su zimbra
zmlocalconfig -e postfix_smtpd_reject_unlisted_recipient=yes
zmmtactl upgrade-configuration

Argonavis è in grado di fornire supporto tecnico e commerciale su Zimbra, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

26 Giugno 2015

Reject vs Bounce

Capita che alcuni messaggi ricevuti dal nostro server di posta, non possano essere effettivamente consegnati, ad esempio il destinatario del messaggio non esiste nel nostro dominio.

In questo caso il protocollo SMTP prevede due possibilità: il reject (rifiuto) o il rimbalzo (bounce).

La differenza fra queste due tecniche è abbastanza fine, ma sostanziale.

Nel caso di reject del messaggio il server di posta verifica le intestazioni che gli sono state fornite, e se riscontra degli errori, non accetta il comando DATA, per cui la trasmissione del messaggio viene interrotta prima che il messaggio venga ricevuto.

Nel caso di bounce, invece, il server di posta accetta il messaggio completamente, per analizzarlo successivamente, in questo caso se il server considererà di non poterlo consegnare, deve generare un messaggio da recapitare al mittente per informarlo delle ragioni per cui non è stato possibile consegnare la mail.

Le differenze fra queste due strategie si possono sintetizzare in questa maniera:

  • Reject è meno rapido nella ricezione del messaggio, in sistemi poco performanti rischia di mandare in timeout la sessione SMTP, ma riduce il traffico generato ed evita il rischio di backscattering
  • Bounce è più rapido nella chiusura della sessione SMTP, ma accetta ogni volta l’intero messaggio, anche se non verrà mai consegnato ed è alto il rischio di essere considerato server di backscattering.

Esiste una ulteriore possibilità, detta Silently dropping, tipicamente utilizzata nelle quarantene, il messaggio viene completamente accettato, non viene consegnato (a seguito del verdetto di un insieme di regole) ma non viene generato il messaggio di mancato delivery. L’utente è ancora in grado di sbloccare manualmente la consegna del messaggio.

Argonavis è in grado di fornire supporto tecnico per ottimizzare la tua configurazione, se hai necessità di altre informazioni puoi mandare un messaggio.

Richiedi Informazioni

24 Giugno 2015

LibraESVA Zimlet

Argonavis ha saputo sfruttare le approfondite conoscenze che ha acquisito in tanti anni di esperienza sull’utilizzo del prodotto ed ha sviluppato una Zimlet per integrare LibraESVA e Zimbra.

L’idea che ha guidato lo sviluppo della Zimlet è poter offrire all’utente finale la possibilità di Schermata del 2015-04-21 09:04:33visualizzare le proprie code di quarantena ed alla necessità poter intervenire sbloccando dei messaggi, o aggiungendo ed eliminando regole di whitelist/blacklist private per l’utente.

Queste funzionalità si distinguono per la facilità di utilizzo da parte dell’utente, che ritrova le interfacce all’interno di Zimbra, senza dover andare a consultare altre interfacce.

La zimlet mette a disposizione sui propri indirizzi email e relativi alias le funzionalità di:

  • Ricerca nella quarantena
  • Rilascio dei messaggi bloccati
  • Aggiunta / Rimozione regole di Whitelist private
  • Aggiunta / Rimozione regole di Blacklist private
  • Consultazione nei log SMTP

La Zimlet LibraESVA è in grado di individuare anche le caselle che inoltrano i messaggi (forward) alle proprie caselle e le liste di distribuzione. In questa maniera è possibile mostrare nelle ricerche anche le mail che gli utenti ricevono da questi indirizzi.

Il meccanismo di rilascio dei messaggi è stato costruito per rilasciare il messaggio selezionato solo all’indirizzo di chi ha fatto la richiesta, senza che il messaggio venga recapitato agli altri utenti che invece ricevono in forward.

La Zimlet LibraESVA è un’idea di ArgonavisLab ed è un’esclusiva per i suoi clienti, se sei interessato a questa Zimlet puoi contattarci.

INFORMAZIONI

24 Aprile 2015