Log del phishing via email

Questo report è un log del phishing a livello di evento: una riga per ogni interazione di simulazione osservata (data, azione, email del destinatario, oggetto, mittente, difficoltà). Mantiene un formato esteso (long-form): non riduce la cronologia di una persona a un unico risultato. La query include gli ultimi 12 mesi di calendario in occurred_after (mezzanotte UTC dello stesso giorno del mese di dodici mesi prima, non una durata di 365 giorni). Configurazione, credenziali, paginazione e nuovi tentativi in caso di limite di frequenza sono gli stessi della guida alla connettività di Power BI / Excel. Aggiungere prima la query condivisa Fn_FetchAll: questo report la richiama per nome.

​

Ambiti della chiave richiesti

Una chiave a cui è stato concesso solo simulation:read non può chiamare l’endpoint degli eventi di reportistica (l’API restituisce 403). Vedere scegliere la granularità corretta.

​

Endpoint di origine

Filtri consentiti nell’elenco degli eventi (qualsiasi altro filtro restituisce 400): limit, page_token, simulation, entity, event_type, occurred_after. Questa famiglia di report è un dataset in anteprima. Consultare lo schema del dataset e le policy sui dati in GET /v1/reporting/datasets e GET /v1/reporting/datasets/simulation_events.

​

Granularità

Una riga per ogni evento di simulazione di reportistica. Una persona che ha aperto e poi cliccato sullo stesso messaggio genera due righe. Gli eventi con entity_id nullo (nessun partecipante attore / destinatario / target) compaiono comunque: email è nullo. La finestra dell’API è ampliata di un minuto; il limite esatto di occurred_at >= WindowStart viene riapplicato in locale, in modo che l’ultimo anno non dipenda dal fatto che il server tratti occurred_after come inclusivo o esclusivo. Budget di richieste: una scansione paginata degli eventi nella finestra, più una scansione delle entità. Impostare sempre limit = "500".

​

Mappatura delle colonne

I nomi delle colonne del formato precedente provengono dall’esportazione del provider precedente. I campi /v1 sono i nomi pubblici dell’API; la query assegna alias ad alcuni di essi per il report.

​

Token di azione

action è il token chiuso di reportistica. La voce precedente “Email Sent” corrisponde a simulation.delivered (delivered è il verbo pubblico; il token sulla rete è simulation.delivered). Campi aggiuntivi mantenuti perché presenti nell’API: sender_domain, full_name, event_id, entity_id, simulation_id, occurred_at, oltre a entity_type e entity_status provenienti dal join delle entità.

​

Differenze rispetto all’esportazione precedente

• L’IP grezzo non è mai disponibile. /v1 non espone l’IP grezzo del client: si tratta di privacy by design, non di una mappatura in sospeso. La query non aggiunge alcuna colonna IP segnaposto.
• Il tipo di dispositivo è derivato, non grezzo. device_type è una classe di dispositivo derivata per gli eventi di clic, invio e segnalazione. I token osservati includono desktop, mobile, tablet e unknown, ma l’emettitore memorizza una stringa libera: trattarla come testo aperto, non come enum chiuso. È null quando l’evento non ha una classe derivata, e la stringa grezza user_agent rimane privata.
• “Email Sent” è simulation.delivered. Utilizzare questo token quando si filtrano o si contano gli invii. Non cercare una stringa email_sent del formato precedente.
• L’email del destinatario è un join, non un campo dell’evento. L’evento di reportistica omette l’email; la query scansiona /entities per compilarla.
• Ultimi 12 mesi di calendario, non una durata di 365 giorni e non l’intera cronologia.
• Formato esteso, non ridotto. Una riga per interazione, non un risultato per persona.

​

Passaggi successivi