아무도 쓰지 않는 서브도메인이 회사 명의로 피싱에 악용된다
Subdomain Takeover는 잘 알려지지 않은 취약점인데, 버그바운티에서는 Medium~High 심각도로 분류되는 실제 위협이다. 핵심 원리는 간단하다.
- 회사가
blog.yourcompany.com→ GitHub Pages로 연결하는 CNAME을 만든다 - 서비스를 그만두면서 GitHub 저장소를 삭제하지만, DNS의 CNAME은 그대로 남긴다
- 공격자가 동일한 GitHub Pages URL을 등록하면,
blog.yourcompany.com이 공격자 페이지를 가리키게 된다
취약한 서비스 유형
Takeover가 가능한 서비스들은 특정 URL 형식으로 응답이 달라진다. 연결이 끊긴 경우 "404 - Repository not found"(GitHub Pages), "NoSuchBucket"(AWS S3), "There is no app configured at that hostname"(Heroku) 같은 특징적인 에러를 반환한다.
내 도메인 점검 방법
# 서브도메인 목록 수집
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
방지 방법
근본적인 해결책은 서비스를 중단할 때 DNS 레코드를 함께 삭제하는 거다. Vercel, Netlify, Heroku, AWS S3 등 외부 서비스와 연결된 서브도메인을 정기적으로 감사해야 한다.
# DNS 레코드 감사 스크립트 예시
# 각 CNAME 타겟이 실제로 존재하는지 확인
dig CNAME staging.yourcompany.com +short
# "yourapp.vercel.app." 같은 값이 나오면 해당 Vercel 프로젝트가 존재하는지 확인
자산 관리가 보안의 시작이다
Subdomain Takeover를 막으려면 조직이 보유한 서브도메인 전체를 파악하고 있어야 한다. 클라우드 인프라가 빠르게 변하는 환경에서 방치된 DNS 레코드는 생각보다 자주 발생한다. 외부 공격 표면(Attack Surface)을 주기적으로 점검하는 게 중요하다.