インシデント指標としてのDNS変更
サイバーインシデント中、DNSレコードの変更は原因にも症状にもなり得ます。変更されたMXレコードは、ビジネスメール詐欺の一環として、組織の受信メールを攻撃者が管理するサーバーにリダイレクトする可能性があります。変更されたNSまたはAレコードは、ドメインレジストラアカウントが侵害され、攻撃者がドメイン全体を再ポイントし、場合によってはマルウェアや偽のログインページを自らが制御するインフラストラクチャから提供している兆候である可能性があります。その他のケースでは、DNS自体が攻撃ベクトルではないにもかかわらず、DNSの証拠がインシデント発生時にどのインフラストラクチャが使用されていたかを再構築するのに役立つことがあります。
DNSタイムラインの構築
インシデントが疑われたら、できるだけ早くDNSレコードを収集します。完全な調査が開始される前に、攻撃者によってレコードが元に戻されたり、正当な管理者によって修正されたりする可能性があるためです。利用可能な場合は、組織自体が保存していた以前のスナップショット（以前の監視結果や構成バックアップなど）と比較し、DNS TTL値と利用可能な変更ログまたはレジストラの監査証跡をタイミングの裏付け証拠として使用して、具体的にどのレコードが変更されたか、おおよそいつ変更されたかを特定します。
DNSのタイムラインを他のインシデント証拠と相互参照する: メールが別のサーバーに届き始めた時期を示すメールヘッダー、ドメインの新しい証明書が発行された時期を示す証明書の透明性ログ、トラフィックパターンが変化した時期を示すサーバーまたはアプリケーションのログ。DNSの証拠は、単独で存在するよりも、これらの他の情報源と矛盾しない、あるいは矛盾する場合に最も有用である。
レジストラおよびレジストリレベルの証拠
DNSレコード自体に加えて、RDAP登録データは、ドメインのレジストラ、ネームサーバー、または登録者の連絡先が同時期に変更されたかどうかを示すことができ、これは単一のDNSゾーンファイルに限定された問題ではなく、レジストラにおけるアカウントレベルの侵害を示唆するでしょう。clientTransferProhibitedなどのステータスコードが不正な移転の直前に削除されるのは、レジストリデータで確認する価値のある特定のパターンです。
対応と復旧のための文書化
DNSおよびRDAPのすべての観測結果を、そのタイムスタンプと情報源とともにインシデント記録の一部として記録してください。この証拠は、レジストラ、ホスティングプロバイダー、法執行機関、またはサイバー保険会社と共有する必要がある場合が多く、それぞれが「何が、いつ変更されたのか」について具体的に尋ねる可能性があるためです。正しいレコードへの復元は運用上の対応ステップであり、誤ったレコードが何であったかという証拠収集とは別に文書化されるべきです。
- インシデントの疑いがある場合、直ちに現在のDNSおよびRDAPレコードをキャプチャします。
- 何が変更されたかを特定するために、以前に保存されたスナップショットと比較する。
- メールヘッダー、証明書発行、サーバーログと相互参照する。
- DNSレコードだけでなく、レジストラレベルのステータスコードや連絡先変更も確認します。
- 証拠収集は修復ステップとは別に保管してください。