Molte persone credono che accedere esclusivamente a siti HTTPS sia sufficiente per garantire la sicurezza durante la navigazione su reti Wi-Fi non protette. Spoiler: anche questa convinzione è un falso senso di sicurezza.
HTTPS: un passo avanti, ma non infallibile
HTTPS (HyperText Transfer Protocol Secure) utilizza protocolli di crittografia come TLS per proteggere la comunicazione tra il browser e il sito web, garantendo riservatezza e integrità dei dati.
Sebbene HTTPS offra quindi una protezione significativa rispetto a HTTP.
Iscriviti GRATIS alla RHC Conference 2025 (Venerdì 9 maggio 2025)
Il giorno Venerdì 9 maggio 2025 presso il teatro Italia di Roma (a due passi dalla stazione termini e dalla metro B di Piazza Bologna), si terrà
la RHC Conference 2025. Si tratta dell’appuntamento annuale gratuito, creato dalla community di RHC, per far accrescere l’interesse verso le tecnologie digitali, l’innovazione digitale e la consapevolezza del rischio informatico.
La giornata inizierà alle 9:30 (con accoglienza dalle 9:00) e sarà interamente dedicata alla RHC Conference, un evento di spicco nel campo della sicurezza informatica. Il programma prevede un panel con ospiti istituzionali che si terrà all’inizio della conferenza. Successivamente, numerosi interventi di esperti nazionali nel campo della sicurezza informatica si susseguiranno sul palco fino alle ore 19:00 circa, quando termineranno le sessioni. Prima del termine della conferenza, ci sarà la premiazione dei vincitori della Capture The Flag prevista per le ore 18:00. Potete iscrivervi gratuitamente all'evento utilizzando questo link.
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
In questo articolo della nostra Rubrica WiFi, mostreremo come questa protezione da sola non è sufficiente soprattutto in ambienti non sicuri come le reti Wi-Fi aperte.
Nonostante la crittografia garantita dal protocollo HTTPS, la rete aperta e l’accesso facile alle informazioni da parte degli attaccanti ci espone ad:
Attacchi Man-in-the-Middle (MitM): Un attaccante può intercettare il traffico tra l’utente e il sito web, potenzialmente reindirizzando l’utente a un sito falso che imita quello legittimo.
Spoofing DNS e ARP poisoning: Tecniche che permettono a un attaccante di manipolare le risposte DNS o la cache ARP, reindirizzando l’utente verso siti malevoli anche se digitati correttamente.
Intercettazione dei metadati: Anche se il contenuto delle comunicazioni è crittografato, informazioni come i nomi di dominio visitati (DNS queries) possono essere visibili e utilizzate per profilare l’utente.
Come scritto in diversi articoli gli hacker possono sfruttare diverse tecniche per aggirare o compromettere la protezione HTTPS, tra cui:
Reindirizzamenti Malevoli Con tecniche come lo spoofing DNS, l’attaccante modifica le risposte DNS per reindirizzare l’utente verso un sito web falso, che può avere un certificato HTTPS valido o simulato, facendo credere all’utente di essere al sicuro.
Siti HTTPS Falsi (Certificati Contraffatti) Un attaccante può creare un sito falso con un certificato SSL/TLS valido utilizzando servizi di certificazione automatizzati o persino ottenendo certificati legittimi per domini che assomigliano a quelli reali (es. typo-squatting). L’utente, vedendo il lucchetto verde o l’indicazione HTTPS, può essere indotto a fidarsi del sito contraffatto.
Downgrade dell’HTTPS Tramite un attacco chiamato SSL stripping, un hacker può forzare una connessione a un sito HTTPS a utilizzare HTTP, compromettendo la crittografia. Questo attacco sfrutta la possibilità che il sito supporti entrambe le versioni del protocollo.
Attacchi ai Certificati di Root Se un attaccante riesce a compromettere i certificati di root installati sul dispositivo della vittima (ad esempio tramite malware), può creare certificati personalizzati per qualsiasi sito web, rendendo il traffico completamente vulnerabile anche con HTTPS.
La buona notizia
Partiamo col dire che dai nostri test e analisi di alboratioro: uno degli attacchi più insidiosi degli ultimi anni, l’SSL Stripping, è risultato essere molto meno efficace.
Introdotti nel 2009 da Moxie Marlinspike, questo attacco aveva lo scopo di trasformare una connessione sicura HTTPS in una semplice HTTP, privando l’utente della protezione crittografica senza che se ne accorgesse.
In pratica, l’attaccante si inseriva tra il browser e il sito web – un classico attacco man-in-the-middle – intercettando le comunicazioni e modificandole al volo, con la possibilità di leggere e manipolare tutto ciò che passava.
L’introduzione di HSTS
Per contrastare questo tipo di attacco, nel 2012 è stato introdotto il meccanismo HTTP Strict Transport Security (HSTS). Attraverso l’intestazione Strict-Transport-Security, un server può indicare al browser di accedere al sito esclusivamente tramite connessioni HTTPS per un periodo di tempo specificato. Questo impedisce al browser di effettuare richieste HTTP non sicure verso il sito, riducendo significativamente la superficie di attacco per l’SSL Stripping.
Immaginiamo HSTS come un varco elettronico: una barriera digitale che si apre solo se arrivi con i requisiti giusti — in questo caso, una connessione HTTPS. Se tenti di passare con un collegamento HTTP non cifrato, la sbarra rimane abbassata. Niente accesso.
Il sito web comunica al browser, attraverso una semplice intestazione HTTP, una regola precisa:
“Per entrare qui, devi usare solo HTTPS, sempre. Qualsiasi altra via è bloccata.”
Una volta ricevuto quest’ordine, il browser lo memorizza e da quel momento in poi rifiuta qualsiasi connessione non protetta a quel sito. Nemmeno l’utente può forzarlo: il varco resta chiuso a chi non rispetta i requisiti di sicurezza.
Limitazioni e soluzioni
Una limitazione di HSTS è che la sua efficacia dipende dal fatto che l’utente abbia già visitato il sito almeno una volta tramite HTTPS. Per mitigare questo problema, i principali browser mantengono una lista interna di siti “autorizzati” che devono essere contattati solo e sempre via HTTPS già dalla prima visita. È come se quei siti avessero il badge elettronico pre-configurato: l’accesso sicuro è garantito fin da subito.
Tuttavia, questa lista non può includere tutti i siti web esistenti, lasciando una finestra di vulnerabilità per siti non inclusi.
Ecco perché, per i siti che non sono inclusi in quella lista e non configurano HSTS correttamente, la barriera può restare alzata. E in quel caso, un attaccante potrebbe ancora tentare un downgrade, forzando una connessione HTTP con tecniche come SSL Stripping o DNS Spoofing.
Configurazioni errate e rischi residui
Oltre a quanto già detto, le configurazioni errate possono esporre i siti a ulteriori rischi. Ad esempio, se un sito non implementa correttamente HSTS o non è incluso nella lista pre-caricata dei browser, un attaccante potrebbe ancora tentare un attacco di SSL Stripping. È quindi fondamentale che i siti web configurino correttamente HSTS e che gli utenti siano consapevoli dei rischi associati a connessioni non sicure.
HSTS è uno strumento potente, ma non magico. Funziona molto bene ma se si sodisfano i seguenti criteri:
Il sito lo ha configurato in modo corretto
Il dominio è presente nella lista pre-caricata del browser
L’utente non viene intercettato prima della prima connessione sicura
L’adozione di HTTPS e HSTS ha reso gli attacchi di SSL Stripping significativamente meno efficaci. Tuttavia, la sicurezza completa dipende da una corretta configurazione dei server e dalla consapevolezza degli utenti. È essenziale che i siti web implementino HSTS in modo appropriato e che gli utenti prestino attenzione alla sicurezza delle loro connessioni.
Attenzione
La sicurezza completa non esiste, la consapevolezza e conoscenza di questi limiti ci permette di essere meno esposti. Soprattutto su reti aperte come quelle pubbliche o non protette.Gli attaccanti ci hanno mostrato più di una volta di essere molto ingegnosi e di riuscire a trovare sempre un modo di ottenere quello che vogliono. In questi due laboratori vogliamo dare evidenza di due possibili scenari in cui ci potremmo trovare collegandosi ad una rete aperta:
Un portale fasullo: laboratorio per superare le cifrature l’HTTPS Laboratorio realizzato grazie a Marco Mazzola
File in chiaro: laboratorio sul degrado della cifratura nei trasferimenti FTP Laboratorio realizzato grazie a Manuel Roccon
⚠️ Attenzione le informazioni riportate in calce sono a scopo educativo! Non utilizzarle per attività illegali o senza autorizzazione.⚠️
NB: Tutte le simulazione sono svolte in un ambiente di laboratorio, senza coinvolgere reti o utenti reali.
ARP spoofing
Partiamo da un piccolo accenno sull’arp spoofing che useremo in entrambi i laboratori e che viene usata di frequente nelle reti non sicure.
L’ARP spoofing (o ARP poisoning) è una tecnica di attacco informatico che sfrutta le vulnerabilità del protocollo ARP (Address Resolution Protocol) per associare l’indirizzo MAC dell’attaccante all’indirizzo IP di un altro dispositivo sulla stessa rete locale.
In parole semplici, l’attaccante invia messaggi ARP falsificati sulla rete, convincendo gli altri dispositivi (ad esempio, un computer vittima e il router) che l’indirizzo MAC dell’attaccante corrisponde all’indirizzo IP della vittima (o del router).
In breve possiamo vedere nella tabella di arp dispositivo della vittima, prima dell’attacco ARP, il MAC address corretto associato all IP gateway.
Nei sistemi Windows “arp -a” permette di vedere l’attuale tabella arp creata da precedenti comunicazioni con gli hosts.
Una volta iniziato attacco di arp spoofing, questo mac associato all’IP del gateway è stato sostituito con quello dell’attaccante.
D’ora in poi tutto il traffico che la vittima cercherà di inviare al gateway (192.168.0.1) per raggiungere internet, arriverà tutto all’attaccante, che poi tramite forwarding invierà al router originale e viceversa.
La vittima è già sotto attacco e non si sta accorgendo del problema.
Alcune Considerazioni
ARP spoofing è uno degli attacchi per poter eseguire del MiTM.
Un’altra tecnica potrebbe essere quella di usare il DHCP spoofing, inducendo i client a usare differenti configurazioni DHCP da quelle previste, incluso un gateway diverso che può essere controllato dall’attaccante per sniffare e re-indirizzare il traffico.
LAB 1 – Un portale fasullo: laboratorio per superare le cifrature l’HTTPS
In questo laboratorio analizziamo passo dopo passo un attacco Man-in-the-Middle (MITM) condotto su una rete Wi-Fi non protetta. L’obiettivo è simulare uno scenario reale in cui un attaccante riesce a intercettare il traffico della vittima e manipolarlo, sfruttando l’urgenza e la disattenzione dell’utente. Tutte le operazioni sono svolte in ambiente di laboratorio, a fini esclusivamente formativi.
Descrizione Scenario
Connessione del Client alla Rete
Il dispositivo client si connette a una rete Wi-Fi Free, preparandosi a navigare verso siti web.
Intercettazione del Traffico tramite ARP Spoofing
Utilizzando tecniche di ARP spoofing, l’attaccante manipola le tabelle ARP della rete locale, facendo sì che il traffico del client venga indirizzato attraverso il dispositivo dell’attaccante. Questo posiziona l’attaccante tra il client e il gateway, permettendo l’intercettazione trasparente dei dati.
Reindirizzamento delle Richieste DNS (DNS Hijacking)
L’attaccante manipola le risposte DNS, indirizzando tutte le richieste del client verso un server controllato. Questo permette di presentare al client contenuti falsificati o dirottare le sue richieste verso destinazioni malevole.
Presentazione di un Captive Portal Falso
Il client, tentando di accedere a Internet, viene reindirizzato a un captive portal falso che simula una pagina di accesso. Questo portale può essere utilizzato per indurre l’utente a fornire credenziali o come in questo caso per installare certificati malevoli.
Installazione di un Certificato Malevolo
Il captive portal falso può richiedere l’installazione di un certificato SSL/TLS controllato dall’attaccante. Se l’utente accetta, l’attaccante può decrittare il traffico HTTPS del client, accedendo a informazioni sensibili.
Analisi del Traffico in Chiaro
Con il certificato installato, l’attaccante può monitorare e analizzare il traffico del client, raccogliendo dati come credenziali di accesso, informazioni personali e altri dati sensibili
Descrizione degli strumenti e fasi Operative
In questo laboratorio sia vittima che attaccante si trovano nello stesso segmento di rete non protetta, dove non sono state implementate tecniche protezione lato rete (parleremo di queste mitigazioni nei prossimo articoli )
La vittima
La nostra vittima è un utente con sistema operativo Window 11 aggiornato alle ultime patch disponibili, che si connette ad una rete WIFI aperta. L’utilizzo di una rete non sicura avviene per diversi motivi come già trattato nell’articolo “Reti WiFi Aperte: Un Terreno Fertile per il Cybercrime”.
Ed è proprio questa esigenza di restare connessi a tutti i costi che diventa un’arma molto potente per gli attaccanti.
L’attaccante
L’attaccante opera da una macchina Kali Linux, sulla stessa rete della vittima, e predispone il sistema per intercettare e manipolare il traffico.
Predisposizione del attacco
Fase 1 – Abilitazione del forwarding
Il primo passo consiste nel abilitare il packet forwarding su Kali, trasformandolo in un nodo che inoltra il traffico tra la vittima e il gateway reale.
sudo sysctl -w net.ipv4.ip_forward=1
Fase 2 – Reindirizzamento del traffico HTTP e HTTPS
Utilizziamo iptables per dirottare tutto il traffico in uscita su porte 80 (HTTP) e 443 (HTTPS) verso la porta locale 8080, dove un proxy sarà in ascolto.
Da questo momento tutte le richieste DNS ricevute dall’interfaccia wlan0 restituiranno sempre l’indirizzo IP dell’attaccante (192.168.1.251), simulando un captive portal o un MITM proxy.
Fase 4 – ARP Spoofing
Per intercettare il traffico, l’attaccante esegue un attacco ARP spoofing, facendo credere alla vittima che il suo MAC sia quello del gateway.
Come visto sopra in questo modo, tutto il traffico destinato al gateway sarà deviato attraverso la macchina dell’attaccante, che agisce da intermediario trasparente.
Fase 5 – Attivazione di mitmproxy
Ora abilitiamo mitmproxy, che agirà da proxy trasparente per intercettare e ispezionare il traffico HTTP e HTTPS.
NB:Per questo laboratorio abbiamo selezionato “mitmproxy” in quanto dispone di un certificato scaricabile pubblicamente che non deve essere trustato, e quindi semplifica l’ installazione nel client della vittima (http://mitm.it/).
Azione
Quando la vittima si collega alla rete WiFi aperta e non protetta, tutto il suo traffico finirà nella macchina Kali Linux dell’attaccante. Già questo abbiamo visto nei vari articoli essere un problema di per sé, ma se la vittima non effettuasse ulteriori azioni almeno il traffico HTTPS sarebbe al sicuro.
Presentazione del Captive Portal e Installazione Certificato
Una volta che la vittima apre il browser e prova a navigare, viene automaticamente reindirizzata a un falso captive portal ospitato dall’attaccante.
Il portale simula una schermata di accesso alla rete dove viene proposto il download del certificato per poter navigare in modo “sicuro”
La vittima a causa della sua esigenza di essere connesso accetta e installa il certificato senza prestare troppa attenzione a quello che sta facendo.
Effettua quindi il download del certificato e in pochi semplici passaggi lo installa :
Il portale di login registra questa azione e mette il dispositivo della vittima in white list. In caso di problemi lato script l’attaccante potrebbe vedere per una seconda volta la pagina del portale dove questa volta deve solo cliccare “Ho installato il certificato- Continua”
La vittima da questo momento può navigare. Ignaro che il suo traffico arriverà all’attaccante che potrà da ora decifrare tutto il traffico cifrato HTTPS.
Analisi del traffico
Come mostrato in figura con il certificato accettato e il traffico in transito attraverso mitmproxy, l’attaccante potrà:
intercettare credenziali di accesso,
visualizzare richieste a servizi sensibili (banche, email, social),
analizzare contenuti originariamente cifrati.
Considerazioni
In conclusione, questo laboratorio rappresenta un’opportunità preziosa per comprendere le tecniche storiche di intercettazione in rete, esplorandone il funzionamento in un ambiente controllato e sicuro. Analizzare questi scenari non significa solo conoscere “come avvenivano gli attacchi”, ma soprattutto capire come prevenirli e rafforzare la sicurezza delle nostre infrastrutture digitali. Solo attraverso lo studio pratico e la consapevolezza possiamo costruire sistemi più resilienti, capaci di resistere alle minacce del passato e del futuro.
LAB 2 – File in chiaro: laboratorio sul degrado della cifratura nei trasferimenti FTP
Come HTTP, il protocollo FTP (File Transfer Protocol) è ormai obsoleto e non sicuro; ma continua a essere utilizzato in molte organizzazioni per il trasferimento di file, inclusi dati sensibili.
Come HTTPS, invece il protocollo FTPS permette di instaurare una connessione cifrata e sicura tra Client e Server; questa estensione del protocollo FTP aggiunge la cifratura TLS o SSL (da non confondere con SFTP), in modo che nessuno a parte server e client possano accedere al contenuto dei dati.
L’FTP (File Transfer Protocol) è un protocollo standard di rete usato per trasferire file tra un client e un server su una rete TCP/IP, come Internet. In pratica, permette di caricare (upload) e scaricare (download) file da un computer remoto.
Questo è ancora molto usato per lo scambio di dati,
per cui è chiaro che anche questi dati che viaggiano nella rete o verso internet dovrebbero essere protetti da cifratura.
In questo tipo di attacco forzeremo la vittima a usare un protocollo debole, FTP downgrade.
Questo attacco può essere sferrato quando la vittima utilizza un client FTP configurato per decidere in autonomia il protocollo più sicuro tra i disponibili.
In questo esempio abbiamo usato FILEZILLA, in cui la configurazione di default prevede che il programma scelga lui in automatico la connessione sicura se presente.
In questo caso connettendosi normalmente il client sarà connesso tramite TLS in automatico, perchè questo capirà che FTP server ha configurato il protocollo TLS.
Vediamo invece che utilizzando un attacco MiTM (Man In The Middle), in cui un aggressore si posizionerà in mezzo alla comunicazione, permetterà di forzare la vittima ad usare il protocollo FTP in chiaro, così da recuperare le credenziali di accesso.
PREPARAZIONE ATTACCO
Prima cosa abilitare il forwarding dei pacchetti, che trasforma l’attaccante in un router IPv4, così come vedremo dopo tutto il traffico della vittima che arriverà verrà girato al vero gateway e vice versa:
echo 1 > /proc/sys/net/ipv4/ip_forward
Installiamo un FTP locale nel dispositivo della vittima. In questo esempio abbiamo installato e avviato pure FTP e configurato in modo che accetti solo connessioni in chiaro (escludendo il TLS).
sudo systemctl start pure-ftpd
Eseguiamo del ARP spoofing (lo spiegheremo meglio qui sotto) tramite il framework MITMf, questo farà in modo che la vittima modifichi il mac address associato all’IP del router sostituendolo con quello della vittima.
MITMf (Man-In-The-Middle Framework) si pone come un potente strumento “tutto in uno” per eseguire attacchi Man-In-The-Middle e manipolare il traffico di rete. La sua forza risiede proprio nell’aver superato le limitazioni di tool precedenti come Ettercap e Mallory, offrendo un’architettura modulare e altamente estensibile.
MITMf rappresenta un’evoluzione significativa nel panorama degli strumenti MITM, offrendo una piattaforma potente, flessibile e aggiornata per l’analisi della sicurezza delle reti e la simulazione di scenari di attacco.
https://github.com/byt3bl33d3r/MITMf
Useremo il parametro -i per indicare interfaccia connessa alla rete pubblica, –spoof e –arp per questo attacco di arp poisoning e infine –target e –gateway, come è intuibile, per IP di vittima e gateway.
Come spiegato sopra grazie all’ARP spoofing tutto il traffico che la vittima cercherà di inviare al gateway per raggiungere internet e FTP esterno, arriverà tutto all’attaccante, che poi tramite forwarding invierà al router originale e viceversa.
Il tutto senza che la vittima si accorga di nulla.
Ora per poter intercettare il traffico ftp transitante creiamo una regola di prerouting tramite iptables nel dispositivo dell’attaccante, così tutto quello il traffico che la vittima effettuerà verso la porta 21, verrà dirottato al FTP server locale dell’attaccante.
Ora se la vittima si collegasse da qui in poi a un server FTP, l’autenticazione verrà fatta sul server dell’attaccante priva di TLS.
In questo caso questa ultima versione di FILEZILLA avvertirebbe di un problema e di un probabile attacco di downgrade, un altro software potrebbe anche non avere questo controllo e procedere senza avvisi.
Questo perché in precedenza ci siamo collegati tramite TLS, se fosse la prima volta non avrebbe però segnalato il problema.
Se la vittima consentirà a questo messaggio senza farsi molte domande e proseguirà con l’autenticazione, MITMF catturerà le credenziali scambiate in chiaro, incluso IP del server FTP.
Il messaggio che usiamo una connessione non sicura lo vedremo anche su filezilla nei log.
Una conseguenza oltre al furto di credenziali, se l’attaccante avesse configurato un server locale FTP che possa accettare qualunque credenziale passata dalla vittima, potrebbe accedere anche il furto dei dati che la vittima potrebbe provare a inviare all’attaccante.
Ovviamente per questo caso manca il prerouting anche della porta 20 e alcune porte passive.
NB: FileZilla segnala il downgrade solo se in precedenza era avvenuta una connessione FTPS, ma non sempre blocca il tentativo se la configurazione è su “connessione automatica”.
Considerazioni
Con questo laboratorio abbiamo dimostrato come, anche in presenza di protocolli sicuri come FTPS, la sicurezza possa essere compromessa se non si adottano configurazioni adeguate e consapevoli. Attraverso un attacco Man-in-the-Middle (MITM) e tecniche di ARP spoofing, è stato possibile forzare un client FTP, configurato per selezionare automaticamente il protocollo più sicuro disponibile, a retrocedere a una connessione non cifrata (FTP), esponendo così le credenziali e i dati trasmessi.
Questo scenario potrebbe presentarsi anche con i protocolli POP, IMAP, SMTP se il client di posta agisse in automatico a configurarsi il protocollo.
Importante quindi prestare attenzione alle configurazioni dei client per utilizzare esclusivamente connessioni sicure.
Mitigazioni
Per ridurre i rischi legati all’utilizzo di reti pubbliche o non affidabili, esistono diverse tecniche di mitigazione che possono essere applicate a livello infrastrutturale. Tra le più efficaci troviamo:
Network Isolation – Separazione logica dei dispositivi per limitare la visibilità e l’interazione diretta tra client.
Private VLAN – Isolamento dei client all’interno della stessa VLAN.
Dynamic ARP Inspection (DAI) – Protezione contro attacchi di tipo ARP spoofing tramite verifica dell’integrità delle risposte ARP.
DHCP Snooping – Blocco delle risposte DHCP non autorizzate per prevenire attacchi man-in-the-middle.
Port Security sugli switch – Limitazione e controllo degli indirizzi MAC connessi alle porte fisiche.
QoS e Traffic Shaping – Gestione della banda e delle priorità per migliorare l’efficienza e ridurre le superfici di attacco legate al congestionamento.
Segmentazione della rete – suddivisione dell’infrastruttura in zone separate per contenere le minacce e semplificare il controllo (può essere fatto anche su base login).
Nei prossimi articoli approfondiremo ciascuna di queste soluzioni, analizzando scenari reali, configurazioni consigliate e il loro impatto sulla sicurezza complessiva della rete.
Conclusioni Finali
Come RedWave Team vogliamo sensibilizzare sul fatto che affidarsi ciecamente ai protocolli cifrati o alle configurazioni predefinite può generare un pericoloso senso di sicurezza. Abbiamo infatti visto, come connessioni protette possono essere compromesse se gli strumenti non sono configurati correttamente o se l’utente non è pienamente consapevole dei rischi.
La sicurezza delle comunicazioni non si basa soltanto sull’uso di HTTPS o FTPS, ma sull’adozione di un approccio proattivo che includa configurazioni sicure, formazione continua e buone pratiche operative.
Nel prossimo articolo esploreremo l’uso della VPN come ulteriore livello di protezione su reti non affidabili, e nei successivi analizzeremo strategie di mitigazione concrete per ridurre l’esposizione al rischio anche su reti problematiche come una WiFi aperta.
“La protezione dei diritti di bambini e adolescenti rappresenta una priorità per la Polizia di Stato e richiede un’attenta valutazione delle minacce emergenti, l’impiego di t...
Nel vasto arsenale del cybercrimine, una categoria di malware continua ad evolversi con una velocità e una precisione quasi industriale: gli information stealer. Questi strumenti, nati inizialmen...
Sabato 3 maggio, un post pubblicato su un canale Telegram legato al gruppo “Mr Hamza” ha rivendicato un cyberattacco ai danni del Ministero della Difesa italiano. Il messaggio, scritto i...
Microsoft ha confermato che il protocollo RDP (Remote Desktop Protocol) consente l’accesso ai sistemi Windows anche utilizzando password già modificate o revocate. L’azienda ha chia...
Una nuova campagna di phishing sta circolando in queste ore con un obiettivo ben preciso: spaventare le vittime con la minaccia di una multa stradale imminente e gonfiata, apparentemente proveniente d...
