DNS Attribution Laundering과 SubdoMailing 대응: 방치된 DNS 위임의 두 가지 악용 경로

서론

보안 분석가가 피싱 이메일을 추적할 때 가장 먼저 확인하는 것 중 하나가 SMTP 연결 정보다. Received 헤더에서 발신 서버의 IP 주소, 호스트명, 역DNS 결과를 확인하며 '누가 이 이메일을 보냈나'라는 질문에 답한다. 그런데 DNS 레코드 하나로 신뢰할 수 있는 기관의 이름이 외부 SMTP 서버의 네트워크 정체성처럼 기록될 수 있다면, 이 추적 과정은 왜곡된다.

2026년 2월과 7월, 스탠퍼드대학교와 유타주립대학교의 호스트명이 각각 외부 SMTP 서버의 Received 헤더에 나타났다는 연구 결과가 공개됐다. 두 기관은 해당 이메일을 보내지도 않았고, 이메일 인증에도 관여하지 않았다. CNAME 레코드 하나로 신뢰할 수 있는 호스트명이 외부 SMTP 서버의 겉옷이 된 것이다. 연구진은 이를 'DNS Attribution Laundering'이라 명명했으며, 기존 'SubdoMailing'과 다른 관측 패턴임을 지적했다.

Zenodo 공개 데이터셋(DOI 10.5281/zenodo.21400689)은 해당 인프라 운영자가 기관 귀속을 의도적으로 노렸다는 증거를 확립하지는 못한다고 명시한다. 그러나 관측된 DNS 체인과 Received 헤더 패턴 자체는 실제 발생했으며, 이는 모든 조직이 관리해야 할 관찰 가능한 리스크다.

영향 범위

이 문제는 DNS 레코드를 관리하는 모든 조직에 영향을 미친다. 특히 연구 프로젝트, SaaS 서비스, 외부 벤더 연동 등을 위해 서브도메인과 CNAME 레코드를 많이 사용하는 기관에서 위험이 높다.

대학은 연구 과제, 학위 논문, 임시 실험 환경 등으로 수년간 DNS 레코드를 축적한다. 프로젝트가 종료되고 자금 지원이 끊겨도 DNS 레코드는 그대로 남아 있는 경우가 많다. 기업 역시 마케팅 플랫폼, 클라우드로 이전한 서비스, 인수·합병 대상의 도메인, 중단된 제품의 관련 레코드 등을 장기간 방치할 수 있다.

이메일 수신 측에도 영향이 있다. 메일박스 공급자, 보안 이메일 게이트웨이, SOC 팀, 위협 인텔리전스 시스템 등이 DNS에서 얻은 호스트명을 인증된 조직 정체성으로 오해하면, 피싱 탐지 정확도가 떨어지고 조사가 잘못된 방향으로 이어질 수 있다.

기술적 분석

DNS Attribution Laundering의 작동 원리

DNS Attribution Laundering은 방치되거나 외부 위임된 DNS 관계로 인해, 외부 SMTP 인프라가 신뢰할 수 있는 제3자의 호스트명 아래 나타나는 현상을 가리킨다. 이메일 영역에서 구체화된 하위 유형인 'CNAME-Assisted SMTP Attribution Laundering'의 흐름은 다음과 같다.

1. 기관 A가 연구 프로젝트용 서브도메인(예: therate.hec.utah.edu)을 생성하고 CNAME을 외부 도메인(예: cse-online.net)으로 설정
2. 프로젝트 종료 후 DNS 레코드는 그대로 방치
3. 외부 도메인의 소유권, 구성, 용도가 변경
4. 외부 도메인이 가리키는 IP 중 하나가 SMTP 발신원으로 사용됨
5. Google 등의 수신 메일 서버가 역DNS를 통해 기관 A의 호스트명을 SMTP 연결 정보에 기록
6. 이메일 인증은 독립적 도메인으로 통과 (SPF/DKIM)
7. 결과: 기관 A의 호스트명이 SMTP 트레이스에 나타나는지라도, 실제 발신자나 인증 대상이 아님

실제 사례

유타주립대학교 사례 (2026년 7월 3일 발견)

Received: from nicolasprof.com (therate.hec.utah.edu. [5.175.188.80]) by mx.google.com ...

이 헤더에서 5.175.188.80이 실제 SMTP 소스 IP고, nicolasprof.com이 HELO/EHLO로 제시한 도메인이다. therate.hec.utah.edu는 역DNS로 나타난 유타주립대학교 호스트명이며, SPF 인증 도메인은 peakespeciate.net 등 완전히 다른 도메인이다. DNS 체인을 추적하면 therate.hec.utah.edu가 CNAME으로 cse-online.net을 가리키고, 이 도메인은 57개 IP를 반환한다.

연구진은 이 IP를 씨드로 한 확장 분석 결과 1,449개 IP, 412개 도메인, 3,487개 관계를 포함하는 네트워크 그래프를 구축했으며, 이는 42개국, 161개 ASN에 걸쳐 분포했다. 스탠퍼드대학교 사례에서는 wholecellviz.stanford.edu가 CNAME으로 wholecellviz.org를 가리키고 약 50개 IP를 반환했으며, 이 중 50.6.197.216이 피싱 SMTP 소스로 확인됐다.

Zenodo 데이터셋은 이 관측 결과 자체를 뒷받침하지만, 해당 IP와 도메인을 실제로 어떤 주체가 운영했는지, 그리고 기관 호스트명 노출을 의도했는지 입증하지는 않는다고 명시한다.

SubdoMailing과의 차이점

두 기법은 모두 방치된 DNS 관계에서 시작하지만, 신뢰 도메인을 사용하는 방식이 다르다.

SubdoMailing은 '누가 보냈는가'라는 신원 문제를 관여하고, DNS Attribution Laundering은 '어디서 보냈는가'라는 인프라 귀속 정보를 왜곡한다.

탐지 포인트

1. Received 헤더의 DNS-유도 호스트명과 SPF/DKIM 인증 도메인이 완전히 다를 때
2. CNAME 체인 뒤에 50개 이상 IP가 분산되는 이상 패턴
3. 기관 도메인의 역DNS 결과가 실제 SMTP 소스 IP와 일치하지 않을 때
4. HELO/EHLO 도메인과 DNS-유도 호스트명이 완전히 다를 때

대응 방안

도메인 소유자 관점

DNS 인벤토리를 정기적으로 점검한다. 외부 위임된 레코드, CNAME 체인, 프로젝트 종료 후 방치된 관계를 식별하고 정리한다. 특히 CNAME 대상 도메인의 소유권을 주기적으로 확인하며, 프로젝트나 벤더 계약이 종료되면 DNS 레코드 정리를 반드시 포함해야 한다.

수신 측 메일 게이트웨이 관점

DNS-유도 호스트명을 인증된 조직 신원으로 취급하지 않는다. SPF/DKIM 인증 도메인과 Received 헤더 호스트명 사이에 불일치가 있을 때 이를 탐지 신호로 활용하고, 기관 도메인의 DNS 체인을 자동으로 검증하도록 구성한다.

SOC/분석가 관점

Received 헤더의 호스트명만으로 조직 귀속을 결론짓지 않는다. 실제 연결 IP, HELO/EHLO, 역DNS, CNAME 체인, SPF 도메인을 모두 독립적으로 검증하며, DNS 연관성이 실제 소유권 증거가 아님을 인지한다.

결론

DNS Attribution Laundering은 새로운 취약점이 아니라, 방치된 DNS 관계가 만들어내는 착시 현상이다. Zenodo 데이터셋은 운영자의 의도를 입증하지는 못하지만, 관측된 DNS 체인과 헤더 패턴은 실제 존재하며, 이는 분석가가 주의해야 할 확인된 현상이다.

SubdoMailing과 근본적으로 다른 점은 이메일 신원 자체가 아닌 인프라 귀속 정보만 왜곡한다는 것이다. 보안 분석가가 Received 헤더 한 줄에서 '누가 보냈다'는 결론을 내려버리는 순간, 이 착시는 잘못된 조사를 낳는다.

도메인 소유자는 프로젝트 종료와 함께 DNS 레코드도 정리해야 한다. 레코드 하나가 연구 프로젝트의 유물이 아닌, 외부 SMTP 인프라의 겉옷이 될 수 있음을 인지해야 한다.

참고문헌

1. Lappu AI Research - DNS Attribution Laundering
   https://lappuai.com/research/dns-attribution-laundering/
2. Medium - DNS Attribution Laundering vs. SubdoMailing
   https://medium.com/@nate_86/dns-attribution-laundering-vs-subdomailing-similar-dns-weakness-very-different-email-abuse-42106de4b7dc
3. Zenodo - Utah-seeded Expansion Dataset (DOI 10.5281/zenodo.21400689)
   https://doi.org/10.5281/zenodo.21400689
4. Red Sift - SubdoMailing Guide
   https://www.redsift.com/guides/subdomailing
5. Microsoft - Dangling DNS and Subdomain Takeover Guide
   https://www.microsoft.com/en-us/security/blog

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.