Difesa help-desk contro Scattered Spider — il playbook anti social engineering

Questo playbook scatta per il social engineering di recupero identità: un attaccante che contatta il tuo help desk, service desk o supporto IT — per telefono, chat o ticket — per ottenere un reset password, un reset MFA, una re-enrollment del dispositivo MFA, o l'installazione di un tool di accesso remoto. L'attore canonico è Scattered Spider (tracciato anche come UNC3944, Octo Tempest, Scatter Swine, Oktapus, Storm-0875, Muddled Libra), ma il protocollo vale per ogni abuso di account-recovery.

In scope: il protocollo di verifica help-desk, l'hardening della superficie di recupero, e il backstop di detection per quando la verifica fallisce.

Fuori scope: l'incident response post-compromissione una volta confermato il takeover — per quello, passa al playbook compromissione identity provider. Questo è il fratello *lato prevenzione*: fermare il reset fraudolento prima che diventi un takeover.

Capisci la catena o il protocollo sembrerà arbitrario. Da AA23-320A e MITRE ATT&CK G1015:

1. Recon. L'attore raccoglie nomi, ruoli, employee ID e dati personali da LinkedIn, data-broker e breach dump (MITRE T1589, T1593.001). Impara *esattamente* cosa chiede il tuo help desk prima di resettare una password.

1. Pretesto + SIM swap. Può prima fare SIM swap del numero mobile del target (T1451) per ricevere i codici SMS/voce della vittima, poi chiamare il help desk impersonando il dipendente (T1656).

1. La richiesta. Al telefono (spearphishing voice, T1566.004) chiede all'operatore di resettare la password e/o spostare l'MFA su un nuovo dispositivo. In alternativa si finge IT e chiede al *dipendente* di leggere un codice usa-e-getta, o di installare un tool di accesso remoto (T1219).

1. Persistenza. Una volta dentro, registra il proprio token MFA (T1556.006) e — nelle intrusioni mature — aggiunge un identity provider federato al tenant SSO con account-linking automatico (T1484.002), mantenendo l'accesso anche dopo il cambio password (T1078).

1. Impatto. Esfiltrazione dati verso MEGA.nz, Amazon S3 e Snowflake, seguita nei casi recenti da ransomware DragonForce che cifra VMware ESXi (T1486).

L'unica decisione che spezza la catena è lo step 3: l'operatore che rifiuta il reset senza verifica reale.

Adotta un protocollo scritto e obbligatorio che un operatore non possa derogare sotto pressione sociale. Nessun reset — password, MFA, o re-enrollment dispositivo — procede finché l'identità non è provata da almeno un fattore che il vero dipendente controlla fisicamente, non da una conoscenza che un chiamante può aver rubato.

Vietati come prova unica (tutti ottenibili dall'attaccante): nome completo, employee ID, data di nascita, nome del manager, ultime quattro cifre del codice fiscale, postazione, domande di sicurezza.

Verifiche accettate (richiedine una, due per account privilegiati):

• Video live con badge aziendale mostrato alla camera, con prompt di liveness, confrontato con la foto su HRIS.
• Callback al numero registrato su HRIS — mai un numero fornito dal chiamante. Se il chiamante obietta al callback, è di per sé un red flag.
• Approvazione out-of-band del manager: il manager diretto conferma la richiesta su un canale separato e pre-stabilito (non l'email del chiamante).
• Push a un authenticator phishing-resistant già registrato che il dipendente possiede (non il dispositivo in fase di enrollment).

Stratifica il protocollo per rischio dell'account:

• *Utente standard*: un fattore accettato.
• *Privilegiato / admin / approvatore finanziario*: due fattori e un hold obbligatorio (vedi sotto).
• *Break-glass / domain admin*: solo verifica di persona.

Applica sempre un cooldown. Ogni enrollment di un nuovo dispositivo MFA notifica il canale verificato esistente del dipendente e impone una breve finestra di hold prima che il nuovo dispositivo sia fidato — così un dipendente reale può gridare "non sono stato io" prima che l'attaccante sia operativo.

Dai agli operatori un percorso esplicito di rifiuta-ed-escala, così la scelta sicura è il default sotto pressione:

• Pressione di urgenza o autorità ("il CEO lo vuole tra cinque minuti", "perdo una deadline del board") → trattala come red flag, non come motivo per saltare passaggi. I veri dirigenti tollerano la verifica; gli attaccanti fabbricano urgenza.
• Il chiamante chiede di bypassare il protocollo o si infastidisce per il callback → rifiuta ed escala al SOC. Gli utenti legittimi non obiettano alla verifica.
• Il chiamante non riesce a completare video + badge → niente reset da remoto; instrada a verifica di persona o via canale manager verificato.
• Chiamata in entrata che dice di essere IT e chiede al dipendente di leggere un codice usa-e-getta o installare un tool → l'IT non chiede mai un OTP né installa tool con una chiamata non sollecitata. Riaggancia e segnala.
• Più verifiche fallite su account diversi in poco tempo → è un indicatore di campagna, non sfortuna. Alza un alert al SOC e valuta un freeze temporaneo su tutti i reset iniziati per telefono.

Metti per iscritto, esplicitamente, che un operatore non è mai penalizzato per aver rifiutato un reset non verificabile — solo per aver saltato la verifica. Inverti l'incentivo che i social engineer sfruttano.

Il protocollo è il controllo umano; questi sono i controlli tecnici che riducono quanto può costare un singolo errore. Dalle mitigation di AA23-320A e dalla guida CISA su MFA phishing-resistant:

• Adotta MFA phishing-resistant (FIDO2/WebAuthn o PKI). Non è suscettibile a push bombing o SIM swap — le due tecniche che l'advisory lega a questo attore. Ritira SMS e OTP vocale per ogni account che conta.
• Allerta su ogni registrazione di dispositivo MFA e su nuovi identity provider federati / modifiche di domain-trust (la mossa di persistenza T1484.002). Tratta una federazione SSO inattesa come un incidente.
• Vincola i tool di accesso remoto. L'application allowlisting blocca RMM non autorizzati (AnyDesk, ScreenConnect, TeamViewer, Ngrok e simili citati nell'advisory); blocca le loro porte in entrata e uscita al perimetro e consenti l'accesso remoto solo via VPN/VDI aziendale.
• Applica gli standard di autenticazione NIST (SP 800-63B): password lunghe e uniche, niente rotazione forzata ricorrente, e credenziali admin obbligatorie per installare software.
• Segmenta così un singolo account recuperato non raggiunge l'estate ESXi/backup/Snowflake che l'attore monetizza.

Assumi che il protocollo fallirà ogni tanto: un chiamante convincente, un operatore di fretta, un desk in outsourcing fuori copione. Dopo un reset fraudolento l'account è realmente valido — il login non è anomalo, quindi l'alerting a livello identità da solo lo manca. Ciò che resta anomalo è il *comportamento*: una sessione con impossible travel, un host che storicamente solo riceve dati che improvvisamente si espande lateralmente, l'esecuzione di RMM, e un egress sostenuto verso destinazioni mai viste (MEGA.nz, bucket S3 sconosciuti, query Snowflake massive).

Monitora esplicitamente: nuovi enrollment MFA, modifiche di trust federato, "risky login" in stile CISA, esecuzione di processi RMM, e traffico est-ovest e in uscita anomalo. È esattamente qui che si inserisce il pilastro AI Traffic Analysis di Zero Hunt: un modello deep-learning con quattro inference head (traffico sospetto, classificazione malware, identificazione tipo di attacco, fingerprinting applicativo), che gira sulla GPU dell'appliance, segnala il fan-out laterale e l'esfiltrazione di una sessione che il help desk ha erroneamente fidato — *mentre accade*, non nel digest SIEM del mattino dopo. Il protocollo di verifica è la porta d'ingresso; la detection comportamentale a wire-speed è il filo d'inciampo per le volte in cui la porta viene aperta con le parole.

Tienile per poter provare che il controllo funziona a un auditor, a un assicuratore o al board — e per cogliere presto una campagna:

• Log dei reset al help desk: per richiesta — timestamp, operatore, account, metodo di verifica usato, esito (reset / rifiutato / escalato).
• Audit log di enrollment e modifiche MFA, con dispositivo e IP di origine.
• Log di modifiche identità federata / domain-trust (il canarino della persistenza).
• Alert di risky-login e impossible-travel, conservati col dettaglio di sessione.
• Log di installazione/esecuzione RMM dall'allowlisting endpoint.
• Anomalie di traffico in uscita/laterale correlate alla finestra dell'account.

Traccia queste metriche ogni mese: percentuale di reset completati via metodo di verifica approvato (target 100%), tasso di fallimento/rifiuto verifica (un numero sano non-zero indica che il protocollo è applicato), e tempo medio dal sospetto reset fraudolento alla revoca dell'account.

Pattern che ricorrono nelle organizzazioni colpite da Scattered Spider:

• Verifica solo su PII. Resettare su dati che l'attaccante ha già comprato. La root cause singola più comune.
• La corsia di eccezione VIP. Un percorso veloce per i dirigenti che salta la verifica — proprio gli account che l'attore prende di mira e il pretesto ("sono il CFO, sbrigati") che usa.
• Un help desk in outsourcing su un protocollo più debole del parent. L'advisory segnala esplicitamente l'abuso degli help desk IT *in appalto* (T1199); il tuo protocollo deve vincolare il BPO contrattualmente ed essere testato su di esso.
• MFA via SMS o chiamata vocale lasciato attivo per account sensibili — battuto dal SIM swap che spesso precede la chiamata.
• Nessun alert sull'enrollment di un nuovo dispositivo MFA, così il dispositivo dell'attaccante diventa operativo in silenzio.
• Trattarlo come un problema dell'help desk IT. È un controllo di persone-e-processo che possiede il board: formazione, incentivi, il contratto BPO, e la decisione di finanziare l'MFA phishing-resistant stanno tutti sopra il service desk.