DNS 악용 공격 — 비인가 DNS·공유 호스팅·레코드 변조·터널링¶

이 페이지에서 다루는 것

회사 DNS를 건너뛰는 비인가 DNS 사용과 그 흔적 6곳, 공유 호스팅에서의 차단 딜레마, 우리 DNS 레코드 변조(도메인 섀도잉·바꿔치기), DNS 터널링의 원리와 정상 트래픽 가려내기.

표기

[보충] = 꼭 알아야 할 실무 보충, [정정] = 흔히 잘못 알려진 내용 정정, [변경됨]/[주의] = 최근 바뀐 점과 옛 방식대로 하면 위험한 점. 전체 흐름은 DNS 개요에서, 기록 한 줄을 판별하는 순서는 판별표에서 볼 수 있습니다.

허가되지 않은 DNS 서버 사용¶

여기서부터 "DNS 자체를 이상하게 쓰는 공격"입니다. 공격자는 기록·차단을 피하려고 회사 DNS를 건너뜁니다.

공격 기법 목차¶

허가되지 않은 DNS 서버 사용 / 공유 호스팅의 악성 사이트 / 우리 DNS 레코드 변조 / DNS 터널링 / 블록체인 DNS / IDN. 정찰(SRV·TXT)부터 초기 침투(유사 도메인, 서브도메인 탈취), 명령·통제(DGA, TXT 명령, 우회 DNS), 유출(터널링)까지 전 단계에 쓰임.

원리와 처방¶

PC의 DNS 설정은 "부탁"이지 "강제"가 아님. 프로그램은 직접 DNS 패킷을 만들어 아무 서버로나 보낼 수 있음 → 막는 곳은 방화벽
정상 프로그램도 그럼: 브라우저 DoH, DNS가 고정된 IoT·스트리밍 기기, 일부 VPN·게임·개발 도구 → 악성코드이거나 "말 안 듣는 프로그램·직원", 어느 쪽이든 조사 대상
처방: ① 회사 DNS만 밖으로 53번 허용 ② 모든 DNS가 보이게(서버 기록만으론 우회가 안 보임) ③ 막힌 기록도 경보 ④ DoH는 TLS 복호화
[보충] 막는 대신 방화벽이 밖으로 나가는 53번을 회사 DNS로 가로채 돌려보내는 방법도 있음(고정 DNS 기기가 안 깨짐). 원래 목적지는 따로 기록

토론: 수상한 질문 찾기¶

대부분 회사 DNS(192.168.42.2)로 가는데 패킷 708번 하나만 8.8.8.8로 감. 외부 DNS 사용은 목적지 IP 칸에서 보이고, 질문한 이름(www.google.com)으로는 안 보임. 악성코드는 C2에 연락하기 전에 Google 등으로 연결 확인을 하므로 평범한 이름이 먼저 나옴 → 그 다음 행동을 볼 것. 같은 기록도 칸마다 다른 공격이 보임(이름: 피싱·DGA / 목적지: 우회 / 응답: NXDOMAIN·잠복 / 타입: TXT·SRV).

복습 Q&A

새벽 2시, 1.1.1.1로 3건: www.microsoft.com, www.google.com, a8kq2vx.duckdns.org → 시간대·회사 DNS 우회·연결 확인 후 접속 패턴이 겹침. 가장 결정적인 것은 마지막 이름: 무료 동적 DNS(DDNS) 서비스의 무작위 하위 이름 = C2 후보. DDNS·호스팅 플랫폼은 하위 이름마다 주인이 달라 하위 이름이 사실상 등록 단위이므로, "하위 이름만 무작위면 정상" 규칙의 예외
"외부 53번 차단했으니 우회 끝"이 틀린 이유: ① 암호화 DNS(DoH 443, DoT·DoQ 853) ② DNS 자체를 안 쓰거나 다른 길: IP 직접 하드코딩, 53이 아닌 포트로 DNS, 공격자 자체 DoH 서버 ③ 회사 DNS를 정상적으로 거치는 터널링(질문이 회사 DNS를 거쳐 공격자 권한 서버까지 감 → 53 차단과 무관). 대응: 853 차단, 알려진 DoH 차단, 브라우저 정책, 내부 DoH, 막힌 시도 경보, 기본 차단 방식의 아웃바운드 정책, 회사 DNS 질의 패턴 감시(터널링 탐지), EDR·행동 탐지

2026년 관점

DoH 대응은 TLS 복호화(비용·성능, 인증서 고정 프로그램 깨짐, 개인정보·법적 문제, ECH)보다 여러 겹: 브라우저 정책, Firefox 신호 도메인 use-application-dns.net NXDOMAIN, 알려진 DoH 서버 차단, 853(TCP/UDP) 차단, 내부 DoH 제공, PC 기록
공격자 자체 DoH 서버는 목록으로 못 잡음 → 행동 기반 탐지
53번 차단 전에 며칠 "기록만" 해서 부작용 장비 파악 + 감염 장비 찾기
정정: DoQ는 UDP 853, UDP 443은 HTTP/3 기반 DoH

외부 DNS 흔적과 공유 호스팅 차단¶

외부 DNS 사용의 흔적은 여섯 군데에 남고, 어느 것이든 경보로 이어져야 합니다. 공유 호스팅은 공격 기법이 아니라 "IP 하나에 사이트 수천 개일 때 어떻게 막나"라는 차단 딜레마입니다.

외부 DNS 사용의 흔적¶

기록	어디서	이름	프로그램	트래픽 전에 잡나	비고
① 방화벽	네트워크	✗	✗	✗	차단·허용 둘 다. NAT 바깥이면 출발지가 뭉침
② 흐름 / 네트워크 센서	네트워크	흐름 ✗ / Zeek ○	✗	✗	목적지 53 + 내부 출발 + 외부 목적지 + 출발지≠DNS 서버
③ PC 방화벽	PC	✗	○	✗	Windows Security Event ID 5156(필터링 플랫폼 연결 허용), 5157(차단). 감사 정책 필요, 5156은 양이 많음. `pfirewall.log`
④ IDS	네트워크	규칙에 따라	✗	✗	과거 경보로 시작 시점(감염 시점) 추정
⑤ PC 무결성 점검	PC	—	○	○	DNS 설정·hosts 변경 감시
⑥ EDR	PC	○	○	✗(설정 변경 기록 기능이 있으면 ○)	"회사 DNS가 아닌 모든 DNS"로 가장 포괄적

PC 무결성 점검에서 볼 두 곳:

DNS 서버 설정: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{ID}\NameServer → Sysmon Event ID 13(레지스트리 값 설정)으로 감시. 바뀌면 그 PC의 모든 프로그램이 공격자 DNS를 씀(예: DNSChanger)
hosts 파일: C:\Windows\System32\drivers\etc\hosts → Sysmon Event ID 11(파일 생성)·FIM으로 감시. DNS보다 먼저 확인되므로 DNS 질의 자체가 안 생겨 네트워크·DNS 기록에 흔적이 없음

공유 호스팅¶

월 3달러 수준, IP 하나에 작은 사이트 수천 개(아파트 한 건물에 수천 세대). 예: cuzb.com → 91.195.240.79 → 다른 사이트 5,857개
역방향 IP 조회 ≠ PTR: PTR은 IP 주인이 정한 이름 1개(custip-1079.sedoparking.com), 역방향 IP 조회는 Passive DNS에서 그 IP를 가리킨 도메인 전부
주차(parking) 서비스(sedoparking.com)는 미사용 도메인 다수를 소수 IP로 서비스. 악성 광고, 대기 중·버려진 공격 도메인과 연결되기도 함
흔한 답: 업무 사이트는 공유 호스팅에 거의 없어 대개 도메인·IP 둘 다 막아도 OK. 더 좋은 답: 막기 전에 그 IP로 간 트래픽 양과 관련 도메인을 기록으로 확인

복습 Q&A

네트워크 기록에 흔적이 전혀 없는 감염 의심 PC → ⑤ PC 무결성 점검: DNS 서버 설정(레지스트리)과 hosts 파일 두 곳. EDR은 설정 변경까지 기록할 때 유용. 그 밖에 집 공유기 DNS, 브라우저 DoH·프록시 설정도 후보
역방향 IP 조회 3,000개: 작은 호스팅 ASN + 우리 PC 2대·전부 악성 도메인 → IP 차단 가능(도메인도 차단, 만료일, 두 PC 조사). Cloudflare ASN + PC 400대·다양한 도메인 → IP 차단 금지. 대신 도메인 차단(DNS·프록시), 400대 중 실제로 악성 도메인에 간 PC를 DNS·프록시·EDR로 특정, 필요 시 CDN에 악용 신고

2026년 관점

"IP 하나에 수천 개"는 전통적 공유 호스팅만이 아님(CDN, 클라우드 플랫폼). 역방향 IP 조회 결과만으로는 구분 불가 → ASN 먼저 확인 후 위 판단 적용
재택 시대: 집 공유기 DNS 변조 → 회사 노트북은 어디서든 회사 DNS(VPN·클라우드 Protective DNS) 강제
EDR 표준화. 단 브라우저 자체 DoH는 제품에 따라 DNS가 아닌 HTTPS 연결로만 보일 수 있음
[주의] 여섯 군데가 같은 사건에 각각 경보 → 경보 피로. 주 경보 하나 + 나머지는 덧붙이기용, 정상 예외 미리 등록

레코드 변조와 DNS 터널링¶

공격자가 우리 DNS 관리자 계정을 뚫으면 우리 도메인 자체가 공격 도구가 됩니다. DNS 터널링은 DNS를 데이터 통로로 쓰는 공격으로, 막기는 어렵지만 찾기는 쉽습니다.

DNS 레코드 변조¶

도메인 섀도잉: 우리 도메인 아래 새 하위 이름 추가(blog.example.com → 공격자 서버). 우리 평판·나이·TLD를 그대로 빌려 이름 기반 판별을 전부 통과
레코드 바꿔치기("정말 나쁜" 쪽): VPN 로그인 페이지를 복제해 올리고 vpn. A 레코드를 공격자 서버로. 입력한 비밀번호를 진짜 페이지로 넘겨 로그인이 성공하므로 눈치채지 못함
DNS를 통제하면 TXT로 소유 증명 → 진짜 HTTPS 인증서 발급. 주소창(진짜 도메인)과 자물쇠(진짜 인증서) 모두 정상으로 보여 사용자 수칙이 무력화됨
서브도메인 탈취와 차이: 탈취는 방치된 CNAME의 빈자리, 섀도잉은 계정을 뚫고 직접 추가
방어: MFA + 변경 감지. 보충: 레코드 목록 관리로 "새 레코드" 경보, crt.sh에서 우리가 발급 안 한 인증서 감시, 관리자 계정 로그인·변경 알림

DNS 터널링¶

원리: DNS는 텍스트를 보내고 텍스트를 받음 → 하위 이름에 데이터(파일, 명령 결과)를 인코딩해 보내고, 공격자 권한 서버의 터널링 소프트웨어(iodine: IP 터널, dnscat2: C2)가 해독 후 응답(TXT·CNAME)에 명령을 실어 보냄
"거의 항상 통한다": DNS는 최소 한 곳(회사 DNS 서버)에서 밖으로 나갈 수 있어야 함
두 경로: ① 공격자 DNS로 직접(외부 53번 차단으로 막힘) ② 회사 DNS를 거쳐 재귀로 도달(외부 53번 차단과 무관)
외부 53번 차단 규칙은 "회사 DNS 서버만 허용, 나머지 차단". 회사 DNS 서버의 재귀는 막으면 인터넷 마비라 열어둠 → 방화벽은 질문 내용을 보지 않으므로 터널링 질문도 정상 재귀로 통과. 상위 Protective DNS로 포워딩하는 구성도 배달은 동일(단 상위에서 탐지 가능)
방화벽은 "길"을 막고, DNS 서버는 "목적지"를 막는다: 터널링은 회사 DNS 서버에서 패턴 탐지 → 등록 도메인 차단(Protective DNS/RPZ) → 감염 PC 격리
찾는 신호: 길이 한계까지 채운 하위 이름(이름 253자, 덩어리 63자 제한), 무작위·인코딩 문자열, 한 도메인에 질문 폭주, TXT·CNAME 비중, 이상한 프로그램(Sysmon 22), 비정상 데이터량
16진수처럼 보여도 암호화 때문에 해독이 안 될 수 있음. 판정에는 지장 없음

복습 Q&A

레코드 바꿔치기 탐지: A 레코드 변경 감지, crt.sh 무단 인증서, 관리자 계정 로그인 감시, 사내에서 조회한 응답 IP가 우리 서버가 아님
60자 무작위 하위 이름 TXT가 1분에 수백 건 → 터널링 의심. 회사 DNS를 거쳤다면 외부 53번 차단으로 못 막음. 등록 도메인부터 확인(백신·안티스팸 평판 조회 sophosxl.net 등 정상 오탐 거르기) → 평판·나이 → 프로그램 → 다른 PC

2026년 관점

low-and-slow(짧게 나눠, 느리게) 회피 → 길이·엔트로피·빈도·고유 하위 이름 수·데이터 비율을 종합한 머신러닝 탐지(Protective DNS, NDR)
DoH 터널링은 DNS 기록 기반 탐지를 무력화 → EDR·NDR의 행동·연결 패턴
대용량 유출은 합법 클라우드(Google Drive, Telegram 등)로 이동. DNS 터널링은 소량 C2·막힌 환경용
[주의] 긴 무작위 이름을 쓰는 정상 서비스(백신 평판 조회, CDN) 오탐

터널링 가려내기와 탐지 체크리스트¶

"길고 무작위한 이름 = 터널링"이 아닙니다. 판별은 ① 등록 도메인 ② 통신량 두 축으로 합니다.

토론: 세 개의 "터널링 의심" 경보¶

	겉모습	타입	등록 도메인	통신량	결론
①	아주 긴 무작위 이름	TXT	`sophosxl.net`(Sophos 백신 Live Protection)	적음	정상. 기술적으로는 터널링이지만 좋은 목적
②	아주 긴, 비표준 글자 섞인 이름	NULL(거의 안 쓰임)	`pirate.sea`(정체불명, hack.lu CTF)	많음	악성(iodine)
③	무작위 하위 이름	A	`cloudfront.net`(AWS CDN)	적음	정상

백신이 DNS를 쓰는 이유도 공격자와 같음: DNS는 거의 어디서나 열려 있음
NULL 레코드는 아무 바이너리나 담을 수 있어 iodine의 기본 타입. 등장 자체가 강한 신호
A 응답은 IP 4바이트만 담아 응답 통로로 비효율적(질문 쪽 유출은 가능)
확인된 정상 DNS 데이터 서비스는 등록 도메인 단위로 허용 목록화하되, 조회 프로그램이 진짜 그 제품인지 가끔 확인

탐지 체크리스트¶

한 등록 도메인 아래 고유 하위 이름 수 폭증 — 매번 새 이름이라 캐시에 안 걸리고 매번 재귀로 나감 → 회사 DNS 서버 기록·출구 센서 모두에 그대로 남음("캐시 때문에 첫 조회만 보임"과 반대)
한 출발지의 대량 질문(1MB 유출에 질문 수만 건)
TXT·CNAME·MX·NULL 과다
길고 무작위한 하위 이름 + 이상한 등록 도메인
TXT 응답에 사람이 못 읽는 인코딩 데이터(정상 TXT는 v=spf1처럼 읽힘)
허가되지 않은 DNS 서버 사용
오탐: CDN, 백신 조회, DNS 하이재킹 테스트(Chrome이 시작 시 점 없는 무작위 한 단어 이름 몇 건 조회 → NXDOMAIN)
정체불명·악성 등록 도메인으로의 대량 질문은 지금도 유출 중일 수 있으니 최우선 조사

복습 Q&A

4.3.2.1.zen.spamhaus.org(메일 서버, 메일마다) = DNSBL 스팸 평판 조회, 뒤집힌 IP 형식 / k8x2m9q4v7.data.update-svc.online NULL, PC 한 대 1분 300건 = 악성 터널링 / qwzxkplmrt 여러 PC 부팅 직후 3건 NXDOMAIN = Chrome 하이재킹 테스트
low-and-slow(A 타입, 짧은 이름, 10분에 1건)에도 남는 단서: 등록 도메인(신규·평판 없음·우리에게 처음), 장기간 누적한 고유 하위 이름 수, 규칙적인 간격(비컨), 사람 없는 시간에도 지속, 조회 프로그램(Sysmon 22), 다른 PC는 안 감. 보는 법: 출발지 PC × 등록 도메인으로 묶어 며칠~몇 주 단위로 집계, 간격의 규칙성 확인

2026년 관점

오탐 확장: 보안 제품 전반의 DNS 조회, DNSBL(zen.spamhaus.org), 클라우드·텔레메트리 → 문서화된 허용 목록
회피: low-and-slow, A/AAAA(AAAA 응답 16바이트), 짧은 이름, 평판 좋은 도메인(섀도잉, DDNS) → 종합 점수·머신러닝, 장기 누적 분석
허용 목록은 등록 도메인 단위로 좁게. 터널링 기준에서만 빼고 다른 탐지에서는 계속 보이게