Changements DNS comme indicateurs d'incident
Lors d'un incident cyber, les modifications des enregistrements DNS peuvent être à la fois une cause et un symptôme. Un enregistrement MX modifié peut rediriger les courriels entrants d'une organisation vers un serveur contrôlé par un attaquant dans le cadre d'une compromission de messagerie professionnelle (BEC). Un enregistrement NS ou A modifié peut être le signe qu'un compte de bureau d'enregistrement de domaine a été compromis et que l'attaquant a redirigé le domaine entièrement, parfois pour diffuser des malwares ou une fausse page de connexion depuis l'infrastructure qu'il contrôle. Dans d'autres cas, les preuves DNS aident simplement à reconstituer l'infrastructure utilisée au moment de l'incident, sans que le DNS lui-même ne soit le vecteur d'attaque.
Établir une chronologie DNS
Collectez les enregistrements DNS dès que possible après la suspicion d'un incident, car les enregistrements peuvent être modifiés par un attaquant ou corrigés par l'administrateur légitime avant le début d'une enquête complète. Lorsque disponibles, comparez-les à toute capture d'écran antérieure que l'organisation elle-même aurait sauvegardée, comme un résultat de surveillance précédent ou une sauvegarde de configuration, afin d'identifier spécifiquement quels enregistrements ont changé et approximativement quand, en utilisant les valeurs de TTL DNS et tout journal de modification ou piste d'audit du bureau d'enregistrement disponible comme preuve de chronologie.
Croiser la chronologie DNS avec d'autres preuves d'incident: les en-têtes de courriel montrant quand le courrier a commencé à arriver sur un autre serveur, les journaux de transparence des certificats montrant quand un nouveau certificat a été émis pour le domaine, et les journaux de serveur ou d'application montrant quand les schémas de trafic ont changé. Les preuves DNS sont plus utiles lorsqu'elles corroborent, ou sont en conflit avec, ces autres sources plutôt que d'être autonomes.
Preuves du registraire et au niveau du registre
Au-delà des enregistrements DNS eux-mêmes, les données d'enregistrement RDAP peuvent montrer si le registraire, les serveurs de noms ou le contact du titulaire du domaine ont changé à peu près au même moment, ce qui indiquerait une compromission au niveau du compte chez le registraire plutôt qu'un problème limité à un seul fichier de zone DNS. Les codes de statut tels que clientTransferProhibited étant supprimés peu avant un transfert non autorisé sont un modèle spécifique qu'il convient de vérifier dans les données du registre.
Documentation pour la réponse et le rétablissement
Enregistrez chaque observation DNS et RDAP avec son horodatage et sa source dans le cadre du dossier d'incident, car cette preuve doit souvent être partagée avec le bureau d'enregistrement, le fournisseur d'hébergement, les forces de l'ordre ou un assureur cybernétique, chacun d'eux pouvant demander des détails précis sur ce qui a changé et quand. La restauration des enregistrements corrects est une étape de réponse opérationnelle et doit être documentée séparément de la collecte de preuves des enregistrements incorrects.
- Capturer les enregistrements DNS et RDAP actuels immédiatement en cas de suspicion d'incident.
- Comparez avec toute capture d'écran précédemment sauvegardée pour isoler ce qui a changé.
- Vérifier en croisant avec les en-têtes d'e-mail, l'émission de certificats et les journaux de serveur.
- Vérifiez les codes de statut au niveau du bureau d'enregistrement et les modifications de contact, pas seulement les enregistrements DNS.
- Maintenez la collecte de preuves séparée des étapes de correction.