1. DNS Tunneling
1.1 DNS
DNS(Domain Name System)는 사람이 인식하기 쉬운 도메인 이름을 IP 주소로 변환하기 위한 분산형 이름 해석 시스템이다. 사용자가 웹 브라우저에 도메인을 입력하면, 클라이언트는 DNS 질의를 생성해 로컬 DNS 서버 또는 리졸버로 전송하고, 최종적으로 권한 DNS 서버로부터 해당 도메인에 대응되는 IP 주소를 응답받는다. 이 과정은 대부분의 네트워크 통신에서 선행되며, DNS가 정상적으로 동작하지 않으면 사실상 인터넷 사용이 불가능해진다. 이러한 특성 때문에 DNS 트래픽은 네트워크 환경에서 기본적으로 허용되는 경우가 많고, 보안 장비에서도 상대적으로 완화된 검사를 적용받는다.
자세한 내용은 이전 글에서!
https://xsreem.tistory.com/204
1.2 개념
DNS 터널링(DNS Tunneling)은 정상적인 DNS 프로토콜을 악용해, 원래 DNS와 무관한 데이터를 DNS 질의(Query)와 응답(Response) 안에 은닉하여 송수신하는 기법이다.
DNS 질의 이름이나 응답 레코드에 인코딩된 데이터를 포함시키는 방식으로 동작하며, 표면적으로는 일반적인 도메인 조회 트래픽과 구분하기 어렵다. 이러한 특성 때문에 DNS 터널링은 주로 방화벽, 프록시, 네트워크 보안 장비의 통제를 우회하기 위한 Command & Control(C2) 채널이나 데이터 유출 수단으로 활용된다. DNS는 거의 모든 네트워크 환경에서 필수적으로 허용되는 트래픽이기 때문에, 공격자 입장에서는 차단 가능성이 낮고 은밀성이 높은 통신 채널로 인식된다.
1.3 공격에 유리한 이유
DNS가 터널링에 자주 악용되는 가장 큰 이유는 네트워크 환경에서 기본적으로 허용되는 트래픽이라는 점이다. 대부분의 방화벽은 UDP 53번이나 TCP 53번 포트를 사용하는 DNS 트래픽을 차단하지 않으며, 내부 시스템이 외부와 통신하기 위해서는 DNS 해석이 선행되어야 하기 때문에 정책적으로도 허용되는 경우가 많다. 또한 HTTP나 HTTPS 트래픽은 프록시나 보안 장비를 통해 비교적 엄격하게 통제되지만, DNS는 별도의 통제 대상에서 제외되는 환경도 적지 않다. 일반적인 보안 장비 역시 DNS를 단순한 이름 해석 트래픽으로 처리하는 경우가 많아, 내부에 데이터가 포함되어 있더라도 패턴 기반 탐지를 회피하기 쉽다. 여기에 UDP 기반 통신이라는 특성까지 더해져 연결 수립 과정 없이 빠르게 데이터를 주고받을 수 있기 때문에, DNS는 공격자에게 항상 열려 있는 백도어 통로처럼 활용된다.
2. DNS 터널링 동작 원리
2.1 기본 원리
DNS 터널링은 DNS 프로토콜의 구조적 특성을 이용해, DNS가 처리 가능한 형식 안에 임의의 데이터를 삽입하고 이를 양방향으로 교환하는 방식으로 동작한다. DNS 자체는 단순한 이름 해석 프로토콜이지만, 질의 이름(Query Name)과 응답 레코드(Response Record)에 비교적 자유로운 문자열을 포함할 수 있다는 점이 터널링의 기반이 된다.
2.2 DNS 프로토콜 구조와 악용 지점
1) DNS 요청 - Query Name
DNS 요청은 기본적으로 Query Name, Query Type, Query Class로 구성되며, 이 중 터널링에 가장 많이 악용되는 부분은 Query Name이다. Query Name은 점(.)으로 구분된 라벨(label)들의 집합으로 이루어지며, 각 라벨은 최대 63바이트, 전체 도메인 이름은 최대 255바이트까지 허용된다. 이 제한 범위 내에서 공격자는 의미 없는 무작위 문자열이나 인코딩된 데이터를 자유롭게 삽입할 수 있다.
2) DNS 응답 - TXT, A, CNAME 레코드
DNS 응답에서는 A, AAAA, CNAME, TXT 등 다양한 레코드 타입을 사용할 수 있는데, 특히 TXT 레코드는 문자열 기반 데이터를 비교적 자유롭게 담을 수 있어 명령 전달이나 추가 데이터 전송에 자주 활용된다. 이처럼 DNS는 프로토콜 설계상 데이터 무결성이나 의미를 검사하지 않기 때문에, 정상적인 형식을 유지하는 한 내부에 어떤 데이터가 포함되었는지는 검증하지 않는다.
3.2 데이터 인코딩과 질의 생성 과정
DNS 터널링의 첫 단계는 전송할 데이터를 DNS에서 허용하는 문자 집합으로 변환하는 것이다. DNS는 바이너리 데이터를 직접 전송할 수 없기 때문에, 공격자는 데이터를 Base32, Base64, Hex 등의 방식으로 인코딩한다. 이 과정에서 선택되는 인코딩 방식은 전송 효율과 탐지 회피에 직접적인 영향을 미친다.
인코딩된 데이터는 서브도메인 형태로 분할되어 Query Name에 포함된다. 예를 들어, 문자열이 길 경우 단일 라벨에 담을 수 없기 때문에 여러 라벨로 나누어 전송하며, 각 질의는 하나의 데이터 조각을 운반하는 역할을 한다. 결과적으로 DNS 요청은 다음과 같이 정상적인 도메인 조회와 유사한 형태를 띠게 된다.
<encoded_chunk_1>.<encoded_chunk_2>.exfil.attacker.com이러한 질의는 로컬 DNS 캐시나 리졸버를 거쳐 공격자가 소유한 도메인의 권한 DNS 서버로 전달된다.
3.3 권한 DNS 서버에서의 데이터 수신 및 처리
DNS 터널링에서 공격자가 제어하는 핵심 요소는 Authoritative DNS Server이다. attacker.com과 같은 도메인의 권한 서버는 외부에서 유입되는 모든 DNS 질의를 직접 수신하며, Query Name에 포함된 인코딩 데이터를 그대로 확인할 수 있다.
권한 서버는 수신된 질의를 파싱하여 서브도메인에 포함된 문자열을 추출하고, 이를 다시 디코딩해 원본 데이터를 복원한다. 이 과정은 자동화된 스크립트나 커스텀 DNS 서버 구현을 통해 수행되며, 일반적인 DNS 서버 로그에는 단순 질의로만 기록된다.
복원된 데이터는 공격자의 C2 로직에 따라 명령 처리, 상태 확인, 추가 페이로드 요청 등으로 활용된다. 이 시점에서 DNS는 단순한 이름 해석이 아니라, 사실상 데이터 업링크 채널로 기능한다.
3.4 DNS 응답을 통한 다운링크 통신
DNS 터널링은 단방향이 아니라 양방향 통신을 전제로 한다. 공격자는 클라이언트로 명령이나 추가 데이터를 전달하기 위해 DNS 응답을 활용한다. 이때 가장 많이 사용되는 레코드는 TXT 레코드이며, 경우에 따라 A, CNAME 레코드도 사용된다.
응답에 포함되는 데이터 역시 인코딩된 문자열 형태로 전달되며, 클라이언트는 이를 수신한 뒤 디코딩하여 실행하거나 다음 동작을 수행한다. DNS 응답은 클라이언트가 요청한 결과로 보이기 때문에, 네트워크 상에서는 매우 자연스러운 트래픽 흐름으로 인식된다.
3.5 전체 통신 흐름 정리
| 단계 | 내부 동작 |
| 데이터 준비 | 명령, 키 입력, 시스템 정보 등을 수집 |
| 인코딩 | Base32/Base64/Hex 등으로 문자열 변환 |
| Query 생성 | 인코딩 데이터를 서브도메인에 삽입 |
| 전송 | 로컬 DNS → 리졸버 → 권한 DNS 서버 |
| 서버 처리 | 질의 파싱 및 데이터 디코딩 |
| 응답 생성 | 명령 또는 데이터 인코딩 후 응답 |
| 클라이언트 처리 | 응답 디코딩 및 명령 실행 |
3. DNS 터널링의 주요 활용 시나리오
3.1 Command & Control (C2)
DNS 터널링은 침해 이후 공격자가 내부 시스템을 원격으로 제어하기 위한 Command & Control 채널로 가장 널리 사용된다. 악성코드는 일정 주기로 DNS 질의를 전송해 외부 공격 인프라에 비콘을 보내고, DNS 응답을 통해 명령을 수신한다. 이러한 통신은 정상적인 도메인 이름 해석 요청과 구분이 어려운 형태를 유지하며, HTTP나 HTTPS 기반 C2 채널이 차단된 환경에서도 안정적으로 동작한다.
3.2 Exfiltration
DNS 터널링은 내부 시스템에서 수집한 정보를 외부로 유출하는 데에도 효과적으로 사용된다. 공격자는 자격 증명, 키 입력 정보, 시스템 메타데이터와 같은 소량이지만 민감한 데이터를 인코딩한 뒤 DNS 질의의 서브도메인에 포함시켜 외부 서버로 전송한다. DNS는 대부분의 네트워크 환경에서 기본적으로 허용되기 때문에, 웹 트래픽이나 파일 전송이 차단된 환경에서도 데이터 유출이 가능하다.
3.3 Network footprinting and exploration
DNS 터널링은 공격 초기 단계에서 내부 네트워크 구조를 파악하기 위한 정찰 수단으로도 활용된다. 공격자는 DNS를 통해 내부 시스템의 네이밍 규칙, 내부 도메인 구조, 접근 가능한 네트워크 범위 등을 간접적으로 탐색할 수 있다. 예를 들어, 악성코드는 내부 호스트명이나 도메인 정보를 DNS 질의 형태로 외부로 전송해 공격자가 네트워크 환경을 파악할 수 있도록 한다. 이러한 방식은 직접적인 네트워크 스캔보다 눈에 띄지 않으며, 방어 측 입장에서는 정상 DNS 트래픽과 구분하기 어려운 형태로 진행된다.
3.4 VPN bypass for network restrictions
DNS 터널링은 네트워크 접근이 제한된 환경에서 우회 통신 수단으로 사용된다. 많은 조직은 VPN 사용이나 특정 포트 기반 통신을 엄격하게 통제하지만, DNS는 필수 서비스로 인식해 상대적으로 완화된 정책을 적용한다. 공격자는 이러한 환경에서 DNS를 사실상의 터널로 활용해 외부 서버와 통신하며, 네트워크 분리나 방화벽 정책을 우회한다.
3.5 Malware delivery and staging
DNS 터널링은 악성코드 전달 및 스테이징 단계에서도 사용될 수 있다. 공격자는 DNS 응답을 통해 다음 단계의 페이로드 위치나 실행 명령을 전달하거나, 소형 페이로드 자체를 분할·인코딩해 전송한다. 이 방식은 초기 악성코드가 최소한의 기능만을 가진 상태로 배포된 이후, 추가 기능을 동적으로 로드하도록 설계된 공격에서 주로 활용된다.
4. 정상 DNS와 DNS 터널링의 차이
정상적인 DNS 트래픽은 일반적으로 짧고 의미 있는 도메인 이름을 사용하며, 실제 서비스 접근이 필요할 때만 질의가 발생한다. 반면 DNS 터널링에서는 인코딩된 데이터가 포함되면서 도메인 길이가 비정상적으로 길어지고, 무작위 문자열에 가까운 형태를 띠는 경우가 많다. 또한 특정 도메인에 대해 주기적이거나 고빈도의 질의가 발생하며, A나 AAAA 레코드보다 TXT, NULL, CNAME 레코드가 상대적으로 자주 사용된다. 트래픽의 목적 역시 이름 해석이 아니라 데이터 송수신이라는 점에서 근본적인 차이를 가진다.
| 구분 | 정상 DNS 트래픽 | DNS 터널링 트래픽 |
| 목적 | 도메인 이름을 IP 주소로 변환 | 명령 전달, 데이터 송수신, C2 유지 |
| 트래픽 성격 | 서비스 접근을 위한 부수 트래픽 | 통신 자체가 주 목적 |
| 도메인 길이 | 짧고 사람이 인식 가능한 형태 | 비정상적으로 길고 무작위 문자열 |
| 서브도메인 구성 | 의미 있는 단어 또는 서비스명 | Base32/Base64/Hex 인코딩 문자열 |
| 문자열 엔트로피 | 낮음 | 매우 높음 |
| Query 발생 빈도 | 사용자 행위에 따라 불규칙 | 주기적·고빈도 |
| 시간대 분포 | 업무 시간대 중심 | 심야·비활성 시간대에도 지속 |
| 주 사용 레코드 | A, AAAA | TXT, CNAME, NULL |
| TXT 레코드 사용 | 드묾 | 빈번 |
| NXDOMAIN 비율 | 낮음 | 상대적으로 높음 |
| 단일 도메인 반복 | 적음 | 특정 도메인에 집중 |
| 응답 크기 | 작고 일정 | 상대적으로 크거나 불규칙 |
| 트래픽 방향성 | 질의 위주 | 질의·응답 모두 데이터 포함 |
| 관련 프로세스 | 브라우저, 정상 애플리케이션 | PowerShell, cmd, mshta, 악성 프로세스 |
| 보안 탐지 관점 | 정상 베이스라인 | 이상 행위 후보 |
5. 탐지 관점에서의 DNS 터널링 특징
네트워크 레벨에서는 평균적인 DNS 요청과 비교해 비정상적으로 긴 도메인 이름이 반복적으로 등장하거나, 동일 도메인에 대한 고빈도 질의가 지속적으로 발생하는 패턴이 주요 지표가 된다. 또한 TXT 레코드 요청 비율이 비정상적으로 높거나, 존재하지 않는 도메인에 대한 NXDOMAIN 응답 비율이 증가하는 현상 역시 의심 신호로 볼 수 있다. 로그 및 포렌식 관점에서는 DNS 로그에서 엔트로피가 높은 서브도메인이 반복적으로 나타나는지, 특정 프로세스가 과도한 DNS 요청을 발생시키고 있는지, 사용자 행위와 무관한 시간대에 지속적인 DNS 통신이 이루어지는지를 함께 확인하는 것이 중요하다.
예시1) 인코딩된 서브도메인 기반 데이터 업링크
2026-01-05T02:14:33Z
client=10.10.10.23
query=QxJGM0NTRkY4M0ZBMTk0MkE0.exfil.attacker.com
qtype=TXT
rcode=NOERROR첫째, 서브도메인이 사람이 인식하기 어려운 무작위 문자열 형태를 띠며 Base32 또는 Base64 인코딩 패턴과 유사하다.
둘째, TXT 레코드를 사용하고 있으며, 이는 일반적인 웹 브라우징 환경에서는 빈도가 낮다.
셋째, 동일한 2차 도메인(exfil.attacker.com)에 대해 유사한 길이의 질의가 반복적으로 발생한다.
이는 내부 시스템에서 수집된 데이터를 잘게 분할해 DNS 질의를 통해 외부로 전송하는 전형적인 DNS 기반 데이터 유출 패턴이다.
예시2) 주기적 비콘 형태의 DNS C2 통신
02:14:33 query A c2.attacker.com
02:15:03 query A c2.attacker.com
02:15:33 query A c2.attacker.com
02:16:03 query A c2.attacker.com이 패턴은 일정한 간격(30초)으로 동일한 도메인에 대한 DNS 질의가 발생하고 있다.
사용자 행위와 무관하게 정해진 주기로 반복되는 DNS 요청은 C2 비콘링(beaconing)의 전형적인 특징이며, HTTP가 아닌 DNS로 수행될 경우 탐지가 더 어려워진다.
6. 방어 및 대응 전략
DNS 터널링에 대응하기 위해서는 네트워크와 엔드포인트를 아우르는 다층적인 전략이 필요하다. 네트워크 보안 측면에서는 DNS 로그를 수집하고 장기 보관해 이상 패턴을 분석할 수 있는 기반을 마련해야 하며, 도메인 길이나 문자열 엔트로피를 기준으로 한 이상 탐지 기법을 적용하는 것이 효과적이다. 또한 내부 시스템이 반드시 내부 DNS 서버를 사용하도록 강제함으로써 외부 우회 통신을 제한할 수 있다. 엔드포인트 관점에서는 DNS 요청을 발생시키는 프로세스를 추적하고, PowerShell, cmd, mshta와 같은 LoLBins와의 연계를 분석해 비정상 행위를 식별해야 한다. 여기에 EDR을 활용한 비정상 네트워크 행위 탐지를 결합하면 탐지 효율을 높일 수 있다. 조직 차원에서는 알려진 DNS 터널링 도메인을 차단하고, DNS over HTTPS와 같은 암호화 DNS 사용에 대한 통제 정책을 수립하며, 보안 관제 룰에 DNS 기반 C2 시나리오를 포함시키는 것이 중요하다.
6.1 탐지 포인트
1) query 길이 이상치: 정상 DNS 대비 비정상적으로 긴 query 길이가 반복적으로 관찰되는 경우 의심 대상이다.
2) 엔트로피 기반 탐지: query 문자열의 문자 분포가 균등하고 무작위에 가까울수록 인코딩 데이터일 가능성이 높다.
3) TXT 레코드 집중 사용: qtype_name=TXT
4) NXDOMAIN 비율 증가: 존재하지 않는 도메인에 대한 질의가 반복될 경우, 데이터 업링크용 질의일 가능성이 있다.
6.2 SIEM 로그 기준 탐지 룰 예시
1) 비정상적으로 긴 DNS Query 탐지
IF
event.category = "dns"
AND length(dns.query) >= 60
AND count(dns.query) BY src_ip, dns.query >= 10 WITHIN 5m
THEN
alert "Suspicious Long DNS Query (Possible DNS Tunneling)"
2) TXT 레코드 과다 사용 호스트 탐지
IF
event.category = "dns"
AND dns.question.type = "TXT"
AND count(*) BY src_ip >= 20 WITHIN 10m
THEN
alert "Excessive DNS TXT Queries (Possible DNS C2)"
3) 엔트로피 기반 서브도메인 탐지
IF
event.category = "dns"
AND entropy(dns.query) >= 4.0
AND dns.query NOT IN whitelist_domains
THEN
alert "High Entropy DNS Query (Encoded Data Suspected)"
4) DNS Beaconing 패턴 탐지
IF
event.category = "dns"
AND same(dns.query) BY src_ip
AND stddev(event.time_delta) <= 5s
AND count(*) >= 10 WITHIN 15m
THEN
alert "DNS Beaconing Behavior Detected"
5) NXDOMAIN 비율 이상 탐지
IF
event.category = "dns"
AND dns.response_code = "NXDOMAIN"
AND count(*) BY src_ip >= 30 WITHIN 10m
THEN
alert "Excessive NXDOMAIN Responses (Possible DNS Exfiltration)"
출처
https://www.dnssense.com/post/what-is-dns-tunnelling
What is DNS Tunneling? How Can You Prevent DNS Tunneling Attacks? | DNSSense
Security has become a massive concern in the rapidly evolving world of information technology. Our ever-increasing reliance on digital systems means the threats we face are becoming more sophisticated.
www.dnssense.com
https://www.paloaltonetworks.co.kr/cyberpedia/what-is-dns-tunneling
DNS 터널링이란?
DNS 터널링은 DNS 프로토콜을 악용하여 클라이언트-서버 모델을 통해 악성 코드 및 기타 데이터를 터널링하는 공격 방법입니다. 악의적인 공격자는 DNS를 통해 명령 및 제어(C2) 채널을 사용하여 이
www.paloaltonetworks.co.kr
https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunneling
What Is DNS Tunneling? [+ Examples & Protection Tips]
DNS tunneling is a technique that sends data from other applications or protocols by hiding it inside DNS queries and responses.
www.paloaltonetworks.com
'Program > 토스뱅크 사이버보안 엔지니어 부트캠프(공격&방어 기술)' 카테고리의 다른 글
| 침해사고 분석 및 대응을 위한 시각화 도구 아키텍처 및 기능 소개 (0) | 2026.02.10 |
|---|---|
| 침해사고 분석 및 대응을 위한 시각화 도구 개발 (0) | 2026.02.10 |
| Google Drive API 사용 방법 (1) | 2026.01.10 |
| KAPE(Kroll Artifact Parser and Extractor) (0) | 2025.12.30 |
| Havoc Framework (0) | 2025.12.17 |
