Vishing: detection e risposta organizzativa

Una segnalazione di vishing raramente contiene da sola la prova di una compromissione. Diventa utile quando viene correlata con autenticazioni, modifiche all’account, attività dell’help desk e altri messaggi ricevuti nello stesso intervallo temporale.

Prerequisiti e domanda di analisi

Servono orari normalizzati, identità dell’utente, log di autenticazione, audit delle modifiche all’account e ticket dell’help desk. Eventi telefonici dettagliati possono non essere disponibili e non sono indispensabili per iniziare. La domanda non è “questa chiamata era falsa?”, ma “esistono azioni digitali non autorizzate temporalmente e logicamente compatibili con la chiamata segnalata?”.

Definisci una finestra iniziale limitata, per esempio da trenta minuti prima a due ore dopo la chiamata, e ampliala soltanto quando emergono elementi concreti. Conserva timezone, origine del timestamp e ritardi di ingestione: una correlazione apparente può dipendere da orologi o pipeline differenti.

Modello delle evidenze

Microsoft Entra ID Protection distingue rischio dell’accesso e rischio dell’utente e rende disponibili dettagli come applicazione, dispositivo, posizione, MFA e stato della detection. Questi segnali sostengono un’indagine, ma il punteggio non sostituisce la conferma: un viaggio, una VPN autorizzata o una nuova applicazione possono spiegare l’anomalia.

Procedura di correlazione

1. Stabilisci identità, intervallo UTC e sistemi da interrogare.
2. Recupera accessi riusciti e falliti, incluse autenticazioni non interattive quando disponibili.
3. Cerca registrazione o rimozione di metodi MFA, reset password, nuovi dispositivi, consenso ad applicazioni e revoca di sessioni.
4. Confronta ticket e contatti dell’help desk: una richiesta telefonica può precedere o seguire un reset fraudolento.
5. Costruisci una timeline indicando per ogni evento fonte, affidabilità e relazione con la chiamata.
6. Chiedi conferma all’utente tramite un canale già noto, senza suggerire risposte e senza attribuire colpe.

Query di partenza, non verdetto

Il seguente pseudocodice descrive una correlazione vendor-neutral. I nomi dei campi devono essere adattati allo schema effettivo e verificati su eventi benigni:

window_start = reported_call_time - 30m
window_end   = reported_call_time + 2h

identity_events
| where user_id == reported_user
| where event_time between (window_start .. window_end)
| where event_type in (
    "sign_in", "mfa_method_change", "password_reset",
    "new_device", "session_revoke", "application_consent"
  )
| project event_time, event_type, result, source, device, location, risk
| sort by event_time asc

La query deve restituire anche eventi riusciti e legittimi: filtrare soltanto gli errori può nascondere l’azione che ha avuto successo. Registra query, versione dello schema e intervallo usato, così un secondo analista può ripetere la ricerca.

Ipotesi di detection

Una detection utile combina segnali con una spiegazione operativa. Esempi da validare includono: modifica di un metodo MFA poco dopo un ticket di reset; nuova autenticazione seguita da registrazione di dispositivo; più richieste MFA e successivo accesso riuscito da proprietà insolite; consenso a un’applicazione dopo una segnalazione di assistenza telefonica.

Non trasformare ogni sequenza in un incidente. Un nuovo telefono, una migrazione pianificata o un intervento reale del supporto possono produrre la stessa cronologia. Mantieni allowlist con responsabile e scadenza, misura la copertura e conserva il motivo della chiusura dei falsi positivi.

Playbook di contenimento e mitigazione

• Se vi è un accesso non autorizzato confermato, revoca sessioni e token secondo la piattaforma.
• Proteggi il reset: una password nuova non basta se metodi MFA o sessioni sono compromessi.
• Verifica modifiche a dispositivi, inoltri, regole, consensi e meccanismi di recupero.
• Preserva gli eventi prima che scadano i tempi di conservazione.
• Cerca altre segnalazioni con la stessa identità dichiarata, richiesta o sequenza, senza usare il solo numero chiamante come indicatore affidabile.
• Comunica a help desk e utenti una procedura verificabile, evitando dettagli che facilitino l’impersonazione.

NIST SP 800-61 Rev. 3 colloca la risposta in tutte le funzioni del Cybersecurity Framework: preparazione e miglioramento non sono fasi esterne all’incidente. Dopo il contenimento, aggiorna rubriche ufficiali, criteri di verifica del supporto, logging e formazione sulla base delle lacune osservate.

Severità e chiusura

La severità dipende dall’impatto dimostrato: richiesta respinta, dati divulgati, autenticazione approvata, sessione compromessa o modifica persistente sono situazioni diverse. Documenta quali asset erano accessibili e quali azioni sono state escluse dalle evidenze disponibili.

Chiudi l’incidente soltanto dopo aver definito lo stato dell’identità, revocato gli accessi necessari, verificato i meccanismi di recupero e assegnato le azioni correttive. “Nessun evento trovato” significa soltanto che le sorgenti interrogate non hanno restituito eventi nella finestra indicata.

Limiti

Il numero visualizzato può essere falsificato e non deve diventare da solo un indicatore di compromissione. I log cloud possono arrivare in ritardo; le piattaforme applicano classificazioni proprietarie; l’assenza di rischio elevato non prova la legittimità. Le registrazioni vocali introducono inoltre obblighi e rischi privacy che questo articolo non determina.

Fonti essenziali

Fonti primarie consultate il 10 ottobre 2026. Query, finestre temporali e playbook sono proposte editoriali da collaudare con schemi, licenze, retention e procedure reali.

• NIST — SP 800-61 Rev. 3, Incident Response
• Microsoft — ID Protection risk reports
• Microsoft — investigare il rischio di identità