ALAKEEL

DNS für Pentester

DNS ist für dich als Pentester im Prinzip das Telefonbuch des Internets – und gleichzeitig eine riesige Informationsquelle + potenter Angriffsvektor.
Wenn du DNS gut verstehst, wirst du bei der Recon besser, findest versteckte Systeme leichter und erkennst Angriffe/Misskonfigurationen schneller.

Ich geh das durch mit Fokus auf:

  • Wie DNS funktioniert (nur so tief wie nötig)
  • Welche Record-Typen für Pentester wichtig sind
  • Was du in der Recon mit DNS machst
  • Typische Schwächen & Angriffe rund um DNS
  • Was du im Pentest-Bericht dazu schreiben kannst

1. Was ist DNS überhaupt?

DNS (Domain Name System) übersetzt Namen in IP-Adressen und andere Infos.

  • Du tippst ein: https://app.example.com
  • Browser fragt: „Welche IP hat app.example.com?“
  • DNS antwortet z. B.: 203.0.113.10
  • Erst dann wird eine TCP/HTTPS-Verbindung aufgebaut

Ohne DNS müsstest du alles über IP-Adressen machen. DNS ist:

  • verteilt
  • hierarchisch
  • cachend (um Performance zu verbessern)

Für Pentester ist DNS:

  • Ein Recon-Tool (Subdomains, interne Hinweise, alte Systeme)
  • Ein Angriffsvektor (DNS spoofing, tunneling, exfiltration)
  • Ein Indikator für Struktur & Organisation eines Unternehmens

2. DNS-Hierarchie – wer fragt wen?

2.1 Beteiligte

  • Client / Resolver
    Meist dein OS/Browser → spricht mit einem rekursiven Resolver (z. B. vom ISP, Unternehmen, 1.1.1.1, 8.8.8.8).
  • Rekursiver Resolver
    • Nimmt die Anfrage deines Clients.
    • Fragt bei Bedarf andere Nameserver und cached Antworten.
  • Authoritative Nameserver
    • Zuständig für eine bestimmte Zone, z. B. example.com.
    • Liefert „offizielle“ Antworten (z. B. A-Record von www.example.com).
  • Root & TLD-Server
    • Root (.) verweist auf .com-TLD.
    • TLD-Server (.com) verweist auf Nameserver für example.com.
    • Die wiederum kennen Details zu Hosts unter example.com.

2.2 Typischer Ablauf

User → fragt Resolver:

  1. app.example.com?
  2. Resolver kennt es nicht → fragt Root: „Wer ist zuständig für .com?“
  3. Root: „Da sind die .com-Nameserver.“
  4. Resolver: „Wer ist zuständig für example.com?“
  5. TLD: „Hier sind die Nameserver: ns1.example.net …“
  6. Resolver fragt ns1.example.net: „A-Record für app.example.com?“
  7. Antwort: 203.0.113.10
  8. Resolver cached das und gibt es an den Client zurück.

3. Wichtige DNS-Records für Pentester

3.1 A- und AAAA-Records

  • A-Record → Name → IPv4
    app.example.com → 203.0.113.10
  • AAAA-Record → Name → IPv6

Pentest-Relevanz:

  • Basis für Ziel-IP.
  • Mehrere A-Records (Round Robin) → mehrere Server.
  • Abweichende IPs pro Subdomain zeigen verschiedene Umgebungen:
    dev.example.com, test.example.com, vpn.example.com usw.

3.2 CNAME (Alias)

  • „Alias-Record“: Name zeigt auf anderen Namen.

Beispiel:

www.example.com CNAME app.example.com

Pentest-Relevanz:

  • CNAME kann auf externe Systeme zeigen (z. B. Cloud, SaaS, CDN):
    app.example.com CNAME mycorp.azurewebsites.net
  • Interessant für:
    • Cloud-Asset-Identifikation
    • Mögliche Subdomain-Takeover-Szenarien (wenn Ziel nicht mehr existiert, aber CNAME noch zeigt)

3.3 MX-Records (Mail-Server)

  • Zuständig für E-Mail für eine Domain.

Beispiel:

example.com MX 10 mail1.example.com
example.com MX 20 mail2.backup-provider.net

Pentest-Relevanz:

  • Zeigt Mail-Infrastruktur:
    • Eigener Mailserver? Externer Provider?
  • Mailserver sind häufig:
    • Für Credential-Stuffing, Phishing-Simulation, SMTP-Prüfungen relevant.
  • Manchmal verraten Hostnames interne Strukturen:
    • exchange01.internal.example.com

3.4 NS-Records (Nameserver)

  • Welche Server sind authoritative für die Zone.

Beispiel:

example.com NS ns1.example.com
example.com NS ns2.provider.net

Pentest-Relevanz:

  • Nameserver können selbst schwach konfiguriert sein (z. B. offene Zonen-Transfers).
  • Interne Strukturen/Provider sichtbar:
    • ns1.internal.example.com

3.5 TXT-Records

Freies Textfeld. Sehr häufig genutzt für:

  • SPF (Mail-Sender-Policy),
  • DKIM / DMARC-Informationen,
  • Verifikationen (Google, Office 365, etc.),
  • Manchmal „Debug-/Konfiginfos“ – schlimmstenfalls sogar Secrets 😬.

Beispiel:

example.com TXT "v=spf1 include:_spf.provider.net ip4:203.0.113.20 -all"

Pentest-Relevanz:

  • SPF/DKIM/DMARC helfen dir bei Phishing-/Mail-Security-Bewertung.
  • TXT kann Hinweise auf:
    • Drittanbieter,
    • interne Systeme,
    • Konfigurationsdetails
      geben.

3.6 PTR-Records (Reverse DNS)

  • Mapping IP → Name.

Beispiel:

203.0.113.10.in-addr.arpa PTR app.example.com

Pentest-Relevanz:

  • Reverse-Lookups über IP-Ranges können:
    • Hosts sichtbar machen, die du per Domain nicht erkennst.
    • Interne Namenskonventionen offenlegen:
      db01.prod.example.com, vpn01.eu.example.com.

3.7 SRV-Records

Service-Records, z. B.:

  • _sip._tcp.example.com
  • _kerberos._tcp.example.com
  • _ldap._tcp.example.com

Pentest-Relevanz:

  • Zeigen spezifische Services:
    • VoIP, Kerberos, LDAP, AD-Domänen etc.
  • Besonders spannend in internen DNS-Zonen:
    • Active Directory nutzt massenhaft SRV-Records → hilft sehr in internen Tests.

4. DNS im Pentest: Recon & Informationsgewinn

DNS ist einer deiner ersten Schritte in der Information Gathering / Recon-Phase.

4.1 Zonen und Subdomains identifizieren

Ziele:

  • alle (oder möglichst viele) Subdomains finden:
    • www.example.com
    • app.example.com
    • api.example.com
    • dev.example.com
    • int-vpn.example.com
  • daraus: neue Angriffsflächen entdecken (alte Apps, Staging, Admin-Interfaces, Tools).

Typische Methoden (nur konzeptionell):

  • Dictionary/Brute Force von Subdomain-Namen.
  • Nutzung von:
    • Zertifikats-Transparenz-Logs (CN/SAN → neue Subdomains),
    • öffentliche DNS-Datenbanken,
    • *.example.com-Wildcard-Hinweise,
    • Reverse-DNS über IP-Ranges des Unternehmens.

Als Pentester:

  • Jede gefundene Subdomain ist potenziell ein weiterer Einstiegspunkt.
  • Besonders spannend:
    • dev, test, staging, old, backup, vpn, admin, jira, git, sonarqube, etc.

4.2 Zonentransfer (AXFR) – Klassiker

Zone Transfer (AXFR) ist eigentlich für DNS-Replikation zwischen Nameservern gedacht.

  • Wenn ein Nameserver versehentlich AXFR für jeden erlaubt:
    • Du kannst die gesamte Zone in einem Rutsch bekommen:
      alle A, MX, TXT, SRV-Records, etc.

Pentest-Relevanz:

  • Wenn möglich → Goldmine:
    • Vollständige Asset-Liste,
    • Interne Hostnames,
    • Struktur der Umgebung.

Heutzutage bei externen Zonen selten noch offen, aber:

  • interne Nameserver sind öfter falsch konfiguriert.
  • manchmal „vergessene“ Secondary-Server.

4.3 DNS als Struktur-Landkarte

Anhand von DNS-Strukturen erkennst du:

  • Regionen/Standorte (eu-, us-, ap-),
  • Umgebungen (dev, qa, prod),
  • Technologie-Stacks (Hostnamen wie sharepoint, sap, oracle, k8s, rancher),
  • Partner/Provider (-sf-api, *.cloudapp.azure.com, *.amazonaws.com).

Diese Infos helfen, zielgerichtet weitere Tests zu planen:

  • Wo lohnt sich Web-Pentest?
  • Wo lohnt sich VPN/Infra-Test?
  • Welche externen Dienste sollte man besonders beachten?

5. DNS-Security-Themen & typische Schwachstellen

5.1 Fehlkonfigurierte Nameserver

  • Offene AXFR-Zonentransfers.
  • Rekursive Resolver bei externen DNS-Servern (DDoS-Amplification, Abuse).
  • Veraltete DNS-Software.

Pentest-Bewertung:

  • Offener AXFR ist in vielen Standards ein mittleres bis hohes Risiko (Informationsleck).
  • Offene Rekursion kann DDoS-Mitwirkung ermöglichen → eher Infrastrukturthema.

5.2 Subdomain-Takeover

Konzept:

  1. app.example.com zeigt per CNAME auf myapp.saasprovider.com.
  2. Die Instanz bei saasprovider.com wurde gelöscht, aber CNAME existiert noch.
  3. Angreifer registriert myapp.saasprovider.com neu.
  4. Jetzt kontrolliert er app.example.com (im Rahmen dieses Dienstes).

Pentest-Relevanz:

  • Du suchst nach:
    • CNAMEs/Einträgen, die auf externe Dienste zeigen (z. B. Azure, AWS, GitHub Pages, Heroku, etc.).
    • Zielressourcen, die nicht mehr existieren, aber buchbar sind.
  • Risiko:
    • Angreifer kann legitime Subdomain übernehmen → Phishing, Session-Stealing, Content Injection.

5.3 DNS Cache Poisoning / Spoofing (Konzept)

Ziel:

  • Einen rekursiven Resolver oder Client dazu bringen, falsche DNS-Antwort zu cachen.

Konsequenz:

  • User gehen auf login.example.com → landen aber auf IP eines Angreifers.

Ist heute deutlich schwerer (u. a. durch Zufall in Query-ID + Source-Port), aber nicht unmöglich bei:

  • schwach abgesicherten Resolvern,
  • lokalen DNS-Manipulationen (Malware, Rogue DHCP),
  • fehlenden Sicherheitsmechanismen (z. B. DNSSEC).

Für externe Web-Pentests eher theoretisch, aber in Red-Teams / internen Tests relevanter.

5.4 DNSSEC (Domain Name System Security Extensions)

DNSSEC fügt DNS eine Signierungsschicht hinzu:

  • Antworten werden kryptographisch signiert.
  • Resolver kann prüfen: „Kommt diese Antwort wirklich vom legitimen Nameserver?“

Schützt primär vor:

  • Manipulation/Poisoning von DNS-Zonen auf dem Weg.

Pentest-Perspektive:

  • Du prüfst:
    • Hat die Domain DNSSEC aktiviert?
    • Sind Signaturen korrekt (kein administrativer Fehler)?
  • DNSSEC löst nicht:
    • Probleme im Webserver,
    • HTTPS-Konfiguration,
    • interne Logik.

Es ist eher ein „Nice-to-have“-Plus in der Gesamt-Security.

5.5 DNS als Datenkanal / Tunnel

DNS-Tunneling:
Idee: Daten (z. B. aus einem internen Netz) über DNS-Anfragen an einen externen Server exfiltrieren.

  • Internes System macht DNS-Anfragen zu payload1.attacker.com, payload2.attacker.com…
  • Der externe Nameserver von attacker.com loggt diese Anfragen und rekonstruiert Daten.

Pentest-Relevanz:

  • In Red-Team-/Internal-Szenarien:
    • DNS ist oft nach draußen erlaubt, auch wenn HTTP/HTTPS eingeschränkt ist.
  • Verteidigung:
    • DNS-Logging,
    • Erkennung ungewöhnlicher Query-Patterns (lange Subdomains, hohe Frequenz),
    • Restriktionen / DNS-Proxy.

In einem klassischen Web-Pentest beschreibst du DNS-Tunneling eher auf Konzept-Ebene als Risiko, nicht als tatsächliche Data-Exfiltration.

5.6 Privacy/Leak-Aspekte

  • DNS-Anfragen zeigen, welche Domains ein User anfragt.
  • Ohne Verschlüsselung (klassisches DNS) ist das für jeden zwischen Client und Resolver sichtbar.

Neuere Ansätze:

  • DoT (DNS over TLS),
  • DoH (DNS over HTTPS)
    → Verschlüsselung der DNS-Anfragen.

Pentest-Relevanz:

  • In Unternehmensnetzwerken kann DoH/DoT Logs/Monitoring erschweren oder gewollt sein.
  • Für Web-Pentests meist nicht zentral, aber für Network/Infra-Assessments relevant.

6. DNS im internen Pentest / AD-Umfeld

Wenn du intern testest (z. B. Windows-Domain):

  • AD nutzt DNS intensiv:
    • SRV-Records für Kerberos, LDAP, Domain Controller.
    • Hostnames verraten Rollen der Systeme (dc01, fileserver01, sql01).
  • Interne Zonen:
    • corp.local, ad.example.com, etc.

Pentest-Potenzial:

  • Interne DNS-Abfragen öffnen dir eine genaue Sicht auf:
    • Domain-Controller,
    • File-/DB-Server,
    • Management-Systeme.
  • Manchmal falsche Delegationen oder „vergessene“ Zonen.

7. Typische DNS-bezogene Findings im Pentest-Report

Egal ob externer oder interner Test, du kannst z. B. folgende Findings formulieren:

7.1 Offen zugänglicher Zonentransfer (AXFR)

Beschreibung:
Authoritative Nameserver für example.com erlauben anonymen Zonentransfer. Dadurch kann ein Angreifer sämtliche DNS-Records der Zone abrufen (Hosts, Subdomains, Mailserver, interne Namensräume) und so die Angriffsfläche deutlich erweitern.

Risiko:
Informationsleck / Recon-Erleichterung → meist medium.

Empfehlung:
AXFR nur zwischen autorisierten Nameservern zulassen, IP-basiert einschränken, TSIG verwenden.

7.2 Potenzieller Subdomain-Takeover

Beschreibung:
Mehrere Subdomains (xyz.example.com) zeigen per CNAME oder Alias auf externe Dienste, deren Ressourcen nicht mehr existieren. Ein Angreifer könnte diese Ressourcen neu registrieren und so die Subdomain übernehmen.

Risiko:
Content-Injection, Phishing, Cookie-/Session-Missbrauch → je nach Kontext high.

Empfehlung:
Nicht mehr genutzte DNS-Einträge entfernen bzw. externe Ressourcen sichern.

7.3 Fehlende DNSSEC-Signierung

Beschreibung:
Für Domain example.com ist DNSSEC nicht aktiviert. Somit sind DNS-Antworten nicht kryptographisch geschützt und prinzipiell für Manipulation anfällig (z. B. durch Cache Poisoning).

Risiko:
Meist low bis medium (Kontext-abhängig).

Empfehlung:
DNSSEC implementieren, wenn möglich, insbesondere für sicherheitskritische Zonen.

7.4 Informationsreiche / schlecht gepflegte DNS-Zonen

Beschreibung:
Die öffentliche DNS-Zone enthält zahlreiche Einträge, die interne Strukturen und Testsysteme offenbaren (z. B. int-db01.example.com, dev-legacy.example.com). Ein Angreifer kann diese Informationen für gezielte Angriffe auf weniger gehärtete Systeme verwenden.

Risiko:
Erleichterte Recon, Angriffsvektor über schwache/alte Systeme → medium.

Empfehlung:
Aufräumen und Minimierung der öffentlich sichtbaren Einträge, Trennung interner und externer Zonen.

8. Kurz-Zusammenfassung für Pentester

Wenn du DNS im Pentest betrachtest, denk an:

  1. Recon-Tool
    • Subdomains, interne Hinweise, Technologien, Umgebungen.
  2. Asset-Finder
    • mehr Hosts = mehr Angriffsfläche → dev/test/admin/vpn etc.
  3. Infosicherheits-Thema
    • Offene AXFR, Subdomain-Takeover, schlecht gepflegte Zonen.
  4. Integrität & Vertraulichkeit
    • DNSSEC, Cache Poisoning, DNS-Tunneling (in internen/Red-Team-Szenarien).
  5. Bericht
    • Klare Findings + konkrete Handlungsempfehlungen (AXFR abschalten, DNS-Records aufräumen, DNSSEC erwägen, Subdomain-Takeover verhindern).

In

, , , , , , , , , , ,