Honeypot, Honeynet, Honeyfile, Honeytoken - Deception Technologies

Cosa fa

#

Le deception technologies sono esche informatiche che simulano sistemi e dati reali per attirare gli attaccanti, deviandoli dai target reali e permettendo di osservarne le tecniche in ambiente controllato.

TL;DR

#

1. Honeypot: server esca che sembra vulnerabile. Ogni connessione in entrata e' sospetta per definizione.
2. Honeynet: rete di honeypot che simula un'intera infrastruttura. Osserva il lateral movement.
3. Honeyfile: file con nome invitante (passwords.txt). Aperto una volta = alert critico.
4. Honeytoken: credenziale o record falso inserito tra dati reali. Se usato = dati gia' esfiltrati.
5. Nessun dato reale in un honeypot: i dati sono bogus (fabbricati), la loro divulgazione e' harmless.
6. Principio: "Conosci il tuo nemico" (Sun Tzu). Osservare per capire le TTP dell'attaccante.

Honeypot

#

Un honeypot e' un sistema intenzionalmente apparente come vulnerabile o prezioso, progettato per attirare l'attenzione di un attaccante e permettere al team SOC di osservarne le tecniche in sicurezza. A differenza dei sistemi di produzione, non ha traffico legittimo: ogni connessione in entrata e' anomalia.

flowchart LR
    ATK([Attaccante]) -- "Scansione / Attacco" --> H["Honeypot
(Server Esca)"]
    H -. "Alert Silenzioso" .-> SOC((Team SOC))
    PROD[(Rete Reale)] -. "Isolata dal Honeypot" .-> SAFE[" "]

    style H fill:#f57f17,stroke:#fbc02d,stroke-width:2px,color:#fff
    style SOC fill:#1a365d,stroke:#3182ce,color:#fff
    style SAFE fill:none,stroke:none

Come funziona: l'attaccante trova un server apparentemente vulnerabile. Ha qualche protezione (abbastanza da sembrare realistico - un server completamente aperto insospettirebbe un esperto). Mentre esplora, il team SOC osserva in tempo reale: quali porte scansiona, quali exploit tenta, quali tool usa.

Honeynet

#

Una honeynet e' un gruppo di honeypot in un segmento di rete separato ma raggiungibile, che simula un'intera infrastruttura. Un solo server fisico ospita piu' VM, ognuna con il suo OS e applicazioni. Dal punto di vista della rete, l'attaccante vede sistemi distinti e si muove tra loro credendo di essere in una rete reale.

flowchart TB
    ATK([Attaccante]) -- "Infiltra e Lateral Movement" --> PHY
    subgraph PHY ["Server Fisico Singolo"]
        direction LR
        VM1["VM1
Web Server
(esca)"] <--> VM2["VM2
Database
(esca)"] <--> VM3["VM3
File Server
(esca)"]
    end
    PHY -. "Ogni movimento registrato" .-> SOC((SOC))

    style PHY fill:#37474f,stroke:#607d8b,stroke-width:2px,color:#fff
    style VM1 fill:#f57f17,stroke:#fbc02d,color:#fff
    style VM2 fill:#f57f17,stroke:#fbc02d,color:#fff
    style VM3 fill:#f57f17,stroke:#fbc02d,color:#fff
    style SOC fill:#1a365d,stroke:#3182ce,color:#fff

Honeyfile

#

Un honeyfile e' un documento progettato per attirare l'intruso tramite il nome. L'atto di aprirlo o copiarlo attiva immediatamente un alert sul sistema di monitoraggio. La trappola non e' il contenuto (puo' essere vuoto) ma l'accesso al file stesso.

flowchart LR
    ATK([Attaccante]) -- "Esplora cartelle e apre" --> F["passwords.txt
(Honeyfile)"]
    F -. "Event ID 4663
Trigger Alert!" .-> SOC((Team SOC))

    style F fill:#f57f17,stroke:#fbc02d,stroke-width:2px,color:#fff
    style SOC fill:#1a365d,stroke:#3182ce,color:#fff

Honeytoken

#

Un honeytoken e' un record falso inserito in un sistema di produzione reale, indistinguibile dai dati legittimi. A differenza dell'honeyfile (che rileva l'accesso), l'honeytoken rileva l'esfiltrazione dei dati: il token "tradisce" il ladro quando viene usato fuori.

flowchart LR
    DB[(Database REALE
con honeytoken embedded)] -- "Esfiltrazione dati" --> ATK([Attaccante])
    ATK -- "Usa email finta per spam" --> T["finto_admin@azienda.com
(Honeytoken)"]
    T -. "Riceve email → Breach CERTO" .-> SOC((Team SOC))

    style DB fill:#1a365d,stroke:#3182ce,color:#fff
    style T fill:#f57f17,stroke:#fbc02d,stroke-width:2px,color:#fff
    style SOC fill:#1a365d,stroke:#3182ce,color:#fff

L'email vergine non puo' ricevere messaggi per nessun altro motivo: non e' pubblicata, non e' registrata da nessuna parte, non esiste fuori dal DB. Un messaggio su quella inbox ha una sola spiegazione possibile.

Confronto

#

Scenario Reale

#

Un'azienda sospetta di avere un insider che sta estraendo dati dal CRM. Il SOC inserisce:

1. Un honeyfile stipendi_direzione_2026.xlsx nella cartella condivisa del reparto contabilita' (FIM + alert su accesso)
2. Un honeytoken (email backup-notificazioni@azienda.com) nel database dei fornitori

Tre settimane dopo, l'email vergine riceve un messaggio di marketing. Il SOC ha conferma che il DB fornitori e' stato esfiltrato. Confrontando il timestamp dell'accesso al honeyfile con i log di accesso VPN si identifica la sessione sospetta.

Dev parallel: una "sentinel" API key con valore impossibile (DEADBEEF-0000-0000-0000-HONEYPOT) e un webhook che scatta quando viene usata in una request. Se il valore impossibile appare nei log di produzione, il codice sorgente e' stato rubato. Stessa logica dell'honeytoken: il token tradisce il ladro nel momento in cui viene usato.

Collegato a

#

• ids-ips - sistema di rilevamento complementare alle deception tech
• siem-soar - i SIEM raccolgono gli alert da FIM e honeytoken
• lateral-movement - cio' che la honeynet e' progettata per osservare