Modifiche DNS come indicatori di incidente
Durante un incidente informatico, le modifiche ai record DNS possono essere sia una causa che un sintomo. Un record MX modificato può reindirizzare la posta in arrivo di un'organizzazione a un server controllato dall'attaccante come parte di una compromissione della posta elettronica aziendale (BEC). Un record NS o A modificato può essere un segno che un account del registrar del dominio è stato compromesso e l'attaccante ha reindirizzato completamente il dominio, a volte per distribuire malware o una falsa pagina di accesso da un'infrastruttura che controlla. In altri casi, le prove DNS aiutano semplicemente a ricostruire quale infrastruttura fosse in uso al momento dell'incidente, senza che il DNS stesso fosse il vettore di attacco.
Costruire una cronologia DNS
Raccogli i record DNS il prima possibile una volta che si sospetta un incidente, poiché i record possono essere modificati dall'attaccante o corretti dall'amministratore legittimo prima che inizi un'indagine completa. Se disponibile, confronta con qualsiasi snapshot precedente che l'organizzazione stessa aveva salvato, come un risultato di monitoraggio precedente o un backup di configurazione, per identificare specificamente quali record sono cambiati e approssimativamente quando, utilizzando i valori TTL DNS e qualsiasi registro modifiche o audit trail del registrar disponibile come prova a supporto della tempistica.
Confrontare la cronologia DNS con altre prove dell'incidente: intestazioni di email che mostrano quando la posta ha iniziato ad arrivare a un server diverso, log di trasparenza dei certificati che mostrano quando un nuovo certificato è stato emesso per il dominio, e log del server o dell'applicazione che mostrano quando i pattern di traffico sono cambiati. Le prove DNS sono più utili quando corroborano, o sono in conflitto con, queste altre fonti piuttosto che essere considerate da sole.
Registrar e prove a livello di registro
Al di là dei record DNS stessi, i dati di registrazione RDAP possono mostrare se il registrar, i nameserver o il contatto del registrante del dominio sono cambiati nello stesso periodo, il che indicherebbe una compromissione a livello di account presso il registrar piuttosto che un problema limitato a un singolo file di zona DNS. Codici di stato come clientTransferProhibited rimossi poco prima di un trasferimento non autorizzato sono un modello specifico da verificare nei dati di registro.
Documentare per la risposta e il recupero
Registrare ogni osservazione DNS e RDAP con la relativa data e ora e la fonte come parte del registro dell'incidente, poiché queste prove spesso devono essere condivise con il registrar, il fornitore di hosting, le forze dell'ordine o un fornitore di cyber assicurazioni, ognuno dei quali potrebbe richiedere dettagli specifici su cosa è cambiato esattamente e quando. Il ripristino dei record corretti è una fase di risposta operativa e dovrebbe essere documentato separatamente dalla raccolta probatoria di quali fossero i record errati.
- Catturare immediatamente i record DNS e RDAP correnti al sospetto di un incidente.
- Confronta con qualsiasi snapshot precedentemente salvato per isolare le modifiche.
- Confrontare con le intestazioni delle email, l'emissione dei certificati e i log del server.
- Controlla i codici di stato a livello di registrar e le modifiche dei contatti, non solo i record DNS.
- Mantenere la raccolta delle prove separata dalle fasi di bonifica.