Oltre il phishing: come individuare un account compromesso tramite i log di autenticazione

Obiettivo e pubblico

• Obiettivo: Fornire un metodo di analisi strutturato per ricercare e correlare le evidenze di un attacco di phishing all'interno dei log di autenticazione cloud e di sistema, integrando la rilevazione dell'anomalia di Impossible Travel.

• Pubblico: Amministratori di sistema, analisti SOC junior, studenti di cybersecurity e professionisti dell'Incident Response.

Prerequisiti

• Conoscenze: Comprensione dei flussi di autenticazione basati su identità (credenziali, MFA, token di sessione) e familiarità con la riga di comando (Bash e PowerShell).

• Strumenti: Accesso a una console di gestione identità (es. Microsoft Entra ID), SIEM o terminali con permessi di lettura sui log di sistema (auth.log / Eventi di Sicurezza Windows).

• Accessi autorizzati: Permessi di lettura sui log del tenant di test o dei server di laboratorio isolati.

Uso autorizzato

Esegui le attività di analisi, ricerca log e simulazione esclusivamente su sistemi propri o in un laboratorio isolato per il quale hai un’autorizzazione esplicita. Non interrogare tenant di produzione reali o ambienti di terze parti senza formale mandato.

Preparazione del laboratorio

• Isolamento: Utilizza un tenant di prova o macchine virtuali (Linux/Windows) disconnesse dalla rete aziendale.

• Dati sintetici: Popola i registri con eventi di autenticazione simulati che includano anomalie di geolocalizzazione, sessioni anomale o modifiche alle chiavi/dispositivi successivi a una finta interazione di phishing.

• Stato iniziale: Assicurati che l'account di test (m.rossi) si trovi in uno stato pulito, senza alert di rischio attivi. Puoi usare un utente reale se vuoi, in questo caso ricorda di modificare i comandi utilizzando il corretto username dell'utente.

Procedura guidata e Scenari pratici

Per trovare le evidenze di phishing nei log, dobbiamo cercare lo scarto temporale e logico tra il momento in cui l'utente riceve/clicca il link fraudolento e l'istante in cui l'attaccante sfrutta le credenziali rubate.

Che cos'è l'Impossible Travel (Viaggio Impossibile)

L'Impossible Travel è un indicatore di compromissione fondamentale nell'analisi dei log di identità. Si verifica quando un utente effettua due accessi consecutivi con successo da due posizioni geografiche distinte in un intervallo di tempo talmente breve che lo spostamento fisico tra i due luoghi risulta impossibile per qualsiasi mezzo di trasporto umano.

• Esempio analitico: Se un utente si autentica con successo da Milano alle ore 08:30 e, dopo appena due minuti (08:32), risulta autenticato da un indirizzo IP localizzato a Singapore, il sistema rileva l'incompatibilità fisica. Questo comportamento anomalo indica solitamente che le credenziali (o i cookie di sessione trafugati tramite phishing) sono state utilizzate contemporaneamente da un attaccante remoto o tramite script automatizzati.

Scenario 1: Ricerca di evidenze nei log Cloud (Es. Microsoft Entra ID / Kusto)

Quando un utente cade in un attacco di phishing (specialmente in scenari Adversary-in-the-Middle dove viene intercettato anche il codice MFA), l'evidenza principale risiede nei log di accesso (sign-in logs).

1. Estrarre i log dell'utente coinvolto nella finestra temporale sospetta:

   Snippet di codice

   
   

   SigninLogs
   | where UserPrincipalName == "m.rossi@company.com"
   | where TimeGenerated between (datetime(2026-10-10T08:00:00Z) .. datetime(2026-10-10T12:00:00Z))
   | project TimeGenerated, IPAddress, Location, AppDisplayName, UserAgent, ResultType, ConditionalAccessPolicies
   

2. Cercare l'evidenza dell'anomalia (Impossible Travel o variazioni di sessione): Se i log mostrano un login da una sede abituale seguito a brevissima distanza da un IP estero o da un datacenter non censito (accompagnato magari da stringhe User-Agent insolite come python-requests), hai trovato l'evidenza che l'attaccante sta sfruttando la sessione rubata.

3. Verificare i log di audit per la persistenza: Subito dopo il phishing, l'attaccante tende a registrare un nuovo metodo MFA o a modificare i dati di recupero. Cerca nei log di audit:

   Snippet di codice

   
   

   AuditLogs
   | where ActivityDisplayName has "Register security info" or ActivityDisplayName has "Update user"
   | where TargetResources has "m.rossi@company.com"
   

Scenario 2: Ricerca di evidenze su sistemi Linux (Bash)

Se l'attaccante usa le credenziali o i token sottratti per tentare accessi via SSH, cerchiamo le evidenze nei log di sistema (/var/log/auth.log). In ambienti protetti che usano chiavi o certificati:

1. Verificare se sono stati registrati accessi con chiavi non autorizzate o tentativi di alterazione:

   Bash

   
   

   grep -E "Accepted publickey|Accepted certificate" /var/log/auth.log | grep "m.rossi"
   

2. Individuare modifiche recenti al file delle chiavi autorizzate (authorized_keys), chiaro indizio di persistenza post-phishing:

   Bash

   
   

   grep -i "authorized_keys" /var/log/auth.log
   

   E controlla la data di modifica del file dell'utente:

   Bash

   
   

   stat /home/m.rossi/.ssh/authorized_keys
   

Scenario 3: Ricerca di evidenze su sistemi Windows (PowerShell)

Se l'attaccante si sposta lateralmente o accede a workstation aziendali dopo una campagna di phishing mirata:

1. Filtrare gli accessi riusciti nel registro di sicurezza per individuare indirizzi IP o tipi di logon anomali (es. RDP = Tipo 10):

   PowerShell

   
   

   Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4624)]]" -MaxEvents 20 | 
   Select-Object TimeCreated, @{Name="User";Expression={([xml]$_.ToXml()).Event.EventData.Data[@Name='TargetUserName']}}, @{Name="IP";Expression={([xml]$_.ToXml()).Event.EventData.Data[@Name='IpAddress']}}, @{Name="LogonType";Expression={([xml]$_.ToXml()).Event.EventData.Data[@Name='LogonType']}}
   

2. Verificare la creazione di nuovi account o modifiche ai gruppi privilegiati a seguito della compromissione:

   PowerShell

   
   

   Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4720)]]"
   

Risultato atteso

L'analisi corretta deve permettere di correlare la segnalazione di phishing con almeno un'evidenza tecnica concreta nei log (un'anomalia di Impossible Travel, un IP anomalo, un accesso fuori orario, l'uso di uno User-Agent non standard o l'aggiunta di un nuovo dispositivo MFA), portando all'immediata revoca dei token di sessione e all'isolamento delle utenze colpite.

Ripristino e pulizia del laboratorio

• Rimuovi le chiavi SSH non autorizzate o i dispositivi MFA di test aggiunti durante la simulazione.

• Termina le sessioni attive sospette (pkill -u m.rossi su Linux o chiudendo le sessioni di test su Windows).

• Ripristina le configurazioni iniziali e pulisci i file di log generati per la prova.

Limiti e mitigazioni

• Limiti: L'utilizzo legittimo di reti VPN commerciali o proxy aziendali può generare falsi positivi nell'indicatore di Impossible Travel. Inoltre, se l'attaccante impiega tecniche avanzate di AiTM (Adversary-in-the-Middle) tramite lo stesso proxy dell'utente, i log potrebbero inizialmente apparire regolari.

• Mitigazioni: Adottare chiavi di sicurezza hardware (FIDO2 / WebAuthn) resistenti al phishing, implementare politiche di accesso condizionale basate sulla conformità del dispositivo e centralizzare i log su un SIEM per l'analisi comportamentale avanzata.

Fonti essenziali

Fonti verificate il 10 ottobre 2026.

• Microsoft — Investigare il rischio di identità e i report di accesso

• MITRE ATT&CK — Tactic: Credential Access (TA0006) & Phishing (T1566)

• CERT-AGID — Linee guida per il monitoraggio e la risposta agli incidenti