서브도메인 테이크오버와 DNS 하이재킹

Wed Dec 03 2025•Domain Security

도메인이란 웹사이트에 엑세스 하는 데 사용되는 고유하고 기억하기 쉬운 주소이다.

처음에는 나만의 블로그나 이메일 주소를 가지고 싶어서 사용하게 되었고 별다른 설정 없이 정말 주소만 연결해서 오 된다! 가 끝이었다. 도메인에서 발생할 수 있는 문제 상황도 결제를 놓쳐서 도메인을 뺏기게 되거나 비슷한 도메인을 사서 피싱 사이트를 운영할 수 있다는 것 밖에 모르고있었다.

정말 내가 해킹과 비슷한 일을 당할 줄은 몰랐다. (사실은 해킹도 아니었다)

다행이었던 점은 도메인에 서버나 다른 서비스 연결해둔게 있었으면 엄청난 과금이 발생할 수도 있었는데. 그런 것 없이 안 써서 방치해뒀던 도메인에 발생한 일이어서 눈물 날 일도 없었고, 어느정도 경험으로 치부하고 넘어갈 수 있었다.

1. 나도 모르는 사이트로 접속되는 내 도메인

도메인에 문제가 생겼다는 것을 알게 된 것은 보잘것 없는 내 블로그를 심심할 때 마다 구경하는 친구의 제보를 통해서 였다.

깃허브 블로그를 배포해볼까 해서 전에 사용했었던 도메인이고 블로그를 바꾸면서 레포지토리를 비공개로 돌려놔서(이 부분이 바로 문제의 원인이다) 도메인 주소를 입력해도 아무런 사이트가 뜨지 않아야 정상이었다. 그런데 내 도메인 주소를 입력하면 다른 사람의 사이트로 접속이 되는 상황이 발생했다.

이런 상황을 뭐라고 부르는지 찾아보니 DNS 하이재킹이라는 게 있다는 것을 알게되었다. 현재 내 도메인의 가장 큰 문제는 가짜 웹 사이트로 사용자를 전송 한다는 점이었다.

일단 아무것도 모르는 상태였고, 현재 사용하지 않고 있는 도메인이어서 빠르게 DNS 를 전부 삭제했다.
삭제 직후에는 피싱 사이트에 접속이 되었지만 조금 시간이 지나고 피싱 사이트 접속이 막혔다.

자세히는 모르지만 DNS는 캐시 시스템이기 때문에 잠시동안 살아있었다라는 것 같다. DNS의 캐시 시스템에 대해서도 이후 공부해야 할 것 같다.

2. 원인 분석

25/11/24: 마지막으로 깃블로그 커밋
25/11/25: 레포지토리 비공개로 변경
25/12/03: 피싱 사이트 접속 발견
25/12/03: DNS 레코드 전체 삭제

정확한 깃블로그 레포지토리 비공개 변경한 날짜를 확인하기 위해서 깃허브 로그를 찾아봤다.

로그 확인 하는 법

깃허브 계정 > Settings > Archives > Security log
(Filters: Repository management 설정한 후 확인하면 빠르게 찾을 수 있다)

레포지토리 비공개 후 피싱사이트 연결 확인까지의 간격은 8일 이라는 것을 알 수 있었고
그 사이에 어떤 일이 벌어졌는지 확인해보기로 했다.

1. Cloudflare 계정 침해 여부 확인

프로필 > 활성 세션 에서 다른 장치의 로그인 확인
-> 내 기기를 제외하고 다른 기기의 활성 장치는 없었다.
프로필 > API 토큰 에서 토큰 확인
-> API 토큰을 발급한 적이 없어서 내가 발급 안 한 토큰이 없는지 확인했고 토큰은 비어있었다.
계정 홈 > 계정 관리 > 감사 로그 에서 로그 확인
-> 남아있는 로그에서 내가 한게 아닌 활동을 찾아봤다. 터미널에서 curl ifconfig.me 명령어를 통해 내 ip를 확인 한 후에 내 ip와 일치하지 않으면서 시스템이 작업한 활동이 아닌 것으로 필터링을 했다.

결과적으로 actor의 ip가 아예 안 남아 있는 것과 Cloudflare 의 ip가 있었다. Cloudflare의 ip에 대해서는 https://www.cloudflare.com/ko-kr/ips/ (opens in a new tab) 여기에서 확인 가능하다. 필터링 이후에 확인가능한 로그에는 작업 유형이 view 밖에 없었고 누군가 내 계정에 접속하거나, 무언가 변경했다는 증거를 찾을 수 없었다.

2. DNS 변경 확인

이미 DNS를 모두 삭제해둔 상태라서 DNS > Records 에서는 원본 IP에 변경이 있었는지를 확인 할 수 없었고, 아까전 감사 로그에서 DNS 변경이 있었는지를 같이 확인했다.

3. 트래픽 이상 징후 확인

DNS Query 로그를 분석하는 방법이 있다. DNS > Analytics 에서 확인이 가능하나 조회를 하는 당일을 기준으로 이전 일주일의 기록만 남아있었다. 이미 다른 사이트 연결을 확인하고 차단한지 일주일이 넘게 지났고 DNS만 삭제해놓고 해결 됐으니까 나중에 알아봐야지 했다가 데이터를 찾을 수 없게 되었다. 다음에 비슷한 일이 발생한다면 빠르게 확인하고 데이터를 다운받아 놓아야 된다는 것을 알게 되었다.

4. Page Rules / Cloudflare Workers 확인

라우팅 규칙으로 트래픽을 가로챌 수도 있다고 한다. 확인해보니 별다른 설정이 없었다.

5. 상위 등록기관 및 NS 설정 확인

dig +short NS domain.com으로 DNS의 네임서버 확인를 확인 할 수 있다. 결과가 Cloudflare가 지정해준 네임 서버가 아니면 도메인 등록기관 계정이 탈취되었을 수 있다고 한다. Cloudflare의 네임서버는 https://developers.cloudflare.com/dns/nameservers/ (opens in a new tab) 에서 확인 가능하다. 기본적으로 <proper_name>.ns.cloudflare.com 패턴을 따른다고 한다. 확인 결과 별 다른 문제점을 찾을 수 없었다.

3. 결론

DNS 레코드 변경 이력 없음 + 감사 로그 이상 없음 + 계정 안전함 + dig 조회 결과 정상
=> 해킹 아님

해킹 같은 거창한건 아니었고 블로그를 꺼놨는데 DNS를 안 지워서
목적지가 없는 도메인이 다른 서비스에 재점유 된 상황.

도메인 dangling / 서브 도메인 테이크오버가 발생 한 것 같다는 결론이 나왔다.

11/25: GitHub 레포지토리 비공개 전환
       └─ 깃페이지 블로그 배포 중단
       └─ 하지만 Cloudflare DNS는 그대로 깃페이지 블로그를 가리킴

       [ 8일간 dangling DNS 상태 ]

dangling DNS는 더 이상 유효하지 않은 서비스를 가르키는 DNS 레코드를 말하고, 서브도메인 테이크오버란 도메인에 대한 트래픽을 악의적인 활동을 수행하는 사이트로 리다이렉션 하는 것이다.

dangling DNS는 취약점이고 이러한 취약점에서 발생하는 문제가 서브도메인 테이크오버이다.
이것이 의도적인 공격인지, 아니면 단순히 같은 리소스 이름을 우연히 사용한 것인지는 알기 힘들다.

Dangling DNS vs 서브도메인 테이크오버

# Dangling DNS (취약점)
 
- DNS 레코드가 존재하지 않는 리소스를 가리킴
- 보안 위험은 있지만 아직 악용되지 않은 상태
 
<< 위의 취약점을 악용해서 발생 >>
 
# 서브도메인 테이크오버 (공격/사고)
 
- 공격자가 삭제된 리소스를 재생성
- 피해자의 도메인이 공격자의 콘텐츠를 표시

왜 이런 일이 가능한가?

사용자가 리소스를 삭제해도 DNS는 자동으로 정리되지 않음
같은 리소스 이름을 다른 사람이 재사용 가능
DNS 소유권은 확인하지 않음 (누구든 리소스만 만들면 연결됨)

깃페이지 블로그 예시:
1. 레포지토리를 비공개로 전환 → 깃페이지 블로그 배포 중단
2. DNS는 여전히 깃페이지 블로그를 가리킴
3. 누군가 같은 이름으로 리소스 생성
-> 누군가 만든 리소스로 연결!

진짜 해킹과의 차이점

DNS 하이재킹 (해킹):
✗ 공격자가 DNS 관리 계정을 탈취
✗ DNS 레코드를 직접 변경
✗ 감사 로그에 접근 기록 남음

서브도메인 테이크오버 (내 케이스):
✓ DNS 계정은 안전함
✓ DNS 레코드는 변경되지 않음
✓ 단지 DNS가 가리키는 "목적지"를 누군가 차지함
✓ 내 실수(DNS 미정리)가 원인

4. 해결 방법

DNS 영역에서 더 이상 프로비전 되지 않는 리소스의 FQDN을 가르키는 모든 CNAME 레코드를 제거.
잘못되었거나 의심스러운 DNS 레코드가 있는 경우 원래 값으로 복구 또는 삭제한다.

5. 방지 방법

1. DNS 하이재킹 방지 방법

로그인 강화 (2단계 인증)
- 내 프로필 > 인증 > 2단계 인증 설정한다.
브라우저 보안 규칙 업데이트
- TLS 인증서 출처 조사, 사용하는 도메인과 일치하는 출처에서 발급되었는지 확인한다.
DNSSEC 활성화 (Domain Name System Security Extensions)
- 게시된 DNS 레코드의 암호화 서명을 사용하여 위조된 DNS 응답으로부터 도메인을 보호한다.
- DNS 캐시 포이즈닝을 방지하기 위한 방법이다.
DNS가 변경됐을 때 알림이 오게 설정한다.

2. 서브도메인 테이크오버 방지 방법

DNS 레코드가 사용할 수 없는 리소스를 가리키는 경우 레코드 자체를 DNS 영역에서 제거해야 한다.
잘못되었거나 오래된 하위 도메인 참조를 업데이트 한다.
탐지 서비스 이용 (정기적인 DNS 스캔)
- Cloudflare의 보안 서비스를 활용하는 방법이나, Microsoft Defender 같은 서비스를 이용하면 미사용 DNS 탐지를 자동으로 해준다. 이외에도 자동화 도구를 이용할 수 있다.

6. 발생할 수 있는 피해

DNS 하이재킹과 서브도메인 테이크오버의 경우에는 비슷한 피해가 발생하는 것으로 보인다. 악성 페이지 및 서비스를 호스팅함으로써 발생하는 여러가지 상황들이 있다.

하위 도메인의 콘텐츠에 대한 제어 상실
사용자의 쿠키 수집
피싱 이메일
로그인 정보 탈취

7. 피해를 받았을 때

현재 사용하고 있지 않은 도메인이기도 했고 친구 이외에 도메인 주소를 공유한 적이 없었기 때문에 별다른 2차 피해를 걱정할 필요가 없었지만, 실제 서비스를 하고 있던 웹사이트에서 이런 일이 발생한다면 정말 로그 분석이 중요하고 빠르게 이루어져야 한다는 것을 알게 되었다. 내가 의도한 사이트가 아닌 곳에 접속을 하게 된 사람들이 몇명이나 있는지, 어떤 사람들이 다른 곳으로 접속을 했는지에 대해서 피해 규모를 확인하고 대처를 해야하는 것을 상상하니까 너무나도 막막하게 느껴진다.

정말 DNS 하이재킹이 발생했을 때에 어떻게 해야할지에 대해 정리해봤다.

1. DNS 레코드 복구
   - 변조된 레코드 복구
   - 의심스로운 레코드 삭제
2. 계정 보안 강화
   - 비밀번호 변경
   - 2차 인증 활성화 및 교체
   - 활성 세션 전체 로그아웃
   - API 토큰 재발급
3. 영향 범위 파악
   - DNS Analytics에서 로그 다운로드
   - 접속자 수 확인 및 피해 사용자 파악
4. 피해 조사
   - 로그 분석으로 정확한 공격 시작/종료 시점 파악
   - SSL/TLS 인증서 확인
5. 피해 입은 사람들에게 공지 및 안내
6. 이외에 개인정보 유출 및 대응이 필요한 경우 신고 조치

8. 비슷한 경우

도메인 스푸핑, DNS 캐시 포이즈닝

9. 정리

DNS 하이재킹의 경우 해커의 악의적인 공격에 의해서 DNS 레코드가 변경된 것이고, 현재 내 도메인에서 발생한 서브도메인 테이크 오버의 경우는 공격일수도 있고, 실수나 자동으로 그렇게 될 가능성이 있다.

사용하지 않는 서비스를 내리면 DNS 레코드도 함께 삭제해야 한다는 것과 중요한 로그는 즉시 백업해야 한다는 점, 정기적으로 DNS 점검을 해줘야 한다는 것을 배우게 되었다. 단순히 누군가의 악의적인 공격이 아니라 나의 안일한 생각이 보안 이슈를 일으킬 수 있다는 점에서 세상에 공부할 것이 정말 많다는 것도 다시 한 번 깨닫는다.

해킹이 아니라서 정말 다행이었고 이번 기회에 도메인에 대한 공부와 보안 강화를 조금 진행 할 수 있었다. 하지만 Cloudflare의 서비스 자체에 대한 아쉬움이 조금 남는다. 보안을 설정할 수 있는 부분이 굉장히 다양하지만 어떤 서비스가 유료인지에 대한 정보를 직관적이게 알 수 없어서 서비스를 설정하기 전에 알아볼게 많다. 내가 아직 Cloudflare에 익숙해지지 않아서 그런 것일수도 있다.

이외에도 DNS 쿼리 통계를 보면서 궁금했던 점
현재 사용하고 있는 도메인 중 bgk.dev와 kimbogyeong.com의 트래픽 차이가 심한데 원인이 뭘지

참고
cloudflare - DNS 하이재킹 (opens in a new tab)
Microsoft Learn - 서브도메인 테이크오버 (opens in a new tab)
PaloAlto Networks - Dangling DNS (opens in a new tab)