DNS-tunneling og exfiltration

DNS-etiketter skelner ikke mellem store og små bogstaver og har en begrænset længde, så binære data kodes normalt med Base32 (Base64 blander store og små bogstaver og bruger usikre tegn). Begrænsninger, der skal overholdes:

• Hver etiket må højst være på 63 tegn.
• Det samlede navn må højst være på 255 tegn.
• Derfor indeholder hver forespørgsel højst nogle få hundrede bytes.

Den lave overførselshastighed er grunden til, at eksfiltrering over DNS er langsom og kræver mange forespørgsler, hvilket også gør den nem at opdage.

Forskellige recordtyper maksimerer kapaciteten i svarretningen:

• TXT — store fritekstnyttelaster, den primære transportform for C2-svar.
• NULL — rå bytes, brugt af ældre værktøjer som iodine.
• CNAME / MX — moderat kapacitet, falder ind i legitim trafik.
• A / AAAA — lav kapacitet, men meget almindelige og diskrete.

Kendte tunnelværktøjer, som du bør kunne genkende i detektioner:

• iodine — IP-over-DNS-tunnel, der bruger NULL/TXT-records.
• dnscat2 — krypteret C2-kanal over DNS.
• DNSExfiltrator — trinvis fileksfiltrering.
• Cobalt Strike DNS-beacon — almindelig i red-team-øvelser og virkelige indtrængninger.

Disse værktøjer har genkendelige forespørgselsmønstre og entropisignaturer.

Angribere justerer tunnelen: En langsom og lavfrekvent profil sender få forespørgsler i minuttet for at undgå volumengrænser og egner sig til diskret eksfiltrering af små hemmeligheder som legitimationsoplysninger eller nøgler.

En profil med høj datahastighed maksimerer antallet af forespørgsler til interaktiv C2 eller masseoverførsel og bytter diskretion for hastighed. Detektionslogikken skal kunne fange begge yderpunkter.

Kodede underdomæner ligner tilfældige strenge og har derfor høj entropi sammenlignet med naturlige domænenavne. Beregning af Shannon-entropi pr. etiket er en stærk heuristik.

Legitime navne har en tendens til at kunne udtales og have lav entropi; xj4k9d2mq7zp1.tunnel.evil.com skiller sig ud. Markér domæner, hvis underdomæneentropi overstiger en kalibreret tærskel.

Andre adfærdsmæssige indikatorer:

• Usædvanligt højt antal forespørgsler til ét domæne fra én vært.
• Lange forespørgselsnavne, der nærmer sig grænsen på 255 byte.
• Uforholdsmæssigt mange TXT- eller NULL-records.
• Mange unikke underdomæner under ét overordnet domæne (høj kardinalitet).
• Forespørgsler til et nyoprettet domæne med lavt omdømme.

Slutenheder bør aldrig foretage DNS-forespørgsler direkte til internettet. Tving alle klienter gennem interne resolvere, og blokér udgående UDP/TCP 53 i firewallen.

Det leder DNS gennem et kontrolleret kontrolpunkt, hvor du kan logge, inspicere og anvende trusselsintelligens. Det afbryder også implantater, der fastkoder eksterne resolvere som 8.8.8.8.

Kombinér kontroller for at lukke tunneling ned:

• Centralisér navneopløsningen, og blokér direkte adgang til ekstern port 53.
• Implementér en DNS-firewall / RPZ med feeds om omdømme.
• Opret alarmer for entropi, forespørgselslængde, NXDOMAIN-rate og kardinalitet pr. domæne.
• Begræns hastigheden, og sæt om muligt et maksimum for forespørgselsstørrelsen.
• Hold øje med DoH til ukendte slutpunkter, som skjuler tunneling i HTTPS.

DNS over HTTPS pakker forespørgsler ind i TLS på 443, så traditionel overvågning af port 53 ser intet. Et implantat, der bruger DoH til et uautoriseret slutpunkt, kan føre data gennem tunnelen uden at blive synligt for passiv DNS-logning.

Afhjælp dette ved at fastlåse slutpunkter til en godkendt DoH-resolver, blokere kendte offentlige DoH-IP-adresser og -værtsnavne på administrerede enheder samt inspicere TLS SNI og destinationens omdømme.

DNS-tunneling misbruger underdomæner i forespørgsler og records i svar (TXT, NULL, CNAME) til at oprette en skjult kanal til eksfiltrering og C2. Overførselshastigheden er lav, så det er langsomt, men diskret. Værktøjer som iodine og dnscat2 efterlader genkendelige mønstre.

Opdag det med analyser af entropi, forespørgselslængde, mængde og kardinalitet; forebyg det med centraliserede resolvere, udgående filtrering, DNS-firewalls/RPZ og kontrol over DoH. Næste emne er, hvordan DNSSEC og filtrering beskytter navnesystemet som helhed.