Le campagne di phishing più pericolose oggi non puntano solo a ingannare i dipendenti ma a logorare il Security Operations Center. Quando un’indagine su una singola email richiede ore invece di pochi minuti, la differenza tra incidente contenuto e violazione diventa concreta. Per anni la difesa dal phishing si è concentrata su formazione, filtri email e programmi di segnalazione. Molto meno considerato è ciò che accade dopo la segnalazione, cioè il processo di triage e analisi nel SOC, che può trasformarsi in una superficie di attacco.

Gli attaccanti ragionano per sistemi. Un SOC ha capacità finita e modalità di fallimento prevedibili. In una grande azienda è sufficiente inviare migliaia di messaggi di phishing a bassa sofisticazione per generare una valanga di alert e report. I messaggi più banali creano rumore e costringono gli analisti a smaltire una coda che cresce più velocemente di quanto possa essere gestita. Dentro questo volume si nascondono poche email di spear phishing mirate a ruoli chiave e accessi critici. Il risultato è una forma di denial of service informativo che colpisce l’attenzione umana invece delle risorse di rete.

Sotto pressione i SOC tendono ad accelerare il triage riducendo la profondità delle verifiche. Una quota rilevante dei team non riesce a stare al passo con gli alert in ingresso e questo porta a scorciatoie cognitive, ancoraggio a indicatori superficiali e minore capacità di riconoscere segnali nuovi. Proprio qui lo spear phishing trova copertura, perché è progettato per assomigliare a comunicazioni di routine come fornitori, condivisioni documenti o processi amministrativi.

La dinamica economica favorisce l’attaccante. Generare decoy costa quasi zero, ancora di più con strumenti di generazione automatica, mentre ogni email segnalata costa minuti o ore di tempo qualificato. Il costo di perdere il messaggio giusto può invece tradursi in furto credenziali, movimento laterale, esfiltrazione dati o ransomware.

Molte organizzazioni provano a rispondere con automazioni a regole, whitelist e deduplicazione, ma queste difese creano punti ciechi prevedibili e spesso non sono affidabili se non spiegano il perché delle decisioni. Un approccio più efficace è rendere il triage decision ready, con analisi trasparente e verificabile su autenticità del mittente, controlli SPF DKIM DMARC, reputazione del dominio, indicatori di social engineering e correlazione con telemetria endpoint. La variabile critica diventa la latenza decisionale: passare da 3–12 ore a meno di 5 minuti riduce drasticamente la finestra operativa dell’attaccante.