서브도메인 탈취(Subdomain Takeover) 방지법

아무도 쓰지 않는 서브도메인이 회사 명의로 피싱에 악용된다

Subdomain Takeover는 잘 알려지지 않은 취약점인데, 버그바운티에서는 Medium~High 심각도로 분류되는 실제 위협이다. 핵심 원리는 간단하다. DNS 레코드는 살아있는데, 그 레코드가 가리키는 서비스는 죽어 있는 상태를 공격자가 가로채는 것이다.

회사가 blog.yourcompany.com → GitHub Pages로 연결하는 CNAME을 만든다
서비스를 그만두면서 GitHub 저장소를 삭제하지만, DNS의 CNAME은 그대로 남긴다
공격자가 동일한 GitHub Pages URL을 등록하면, blog.yourcompany.com이 공격자 페이지를 가리키게 된다

이렇게 방치된 레코드를 댕글링(dangling) DNS 레코드라고 부른다. 문제는 공격자가 이 서브도메인을 손에 넣는 순간, 그 페이지가 여전히 회사의 정식 도메인 아래에서 동작한다는 점이다. 브라우저 주소창에는 회사 도메인이 그대로 찍히고, 유효한 SSL 인증서까지 자동 발급된다. 방문자는 물론이고 백신·평판 필터도 이 사이트를 회사 자산으로 신뢰한다.

공격자가 이걸로 실제 뭘 하는가

서브도메인 하나를 빼앗기는 것이 왜 회사 전체의 문제가 되는지, 실제 악용 시나리오로 보면 명확해진다.

브랜드 피싱: login.yourcompany.com 같은 서브도메인을 탈취해 진짜와 똑같은 로그인 페이지를 올린다. 도메인이 진짜라 피해자는 의심하지 않고 아이디·비밀번호를 입력한다.
세션 쿠키 탈취: 쿠키가 Domain=.yourcompany.com처럼 상위 도메인 범위로 발급됐다면, 탈취한 서브도메인의 자바스크립트로 그 쿠키를 읽어 본 서비스 세션을 그대로 훔칠 수 있다.
OAuth·콜백 우회: 인증 리다이렉트 허용 목록에 *.yourcompany.com이 들어 있으면, 탈취한 서브도메인으로 토큰을 넘겨받아 계정을 탈취한다.
이메일 스푸핑 보강: 회사 명의 서브도메인에서 발송·랜딩이 이뤄지면 스팸 필터와 사용자 모두 속기 쉽다.

SENTRIX 레드팀이 외부 공격 표면을 점검할 때, 이 댕글링 레코드는 가장 먼저 훑는 항목 중 하나다. 코드 취약점처럼 소스를 뜯어볼 필요 없이, DNS 조회 몇 번이면 노출 여부가 드러나기 때문이다. 공격자에게도 그만큼 값싸고 확실한 진입점이라는 뜻이다.

취약한 서비스 유형

Takeover가 가능한 서비스들은 특정 URL 형식으로 응답이 달라진다. 연결이 끊긴 경우 "404 - Repository not found"(GitHub Pages), "NoSuchBucket"(AWS S3), "There is no app configured at that hostname"(Heroku) 같은 특징적인 에러를 반환한다. 이런 고유 에러 문자열을 핑거프린트(fingerprint)라고 부르며, 이걸로 어떤 서비스에서 탈취가 가능한지 판별한다.

탈취 가능 여부는 서비스가 "임의 사용자가 같은 이름을 다시 등록할 수 있게 허용하느냐"에 달려 있다. 대표적으로 위험한 유형은 다음과 같다.

정적 호스팅: GitHub Pages, GitLab Pages, AWS S3 정적 웹사이트, 버킷/저장소 이름만 같으면 누구나 재등록 가능
PaaS: Heroku, Vercel, Netlify, Fly.io, 앱 이름·커스텀 도메인이 비면 선점 가능
SaaS 서브도메인: Shopify, Zendesk, Helpjuice, Webflow, Surge, Tumblr 등 커스텀 도메인 연결형 서비스
CDN: Fastly, 일부 CloudFront 배포 설정, 오리진 연결이 끊긴 배포

어떤 서비스가 위험한지는 커뮤니티가 유지하는 can-i-take-over-xyz 목록에 핑거프린트와 함께 정리돼 있다. 다만 클라우드 사업자들이 계정 확인용 TXT 레코드나 소유권 검증 절차를 도입하면서 상황이 계속 바뀐다. "예전엔 됐는데 지금은 막힌" 서비스도 있으니, 목록을 그대로 믿기보다 실제로 응답을 확인하는 게 정확하다.

CNAME만 문제가 아니다, NS 레코드 탈취

더 치명적인 형태는 댕글링 NS 레코드다. 서브도메인의 네임서버를 특정 DNS 사업자에 위임해 두고, 그 사업자 쪽 존(zone)을 삭제한 뒤 NS 레코드만 남긴 경우다. 공격자가 같은 사업자에서 동일한 존을 만들면, 그 서브도메인의 모든 하위 레코드를 통째로 장악한다. CNAME 탈취가 페이지 하나를 가져가는 거라면, NS 탈취는 서브도메인 트리 전체의 DNS를 넘겨주는 셈이라 파급이 훨씬 크다.

내 도메인 점검 방법

점검은 두 단계다. 먼저 내가 가진 서브도메인을 전부 수집하고, 그다음 각 서브도메인이 죽은 서비스를 가리키고 있는지 확인한다. 대부분의 조직이 첫 단계에서 이미 실패한다, 자기가 몇 개의 서브도메인을 열어뒀는지조차 모른다.

# 서브도메인 목록 수집
subfinder -d yourcompany.com -o subdomains.txt

# 각 서브도메인의 CNAME 확인
while read subdomain; do
    cname=$(dig CNAME $subdomain +short)
    if [ -n "$cname" ]; then
        echo "$subdomain -> $cname"
    fi
done < subdomains.txt

# subjack으로 자동 탐지
./subjack -w subdomains.txt -t 100 -timeout 30 -ssl

수집 단계에서는 subfinder, amass, assetfinder 같은 도구가 인증서 투명성 로그(CT log)·검색엔진·패시브 DNS를 뒤져 잊고 있던 서브도메인까지 찾아준다. 사내 DNS 존 파일을 직접 export 할 수 있으면 그게 가장 정확하다.

탐지 단계에서는 subjack 외에 최신 핑거프린트를 반영한 subzy, 그리고 nuclei의 takeover 템플릿이 널리 쓰인다.

# subzy로 탈취 가능 여부 판정 (최신 핑거프린트)
subzy run --targets subdomains.txt --concurrency 50

# nuclei 템플릿으로 스캔
nuclei -l subdomains.txt -t http/takeovers/

도구 없이 브라우저로 직접 확인하기

전용 도구가 없어도 의심 서브도메인 하나는 직접 검증할 수 있다. 절차는 단순하다.

dig CNAME 서브도메인 +short로 어떤 외부 서비스를 가리키는지 본다 (예: xxxx.github.io., yyyy.s3.amazonaws.com.).
브라우저로 그 서브도메인에 직접 접속한다.
정상 콘텐츠 대신 "404 - There isn't a GitHub Pages site here", "NoSuchBucket", "no such app" 같은 서비스 제공자의 기본 에러 화면이 뜨면 댕글링 상태다, 탈취 후보다.

이 상태를 발견하면 절대 방치하면 안 된다. 지금 이 순간에도 공격자의 자동화 스캐너가 인터넷 전체의 CT log를 훑으며 같은 걸 찾고 있다.

방지 방법

근본적인 해결책은 서비스를 중단할 때 DNS 레코드를 함께 삭제하는 거다. 여기서 핵심은 순서다. 반드시 먼저 DNS 레코드를 지우고, 그다음 외부 서비스 자원을 해제해야 한다. 순서가 반대면 레코드가 살아 있는 채로 자원만 비는 틈이 생겨, 그 짧은 창이 바로 탈취 지점이 된다.

Vercel, Netlify, Heroku, AWS S3 등 외부 서비스와 연결된 서브도메인을 정기적으로 감사해야 한다. 사람이 기억에 의존하면 반드시 빠진다, 프로세스로 강제하는 게 맞다.

# DNS 레코드 감사 스크립트 예시
# 각 CNAME 타겟이 실제로 존재하는지 확인
dig CNAME staging.yourcompany.com +short
# "yourapp.vercel.app." 같은 값이 나오면 해당 Vercel 프로젝트가 존재하는지 확인

운영 관점의 방어책은 다음과 같다. 우선순위 순이다.

서비스 해지 체크리스트에 "DNS 레코드 선삭제"를 넣는다. 프로젝트 종료·이전 시 반드시 거치는 단계로 못 박는다.
자원 소유권을 검증 레코드로 고정한다. 클라우드 사업자가 제공하는 소유권 확인용 TXT 레코드를 유지하면, 남이 같은 이름을 재등록해도 연결되지 않는다.
와일드카드 CNAME(*.yourcompany.com)을 외부 서비스로 두지 않는다. 존재하지 않는 서브도메인까지 통째로 외부로 흘러가 탈취 표면이 무한정 커진다.
정기 자동 감사를 건다. 위 subzy/nuclei 스캔을 주기적으로 돌려 새로 생긴 댕글링 레코드를 잡는다.

자산 관리가 보안의 시작이다

Subdomain Takeover를 막으려면 조직이 보유한 서브도메인 전체를 파악하고 있어야 한다. 클라우드 인프라가 빠르게 변하는 환경에서 방치된 DNS 레코드는 생각보다 자주 발생한다. 마케팅팀이 캠페인용으로 잠깐 띄운 랜딩, 개발팀이 테스트로 연결한 스테이징, 퇴사한 담당자가 만든 문서 사이트, 이런 것들이 관리 대장에서 빠진 채로 몇 년씩 살아남는다.

그래서 Subdomain Takeover는 코드의 문제라기보다 외부 공격 표면(Attack Surface)을 얼마나 꾸준히 파악하고 있느냐의 문제다. 한 번 점검으로 끝나지 않는다. 새 서브도메인은 계속 생기고, 서비스는 계속 폐기된다. 그 사이의 틈을 주기적으로 좁히는 것이 유일한 방어다.

CodeScan은 URL 하나로 서버 정보 노출, 보안 헤더, SSL, 외부 노출 지점을 한 번에 점검해 이 공격 표면을 빠르게 그려준다. 방치된 자산이 어디서 새고 있는지 확인하는 첫걸음으로 삼으면 된다.

→ CodeScan으로 보안 점검 시작하기