Cose che racconto nei corsi (e che poi si verificano) - UPDATED

Reti di Calcolatori e Principi di Cybersecurity, intorno alla fine di settembre: "Il DNS è una infrastruttura critica per il funzionamento della società. Pensiamo a cosa accadrebbe se si bloccasse completamente la risoluzione di alcuni nomi."

Il 20 ottobre 2025 molti servizi Internet usati da molti milioni di utenti in tutto il mondo si sono bloccati o sono diventati lentissimi. Tra questi Apple Music, Airbnb, Spotify, Reddit, Perplexity AI, Duolingo, Goodreads, Fortnite, Apple TV, Mc Donald's App, Signal e molti altri (compresi alcuni servizi della pubblica amministrazione UK).

Tutti questi servizi dipendono in tutto o in parte da funzionalità software in Amazon Web Services (AWS), uno dei principali fornitori di servizi cloud al mondo. AWS è composto internamente da molti servizi software.

Il motivo scatenante del blocco globale è stato un problema nella risoluzione DNS del nome di un particolare servizio usato internamente in AWS.

Cybersecurity, corso aziendale intorno a metà ottobre: "Il vero problema nella rilevazione degli attacchi informatici non è la capacità di rilevare gli attacchi. E' quello di rilevare solo gli attacchi, cioè evitare i falsi positivi. E' anche quello di investigare e prioritizzare le decine di alert che ogni organizzazione riceve quotidianamente".

Il 15 ottobre 2025 l'equivalente UK del nostro Garante della Privacy ha emesso una sanzione amministrativa di vari milioni di sterline ad un grande fornitore di servizi informatici che nel 2023 ha subito una intrusione. Questo fornitore aveva molte risorse interne, sia tecnologiche sia umane, dedicate alla rilevazione degli attacchi informatici. L'alert dell'attacco è stato investigato dopo 58 ore (più di due giorni) invece che in 1 ora come da loro garanzie; inoltre, lo avevano categorizzato di livello 2 invece che di livello 1 (punto 181, pg. 58 del report).

(se per caso state pensando che tanto l'IA risolverà tutti questi problemi ho una notizia per voi: no, non è così, non credete a queste promesse o speranze).

UPDATE 26 ottobre

Cybersecurity, corso aziendale intorno a metà ottobre:

"La cybersecurity è concettualmente un game (due avversari, ognuno modifica le proprie azioni in funzioni di quelle dell'avversario):

1. Attaccanti hanno comportamenti che i Difensori non rilevano come sospetti o pericolosi (EDR - Endpoint Detection and Response, SIEM - Security Information and Event Management).
2. Difensori modificano i loro sistemi per rilevare quei comportamenti (modificano le regole che nei loro EDR/SIEM generano ed assegnano priorità agli alert).
3. Attaccanti trovano altri comportamenti che i Difensori non rilevano come sospetti o pericolosi.
4. Difensori modificano i loro sistemi per rilevare anche quei nuovi comportamenti.

E così via. L'effetto è che in ogni momento gli Attaccanti hanno a disposizione molte azioni che i Difensori non identificano come sospetti o pericolosi.".

Esempi di tecniche che al momento in cui sono state rese pubbliche non erano rilevate dagli EDR possono essere trovati cercando "evasion" nel sito web del mio corso di Cybersecurity (sottosezione "Examples"). Un nuovo esempio interessantissimo è qui sotto.

Il 23 ottobre 2025 l'azienda Specter Ops (top del top del top in Cybersecurity) ha pubblicato un documento bellissimo, purtroppo anche lunghissimo e molto complicato, su una tipologia di attacchi ai sistemi Windows che si basa su caratteristiche intrinseche ai sistemi Windows stessi:

1. L 'hash della password di un account (o un "Kerberos ticket" rilasciato a quell'account) è sufficiente per impersonare quell'account nei confronti di molti servizi. Non è cioè necessario avere la password di quell'account.
2. Quando un account si è autenticato, la memoria di un certo processo (LSASS) contiene l'hash della password di quell'account (e tutti i "Kerberos ticket" rilasciati a quell'account). 

La conseguenza è che un malware con livelli di privilegio sufficienti per leggere la memoria del processo LSASS può impossessarsi di tutti gli hash delle password (e di tutti i "Kerberos ticket") esistenti in quel momento in quella macchina Windows (2) e, quindi, impersonare tutti gli account corrispondenti (1). Molti software malevoli sono in grado di eseguire queste azioni automaticamente.

Questa caratteristica intrinseca ai sistemi Windows ha molte gravi implicazioni pratiche in termini di Cybersecurity (ne parlo in dettaglio nel mio corso, qualche link qui).

Per mitigare questo problema Microsoft ha introdotto più volte profonde modifiche architetturali in Windows, già da più di 10 anni. In estrema sintesi, da molti anni LSASS viene eseguito in una sorta di macchina virtuale separata dal resto del sistema in modo che la memoria di LSASS non possa essere letta da nessun altro processo. L'accesso alle informazioni contenute in LSASS (password hash e "Kerberos ticket") avviene invocando delle funzioni del sistema operativo. Per inciso: un sistema operativo che ha al proprio interno una macchina virtuale per proteggere sé stesso da certi attacchi...ciò è un ottimo indicatore dell'importanza e del livello di sofisticazione degli attacchi informatici.

Il sistema operativo e tutte le miriadi di antivirus ed EDR esistenti controllano le interazioni con LSASS. Pattern di interazione sospetti sono bloccati oppure generano degli alert.  L'estrazione fraudolenta di informazioni da LSASS è ancora possibile ma molto più complicata. Occorre trovare sequenze di invocazioni delle funzioni di accesso ad LSASS che non sono considerate come sospette dagli antivirus ed EDR. I software malevoli sono aggiornati "di continuo" in modo da tentare di aggirare le regole di rilevazione ed i sistemi di rilevazione sono poi aggiornati di conseguenza.

In linea di principio ciò è concettualmente identico allo scenario precedente, quando LSASS non era in una macchina virtuale separata ed i software malevoli tentavano di accedere alla memoria di LSASS direttamente. In pratica, mettendo LSASS in una macchina virtuale separata, ci sono molti meno modi per tentare di accedervi, quindi il controllo da parte dei sistemi di rilevazione è molto più capillare e tentare di aggirarlo è molto più complicato.

Il documento di Specter Ops che ho citato più sopra purtroppo è comprensibile solo a specialisti (con molto tempo a disposizione) ma ciò che dice è questo: "Abbiamo trovato un modo per estrarre informazioni da LSASS invocando funzioni che non sono analizzate da nessun EDR. E' bene che i fabbricanti di EDR controllino le invocazioni della funzione che abbiamo usato noi":

We are not currently aware of any EDR products that monitor interactions with the LSA, and to our knowledge, there are no support functions that allow a third-party product to monitor these interactions in a non-invasive manner.

For EDR vendors, we recommend hooking the LsaCallAuthenticationPackage API, and monitor calls to the NTLM security package for NTLM responses to challenge 1122334455667788.

Come detto "...in ogni momento gli Attaccanti hanno a disposizione molte azioni che i Difensori non identificano come sospetti o pericolosi.".