Skip to content

DNS-Analyse in einer PCAP: Leitfaden für Verteidiger

DNS in einem Netzwerkmitschnitt lesen: Anfragen und Antworten, Antwortcodes, seltene und zufällig wirkende Domains sowie Anzeichen für DNS-Tunneling.

Veröffentlicht am 7 Min. Lesezeit

Kurz gesagt. DNS ist in fast jedem Mitschnitt der beste Einstieg: klein, meist unverschlüsselt, und es zeigt, was jeder Host erreichen wollte. Identifizieren Sie zuerst die Resolver, lesen Sie dann die angefragten Namen, ihre Antwortcodes und Antworten, und verknüpfen Sie die Antworten mit den folgenden Verbindungen. Achten Sie auf Namen, die nur einmal angefragt werden, auf Serien von NXDOMAIN für zufällig wirkende Namen und auf viele lange, eindeutige Subdomains unter einer Domain. Diese Muster deuten auf Domain-Generierungsalgorithmen und DNS-Tunneling hin, doch CDNs, Sicherheitsprodukte und Browser erzeugen ähnliche Muster – behandeln Sie sie als Spuren, die bestätigt werden müssen.

DNS in einem Mitschnitt: die Grundlagen

Ein DNS-Austausch besteht normalerweise aus einer Anfrage und einer Antwort über UDP-Port 53, verknüpft über eine 16-Bit-Transaktions-ID. Große Antworten und Zonentransfers nutzen TCP. RFC 1035 definiert das Nachrichtenformat und die Grenzen, die man kennen sollte: Ein Label (der Text zwischen zwei Punkten) ist höchstens 63 Oktette lang, ein vollständiger Name höchstens 255.

Die Felder, die Sie am häufigsten lesen:

FeldWas es verrät
Anfragename (QNAME)Was der Client erreichen wollte
AnfragetypA / AAAA (Adressen), CNAME (Alias), MX, TXT, NS, PTR, SRV ...
Antwortcode (RCODE)NOERROR, NXDOMAIN (Name existiert nicht), SERVFAIL, REFUSED
AntwortenZurückgegebene Adressen, Aliase oder Texte, jeweils mit TTL
Client und ServerWelcher Host gefragt und welcher Resolver geantwortet hat

Da Resolver Antworten für die Dauer der TTL zwischenspeichern, zeigt ein Mitschnitt die erste Auflösung eines Namens, nicht jeden Besuch. Ein Host, der eine gecachte Adresse wiederverwendet, erzeugt Verbindungen ohne passende Anfrage im Mitschnitt.

Eine Lesereihenfolge, die funktioniert

1. Die Resolver identifizieren

Listen Sie die Server auf, die auf Port 53 antworten. In einem verwalteten Netz sollten Clients die internen Resolver nutzen. Ein Arbeitsplatz, der Anfragen direkt an einen externen Resolver schickt, umgeht Protokollierung und Filterung. Achten Sie auch auf DNS over TLS auf Port 853 (RFC 7858) und bedenken Sie, dass DNS over HTTPS (RFC 8484) wie gewöhnliches HTTPS aussieht; die TLS-SNI bekannter DoH-Anbieter ist oft der einzige sichtbare Hinweis.

2. Die Namen lesen, gruppiert nach registrierbarer Domain

Gruppieren Sie Anfragen nach registrierbarer Domain (mega.co.nz statt gfs270n.userstorage.mega.co.nz) und zählen Sie sie. Der Großteil der Liste entfällt auf Betriebssystem, Browser und Geschäftsanwendungen. Im Rest steckt meist die Geschichte: Filesharing-Dienste, frisch registrierte Doppelgänger Ihrer eigenen Domains, Anbieter von dynamischem DNS.

3. Die Antwortcodes prüfen

Ein paar NXDOMAIN-Antworten sind normal (Tippfehler, veraltete Suchdomänen). Eine Häufung davon von einem einzelnen Host, für Namen, die maschinell erzeugt aussehen, ist es nicht.

4. Antworten mit Verbindungen verknüpfen

Nehmen Sie für jeden interessanten Namen die zurückgegebenen Adressen und suchen Sie die Verbindungen dorthin direkt nach der Auflösung. Ein Name, der aufgelöst und dann kontaktiert wurde, ist ein stärkerer Beleg als eine bloße Anfrage. Umgekehrt gilt ebenso: Verbindungen zu öffentlichen Adressen ohne vorherige Auflösung können eine fest eincodierte IP nutzen.

Ungewöhnliche Domains erkennen

Selten gesehene Namen

Häufigkeit ist ein überraschend guter Filter. Eine registrierbare Domain, die in einem Mitschnitt nur einmal vorkommt und kein üblicher Hintergrunddienst ist, lohnt einen Blick. PCAP Parser markiert sie als Rarely-seen domain und schließt dabei lokale Suffixe wie .local oder .corp sowie eine kurze Liste gängiger Dienste aus. In einem kurzen Mitschnitt ist allerdings alles selten; die Markierung ist daher bei längeren Aufzeichnungen nützlicher.

Lange und zufällig wirkende Namen

Von Menschen gewählte Namen bestehen aus Wörtern, maschinell erzeugte nicht. Ein einfaches Maß dafür ist die Shannon-Entropie: die durchschnittliche Anzahl Bits pro Zeichen. Labels, die an englische Wörter erinnern, erzielen niedrigere Werte als Labels aus gleichmäßig gemischten Buchstaben und Ziffern. PCAP Parser markiert einen Namen als Random-looking / long, wenn ein Label mit mindestens 12 Zeichen eine Entropie von mindestens 3,4 Bit pro Zeichen hat oder der vollständige Name länger als 60 Zeichen ist.

Der fiktive Beispielmitschnitt des Tools zeigt das Muster. Der Arbeitsplatz fragt zwei Namen an, die scheitern:

q3v9x7kz2m8w4t1r0p6y.info    A   NXDOMAIN
k7f2p9x4w1q8z3m6hd0s.top     A   NXDOMAIN

Beide sind als zufällig wirkend und selten gesehen markiert. Keiner wurde aufgelöst, also folgte keine Verbindung, aber der Host, der sie gesendet hat, hat nun Priorität.

Domain-Generierungsalgorithmen

Manche Malware-Familien berechnen aus einem Startwert, oft dem Datum, eine Liste von Kandidaten-Domains und probieren sie aus, bis eine aufgelöst wird. MITRE ATT&CK beschreibt das als Dynamic Resolution: Domain Generation Algorithms (T1568.002). Im Verkehr sieht das aus wie das Beispiel oben, nur in größerem Maßstab: viele zufällige Namen, meist NXDOMAIN, von einem einzigen Host, oft in regelmäßigen Abständen.

Indikatoren für DNS-Tunneling im Überblick

DNS-Tunneling missbraucht das Protokoll zum Datentransport: Der Client kodiert Daten in die Labels von Anfragen an eine Domain, deren autoritativer Server von der Gegenseite kontrolliert wird, und der Server antwortet mit kodierten Daten. MITRE ATT&CK führt DNS als Command-and-Control-Kanal auf Anwendungsebene unter T1071.004.

Aus Sicht der Verteidigung sind die Indikatoren in einem Mitschnitt:

  • Viele eindeutige Subdomains unter einer registrierbaren Domain, jede nur einmal angefragt.
  • Lange Labels und lange Namen, nahe an den Grenzen von 63 und 255 Oktetten, mit hoher Entropie oder hex- bzw. base32-artigen Alphabeten.
  • Ungewöhnliche Record-Typen in großer Menge, etwa TXT-, NULL- oder CNAME-Antworten mit langen Werten.
  • Volumen und Regelmäßigkeit: ein stetiger Strom von Anfragen an eine Domain von einem Host, auch wenn die Person am Rechner inaktiv ist.
  • Anfrage- und Antwortgrößen deutlich über dem, was der Rest des Netzes sendet.

Keiner dieser Indikatoren ist für sich allein ein Beweis. Das stärkste Signal sind mehrere davon gemeinsam, für eine Domain, von einem Host.

Häufige Fehlalarme

  • CDNs und Cloud-Dienste nutzen lange, gehashte Hostnamen für die Lastverteilung.
  • Sicherheits- und Reputationsdienste fragen bauartbedingt oft Hashes oder kodierte Daten als DNS-Namen ab.
  • Browser: Chromium fragt beim Start zufällige einteilige Namen ab, um DNS-Hijacking zu erkennen; sie liefern NXDOMAIN und sehen wie DGA-Verkehr aus.
  • Diensterkennung und lokale Namensprotokolle wie mDNS und LLMNR erzeugen Broadcast- oder Multicast-Anfragen für lokale Namen.
  • Telemetrie von Betriebssystemen und Agenten kann häufig und regelmäßig sein.

Prüfen Sie vor einer Schlussfolgerung anhand von Endpoint- oder Host-Logs, welcher Prozess auf dem Host den Verkehr erzeugt hat.

Grenzen von DNS-Belegen in einem Mitschnitt

  • Messpunkt. Ein Mitschnitt vor dem rekursiven Resolver (in Richtung Internet) zeigt den Resolver als Fragenden, nicht den Client.
  • Verschlüsseltes DNS. DoH und DoT verbergen die Namen; sichtbar bleiben nur die Resolver-Adresse und die TLS-Metadaten.
  • Caching. Wiederholte Besuche innerhalb einer TTL erzeugen keine neue Anfrage.
  • Snaplen und Verluste. Abgeschnittene oder verlorene Pakete lassen Antworten fehlen. Prüfen Sie die Snaplen des Mitschnitts und etwaige Warnungen.

Im Browser erledigen

Die DNS-Ansicht von PCAP Parser listet jede Anfrage mit Typ, Antwortcode, Antworten und Resolver, markiert zufällig wirkende und selten gesehene Namen und überführt jeden Namen und jede Adresse in die IOC-Liste, die sich als CSV oder JSON exportieren lässt. Filtern Sie auf eine registrierbare Domain, um alle ihre Subdomains auf einmal zu sehen. Der Rundgang erklärt die übrigen Ansichten, und JA3- und JA4-Fingerprinting behandelt, was in den TLS-Sitzungen nach einer Auflösung zu lesen ist.

FAQ

Wie sehe ich DNS-Anfragen in einer pcap-Datei?

Öffnen Sie den Mitschnitt in einem Tool, das DNS dekodiert: Wireshark mit dem Anzeigefilter dns, tshark mit -Y dns oder einem Viewer im Browser wie PCAP Parser, der jede Anfrage mit Typ, Antwortcode und Antworten in einer DNS-Ansicht auflistet.

Was bedeuten viele NXDOMAIN-Antworten?

Viele nicht existierende Namen können von Tippfehlern, falsch konfigurierter Software oder veralteten Suchdomänen stammen. Eine Serie zufällig wirkender Namen, die alle scheitern, ist aber auch ein klassisches Zeichen für einen Domain-Generierungsalgorithmus, der Kandidaten ausprobiert. Prüfen Sie vor einer Schlussfolgerung, welcher Prozess und welcher Host sie gesendet haben.

Lässt sich DNS-Tunneling in einem einzigen Mitschnitt erkennen?

Man kann Indikatoren erkennen: viele eindeutige, lange, zufällig wirkende Subdomains unter einer Domain, ungewöhnliche Record-Typen wie TXT in großer Menge und regelmäßige Zeitabstände. Keiner davon beweist allein ein Tunneling, und legitime Dienste erzeugen einige davon, also bestätigen Sie mit Host-Spuren.

Verwandte Artikel

Was ein JA3-Fingerprint ist, worin sich JA4 unterscheidet, warum Chromes zufällige Extension-Reihenfolge JA3 aushebelte und wie Verteidiger Fingerprints nutzen.
Fairer Vergleich von Wireshark, tshark, NetworkMiner, Zeek, Zui und PCAP Parser für die pcap-Analyse: Stärken, Grenzen und welches Tool wofür passt.
Warum Netzwerkmitschnitte unter DSGVO und Kundenverträgen sensibel sind, wie WebAssembly-Analyse im Browser Uploads vermeidet und wie Sie das selbst prüfen.