octoberfest7/dns_tunnelingHerramienta de tunelización DNS que utiliza PowerShell y Nslookup para exfiltrar datos y entregar cargas útiles a través de registros DNS TXT/MX, evitando el Modo de Lenguaje Restringido y las defensas de endpoints.
Inspirado por un trabajo reciente que realicé con balizas DNS de Cobalt Strike, junto con una declaración de misión para intentar evadir Microsoft Defender para Endpoint, dediqué un tiempo a investigar cómo se podría usar DNS para transferir un payload a una máquina objetivo. Además, quería desafiarme a mí mismo intentando hacerlo de una manera que sea posible incluso cuando PowerShell está en Modo de Lenguaje Restringido. Esta investigación estaba dirigida a implementaciones más modernas de Windows (es decir, Win10+, Server 2019+), pero como verán más adelante, podría ser posible en versiones anteriores.
El tunelizado DNS es una técnica que existe desde hace mucho tiempo y es utilizada por diversos atacantes. A nivel básico, implica usar el protocolo DNS como medio para la infiltración/exfiltración de datos o como canal de comunicaciones C2. Hay muchas publicaciones en blogs que puedes consultar para obtener más información sobre este tema.
Debido a que es una técnica tan antigua y conocida, muchas organizaciones tienen métodos de detección implementados para intentar prevenirla.
El tipo de registro DNS preferido para el tunelizado DNS ha sido históricamente TXT. Esto se debe a que los registros TXT pueden contener más datos que otros registros y además distinguen entre mayúsculas y minúsculas, algo que los otros registros no hacen, lo que puede tener un impacto cuando comenzamos a hablar de codificación.
El Modo de Lenguaje Restringido (CLM) es un modo de lenguaje restrictivo para PowerShell que reduce en gran medida las capacidades y la funcionalidad permitida de PowerShell. En una lista breve, .NET, objetos COM y los favoritos de los atacantes como (new-object net.webclient).downloadstring... no están disponibles. Este enlace proporciona más información. Las organizaciones imponen esta política para usuarios normales como parte de las reglas de reducción de superficie de ataque. En efecto, solo hace que nuestras vidas como atacantes sean más difíciles.
La mayoría debería estar al menos familiarizada con DNS por el uso de herramientas como Nslookup. Pero a nivel básico, el cliente envía una consulta y el servidor DNS devuelve una respuesta a esa consulta. Existen varios tipos diferentes de registros DNS: CNAME, A, AAAA, TXT, MX y NS, solo por nombrar algunos. Cada uno de estos registros puede almacenar y devolver información diferente. Estos registros se configuran en un archivo de zona, que es servido por un servidor DNS.
Se muestra un ejemplo de archivo de zona aquí:``` $ORIGIN example.com. @ 3600 SOA ns1.p30.dynect.net. ( zone-admin.dyndns.com. ; address of responsible party 2016072701 ; serial number 3600 ; refresh period 600 ; retry period 604800 ; expire time 1800 ) ; minimum ttl 86400 NS ns1.p30.dynect.net. 86400 NS ns2.p30.dynect.net. 86400 NS ns3.p30.dynect.net. 86400 NS ns4.p30.dynect.net. 3600 MX 10 mail.example.com. 3600 MX 20 vpn.example.com. 3600 MX 30 mail.example.com. 60 A 204.13.248.106 3600 TXT "v=spf1 includespf.dynect.net ~all" mail 14400 A 204.13.248.106 vpn 60 A 216.146.45.240 webapp 60 A 216.146.46.10 webapp 60 A 216.146.46.11 www 43200 CNAME example.com.
Si alguien consultara los registros NS de example.com, la consulta devolvería ns1.p30.dynect.net, ns2.p30.dynect.net, ns3.p30.dynect.net y ns4.p30.dynect.net.
# Investigación
## Registro de nombres de dominio
Antes de empezar, debemos hablar brevemente sobre cómo configurar registros DNS para que apunten a una IP que controlamos y en la que ejecutaremos un servidor DNS. Como se muestra a continuación, compré un dominio y configuré registros DNS que dirigen el subdominio "dns" al subdominio "ns1", al cual se le asigna la IP pública del servidor.
Esto significa que cualquier consulta realizada para "dns.edu....com" será dirigida a "ns1.edu....com", que tiene asignada la IP 3..86. En esa IP configuraremos un servidor DNS para servir nuestros registros. Esto retomará su sentido más adelante.
## Encontrando una herramienta del lado del cliente
Mi búsqueda comenzó con una simple consulta en Google de "powershell dns module" que devolvió [este](https://docs.microsoft.com/en-us/powershell/module/dnsclient/?view=windowsserver2022-ps) enlace. De particular interés fue el comando `Resolve-DnsName`. Parece ser básicamente una implementación en PowerShell del conocido binario Nslookup.exe. Nótese que se pueden solicitar tipos específicos de registros:
Bien, entonces tenemos un módulo de PowerShell capaz de hacer consultas DNS y recuperar la respuesta. ¿Funciona en modo de lenguaje restringido (CLM)? La respuesta es más o menos.
Como se puede ver aquí, si abro una nueva ventana de PowerShell, ejecuto `Resolve-DnsName`, pongo PowerShell en CLM (y pruebo con la simple llamada `::WriteLine`), y luego ejecuto `Resolve-DnsName` nuevamente, funciona sin problemas:
Sin embargo, si abro una nueva ventana de PowerShell y la pongo inmediatamente en CLM y luego intento ejecutar `Resolve-DnsName`, falla:
Parece que si un módulo se ha cargado previamente, puede ejecutarse después de que se aplique CLM; sin embargo, CLM impedirá que se cargue si no lo ha hecho ya. Pensando en un entorno objetivo donde CLM está aplicado por defecto para los usuarios (y sin saber si ciertos módulos están precargados o si DnsClient es uno de ellos), en este punto decidí dejar atrás `Resolve-DnsName` y volver al viejo `Nslookup.exe`.
Nslookup.exe es un elemento básico del conjunto de herramientas de TI y un binario muy conocido utilizado con fines legítimos. Las probabilidades están a nuestro favor de que se permita su ejecución incluso en entornos donde la lista blanca de aplicaciones es una preocupación.
Nslookup devolverá prácticamente la misma información que nuestra consulta con `Resolve-DnsName`, solo que tendremos que manipularla de manera un poco diferente cuando llegue el momento.
## ¿Convertir un ejecutable en registros DNS?
Bien, tenemos un medio para hacer consultas DNS en la computadora víctima. ¿Cómo podemos proporcionar nuestro payload en un formato que Nslookup pueda recuperar?