소개
도메인 네임 시스템 (DNS) 정보 수집은 사이버 보안의 정찰 단계에서 가장 중요한 첫 번째 단계입니다. DNS 는 인터넷의 전화번호부 역할을 하며, 사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환합니다. 보안 전문가는 DNS 레코드를 쿼리함으로써 메일 서버, 서브도메인, 보안 설정 등 대상의 인프라에 대한 방대한 정보를 파악할 수 있습니다.
DNS 는 단순히 하나의 엔드포인트가 아닌 인프라 간의 관계를 드러내기 때문에 정찰 과정에서 매우 가치가 높습니다. 하나의 도메인을 통해 웹 서버, 메일 제공업체, 인증 토큰, 별칭, 때로는 잊혀진 전체 환경까지 찾아낼 수 있습니다. 이것이 바로 DNS 정보 수집이 평가 범위를 극적으로 확장하는 이유입니다.
이번 실습에서는 host와 dig라는 두 가지 강력한 명령줄 도구를 사용하여 DNS 정찰을 수행하는 방법을 배웁니다. 실습 대상으로는 보안 연구원들이 DNS 쿼리와 영역 전송을 안전하게 연습할 수 있도록 특별히 설계된 취약한 도메인인 zonetransfer.me를 사용합니다. 기본적인 IP 레코드, 메일 서버 세부 정보, 텍스트 레코드를 추출하는 방법을 배우고, 나아가 전체 영역 전송을 시도하여 대상의 DNS 발자취를 완전히 매핑하는 방법을 익히게 됩니다.
기본 IP 레코드 쿼리 (A/AAAA)
이 단계에서는 가장 기본적인 DNS 레코드인 A 및 AAAA 레코드를 검색하는 방법을 배웁니다. A 레코드는 도메인 이름을 IPv4 주소로 매핑하고, AAAA 레코드는 IPv6 주소로 매핑합니다. 이러한 IP 주소를 찾는 것은 대상의 메인 웹 서버가 어디에 호스팅되어 있는지 정확히 파악할 수 있게 해주므로 매우 중요합니다.
도메인과 호스트는 같은 개념이 아니라는 점을 기억하십시오. 도메인 이름은 DNS 상의 레이블이며, IP 주소는 트래픽이 최종적으로 전달되는 위치입니다. 정찰은 종종 이 두 관점 사이를 변환하는 것에서 시작됩니다.
먼저 DNS 조회를 수행하는 간단한 유틸리티인 host 명령어를 사용하겠습니다. 기본 작업 디렉토리인 ~/project에 있는지 확인하십시오.
다음 명령어를 실행하여 대상 도메인에 대한 기본 조회를 수행합니다:
host zonetransfer.me
IPv4 주소와 해당 도메인과 연결된 메일 서버를 보여주는 다음과 유사한 출력을 확인할 수 있습니다:
zonetransfer.me has address 5.196.105.14
zonetransfer.me mail is handled by 10 alt2.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx2.googlemail.com.
zonetransfer.me mail is handled by 10 alt1.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx3.googlemail.com.
zonetransfer.me mail is handled by 0 aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx4.googlemail.com.
zonetransfer.me mail is handled by 20 aspmx5.googlemail.com.
host는 빠른 확인에 유용하지만, dig(Domain Information Groper) 명령어는 훨씬 더 상세한 출력과 유연성을 제공합니다. dig를 사용하여 A 레코드를 구체적으로 요청해 보겠습니다. +short 플래그를 사용하여 IP 주소만 깔끔하게 출력하도록 하겠습니다.
나중에 분석하기 위해 정찰 데이터를 a_records.txt라는 텍스트 파일로 리다이렉트하여 저장합니다. 다음 명령어를 실행하십시오:
dig A zonetransfer.me +short > ~/project/a_records.txt
cat 명령어를 사용하여 방금 생성한 파일의 내용을 확인할 수 있습니다:
cat ~/project/a_records.txt
출력에는 대상 도메인의 IPv4 주소가 표시됩니다. 발견한 내용을 저장하는 것은 정보 수집 과정에서 매우 중요한 습관이며, 이를 통해 시간이 지남에 따라 대상에 대한 포괄적인 프로필을 구축할 수 있습니다.
5.196.105.14
메일 및 텍스트 레코드 쿼리 (MX, TXT)
이 단계에서는 Mail Exchange(MX) 및 Text(TXT) 레코드를 쿼리하여 대상의 인프라를 더 깊이 파헤쳐 보겠습니다.
MX 레코드는 도메인을 대신하여 이메일 메시지를 수신하는 메일 서버를 지정합니다. 이러한 서버를 식별하면 대상이 어떤 타사 이메일 제공업체 (Google Workspace 또는 Microsoft 365 등) 를 사용하는지, 또는 자체 메일 인프라를 호스팅하는지 알 수 있습니다.
TXT 레코드 역시 신뢰 관계를 설명하는 경우가 많아 매우 가치가 있습니다. 예를 들어, 어떤 시스템이 메일을 보낼 수 있는지, 또는 도메인에 대해 어떤 외부 서비스가 검증되었는지 등을 나타냅니다.
dig를 사용하여 대상 도메인의 MX 레코드를 쿼리해 보겠습니다:
dig MX zonetransfer.me +short
우선순위 번호와 함께 메일 서버 목록이 표시됩니다 (번호가 낮을수록 우선순위가 높음):
20 aspmx5.googlemail.com.
10 alt1.aspmx.l.google.com.
10 alt2.aspmx.l.google.com.
20 aspmx2.googlemail.com.
20 aspmx3.googlemail.com.
0 aspmx.l.google.com.
20 aspmx4.googlemail.com.
다음으로 TXT 레코드를 살펴보겠습니다. 관리자는 TXT 레코드를 사용하여 도메인의 DNS 에 임의의 텍스트를 추가합니다. 사이버 보안에서 TXT 레코드는 SPF(Sender Policy Framework) 규칙, DKIM(DomainKeys Identified Mail) 설정 및 다양한 사이트 검증 토큰을 포함하는 경우가 많아 매우 유용합니다. 이를 통해 이메일 발송이 승인된 내부 IP 범위나 도메인과 통합된 타사 서비스를 파악할 수 있습니다.
TXT 레코드를 쿼리하고 결과를 작업 디렉토리의 txt_records.txt 파일에 저장합니다:
dig TXT zonetransfer.me +short > ~/project/txt_records.txt
파일 내용을 확인하여 관리자가 TXT 레코드에 남긴 정보를 확인하십시오:
cat ~/project/txt_records.txt
v=spf1로 시작하는 항목 (이메일 발송 정책 정의) 이나 다양한 검증 문자열을 발견할 수 있습니다. 이 정보는 대상 도메인이 다른 서비스와 맺고 있는 신뢰 관계를 매핑하는 데 도움이 됩니다.
"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
서브도메인 발견 (CNAME)
이 단계에서는 Canonical Name(CNAME) 레코드에 대해 배웁니다. CNAME 레코드는 별칭 이름을 실제 또는 정식 도메인 이름으로 매핑하는 데 사용됩니다. 예를 들어, www.example.com은 example.com을 가리키는 CNAME 일 수 있습니다.
서브도메인을 발견하는 것은 공격 표면을 확장하는 데 중요한 부분입니다. 조직은 메인 웹사이트는 보안을 강화하지만, dev.target.com이나 testing.target.com과 같이 오래되고 잊혀진 서브도메인을 업데이트하거나 보호하는 것을 잊는 경우가 많습니다.
실습 대상에 존재하는 것으로 알려진 특정 서브도메인을 쿼리하여 CNAME 레코드가 어떻게 작동하는지 확인해 보겠습니다. testing.zonetransfer.me를 쿼리하고 결과를 저장합니다.
다음 명령어를 실행하여 CNAME 레코드를 쿼리하고 cname_records.txt에 저장합니다:
dig CNAME testing.zonetransfer.me +short > ~/project/cname_records.txt
이제 방금 생성한 파일을 확인하십시오:
cat ~/project/cname_records.txt
www.zonetransfer.me.와 같은 출력이 표시될 것입니다. 이는 testing.zonetransfer.me가 실제로는 완전히 다른 도메인을 가리키는 별칭에 불과하다는 것을 의미합니다. 이러한 관계를 찾아내면 보안 연구원은 타사 호스팅 제공업체나 대상에 속한 숨겨진 인프라를 발견할 수 있습니다.
DNS 영역 전송 시도
마지막 단계에서는 DNS 영역 전송 (Zone Transfer) 을 시도합니다. 영역 전송 (특히 AXFR 쿼리 유형 사용) 은 DNS 서버가 여러 서버 간에 DNS 데이터베이스를 복제하기 위해 사용하는 메커니즘입니다.
영역 전송은 정당한 관리 기능이 접근 제어가 취약할 때 보안 문제로 변하는 고전적인 사례입니다. 메커니즘 자체는 정상적이지만, 외부인이 전체 데이터를 요청하도록 허용하는 것은 설정 오류입니다.
DNS 서버가 잘못 설정되어 있으면 익명의 사용자가 영역 파일의 전체 복사본을 요청할 수 있습니다. 이는 공격자에게 도메인과 관련된 모든 서브도메인, IP 주소, 레코드에 대한 완전한 지도를 즉시 제공하여 서브도메인을 추측하거나 무차별 대입할 필요를 없애주기 때문에 매우 심각한 보안 취약점입니다.
영역 전송을 시도하려면 먼저 해당 도메인의 권한 있는 네임 서버 (NS) 를 알아야 합니다. NS 레코드를 쿼리해 보겠습니다:
dig NS zonetransfer.me +short
다음과 같이 네임 서버 목록이 출력됩니다:
nsztm1.digi.ninja.
nsztm2.digi.ninja.
이제 네임 서버 (nsztm1.digi.ninja) 를 알았으므로, axfr 레코드 유형을 사용하여 전체 영역 전송을 직접 요청할 수 있습니다. dig 구문은 @ 기호를 사용하여 대상 도메인과 쿼리할 특정 네임 서버를 지정해야 합니다.
다음 명령어를 실행하여 영역 전송을 시도하고 방대한 출력 내용을 zone_transfer.txt에 저장합니다:
dig axfr zonetransfer.me @nsztm1.digi.ninja > ~/project/zone_transfer.txt
명령어가 완료되면 head 명령어를 사용하여 파일의 앞부분을 확인하십시오:
head -n 20 ~/project/zone_transfer.txt
숨겨진 서브도메인, 내부 IP 주소, 관리자가 남긴 다양한 텍스트 메모를 포함하여 도메인의 DNS 레코드가 완전히 덤프된 것을 볼 수 있습니다. 실제 환경에서 열린 영역 전송을 발견하는 것은 정찰 단계를 크게 가속화하는 중요한 발견입니다.
요약
축하합니다! DNS 정보 수집 실습을 성공적으로 완료했습니다.
이번 실습에서는 host 및 dig 명령어를 활용하여 대상 도메인에 대한 수동적 정찰을 수행하는 방법을 배웠습니다. 기본적인 IPv4 주소 (A 레코드) 추출, 메일 인프라 식별 (MX 레코드), 보안 정책 및 타사 통합 확인 (TXT 레코드) 방법을 살펴보았습니다. 또한 도메인 별칭 (CNAME 레코드) 을 추적하여 숨겨진 서브도메인을 발견하는 방법도 익혔습니다. 마지막으로 잘못 설정된 네임 서버를 대상으로 DNS 영역 전송 (AXFR) 을 성공적으로 실행하여, 단 하나의 취약점이 조직의 전체 외부 네트워크 토폴로지를 노출시킬 수 있음을 확인했습니다.
이러한 기술은 외부 네트워크 매핑의 기초를 형성하며, 모의 해킹이나 취약점 평가를 수행하는 모든 사이버 보안 전문가에게 필수적입니다.
