La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
I Messaggi WhatsApp Sono Veramente Privati? Ecco Cosa Abbiamo Scoperto
Giuseppe Longobardi : 27 Gennaio 2025 19:11
Nell’era della messaggistica istantanea, il livello di sicurezza richiesto per proteggere le comunicazioni è sempre più elevato. Il protocollo Signal si è affermato come uno dei metodi più sicuri e trasparenti per la crittografia end-to-end, adottato non solo dall’app Signal, ma anche da colossi come WhatsApp e altre piattaforme. In questo articolo analizzeremo nel dettaglio:
Il funzionamento globale del protocollo Signal.
Tutte le chiavi coinvolte e la loro evoluzione nel tempo (diagrammi concettuali).
Gli aspetti matematici fondamentali di alcuni step, con esempi numerici illustrativi.
Come un potenziale attacco Man-in-the-Middle (MITM) potrebbe essere realizzato su WhatsApp alterando le chiavi pubbliche, se e solo se l’operatore ha il pieno controllo del server WhatsApp.
Un attacco canonimo conducibile da attori terzi
Come rilevare (almeno in teoria) un MITM confrontando il famoso “numero di 60 cifre” su WhatsApp.
Una possibile soluzione (teorica) al problema del MITM integrando la blockchain
Approfondimento tecnico su come viene generato e perché è importante questo numero di 60 cifre.
Perché, nonostante la possibilità di verifica manuale, quasi nessuno la utilizza, lasciando spazio a ipotetici scenari di intercettazione.
Il protocollo Signal è una combinazione di tecniche crittografiche che garantiscono:
End-to-End Encryption: solo i due interlocutori possono leggere il contenuto dei messaggi.
Forward Secrecy: la compromissione di una chiave non rende decifrabili i messaggi passati.
Future Secrecy: la compromissione di una chiave non rende decifrabili i messaggi futuri.
Elementi chiave del protocollo Signal
X3DH (Extended Triple Diffie-Hellman): fase iniziale di scambio delle chiavi per instaurare una sessione sicura.
Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
Double Ratchet Algorithm: generazione continua di chiavi simmetriche per ogni messaggio, garantendo forward e future secrecy.
Crittografia Simmetrica (AES): una volta generate le chiavi, i messaggi vengono crittografati con un algoritmo simmetrico (es. AES-GCM). Per verificare l’integrità entra in gioco anche l’algoritmo HMAC combinato ad AES.
Verifica dell’identità: un “codice di sicurezza” (o “safety number”) che gli utenti possono confrontare per assicurarsi che nessuno si sia inserito nella comunicazione.
2. Chiavi crittografiche
Le chiavi crittografiche coinvolte sono:
IK (Identity Key)
Coppia di chiavi (pubblica e privata) a lungo termine.
Es.: IK_A (di Alice) e IK_B (di Bob).
SPK (Signed Prekey)
Coppia di chiavi (pubblica e privata) a medio termine, firmata con la Identity Key.
Es.: SPK_B pubblica è caricata sul server, firmata da IK_B privata.
OPK (One-Time Prekey)
Chiave pubblica effimera generata in anticipo, usata per una singola sessione.
Es.: OPK_B pubblica (ce ne possono essere più, pronte all’uso).
EK (Ephemeral Key)
Chiave pubblica effimera generata dinamicamente dal mittente quando vuole iniziare una conversazione (Es.: EK_A per Alice).
3. Fase X3DH: Scambio Chiavi Iniziale
Quando Alice vuole iniziare una sessione sicura con Bob, procede come segue:
Alice ottiene dal server la chiave pubblica a lungo termine di Bob (IK_B), la Signed Pre Key di Bob (SPK_B) e una One-Time Pre Key (OPK_B).
Alice genera una chiave effimera EK_A.
Alice calcola uno shared secret combinando:
IK_A privata con SPK_B pubblica.
EK_A privata con IK_B pubblica.
EK_A privata con SPK_B pubblica.
EK_A privata con OPK_B pubblica.
Bob, una volta ricevuto il primo messaggio di Alice, fa calcoli analoghi con le sue chiavi private per ricavare lo stesso identico shared secret.
A titolo di esempio, analizziamo uno scenario in cui applichiamo una versione semplificata di Diffie Hellman:
Si sceglie un numero primo p di grandi dimensioni e una radice primitiva g modulo p.
Alice genera un valore privato a e calcola la chiave pubblica A=gamod p
Bob genera un valore privato b e calcola la chiave pubblica B=gbmod p
Alice e Bob si scambiano le chiavi pubbliche A e B rispettivamente.
Alice calcola K = Ba mod p, Bob calcola K = Ab mod p. Entrambi ottengono la medesima chiave condivisa K=gab mod p.
1.2 Codice Python esplicativo
#!/usr/bin/env python3
import random
def diffie_hellman_demo():
# Scelta di un numero primo p e di una radice primitiva g (esempio didattico)
p = 23
g = 5
print(f"Valore di p (primo): {p}")
print(f"Valore di g (radice primitiva modulo p): {g}\n")
# Alice genera il proprio valore privato a
# (in uno scenario reale si utilizzano valori molto più grandi e sicuri)
a = random.randint(2, p-2)
print(f"Alice sceglie il valore privato a: {a}")
# Alice calcola la propria chiave pubblica A = g^a mod p
A = pow(g, a, p)
print(f"Alice calcola la chiave pubblica A = g^a mod p: {A}\n")
# Bob genera il proprio valore privato b
b = random.randint(2, p-2)
print(f"Bob sceglie il valore privato b: {b}")
# Bob calcola la propria chiave pubblica B = g^b mod p
B = pow(g, b, p)
print(f"Bob calcola la chiave pubblica B = g^b mod p: {B}\n")
# Alice e Bob si scambiano le chiavi pubbliche A e B (canale insicuro)
# Alice calcola la chiave condivisa K_A = B^a mod p
K_A = pow(B, a, p)
print(f"Alice calcola la chiave condivisa K_A = B^a mod p: {K_A}")
# Bob calcola la chiave condivisa K_B = A^b mod p
K_B = pow(A, b, p)
print(f"Bob calcola la chiave condivisa K_B = A^b mod p: {K_B}\n")
# Verifica che le due chiavi coincidano
if K_A == K_B:
print(f"Chiave condivisa K calcolata correttamente: {K_A}")
else:
print("ERRORE: le chiavi non corrispondono!")
if __name__ == "__main__":
diffie_hellman_demo()
4. Double Ratchet: Evoluzione Continua delle Chiavi
Una volta instaurata la sessione iniziale, si passa al Double Ratchet Algorithm.
Ad ogni messaggio inviato:
Viene generata una nuova chiave simmetrica (K1, K2, K3, …) usando funzioni di derivazione (HKDF).
Si usa la chiave simmetrica corrente (ad esempio K3) per cifrare il messaggio con AES256 in modalità GCM.
Quando viene ricevuta una nuova chiave pubblica dall’altro interlocutore (nuovo scambio Diffie-Hellman), si “salta” a un nuovo ratchet e si aggiorna l’intera catena di chiavi.
Vantaggi:
Forward Secrecy: se una chiave venisse compromessa, solo un messaggio (o un piccolo lotto di messaggi) sarebbe in pericolo, poiché si passa costantemente a nuove chiavi.
Future Secrecy: la compromissione di una chiave attuale non permette di derivare quelle future.
5. MITM in WhatsApp: Ipotesi di Attacco
MITM conducibile da Meta alterando le chiavi
WhatsApp utilizza (con alcune modifiche) lo stesso protocollo Signal per la crittografia end-to-end. Tuttavia, essendo un servizio centralizzato e proprietario, il controllo effettivo del server WhatsApp risiede nelle mani dell’azienda. Di conseguenza, in teoria, un operatore interno o un’entità che compromette i server potrebbe alterare o sostituire le chiavi pubbliche di uno degli interlocutori, inserendosi tra due utenti ignari. Di seguito una spiegazione più approfondita:
Inserimento di un terzo dispositivo controllato dal server
Quando due utenti (A e B) vogliono comunicare, si innesca un processo di scambio chiavi simile a X3DH.
In una situazione normale, WhatsApp fornisce ad A le chiavi pubbliche autentiche di B e viceversa.
Se un operatore di WhatsApp o un aggressore che ha compromesso i server decide di intervenire, può inserire in modo trasparente un terzo dispositivo (controllato da sé), impostato come se fosse B nei confronti di A, e come se fosse A nei confronti di B.
Sostituzione o falsificazione delle chiavi pubbliche
WhatsApp, come qualsiasi sistema che implementa il protocollo Signal, affida al proprio server la distribuzione delle chiavi pubbliche.
In un attacco MITM, il server anziché consegnare la vera chiave pubblica di B ad A, fornisce una chiave pubblica falsa (generata o posseduta dall’operatore malevolo).
In parallelo, al vero B potrebbe essere fornita una chiave pubblica di A leggermente modificata, o il server potrebbe gestire altre strategie di sostituzione delle chiavi.
L’importante è che A non riceva la vera chiave pubblica di B e viceversa, così che il server possa crittografare e decrittografare i messaggi in transito.
Creazione di due sessioni distinte con l’intermediario
Una volta completato lo scambio iniziale di chiavi (alterato), il server malevolo mantiene due sessioni separate:
Sessione 1: Utente A ↔ Server (che si finge B)
Sessione 2: Server ↔ Utente B (che si finge A)
Ogni messaggio che A invia viene decriptato dal server grazie alla chiave falsificata, quindi ri-cifrato con la vera chiave di B prima di inoltrarlo a B.
Viceversa, i messaggi di B passano attraverso la sessione con l’intermediario, che li decripta e li ricifra per A.
Risultato: A e B pensano di comunicare direttamente tra loro, mentre in realtà tutti i contenuti transitano in chiaro (nel momento di decrittazione) su un terzo dispositivo gestito dal server.
Impatto dell’attacco sull’end-to-end
Tecnicamente, i messaggi risultano sempre “cifrati” da un punto di vista formale, ma l’“end” non è più davvero l’utente destinatario, bensì il terzo dispositivo.
A e B, senza un controllo manuale, non hanno modo di accorgersi che la comunicazione è stata intercettata.
Se l’operatore del server non registra alcun log dell’inserimento del terzo dispositivo, l’attacco risulta virtualmente invisibile agli utenti comuni.
Dettagli sul rilevamento e sulla notifica
In teoria, WhatsApp dovrebbe inviare una notifica di cambiamento di chiave quando rileva una modifica nelle identity key di uno dei contatti.
Tuttavia, se il server gestisce l’inserimento del terzo dispositivo in modo da non far risultare alcun cambio di chiave apparente (oppure se gli utenti hanno disattivato gli avvisi di cambio chiave nelle impostazioni), questa notifica potrebbe non comparire o passare inosservata.
L’unico metodo sicuro per rilevare la manomissione della chiave rimane il confronto manuale del codice di sicurezza (60 cifre o QR Code) presente sul profilo di B e su quello di A.
Rischi di compromissione interna o governativa
Qualora un governo o un’agenzia di intelligence riuscisse ad ottenere l’accesso privilegiato all’infrastruttura di WhatsApp (con un mandato legale o tramite hacking), potrebbe effettuare l’inserimento del terzo dispositivo.
In questo scenario, l’utente finale non verrebbe avvisato, perché l’attacco sarebbe direttamente orchestrato all’interno dei server ufficiali.
Se, invece, la modifica delle chiavi venisse effettuata da un attacco esterno non autorizzato (non governativo ma criminale), sarebbero necessarie vulnerabilità nei sistemi di WhatsApp per riuscire ad alterare i processi di distribuzione delle chiavi.
Forward Secrecy e Double Ratchet in presenza di MITM
Anche con Double Ratchet e Forward Secrecy, se l’intermediario è costantemente in mezzo, potrà aggiornare le chiavi in parallelo (instaurando con A e B due catene di ratchet distinte).
Di conseguenza, ogni singolo messaggio viene decifrato e ricifrato in tempo reale per tutta la durata della conversazione.
La forward secrecy, quindi, non protegge da un MITM in corso, ma solo dal rischio che una chiave statica compromessa permetta di decifrare messaggi passati o futuri.
Conclusioni sul possibile attacco MITM interno
L’essenza di un attacco MITM su WhatsApp, con la complicità del server, sta nel fatto che il servizio possiede l’infrastruttura per gestire lo scambio chiavi.
Se le chiavi vengono alterate in modo coordinato dal server, l’utente medio non se ne accorge, a meno che non faccia un controllo manuale del codice a 60 cifre (o QR Code) insieme al proprio interlocutore.
In definitiva, l’end-to-end di WhatsApp, se non viene verificato dall’utente, rimane un atto di fiducia verso il gestore del servizio.
MITM conducibile da terzi su Whatsapp Web
Un attacco che sfrutta WhatsApp Web rappresenta un altro scenario pratico di compromissione della privacy, in cui un attaccante riesce a collegare un proprio dispositivo o browser al profilo WhatsApp della vittima tramite la funzionalità di sincronizzazione offerta dall’app. Questo tipo di attacco è più accessibile rispetto a interventi che richiedono il controllo dei server e può essere condotto utilizzando tecniche di manipolazione del dispositivo della vittima o ingannandola nel processo di collegamento.
WhatsApp Web utilizza un sistema basato su QR Code per autorizzare dispositivi aggiuntivi a sincronizzarsi con il profilo WhatsApp dell’utente.
Un attaccante può creare un QR Code falso che, una volta scansionato dalla vittima, collega l’account al proprio browser o dispositivo, anziché a un client legittimo. Questo può essere fatto tramite attacchi MITM a livello network dove l’attaccante sostituisce fisicamente i bit costituenti l’immagine, richiederebbe un attacco combinato di ARPSpoof, HTTPS Downgrade e DNS Poisoning dato che Whatsapp usa HSTS nella sua CDN.
Una soluzione più semplice è un attacco di pharming, che può essere condotto su una rete fisica mediante un evil twin attack, usando un rogue AP o sfruttando qualcosa come Blue Ducky che permette di fare keystroke injection in dispositivi che hanno una versione di bluetooth vulnerabile.
La vittima, pensando di accedere a WhatsApp Web, in realtà autorizza il dispositivo dell’attaccante.
Sincronizzazione in tempo reale
Una volta che il dispositivo o browser dell’attaccante è collegato, riceve una copia in tempo reale di tutti i messaggi in arrivo e in uscita, incluse immagini, video e note vocali.
WhatsApp Web è progettato per mantenere una sincronizzazione continua con il telefono, quindi l’attaccante ha accesso immediato e costante alla comunicazione.
Persistenza dell’attacco
L’attaccante può mantenere il collegamento per lungo tempo, fintanto che la vittima non rimuove manualmente il dispositivo dall’elenco di quelli autorizzati nella sezione “Dispositivi collegati”.
In alcuni casi, l’attaccante potrebbe anche tentare di nascondere il proprio dispositivo nella lista, configurandolo con un nome generico, come “WhatsApp Web per Windows” o “WhatsApp Desktop”. Rimarrebbe comunque identificabile dal suo IP pubblico, anche se in un ASN di un ISP non soggetto a policy di data retention che impongono il mantenimento di log DHCP per motivi di conformità comunitarie o americane.
Esempio di Scenario
Immagina che un attaccante utilizzi una pagina clone di WhatsApp Web. La vittima apre la pagina, scansiona il QR Code presentato e collega il proprio telefono al dispositivo dell’attaccante. A questo punto:
L’attaccante, attraverso il proprio browser, riceve ogni messaggio, immagine o video inviato e ricevuto dalla vittima.
La vittima, ignara di quanto accaduto, continua a utilizzare WhatsApp normalmente, poiché non ci sono avvisi immediati o segnali visibili che suggeriscono la compromissione (se non l’elenco dei dispositivi collegati, che molti utenti non controllano mai).
Segnali Visibili e Prevenzione
Controllo dei dispositivi collegati:
WhatsApp offre una sezione dedicata per visualizzare tutti i dispositivi attualmente sincronizzati.
L’attaccante comparirà come un dispositivo collegato, ma molti utenti non conoscono questa funzionalità o non prestano attenzione a ciò che vi è elencato.
Durata della sessione:
Il dispositivo dell’attaccante rimarrà collegato finché non viene manualmente rimosso dalla vittima o finché la sessione non scade automaticamente (ad esempio, dopo un periodo di inattività prolungato).
Notifica su alcuni dispositivi:
WhatsApp talvolta invia una notifica all’utente quando viene effettuata una nuova connessione. Tuttavia, l’attaccante può agire sperando che l’utente ignori l’avviso o lo confonda con una connessione legittima.
Come la Blockchain potrebbe rendere trasparente il cambio di chiavi
Una possibile soluzione teorica per evitare che un server centralizzato (come quello di WhatsApp) possa alterare di nascosto le chiavi pubbliche consiste nell’integrare un registro distribuito (blockchain) in cui salvare l’hash (o fingerprint) delle chiavi. In questo modo, ogni variazione non autorizzata delle chiavi risulterebbe immediatamente evidente, poiché:
Pubblicazione iniziale della fingerprint
Ogni utente, al momento della creazione o del rinnovo della propria Identity Key, ne calcola l’hash.
Questo hash (fingerprint) viene registrato in modo immutabile all’interno di un blocco della blockchain (ad esempio Ethereum, Bitcoin, o una chain dedicata).
Tale registrazione funge da “ancora” (anchor): chiunque può consultare pubblicamente la blockchain per verificare l’ultima impronta digitale ufficiale della chiave di un dato utente.
Verifica pubblica e inalterabilità
Se il server prova a sostituire la chiave pubblica dell’utente B con una key fake, l’utente A (o chiunque) potrebbe verificare sulla blockchain che la fingerprint della chiave “presentata” dal server non coincide con quella ufficialmente iscritta nel blocco corrispondente.
Non esiste un modo semplice di “retrocessione” o alterazione passata nella blockchain (se ben implementata), il che rende palese una sostituzione non autorizzata.
Chiaramente i dati pubblicati nei blocchi devono essere pesantemente trattati per evitare attacchi simil rainbow table attack, known plain text, know cipher text o simili.
Trasparenza e responsabilità
Gli utenti, attraverso un semplice blockchain explorer, possono controllare in ogni momento l’hash delle chiavi pubbliche dei propri contatti.
Qualsiasi cambio è registrato in nuovi blocchi, e deve essere firmato dall’utente proprietario della chiave. Se il server tentasse di farlo a nome dell’utente, verrebbe usata una firma falsa, immediatamente rilevabile.
Perché non è (realisticamente) praticabile su larga scala
Costi elevati
L’invio di un gran numero di transazioni in una blockchain pubblica (come Ethereum) comporta costi potenzialmente molto alti (le gas fee).
WhatsApp gestisce miliardi di utenti: anche solo registrare gli aggiornamenti di chiave più rari (le Identity Key) avrebbe un impatto economico enorme.
Scalabilità e throughput
Le reti blockchain pubbliche hanno un throughput (numero di transazioni al secondo) limitato rispetto ai ritmi operativi di un servizio come WhatsApp.
Aggiungere la generazione di nuove chiavi o l’aggiornamento di chiavi effimere (anche se avviene di rado per le Identity Key) rischia comunque di congestionare la rete blockchain o di richiedere meccanismi off-chain altrettanto complessi.
Performance inadatte
I tempi di conferma di un blocco (anche pochi secondi/minuti, a seconda della rete) non sono compatibili con l’immediatezza richiesta dalle app di messaggistica consumer.
Il sistema dovrebbe garantire che ogni cambio di chiave sia immediatamente verificabile, mentre la blockchain tradizionale introduce latenza.
Complessità d’uso per l’utente
Affinché la verifica abbia senso, l’utente dovrebbe saper utilizzare un explorer blockchain e comprendere i concetti di transazioni, hash, firme… Cosa che la maggior parte degli utenti non è disposta a fare.
Gestione di chiavi multiple e Double Ratchet
Il protocollo Signal (e dunque WhatsApp) ruota regolarmente le chiavi per garantire forward secrecy. Se teoricamente decidessimo di registrare ogni variazione chiave in blockchain, il sistema esploderebbe in termini di transazioni.
6. Perché il Controllo Manuale è Determinante
Come in Signal, anche in WhatsApp esiste un metodo di controllo manuale per rilevare eventuali MITM: il codice di verifica (“safety number”). Su WhatsApp prende la forma di un QR code o un numero di 60 cifre.
Se un MITM è in atto, le chiavi “iniettate” dal server saranno diverse e, di conseguenza, il numero di 60 cifre visualizzato sui due dispositivi non coincide.
A e B dovrebbero confrontare manualmente quel numero (o scansionare il QR code) per verificare che sia identico.
Se è diverso, c’è un problema di integrità nella sessione (o un potenziale MITM).
Problema reale
Pochissimi utenti verificano effettivamente quel numero di 60 cifre. Quindi, in pratica, non si accorgerebbero se WhatsApp (o un’entità esterna con accesso ai server) accettasse un dispositivo terzo nella conversazione.
7. Cos’è e Come si Genera il Numero di 60 Cifre
Il numero di 60 cifre che appare nella sezione “Crittografia” di una chat su WhatsApp (o come codice QR) è una rappresentazione leggibile di una fingerprint (un hash) delle chiavi pubbliche utilizzate da te e dal tuo contatto.
1. Scambio e unione delle chiavi pubbliche; Durante la fase di handshake (simile a X3DH), ogni utente possiede una Identity Key (IK) e altre chiavi (Signed Pre Key, One-Time Pre Key). WhatsApp crea una stringa che combina le chiavi pubbliche di entrambi gli interlocutori.
2. Calcolo dell’hash: La stringa delle chiavi pubbliche viene passata a una funzione di hash (ad esempio SHA-256 o SHA-512). Il risultato è un valore binario (molto lungo).
3. Conversione in formato leggibile (60 cifre decimali) : L’hash binario viene convertito in un formato comprensibile per l’essere umano (sequenza di 60 cifre), o in un QR Code. Questo codice è diverso per ogni coppia di dispositivi (A-B), poiché dipende dalle identità crittografiche di entrambi.
Le tecnologie di crittografia end-to-end, come quelle adottate da Signal e WhatsApp, rappresentano un grande passo avanti per la privacy degli utenti. Tuttavia, l’unico modo per garantire che nessuno (nemmeno i proprietari dei server) si inserisca nella conversazione è la verifica manuale dei codici di sicurezza.
Perché mai WhatsApp offrirebbe la possibilità di verificare l’univocità del numero di 60 cifre se non fosse consapevole della reale possibilità di un attacco Man in the middle?
Ed ecco il paradosso: lo strumento di verifica c’è, ma pochissimi utenti lo usano davvero. Di conseguenza, la possibilità di un MITM rimane aperta. La sicurezza non è solo questione di algoritmi, ma anche di buone pratiche e attenzione dell’utente.
Questa è proprio l’idea che vogliamo trasmettere con questo articolo, la consapevolezza e la formazione sono la nostra principale barriera di difesa che ci permette di proteggerci anche quando i sistemi che dovrebbero farlo cedono.
Giuseppe Longobardi CyberSecurity Manager e ICT Trainer, specializzato in Networking e CyberSecurity. Inventore della web app "OnionCert", registrata alla SIAE con N. Registrazione D000016744, ideatore del "Metodo Longobardi" per il Subnetting ed autore di svariati corsi di formazione in ambito Networking e CyberSecurity. Da sempre seguo progetti di ricerca e sviluppo in ambito Industry 4.0 , Smart City e Blockchain. Credo nello sviluppo continuo di nuove competenze, tecnologie e soluzioni open source. La mia filosofa di vita: "Se i tuoi progetti hanno come obiettivo 1 anno pianta del riso, 20 anni pianta un albero, un secolo insegna a degli uomini" Visita il sito web dell'autore
Negli ultimi giorni, il collettivo hacktivista italiano Anonymous Italia ha risposto agli attacchi informatici sferrati dal gruppo filorusso NoName057(16) colpendo una serie di obiettivi russi. Gli at...
Gruppo di ricerca MASSGRAVE ha presentato un Exploit chiamato TSforge che consente di attivare qualsiasi versione di Windows a partire da Windows 7, nonché tutte le edizioni di Microsof...
Su BreachForum un utente dallo pseudonimo EDRVendor ha venduto, dopo poche ore dall’annuncio, l’accesso ad una cassetta postale della polizia di stato italiana. Oltre alla mail viene off...
Team di intelligence sulle minacce di Google ha reso pubblica l’informazione sul gruppo di hacker Triplestrength, finora sconosciuto, attivo dal 2020. Il gruppo è composto da poc...
I canali Telegram degli hacker filorussi di NoName057(16) sono stati eliminati da telegram. Ma subito gli attivisti ricreano nuovi canali marchiati con il suffisso “reborn“. Ma...
Giuseppe Longobardi
