사건 지표로서의 DNS 변경
사이버 사건 발생 시, DNS 기록의 변경은 원인이자 증상일 수 있습니다. 변경된 MX 기록은 비즈니스 이메일 침해(BEC)의 일환으로 조직의 수신 메일을 공격자가 제어하는 서버로 리디렉션할 수 있습니다. 변경된 NS 또는 A 기록은 도메인 등록기관 계정이 침해되어 공격자가 도메인 전체를 재지정했음을 나타내는 징후일 수 있으며, 때로는 공격자가 제어하는 인프라에서 악성코드 또는 가짜 로그인 페이지를 제공하는 데 사용될 수 있습니다. 다른 경우에는 DNS 자체가 공격 벡터가 아니었음에도 불구하고 DNS 증거가 사건 발생 당시 어떤 인프라가 사용되었는지 재구성하는 데 도움을 줍니다.
DNS 타임라인 구축
사건이 의심되는 즉시 DNS 기록을 최대한 빨리 수집하십시오. 공격자가 기록을 다시 변경하거나 합법적인 관리자가 본격적인 조사를 시작하기 전에 수정할 수 있기 때문입니다. 사용 가능한 경우, 조직 자체가 저장한 이전 스냅샷(예: 이전 모니터링 결과 또는 구성 백업)과 비교하여 정확히 어떤 기록이 변경되었고 대략 언제 변경되었는지 파악하고, DNS TTL 값과 사용 가능한 변경 로그 또는 등록기관 감사 추적을 타이밍의 보조 증거로 활용하십시오.
DNS 타임라인을 다른 사건 증거와 교차 참조하십시오: 메일이 다른 서버로 도착하기 시작한 시점을 보여주는 이메일 헤더, 도메인에 대한 새 인증서가 발급된 시점을 보여주는 인증서 투명성 로그, 트래픽 패턴이 변경된 시점을 보여주는 서버 또는 애플리케이션 로그. DNS 증거는 단독으로 사용되기보다 이러한 다른 출처와 일치하거나 상충될 때 가장 유용합니다.
등록기관 및 레지스트리 수준 증거
DNS 기록 자체 외에도, RDAP 등록 데이터는 도메인의 등록기관, 네임서버 또는 등록자 연락처가 비슷한 시기에 변경되었는지 여부를 보여줄 수 있으며, 이는 단일 DNS 존 파일에 국한된 문제라기보다는 등록기관의 계정 수준 침해를 시사합니다. clientTransferProhibited와 같은 상태 코드가 무단 전송 직전에 제거되는 것은 레지스트리 데이터에서 확인할 가치가 있는 특정 패턴입니다.
대응 및 복구를 위한 문서화
모든 DNS 및 RDAP 관찰 내용을 타임스탬프 및 출처와 함께 사건 기록의 일부로 기록하십시오. 이러한 증거는 종종 등록기관, 호스팅 제공업체, 법 집행 기관 또는 사이버 보험 제공업체와 공유해야 할 수 있으며, 이들은 무엇이 언제 변경되었는지에 대한 구체적인 정보를 요구할 수 있습니다. 올바른 레코드를 복원하는 것은 운영상의 대응 단계이며, 잘못된 레코드에 대한 증거 수집과는 별도로 문서화되어야 합니다.
- 사고 의심 즉시 현재 DNS 및 RDAP 기록을 캡처합니다.
- 무엇이 변경되었는지 파악하기 위해 이전에 저장된 스냅샷과 비교합니다.
- 이메일 헤더, 인증서 발급 및 서버 로그와 교차 참조하십시오.
- DNS 기록뿐만 아니라 등록기관 수준의 상태 코드와 연락처 변경 사항을 확인하십시오.
- 증거 수집은 복구 조치와 분리하십시오.