Honeytoken: l’allarme che non mente quasi mai
Honeytoken è il nome di un’idea tanto semplice da sembrare un trucco: mettere in giro qualcosa di falso che nessuno, tranne un intruso, avrebbe motivo di toccare, e farsi avvisare quando qualcuno lo tocca. Una credenziale che non apre nulla, una chiave API che non serve a niente, un file dal nome invitante che nessun dipendente userebbe mai. Sono esche, e la loro forza sta in una proprietà che il resto della sicurezza si sogna: chi le attiva è quasi certamente un attaccante, perché un utente legittimo non ha alcuna ragione per avvicinarvisi.
È un capovolgimento rispetto al modo in cui di solito si cerca un intruso. Il rilevamento tradizionale prova a distinguere l’attività malevola da quella legittima dentro un flusso enorme di eventi reali, e paga questo sforzo con una marea di falsi positivi che esaurisce gli analisti. L’honeytoken fa l’opposto: non cerca l’ago nel pagliaio, pianta aghi che brillano solo se qualcuno li afferra. L’allarme che ne deriva non mente quasi mai, ed è esattamente ciò che manca nei centri operativi sommersi dal rumore.
Capovolgere l’economia del rilevamento
Il problema cronico del rilevamento è il rapporto tra segnale e rumore. Un Security Operations Center riceve ogni giorno migliaia di avvisi, la grande maggioranza dei quali innocui, e la fatica di separare i pochi veri dai molti falsi è la prima causa di affaticamento e di incidenti mancati. Ogni tecnica che aggiunge avvisi, per quanto sofisticata, peggiora questo rapporto se non porta con sé un modo per distinguere ciò che conta.
La deception, l’inganno difensivo, attacca il problema dal lato opposto. Invece di analizzare meglio ciò che accade, cambia il terreno: dissemina l’ambiente di oggetti che esistono solo per essere toccati da chi non dovrebbe. Un decoy non genera traffico, non viene usato da nessun processo legittimo, non compare in nessun flusso di lavoro reale. Per costruzione, qualunque interazione con esso è sospetta, e l’avviso che produce nasce già con una fedeltà altissima e un tasso di falsi positivi prossimo allo zero. Non è un controllo che si aggiunge al rumore, è un controllo che lo aggira.
Cos’è un honeytoken, in concreto
Sotto il nome rientrano oggetti diversi, accomunati dall’essere falsi e sorvegliati. La forma più nota è la canary token, una semplice esca digitale, un documento, un collegamento, una voce di configurazione, che invia un segnale nel momento esatto in cui viene aperta o usata. Ci sono poi le credenziali esca: una chiave API legata a una policy di solo monitoraggio, che non concede alcun accesso reale ma registra e segnala ogni tentativo di utilizzo. Quando uno script automatico raccoglie le chiavi trovate in un ambiente e prova a usarle, quella falsa lo tradisce all’istante.
La collocazione è tutto. Un honeytoken funziona se si trova dove un attaccante guarderebbe ma un utente onesto no: tra le variabili di un sistema, in un archivio di credenziali, in una cartella dal nome allettante, in una voce di database. È il rovescio esatto del problema affrontato da chi cerca di non lasciare credenziali sparse in giro: qui il segreto si lascia in vista apposta, perché serva da trappola e non da chiave.
Honeytoken e identità: cogliere ciò che l’EDR non vede
Il valore di questo approccio cresce proprio mentre gli attacchi cambiano natura. Secondo il CrowdStrike 2026 Global Threat Report, l’82 per cento dei rilevamenti nel 2025 è stato privo di malware, in netta crescita rispetto al 51 per cento del 2020: gli intrusi usano sempre più spesso credenziali legittime e strumenti di sistema, anziché codice malevolo riconoscibile. È il terreno dove la difesa basata sulle firme arranca, perché non c’è un file da identificare, solo un accesso che sembra autentico. Ed è il terreno ideale per le esche d’identità.
Un honeytoken d’identità è un account che sembra prezioso e non lo è: un’utenza di servizio dormiente, una credenziale da amministratore mai usata, una voce costruita per attirare chi, dopo essere entrato, cerca privilegi e percorsi. Tecniche di attacco all’identità come il furto di credenziali dal sistema operativo, il Kerberoasting o il Pass-the-Hash, catalogate nel framework MITRE ATT&CK, si tradiscono nel momento in cui toccano l’esca. Una rete di account e breadcrumb falsi, disseminata sui sistemi e nelle directory aziendali, intercetta il movimento laterale che gli strumenti di protezione degli endpoint spesso non vedono, perché quel movimento usa credenziali vere su canali leciti. L’intruso non sbaglia un comando: sbaglia bersaglio, e nel farlo si rivela.
Dalla trappola al framework: MITRE Engage
Disseminare esche a caso non è una strategia. Perché la deception diventi disciplina serve un metodo, e dal 2022 esiste un riferimento condiviso: MITRE Engage, un framework per pianificare attività di inganno, negazione e ingaggio dell’avversario, nato in sostituzione del precedente MITRE Shield e pensato come contraltare difensivo del catalogo ATT&CK. Alla base di un buon inganno c’è una logica di progettazione a ritroso, principio classico della deception: si parte da cosa si vuole che l’avversario faccia, si determina cosa deve pensare per farlo, e si costruisce ciò che deve vedere perché lo pensi. Engage traduce questo principio in un metodo operativo, organizzando il lavoro in un processo a tre fasi, preparare, operare e comprendere, e in una matrice di obiettivi che va dall’esporre l’avversario all’elicitarne le tecniche, fino a comprenderne le mosse. L’esca smette così di essere un trucco isolato e diventa parte di uno scenario progettato, con un fine dichiarato: osservare l’attaccante, fargli perdere tempo, alzare il costo della sua operazione.
I limiti, perché la trappola va curata
Sarebbe disonesto presentare l’inganno come una soluzione senza costi. Una trappola mal fatta è inutile o controproducente: un decoy palesemente finto non inganna nessuno, e un’esca dimenticata genera confusione invece che segnale. La deception richiede realismo e manutenzione, perché gli ambienti cambiano e le esche devono restare credibili. Va inoltre governata con attenzione anche giuridica, perché la linea tra osservare un intruso e indurlo deliberatamente all’azione non è sempre netta. E va ricordato un punto di fondo: un honeytoken rileva, non previene. È un sensore, non una barriera, e ha senso dentro una difesa che intorno ha già le sue mura.
Resta il fatto che poche tecniche di rilevamento migliorano man mano che gli attacchi diventano più silenziosi. L’honeytoken è una di queste, perché non si fonda sul riconoscere l’attaccante, cosa sempre più difficile, ma su un fatto che non cambia: nessuno che abbia diritto di stare lì ha motivo di toccare l’esca. In un panorama in cui gli intrusi si muovono con credenziali legittime e senza lasciare codice da analizzare, una trappola che produce un allarme quasi sempre vero non è un espediente nostalgico da manuale di sicurezza, è uno dei pochi modi per trasformare il silenzio dell’attaccante moderno nel suo unico, rivelatore, passo falso.
