TL;DR
- Cosa imparerai: Come identificare e bloccare attacchi vishing orchestrati da professionisti pagati a chiamata
- Tempo richiesto: 45 minuti per implementare le contromisure base, 2-3 ore per il setup completo
- Difficoltà: Media — richiede accesso alle policy del service desk e autorità per modificare procedure operative
Il Problema: Quando il Tuo Help Desk Reset la Password dell'Attaccante
Se il tuo service desk ha ricevuto questa chiamata stamattina, probabilmente non se ne è accorto:
*"Ciao, sono Martina del reparto amministrativo di Milano. Sto lavorando da casa e non riesco ad accedere. Il mio responsabile mi ha chiesto urgentemente il report trimestrale... puoi resettarmi la password? Sì, confermo: m.rossi@aziendaspa.com. La mia matricola? Aspetta che controllo... è la 4782. Grazie mille, sei stato gentilissimo!"*
Tono professionale. Nessuna esitazione. Dati parzialmente corretti (presi da LinkedIn o dal sito aziendale). Zero red flag per un operatore sotto pressione.
Il problema? Martina Rossi esiste davvero, ma quella al telefono era una contractor pagata $500-$1.000 da Scattered LAPSUS$ Hunters (SLH) per quella singola chiamata. Tra 3 minuti l'attaccante avrà accesso al sistema con credenziali valide. Il tuo EDR non segnalerà nulla perché l'accesso è legittimo.
SLH ha industrializzato il vishing: recluta specificamente donne madrelingua (statisticamente più credibili al telefono con gli operatori help desk), fornisce script dettagliati, paga a performance. È social engineering professionalizzato.
Prerequisiti: Cosa Ti Serve per Difenderti
Accessi e autorità necessari:
- Permessi per modificare le procedure del service desk IT
- Accesso ai log delle chiamate (se registrate) e dei ticket di assistenza
- Autorità per implementare policy di verifica identità vincolanti
- Budget minimo per tool di callback automation (opzionale ma consigliato)
Licenze e strumenti:
- Sistema di ticketing con campi personalizzabili
- Accesso alla directory aziendale (Active Directory, Entra ID)
- Tool di registrazione chiamate (compliance GDPR permettendo)
- Eventuale integrazione con [sistemi di sicurezza informatica](/servizi/sicurezza-informatica) che loggano tentativi di accesso
Step-by-Step: Implementare Difese Contro Vishing Professionalizzato
Step 1: Analizza i Tuoi Log degli Ultimi 90 Giorni
Prima di cambiare procedure, cerca pattern sospetti nei reset password già effettuati.
Cosa cercare:
```
- Reset password richiesti telefonicamente (vs ticket email)
- Richieste con urgenza esplicita ("il capo mi ha chiesto...")
- Utenti che chiamano fuori orario lavorativo standard
- Reset seguiti immediatamente da accessi VPN/cloud da IP mai visti
- Richieste dove l'operatore ha annotato "conferma verbale telefonica"
```
Query esempio su sistema ticketing:
```sql
SELECT ticket_id, user_email, created_date, resolution_notes
FROM tickets
WHERE category = 'Password Reset'
AND channel = 'Phone'
AND created_date > DATE_SUB(NOW(), INTERVAL 90 DAY)
AND resolution_notes LIKE '%urgent%' OR resolution_notes LIKE '%manager%'
```
Errore comune: Ignorare i ticket risolti "senza problemi". Gli attaccanti professionisti non lasciano tracce evidenti — il successo sta proprio nel NON generare alert.
Step 2: Definisci Livelli di Rischio per le Richieste
Non tutte le richieste telefoniche sono uguali. Crea una matrice di rischio.
Livello BASSO (verifica standard):
- Utente chiama dal numero aziendale registrato
- Richiesta durante orario lavorativo
- Storia precedente di ticket similari
Livello MEDIO (verifica rafforzata):
- Chiamata da numero mobile/esterno
- Primo contatto dell'utente con help desk
- Richiesta accesso a sistemi critici
Livello ALTO (callback obbligatorio):
- Urgenza esplicita o pressione emotiva
- Richiesta reset MFA oltre a password
- Utente con privilegi amministrativi
- Chiamata fuori orario o in festivi
Script operatore per livello ALTO:
```
"Perfetto, procediamo. Per policy di sicurezza su account privilegiati,
richiamo io al numero aziendale registrato entro 10 minuti.
Qual è la tua estensione diretta?"
```
Errore comune: Fare eccezioni "per il direttore generale". Gli attaccanti di SLH impersonano specificamente C-level perché sanno che gli operatori hanno paura di sembrare ostruzionisti.
Step 3: Implementa Callback Verification Automatizzato
Il callback manuale funziona, ma scala male e dipende dalla diligenza dell'operatore.
Soluzione semi-automatica:
- Operatore crea ticket con flag "PENDING_CALLBACK"
- Sistema genera PIN a 6 cifre valido 15 minuti
- Sistema chiama automaticamente il numero aziendale registrato in AD
- IVR legge il PIN
- Utente comunica PIN all'operatore per completare la richiesta
Implementazione con PowerShell + Twilio (esempio concettuale):
```powershell
# Genera PIN e chiama utente
$pin = Get-Random -Minimum 100000 -Maximum 999999
$userPhone = (Get-ADUser -Identity $username -Properties OfficePhone).OfficePhone
# Twilio API call (richiede account)
Invoke-RestMethod -Uri "https://api.twilio.com/2010-04-01/Accounts/$AccountSid/Calls.json" `
-Method POST `
-Body @{
From = $TwilioNumber
To = $userPhone
Twiml = "<Response><Say>Il tuo PIN di verifica è: $pin</Say></Response>"
}
# Salva PIN in ticket
Update-Ticket -TicketId $ticketId -CustomField "VerificationPIN" -Value $pin
```
Errore comune: Chiamare il numero fornito dall'utente al telefono invece di quello registrato in AD. L'attaccante può fornire un numero controllato.
Step 4: Addestra il Team su Tecniche di Pressione Emotiva
Gli script di SLH sfruttano leve psicologiche precise. Il tuo team deve riconoscerle.
Red flag da addestrare:
Urgenza artificiale:
- "Il mio capo ha una call con il cliente tra 10 minuti"
- "È per una gara che scade oggi"
- "Sono in smartworking e mio figlio sta male"
Falsa familiarità:
- "L'altra volta mi aveva aiutato Marco, è in turno?"
- "Di solito basta che confermi l'email aziendale"
- "Ho già parlato con la vostra collega stamattina"
Inversione autorità:
- "Il responsabile IT mi ha detto di chiamare direttamente voi"
- "Ho l'autorizzazione del direttore generale"
- "È una procedura d'emergenza approvata"
Esercitazione pratica mensile:
Fai chiamare un collega esterno (o tu stesso con numero mascherato) simulando queste tecniche. Verifica chi cede.
Step 5: Integra Verifica Multi-Canale Obbligatoria
Non basta il callback. Richiedi conferma su canale diverso dalla voce.
Policy operativa:
```
Per reset password/MFA su richiesta telefonica:
- Callback al numero aziendale registrato (Step 3)
- PLUS: Email di conferma all'indirizzo secondario dell'utente
(se configurato) con link che scade in 15 minuti
- PLUS: Notifica al manager diretto via Teams/Slack
(solo per account privilegiati)
```
Configurazione esempio in Microsoft 365:
- Ogni utente deve avere "ProxyAddresses" con almeno un alias
- L'alias non può essere inoltrato automaticamente alla mailbox principale
- Help desk invia link di conferma all'alias, che arriva solo su device autenticati
Errore comune: Inviare conferma via SMS. SLH usa anche SIM swap attacks — l'SMS non è un secondo fattore affidabile.
Step 6: Logga e Correla Tutto
Ogni richiesta telefonica deve generare dati analizzabili.
Campi obbligatori nel ticket:
- Numero chiamante (anche se nascosto, logga "CALLER_ID_BLOCKED")
- Timestamp preciso
- Dati forniti dall'utente per identificarsi (matricola, ufficio, manager)
- Esito verifica (callback riuscito? PIN corretto?)
- IP primo accesso post-reset (da correlare con log VPN/firewall)
Dashboard SIEM/log aggregation:
```
Alert se:
- Reset password telefonica + accesso VPN da paese estero < 30 min
- Callback fallito ma operatore ha comunque processato richiesta
- Stesso numero chiamante richiede reset per >3 utenti diversi in 7gg
- Utente resettato chiama 2h dopo dicendo "non ho mai chiamato"
```
Questi pattern non li vedi in tempo reale — li cerchi retroattivamente per capire se sei già stato compromesso.
Verifica: Come Testare le Tue Difese
Test 1: Red Team interno (monthly)
Fai simulare un attacco vishing da un collega che il service desk non conosce personalmente.
Scenario:
- Chiamata da numero mobile
- Impersonificazione di dipendente reale (con suo consenso)
- Script con 2-3 red flag (urgenza + falsa familiarità)
- Obiettivo: ottenere reset password senza callback
Successo = fallimento: Se il test ha successo, hai un problema procedurale.
Test 2: Verifica log correlazione
Cerca manualmente pattern sospetti:
```bash
# Esempio query su log Syslog aggregati
grep "password reset" /var/log/servicedesk.log | \
awk '{print $4, $8}' | \
sort | uniq -c | sort -rn | head -20
# Output atteso: lista IP di primi accessi post-reset
# Confronta con baseline geografica utenti
```
Test 3: Callback automation
Simula ticket "PENDING_CALLBACK" e verifica:
- Sistema chiama entro SLA (es. 10 min)?
- PIN viene generato e salvato correttamente?
- Operatore vede chiaramente lo stato "WAITING_PIN_CONFIRMATION"?
Strumenti consigliati:
- Wireshark per verificare traffico Twilio/VOIP
- Postman per testare API callback
- Script PowerShell per generare 100 ticket fittizi e misurare tempi
Troubleshooting: Problemi Comuni e Soluzioni Rapide
Q: Gli operatori si lamentano che la procedura è troppo lunga. I ticket si accumulano.
A: Automatizza il callback (Step 3). Il tempo operatore si riduce a 2 minuti: crea ticket, sistema chiama, operatore aspetta PIN. Nel frattempo gestisce altro. Misura: con automazione, 1 operatore gestisce 40 callback/ora vs 12 manuali.
Q: Un utente reale non risponde al callback perché è in riunione. Come gestiamo l'urgenza legittima?
A: Policy di escalation:
- Callback fallito → operatore invia email con istruzioni self-service password reset (se abilitato)
- Se self-service non disponibile → escalation a team lead che può autorizzare con verifica rafforzata (es. videocall Teams con documento identità)
- Mai processare richiesta senza verifica "perché è urgente"
Q: Ho trovato nei log 3 reset sospetti di 2 mesi fa. Come capisco se siamo stati compromessi?
A: Forensics checklist:
- Estrai tutti gli accessi di quegli account post-reset (VPN, [email](/servizi/email-security), file server)
- Cerca download massivi, accessi a cartelle inusuali, invii email a esterni
- Verifica modifiche AD/Entra: aggiunte a gruppi privilegiati, creazione account di servizio
- Controlla backup: se compromessi, potrebbero aver escluso folder critici da policy backup
- Se trovi anomalie → incident response completo, considera coinvolgere partner come BullTech per [gestione dell'incidente](/servizi/sicurezza-informatica)
Q: Possiamo semplicemente disabilitare i reset password telefonici?
A: Teoricamente sì, ma crea attrito utente enorme. Soluzione ibrida:
- Reset telefonico permesso solo per livello BASSO (Step 2)
- Livello MEDIO/ALTO → solo via ticket email con manager in CC
- Eccezioni per emergenze → escalation a IT manager che decide caso per caso
Il problema è che gli attaccanti SLH useranno proprio le "emergenze" come vettore.
Q: Il nostro service desk è outsourced. Come implementiamo queste policy?
A: Inserisci nel SLA:
- Procedure callback vincolanti (allegato tecnico al contratto)
- KPI su % reset con verifica completa (target >95%)
- Penali se audit trova reset non conformi
- Accesso tuo ai log per verifiche random mensili
Se il fornitore rifiuta → valuta cambio fornitore o internalizzazione help desk.
Conclusione: Il Vishing Non È Risolvibile Solo con Tecnologia
SLH paga $1.000 a chiamata perché funziona. Nessun firewall, nessun EDR, nessun MFA blocca una password resettata legittimamente dal tuo service desk.
Le contromisure sono 70% processo, 20% addestramento, 10% automazione. Implementa callback verification entro questa settimana. Addestra il team sulle red flag entro fine mese. Monitora i log retroattivamente per i prossimi 90 giorni.
E ricorda: l'attaccante deve avere successo una sola volta. Tu devi avere successo ogni volta.
Prossimi passi:
- Audit log ultimi 90gg (oggi)
- Draft policy callback verification (3 giorni)
- Setup automazione o processo manuale (1 settimana)
- Primo red team test (entro 30gg)
- Revisione trimestrale procedure e metriche efficacia