DNS — Angriffsvektoren, Exfiltration & Insider-Wissen

Grundlagen der DNS-Architektur

Das Domain Name System (DNS) wurde 1983 von Paul Mockapetris in den RFCs 882 und 883 definiert und später in RFC 1035 (1987) konsolidiert. Die Hierarchie beginnt an der Wurzel (Root Zone, verwaltet von IANA/ICANN mit 13 Root-Server-Clustern weltweit), gefolgt von Top-Level-Domains (TLDs), Second-Level-Domains und optionalen Subdomains. Insider-Wissen: Die „13 Root-Server“ sind in Wirklichkeit über 1.700 Anycast-Instanzen weltweit verteilt. Ein DDoS auf die Root-Server ist nahezu unmöglich, weil Anycast den Traffic auf hunderte physische Server verteilt — selbst der massive Dyn-Angriff (2016, 1,2 Tbps Mirai-Botnet) konnte die Root-Server nicht beeinträchtigen.

Bei der Namensauflösung unterscheidet man zwischen rekursiver und iterativer Abfrage. Ein rekursiver Resolver nimmt die Anfrage des Clients entgegen und kontaktiert iterativ den Root-Server, den TLD-Server und den autoritätiven Nameserver. Das Ergebnis wird für die TTL-Dauer im Cache gespeichert. Insider-Wissen: Die meisten DNS-Probleme in Unternehmensnetzwerken entstehen durch falsche TTL-Konfiguration. Eine TTL von 86400 (24h) bedeutet, dass DNS-Änderungen erst nach einem Tag weltweit wirksam werden. Für Disaster-Recovery-Szenarien (DNS-Failover) empfehlen wir eine TTL von 60–300 Sekunden — aber nur für die Records, die im Notfall geändert werden müssen. Alle anderen Records sollten hohe TTLs behalten, um die DNS-Last zu reduzieren.

Was kaum jemand weiß: Active Directory ist vollständig von DNS abhängig. Jeder Domain Controller registriert automatisch SRV-Records (_ldap._tcp.dc._msdcs.domain.com, _kerberos._tcp.domain.com), und Clients finden Domain Controller ausschließlich über DNS. Wenn ein Angreifer die DNS-Infrastruktur kontrolliert, kontrolliert er effektiv die Authentifizierung. DNS-Poisoning in einer AD-Umgebung kann dazu führen, dass Clients ihre Credentials an einen gefälschten Domain Controller senden — ohne dass Kerberos oder NTLM dies verhindern können.

DNS-Record-Typen im Detail

DNS-Records (Resource Records) sind die grundlegenden Datensätze innerhalb einer DNS-Zone. Die Vielfalt der Record-Typen ermöglicht es, weit mehr als nur Name-zu-IP-Zuordnungen abzubilden — DNS dient heute auch zur Mailzustellung, Dienstlokalisierung, Zertifikatsvalidierung und E-Mail-Authentifizierung.

Besonders im Bereich der E-Mail-Sicherheit spielen TXT-Records eine zentrale Rolle. SPF definiert, welche Mailserver im Namen einer Domäne senden dürfen. DKIM speichert den öffentlichen Schlüssel für die kryptografische Signatur. DMARC legt fest, wie Empfänger mit Nachrichten umgehen sollen, die Prüfungen nicht bestehen. Insider-Wissen: Weniger als 30 % der deutschen Unternehmen haben DMARC mit p=reject konfiguriert — der Rest erlaubt es Angreifern, E-Mails mit ihrer Domain als Absender zu versenden. Und selbst mit DMARC: BIMI (Brand Indicators for Message Identification) zeigt das Firmenlogo neben verifizierten E-Mails an — ein mächtiges Anti-Phishing-Tool, das kaum jemand nutzt.

• A / AAAA-Record: Bildet Domänennamen auf IPv4 (A) bzw. IPv6 (AAAA) Adressen ab. Insider-Tipp: Wenn Sie AAAA-Records für eine Domain setzen, stellen Sie sicher, dass Ihre Firewall auch IPv6-Traffic filtert — viele Firewalls lassen IPv6 standardmäßig ungeprüft durch („IPv6 Bypass“).
• MX-Record: Definiert den Mailserver mit Priorität. Insider-Tipp: Domains, die keine E-Mails senden, sollten trotzdem einen „Null-MX“-Record (. 0) und SPF (v=spf1 -all) haben — das verhindert Missbrauch der Domain für Spoofing.
• CNAME-Record: Erstellt einen Alias. Insider-Risiko: Dangling CNAME / Subdomain Takeover: Wenn ein CNAME auf einen Cloud-Dienst zeigt (z. B. app.firma.de CNAME firma.azurewebsites.net) und der Cloud-Dienst gelöscht wird, kann jeder diesen Cloud-Hostnamen registrieren und Inhalte unter app.firma.de bereitstellen — inklusive Phishing-Seiten mit gültigem SSL-Zertifikat. Tools wie subjack und can-i-take-over-xyz finden diese verwundbaren CNAMEs.
• TXT-Record (SPF / DKIM / DMARC): SPF (v=spf1 include:_spf.google.com ~all), DKIM und DMARC (v=DMARC1; p=reject; rua=mailto:[email protected]). Insider-Tipp: Starten Sie DMARC mit p=none und rua= (Aggregate Reports) für 4–6 Wochen, analysieren Sie die Reports mit DMARC Analyzer oder dmarcian, und steigern Sie dann schrittweise zu p=quarantine und schließlich p=reject.
• CAA-Record (Certificate Authority Authorization): Ein oft vergessener Record-Typ: CAA definiert, welche Zertifizierungsstellen SSL-Zertifikate für Ihre Domain ausstellen dürfen. Ohne CAA-Record kann jede CA weltweit ein Zertifikat für Ihre Domain ausstellen — einschließlich Let's Encrypt (von Angreifern bei Subdomain Takeover genutzt). firma.de. CAA 0 issue "letsencrypt.org" erlaubt nur Let's Encrypt.
• SRV-Record: Definiert Hostname, Port und Priorität für Dienste. Insider-Wissen für AD: Die SRV-Records _ldap._tcp.dc._msdcs und _kerberos._tcp sind die kritischsten DNS-Records in einer AD-Umgebung. Wenn ein Angreifer diese Records manipuliert, kann er Clients auf einen gefälschten DC umleiten. DNS-Zonen für _msdcs sollten AD-integriert und nur für authentifizierte Benutzer beschreibbar sein.

DNS-Angriffstechniken — was Penetration Tester wirklich ausnutzen

DNS wurde in den 1980er-Jahren ohne Sicherheitsmechanismen entwickelt — Anfragen und Antworten sind standardmäßig unverschlüsselt und unauthentifiziert. Diese Designentscheidung macht DNS 2026 zu einem der vielseitigsten Angriffsvektoren überhaupt. Was auf Penetration Tests am häufigsten gefunden wird, geht weit über klassisches Cache Poisoning hinaus.

• DNS Rebinding — die unterschätzte Gefahr: DNS Rebinding umgeht die Same-Origin-Policy des Browsers. Der Angreifer kontrolliert eine Domain (z. B. evil.com) und deren Nameserver. Beim ersten Aufruf liefert der Nameserver seine eigene IP (mit sehr niedriger TTL, z. B. 1 Sekunde). Der Browser lädt ein JavaScript. Nach Ablauf der TTL liefert der Nameserver für dieselbe Domain plötzlich eine interne IP (z. B. 192.168.1.1 — den Router). Da der Browser glaubt, es sei dieselbe Origin, darf das JavaScript nun HTTP-Requests an den internen Router senden. Damit kann der Angreifer: Router-Konfiguration ändern, IoT-Geräte steuern, interne APIs aufrufen. Verteidigung: DNS-Rebinding-Protection im Resolver (z. B. dnsmasq stop-dns-rebind, Pi-hole hat dies standardmäßig aktiviert).
• DNS Zone Transfer (AXFR) — die Goldgrube für Reconnaissance: Ein DNS-Zonentransfer (dig AXFR firma.de @ns1.firma.de) liefert alle DNS-Records einer Zone — Hostnamen, IP-Adressen, interne Strukturen, Mail-Server, versteckte Subdomains. In korrekt konfigurierten Umgebungen ist AXFR auf autorisierte Secondary-Nameserver beschränkt. Realität: In über 15 % der von uns getesteten Unternehmen war der Zonentransfer für jeden offen. Fix: allow-transfer { none; }; als Default, dann explizit die IPs der Secondary-Server erlauben. Zusätzlich TSIG (Transaction Signature) für authentifizierte Zonentransfers.
• DNS-Amplification-DDoS: Offene DNS-Resolver beantworten Anfragen von beliebigen Quell-IPs. Ein Angreifer sendet eine kleine DNS-Anfrage (60 Bytes) mit der gefälschten Quell-IP des Opfers (IP-Spoofing) und erhält eine große Antwort (4.000+ Bytes bei ANY-Queries). Amplification-Faktor: 50–70x. Mit tausenden offenen Resolvern kann ein einzelner Angreifer Terabit-große DDoS-Angriffe erzeugen. Verteidigung: Keine offenen Resolver betreiben, Response Rate Limiting (RRL) aktivieren, BCP38/BCP84 (Ingress Filtering) auf Netzwerkebene.
• DNS Cache Poisoning 2.0 — SAD DNS (2020): Der SAD DNS-Angriff (Side-channel AttackeD DNS) von Keyu Man und Zhiyun Qian umgeht Source-Port-Randomisierung durch einen ICMP-Rate-Limiting-Seitenkanal im Linux-Kernel. Der Angreifer kann den Quell-Port des DNS-Resolvers ermitteln und gezielt gefälschte Antworten einschleusen — auch bei modernen Resolvern. Betroffen: Alle Linux-basierten Resolver (Unbound, BIND) bis zum Kernel-Patch. Fix: Linux-Kernel aktualisieren + DNSSEC-Validierung aktivieren (macht Poisoning unmöglich, da gefälschte Antworten keine gültige Signatur haben).
• Subdomain Takeover im Detail: Gefährdete Cloud-Dienste: Azure App Service (*.azurewebsites.net), AWS S3 (*.s3.amazonaws.com), GitHub Pages (*.github.io), Heroku (*.herokuapp.com), Shopify (*.myshopify.com). Erkennungszeichen: DNS-Auflösung zeigt NXDOMAIN oder Cloud-Provider-Fehlerseite. Automatisiertes Monitoring: subfinder -d firma.de | httpx -sc -title — alle Subdomains mit HTTP-Status-Codes und Titeln prüfen. 404/NXDOMAIN auf Cloud-CNAMEs = potenzielle Takeover-Gefahr.

DNS-Exfiltration & Tunneling — Daten durch jede Firewall schleusen

DNS-Tunneling ist eine der effektivsten Techniken, um Daten aus einem Netzwerk zu exfiltrieren — und gleichzeitig eine der am wenigsten überwachten. Das Prinzip: Daten werden in DNS-Queries und -Responses kodiert. Da DNS-Traffic auf Port 53 in nahezu jedem Netzwerk erlaubt ist (selbst in stark eingeschränkten Umgebungen), passiert DNS-Tunneling jede Firewall, jeden Proxy und jedes IDS. Über 90 % aller Malware-Familien nutzen DNS für C2-Kommunikation (Palo Alto Unit 42 Report).

So funktioniert es: Der Angreifer kontrolliert eine Domain (z. B. evil.com) und deren autoritätiven Nameserver. Die Malware auf dem kompromittierten System kodiert gestohlene Daten als Subdomain-Labels: aGVsbG8gd29ybGQ.evil.com (Base32/Base64-kodierte Daten). Die DNS-Anfrage traversiert den Unternehmens-Resolver, wird an den autoritätiven Nameserver des Angreifers weitergeleitet, und dieser dekodiert die Daten aus dem Subdomain-Label. Die Antwort kann Befehle enthalten (kodiert als TXT-Record oder CNAME). Throughput: 10–50 KB/s — langsam, aber ausreichend für Credentials, Konfigurationsdateien und Dokumente.

• DNS-Tunneling-Tools: iodine — Erstellt einen IP-über-DNS-Tunnel (vollständiger TCP/IP-Stack über DNS). dnscat2 — Verschlüsselter C2-Kanal über DNS (TXT/CNAME/MX-Records). DNSExfiltrator — Spezialisiert auf Datenexfiltration, unterstützt Kompression und Verschlüsselung. Cobalt Strike DNS Beacon — Kommerzielles C2-Framework mit DNS-Kommunikation. Alle diese Tools sind in der Standard-Konfiguration unerkannt durch die meisten DNS-Security-Lösungen.
• Fast Flux — Infrastruktur-Verschleierung: Fast Flux ist eine Technik, bei der die IP-Adresse einer bösartigen Domain alle 30–60 Sekunden ändert (TTL: 30s). Hunderte kompromittierte Systeme (Proxies) dienen als Frontend — der eigentliche C2-Server steht dahinter. Double Fast Flux rotiert zusätzlich die NS-Records. Ergebnis: Der C2-Server ist praktisch nicht auffindbar. Erkennung: Domains mit TTL < 60 Sekunden und > 10 verschiedenen A-Records innerhalb einer Stunde sind hochverdächtig.
• DNS Beaconing — C2-Heartbeat: Malware sendet regelmäßig DNS-Queries an die C2-Domain (z. B. alle 60 Sekunden heartbeat.evil.com). Die Regelmäßigkeit (Beacon-Intervall) ist ein starker Indikator. Erkennung: Statistische Analyse der DNS-Query-Timestamps pro Domain — regelmäßige Intervalle (±5 % Jitter) sind fast nie legitim. Tools: RITA (Real Intelligence Threat Analytics) erkennt Beaconing automatisch in Zeek/Bro-Logs.
• DGA (Domain Generation Algorithm) — C2-Resilienz: Fortgeschrittene Malware generiert täglich tausende pseudo-zufällige Domainnamen (z. B. x7kf9m2p.com, q3nv8r1t.net). Der Angreifer registriert nur eine davon — die Malware fragt alle ab, bis sie die aktive findet. Erkennung: DGA-Domains haben eine hohe Entropie (zufällige Zeichenfolgen), sind nicht in Alexa/Tranco-Toplisten, und werden nur von einem einzigen Client abgefragt. Machine-Learning-Modelle (Random Forest, LSTM) erkennen DGA-Domains mit >95 % Accuracy. Pi-hole und NextDNS bieten DGA-Detection als Feature.

DNS-Sicherheit & Verteidigung — die mehrschichtige Strategie

DNS-Sicherheit erfordert einen mehrschichtigen Ansatz: Integrität (DNSSEC), Vertraulichkeit (DoH/DoT), Monitoring (Passive DNS) und aktive Verteidigung (RPZ, Sinkholing). Die meisten Unternehmen setzen nur einen Bruchteil dieser Maßnahmen ein — und übersehen die effektivsten.

• DNSSEC — Integrität sicherstellen: DNSSEC erweitert DNS um kryptografische Signaturen (RRSIG, DNSKEY, DS, NSEC/NSEC3). Validating Resolver prüfen diese automatisch und verwerfen manipulierte Antworten. Insider-Wissen: Weniger als 5 % der .de-Domains nutzen DNSSEC. Der Hauptgrund: Angst vor Key-Rollover-Fehlern, die die gesamte Domain unerreichbar machen können. Fix: Managed-DNS-Anbieter (Cloudflare, AWS Route 53) übernehmen Key-Rollover automatisch — kein manuelles Key-Management erforderlich.
• DNS over HTTPS (DoH) / DNS over TLS (DoT) — Vertraulichkeit: DoH (Port 443) und DoT (Port 853) verschlüsseln DNS-Traffic. Insider-Dilemma: DoH ist gut für Privatanwender (schützt gegen ISP-Überwachung), aber schlecht für Unternehmen — es verschlüsselt DNS-Traffic innerhalb von HTTPS, wo er nicht mehr von Security-Tools inspiziert werden kann. Malware nutzt DoH für C2-Kommunikation, die kein DNS-Security-Tool erkennt. Enterprise-Empfehlung: DoH auf Endgeräten blockieren (Gruppenrichtlinie: Disable DNS over HTTPS), stattdessen DoT zum internen Resolver + RPZ/DNS-Filtering auf dem Resolver.
• Response Policy Zones (RPZ) — die DNS-Firewall: RPZ ist der effektivste und kostengünstigste DNS-Schutzmechanismus. RPZ-Feeds von Threat-Intelligence-Anbietern (Farsight DNSDB, Spamhaus, SURBL) werden in den Resolver integriert und blockieren Anfragen an bekannte Malware-, Phishing- und C2-Domains. Insider-Tipp: Kombinieren Sie kommerzielle RPZ-Feeds mit eigenen Blocklisten (erkannte IOCs aus Ihrem SIEM) und Community-Listen (URLhaus, PhishTank). Die Kombination ergibt eine Detection Rate >95 % für bekannte Threats.
• DNS Sinkholing — Malware-C2 unterbrechen: Statt C2-Domains zu blockieren (NXDOMAIN), leiten Sie sie auf einen internen Sinkhole-Server um, der alle Verbindungsversuche protokolliert. Vorteil: Sie erkennen welche internen Systeme versuchen, die C2-Domain zu kontaktieren — und identifizieren so infizierte Hosts. Palo Alto DNS Security, Infoblox BloxOne und Pi-hole unterstützen Sinkholing nativ.
• Passive DNS — das Gedächtnis des DNS: Passive DNS sammelt DNS-Anfragen und -Antworten an strategischen Punkten (Resolver, Network Taps) und baut eine historische Datenbank auf. Damit lässt sich rückwirkend rekonstruieren: Welche Domain war wann auf welche IP aufgelöst? Welche Domains teilen sich eine IP (Shared Hosting → Indicator of Compromise)? Wann wurde eine Domain erstmals gesehen (NXD → plötzlich aktiv = verdächtig)? Dienste: Farsight DNSDB, VirusTotal, PassiveTotal (RiskIQ). Open Source: passivedns (Gamelinux) als Sensor auf dem Netzwerk-Tap.
• DNS-Tunneling-Erkennung: Payload-Analyse: DNS-Tunneling erzeugt ungewöhnlich lange Subdomain-Labels (>50 Zeichen), hohe Entropie und ungewöhnliche Record-Typen (TXT, NULL). Traffic-Analyse: Abnormal hohe Query-Rate pro Domain (>100 Queries/Minute), abnormales Request/Response-Größenverhältnis. Machine Learning: Random-Forest-Modelle auf Features wie Label-Länge, Entropie, Konsonant-zu-Vokal-Verhältnis, Query-Frequenz. Tools: Zeek + dns-tunnels (Skript), PacketBeat + Elasticsearch (anomale DNS-Muster), Cisco Umbrella (Cloud-basierte DNS-Security mit ML-Detection).