DNS-Tunneling erkennen: lange Anfragen, hohe Volumen, seltene Typen

DNS-Tunneling erkennen ist die letzte Erkennung dieser Serie und die, die am weitesten hinten in der Kill Chain ansetzt: Wenn Daten über DNS hinausfließen oder ein Beacon über DNS spricht, ist der Angreifer längst im Netz und hat gefunden, was er wollte. DNS eignet sich dafür, weil es fast überall nach außen erlaubt ist, selten inspiziert wird und mit rekursiver Auflösung einen Weg bietet, der auch dann funktioniert, wenn der Client selbst keine direkte Internetverbindung hat. Dieser Beitrag beschreibt, wie DNS-Tunneling funktioniert, welche Logquellen es zeigen, die Merkmale, die es von normalem DNS unterscheiden, zwei Sigma-Regeln und einen Hunting-Ansatz mit Zählung, den Test und das Tuning, das bei DNS besonders wichtig ist, weil moderne Dienste selbst viel ungewöhnlich aussehenden DNS-Verkehr erzeugen.

Was der Angreifer tut

Beim DNS-Tunneling kontrolliert der Angreifer eine Domain und deren autoritativen Nameserver. Der Client im Opfernetz kodiert Daten in den Namen einer Subdomain, etwa ZXhmaWx0cmllcnRlLWRhdGVu.angreifer.example, und fragt sie ab. Der rekursive Resolver des Unternehmens leitet die Anfrage bis zum Nameserver des Angreifers weiter, der die kodierten Daten aus dem Namen liest und seine Antwort, etwa den nächsten Befehl, in einen TXT-, CNAME- oder NULL-Record kodiert. So entsteht ein bidirektionaler Kanal, der nie eine direkte Verbindung zwischen Client und Angreiferserver braucht, weil der Resolver dazwischen steht. Zwei Anwendungen: als Command-and-Control-Kanal, bei dem kleine Mengen Steuerdaten hin und her gehen (T1071.004), und als Exfiltrationskanal, bei dem größere Datenmengen in vielen Anfragen hinausgeschickt werden (T1048.003). Werkzeuge sind iodine, dnscat2 und die DNS-Kanäle kommerzieller C2-Frameworks. Der Preis für den Angreifer ist die Menge: Weil in jede Anfrage nur wenige Bytes passen, braucht Exfiltration über DNS viele Anfragen, und genau diese Menge ist das, was die Erkennung sieht.

Welche Logquellen die Technik zeigen

Die entscheidende Vorbedingung ist, dass Clients nur über den internen Resolver auflösen dürfen und direkter DNS-Verkehr nach außen an der Firewall blockiert ist. Erst dann laufen alle Anfragen über eine Stelle, an der sie sichtbar sind, und ein Client, der es doch direkt versucht, ist schon dadurch auffällig. Wie DNS-Logs aufgebaut sind, steht im Beitrag zu Zeek.

Das Muster im Log

Normales DNS fragt bekannte Domains mit kurzen, lesbaren Namen ab, meist A- und AAAA-Records, und ein Client stellt über den Tag verteilt eine überschaubare Zahl verschiedener Anfragen pro Domain. Tunneling bricht mit jedem dieser Merkmale, und die Erkennung setzt an fünf davon an. Erstens die Länge: Tunneling-Anfragen sind lang, weil sie Daten tragen; ein abgefragter Name mit über 50 Zeichen im Subdomain-Teil ist selten legitim. Zweitens die Entropie: Kodierte Daten sehen zufällig aus, während echte Subdomains aussprechbar sind; ein hoher Anteil an Ziffern und die Gleichverteilung der Zeichen sind messbar. Drittens der Record-Typ: TXT und NULL tragen viel und werden von Tunneling bevorzugt, während normaler Verkehr fast nur A, AAAA und CNAME kennt; eine Häufung von TXT-Anfragen an eine einzelne Domain ist ein starkes Signal. Viertens die Vielfalt: Beim Tunneling ist fast jede Subdomain einmalig, weil sie andere Daten trägt; ein hoher Anteil eindeutiger Subdomains an allen Anfragen zu einer Domain, nahe 100 Prozent, ist das verlässlichste Merkmal. Fünftens die Menge und der Takt: hunderte oder tausende Anfragen an dieselbe Domain in kurzer Zeit bei Exfiltration, oder regelmäßige Anfragen im festen Takt bei einem Beacon. Die ersten drei Merkmale lassen sich als Regel auf die einzelne Anfrage schreiben; die letzten beiden brauchen eine Aggregation pro Domain, wie sie das Threat Hunting mit Stacking macht.

Zwei Sigma-Regeln

Die erste Regel arbeitet auf der einzelnen Anfrage und fängt die auffälligen Namen, die zweite auf dem Record-Typ.

title: Long DNS Query Name Possible Tunneling
id: 4c9e2b7a-8d1f-4a3e-b6c5-2f0a1d3e4b5c
status: test
description: DNS-Anfrage mit ungewoehnlich langem Namen, moegliches Tunneling
  oder Datenexfiltration ueber DNS.
references:
  - https://attack.mitre.org/techniques/T1071/004/
  - https://attack.mitre.org/techniques/T1048/003/
author: Blue Team
date: 2026-09-13
tags:
  - attack.command_and_control
  - attack.t1071.004
  - attack.exfiltration
  - attack.t1048.003
logsource:
  category: dns_query
  product: windows
detection:
  selection:
    QueryName|re: '^[^.]{52,}\.'      # erste Label laenger als 51 Zeichen
  filter_known:
    QueryName|contains:
      - '.akamai'
      - '.cloudfront.net'
      - '.trafficmanager.net'
      - '._spf.'
  condition: selection and not filter_known
falsepositives:
  - CDNs, Anti-Spam- und Reputationsdienste mit langen kodierten Namen; nach Domain ausnehmen
level: medium
---
title: Rare DNS Record Type To Single Domain
id: 8a3d6f1e-2c9b-4e7a-b5d0-1f4a2b3c9d8e
status: test
tags:
  - attack.command_and_control
  - attack.t1071.004
logsource:
  category: dns_query
  product: windows
detection:
  selection:
    QueryType:
      - 'TXT'
      - 'NULL'
      - 'CNAME'
  filter_known:
    QueryName|contains:
      - '_dmarc'
      - '_domainkey'
      - '.akamai'
  condition: selection and not filter_known
falsepositives:
  - Mail-Authentifizierung (SPF, DKIM, DMARC), CDNs; als Hunting-Suche statt Alarm betreiben
level: low

Die erste Regel ist auf Stufe mittel, weil lange Namen auch legitim vorkommen; die zweite ist bewusst auf niedrig und eignet sich besser als Hunting-Suche denn als Alarm, weil TXT-Verkehr durch Mail-Authentifizierung häufig ist. Der eigentliche Wert steckt in der Aggregation, die Sigma allein nicht ausdrückt: eine Abfrage im SIEM oder gegen das dns.log, die pro Client und Zieldomain die Zahl der Anfragen, die Zahl der eindeutigen Subdomains und deren Verhältnis zählt und alles mit einem Verhältnis nahe 1 und hoher Anzahl meldet. In Pseudocode: gruppiere nach Client und registrierbarer Domain, zähle Anfragen und distinct Subdomains, alarmiere bei Anfragen > 100 und eindeutig/gesamt > 0,9. Diese eine Abfrage findet mehr Tunneling als beide Regeln zusammen; wie man sie als wiederkehrenden Hunt betreibt, steht im Beitrag zu Sigma-Regeln und Threat Hunting.

Der Test

Im Homelab braucht der Test eine Domain, deren Nameserver auf ein System unter eigener Kontrolle zeigt, oder ein Werkzeug wie dnscat2 im Server-Modus auf der Kali-VM und im Client-Modus auf dem Windows-Client. Nach dem Verbindungsaufbau eine kleine Datei durch den Tunnel schicken. Erwartet werden im dns.log des Sensors viele Anfragen an die Testdomain mit langen, zufällig wirkenden Subdomains, ein hoher Anteil an TXT- oder CNAME-Records und ein Verhältnis eindeutiger Subdomains nahe 1; auf dem Client Sysmon 22 mit dem dnscat2-Prozess als Quelle. Die erste Regel trifft auf die langen Namen, die zweite auf die Record-Typen, und die Aggregations-Abfrage zeigt den Client mit dem auffälligen Verhältnis. Atomic Red Team hat für T1048.003 einen Test, der Daten über DNS ausschleust. Wer keinen eigenen Nameserver einrichten will, kann die Erkennung auch gegen öffentliche Beispiel-Captures von DNS-Tunneling validieren, wie im Beitrag zu Wireshark für offene Datensätze beschrieben. Ergebnis und Datum in den Navigator, und damit ist die letzte Technik der Serie abgedeckt.

Fehlalarme und Tuning

• Content Delivery Networks. CDNs kodieren Informationen in lange, zufällig wirkende Subdomains, und Clients fragen viele davon ab. Die großen Anbieter kommen auf eine Erlaubnisliste, die regelmäßig geprüft wird, weil Angreifer legitime CDNs auch missbrauchen.
• Reputations- und Anti-Spam-Dienste. Virenscanner, Mail-Gateways und Sicherheitsprodukte fragen Reputationsdaten über DNS ab, mit langen kodierten Namen und hoher Vielfalt, die exakt wie Tunneling aussieht. Ihre Domains gehören namentlich in den Filter; das ist der häufigste Fehlalarm überhaupt.
• Mail-Authentifizierung. SPF, DKIM und DMARC erzeugen TXT-Verkehr an vielen Domains und lösen die zweite Regel aus, wenn sie als Alarm läuft. Deshalb ist sie als Hunting-Suche gedacht, nicht als Alarm, und die bekannten Mail-Muster sind ausgenommen.
• Telemetrie und Cloud-Dienste. Manche Anwendungen betten Statusinformationen in DNS-Namen ein. Sie werden bei der Erstellung der Baseline gefunden und ausgenommen; die Aggregations-Abfrage hilft dabei, weil sie die Domains mit hohem Verhältnis auflistet, die dann einmal bewertet werden.
• Die Gegenmaßnahme, die die Regel entlastet. Clients dürfen nur über den internen Resolver auflösen, direkter DNS-Verkehr nach außen ist blockiert, und der Resolver führt eine Blockliste für bekannte Tunneling-Domains und neu registrierte Domains. Ein DNS-Firewall- oder Protective-DNS-Dienst übernimmt beides und meldet Anomalien selbst. Danach ist Tunneling nicht nur erkennbar, sondern in vielen Fällen schon blockiert, und die verbleibende Erkennung bestätigt, dass die Kontrolle greift.

Fazit

DNS-Tunneling ist der Kanal, den Angreifer wählen, wenn alles andere blockiert ist, und er verrät sich durch das, was er tragen muss: lange, zufällige Namen, seltene Record-Typen und vor allem eine Flut eindeutiger Subdomains an eine einzelne Domain. Die einzelne Anfrage liefert einen Verdacht, die Aggregation pro Domain liefert den Beweis, und wer den internen Resolver erzwingt und eine Protective-DNS-Lösung betreibt, macht aus der Erkennung eine Sperre. Damit schließt die Serie „Angriff erkennen“: von Kerberoasting am Anfang der Kill Chain bis zur Exfiltration über DNS am Ende hat jedes Kapitel dasselbe Muster, Logquelle, Merkmal, Regel, Test, Gegenmaßnahme, und zusammen ergeben sie die Abdeckungskarte, an der ein Blue Team seine Erkennung messen kann. Der nächste Schritt ist, jede dieser Regeln in der eigenen Umgebung zu testen und in die Purple-Team-Übung aufzunehmen.