Esta publicación también está disponible en: 日本語 (Japonés)
«87633973eb»> controla (C2) los canales de comunicación sobre el servicio de nombres de dominio (DNS) y, en algunos casos, incluso ha utilizado el protocolo para exfiltrar datos. Esto va más allá de lo que una conexión de «latido» C2 comunicaría., Los actores maliciosos también han infiltrado datos maliciosos/cargas útiles en el sistema víctima a través de DNS y, desde hace algunos años, Unit 42 research ha descrito diferentes tipos de abuso descubiertos.
DNS es un protocolo fundamental y fundamental de internet, a menudo descrito como la «guía telefónica de internet», que asigna nombres de dominio a direcciones IP, y mucho más, como se describe en los RFC principales para el protocolo. La ubicuidad del DNS (y la frecuente falta de escrutinio) puede permitir métodos muy elegantes y sutiles para comunicarse y compartir datos, más allá de las intenciones originales del protocolo.,
además de los ejemplos de uso de DNS ya mencionados, existen una serie de herramientas que pueden permitir, entre otras cosas, que sus atacantes creen canales encubiertos sobre DNS con el fin de ocultar la comunicación o eludir las políticas implementadas por los administradores de red. Un caso de uso popular es evitar el registro de conexión Wi-Fi de hoteles, cafés, etc. mediante el uso del DNS a menudo abierto y disponible. En particular, estas herramientas están disponibles gratuitamente en línea en lugares como GitHub y pueden ser fáciles de usar. Puede encontrar más información sobre estas herramientas en la sección del Apéndice al final de este informe.,
en este informe presentamos los tipos, métodos y uso de la infiltración y exfiltración de datos basados en DNS y proporcionamos algunos indicadores hacia los mecanismos de defensa.
DNS
DNS utiliza el puerto 53, que casi siempre está abierto en sistemas, firewalls y clientes para transmitir consultas DNS. En lugar del Protocolo de control de transmisión (TCP) más familiar, estas consultas utilizan el protocolo de datagramas de usuario (UDP) debido a su baja latencia, ancho de banda y uso de recursos en comparación con las consultas equivalentes a TCP., UDP no tiene capacidades de error o control de flujo, ni tiene ninguna comprobación de integridad para garantizar que los datos lleguen intactos.
¿Cómo es el uso de internet (Navegación, Aplicaciones, chat, etc.) tan confiable entonces? Si la consulta DNS UDP falla (después de todo, es un protocolo de mejor esfuerzo) en primera instancia, la mayoría de los sistemas volverán a intentarlo varias veces y solo después de varios errores, potencialmente cambiarán a TCP antes de volver a intentarlo; TCP también se usa si la consulta DNS excede las limitaciones del tamaño del datagrama UDP, generalmente 512 bytes para DNS, pero puede depender de la configuración del sistema.,
La Figura 1 a continuación ilustra el proceso básico de cómo funciona DNS: el cliente envía una cadena de consulta (por ejemplo, mail.googlecom en este caso) con un cierto tipo – típicamente A para una dirección de host. He omitido la parte por la cual los sistemas DNS intermedios pueden tener que establecer dónde existe ‘.com’, antes de descubrir dónde se puede encontrar ‘googlecom’, y así sucesivamente.
Figura 1., La operación DNS simplificada
una vez que un nombre se resuelve en un almacenamiento en caché IP también ayuda: el nombre a IP resuelto generalmente se almacena en caché en el sistema local (y posiblemente en servidores DNS intermedios) durante un período de tiempo. Las consultas posteriores para el mismo nombre desde el mismo cliente no abandonan el sistema local hasta que caduque dicha caché. Por supuesto, una vez que se conoce la dirección IP del servicio remoto, las aplicaciones pueden usar esa información para habilitar otros protocolos basados en TCP, como HTTP, para hacer su trabajo real, por ejemplo, asegurando que los GIFs cat de internet se puedan compartir de manera confiable con sus colegas.,
entonces, en general, unas pocas docenas de consultas DNS UDP adicionales de la red de una organización serían bastante discretas y podrían permitir que una carga útil maliciosa se dirigiera a un adversario; también se podrían recibir comandos a la aplicación solicitante para su procesamiento con poca dificultad.
si desea profundizar en cómo funciona el DNS, desde que escriba las teclas para deletrear el nombre de dominio que desea navegar, lea este artículo.,
Data Trail
al igual que cuando navega por internet, ya sea pivotando desde un resultado de motor de búsqueda o accediendo directamente a una URL de sitio web, sus consultas DNS también dejan un rastro. La cantidad de seguimiento depende de los sistemas y procesos involucrados en el camino, desde la consulta que sale del sistema operativo hasta la recepción de la dirección IP resultante.,
centrándose solo en el lado del servidor y, utilizando algunos ejemplos básicos, es posible que los servidores DNS, especialmente aquellos con registro extendido o de depuración habilitado, recopilen un host completo (sin juego de palabras) de información sobre la solicitud y el cliente que la solicita.,
Este artículo proporciona una idea del tipo de información que se podría obtener de los registros del servidor DNS; un adversario que opera un servidor de este tipo obtiene la IP remota que envía la solicitud, aunque esto podría ser el último salto o la IP del servidor DNS, no la IP exacta del cliente solicitante, así como la cadena de consulta en sí, y cualquiera que sea la respuesta del servidor.
Tunneling DNS
ahora que tenemos una comprensión común de DNS, cómo funciona en una red y las capacidades de Rastreo del lado del servidor, profundicemos un poco más en las capacidades de tunneling., En esta sección describiremos cómo las balizas de comando y control (C2) pueden operar sobre DNS, y cómo es posible la exfiltración e infiltración de datos.
C2
un canal C2 a menudo sirve dos propósitos para el adversario. En primer lugar, puede actuar como una baliza o latido del corazón que indica que su carga útil remota todavía está funcionando, todavía tiene un latido del corazón, ya que está balizando (comunicándose) a su servidor.
podría considerar la operación DNS básica, como se muestra en la Figura 1 anterior, como un ejemplo de un latido del corazón., Si el implante malicioso en el sistema cliente envía repetidamente una consulta al servidor del actor a través de la infraestructura DNS, el actor podría saber a partir de los registros que se está ejecutando un implante. Lo que se hace difícil es distinguir entre múltiples víctimas que están infectadas con el implante.
considere otro ejemplo descrito en la Figura 2 a continuación, donde el sistema cliente está comprometido con malware que está construyendo cadenas de consulta de aspecto extraño para enviar a través de DNS., Las consultas como estas todavía actúan como un latido del corazón que indica al adversario que su carga útil sigue activa, sin embargo, también proporcionan algunos metadatos básicos sobre la víctima y, lo que es más importante, formas de identificar de manera única a una víctima de otra.
Figura 2., Ejemplo C2 DNS query operation
Los nombres de usuario y los nombres de host pueden no ser siempre únicos, y algunas IPs podrían duplicarse a través de múltiples redes utilizando la traducción de direcciones de red (NAT), sin embargo, los sistemas tienen identificadores únicos universales (UUID) u otras propiedades, que cuando se combinan podrían crear un identificador único para un host o víctima dado.
algunos de los metadatos del host comprometido podrían enviarse como texto sin formato, pero podrían parecer más sospechosos a primera vista a cualquiera que vea tales cadenas en una consulta DNS., En muchos casos, los datos contendrán caracteres no compatibles con DNS, en cuyo caso se requerirá codificación. En la Figura 2 se puede ver el equivalente codificado base64 para los metadatos, que se construye utilizando una notación delimitada ‘ – ‘ para el análisis y decodificación simples en el lado del servidor, como se muestra en la Figura 3 a continuación.
Figura 3., Registros DNS del lado del servidor que rastrean la comunicación C2
La Figura 3 muestra un ejemplo de cómo puede ser un registro DNS sin procesar de una aplicación de servidor DNS, con entradas de línea para la consulta del malware y la respuesta del servidor DNS, NXDOMAIN (o dominio inexistente), en este caso.
de alguna manera, un registro como este, o tal vez una pequeña base de datos que contiene los registros decodificados de ellos, podría compararse con los paneles de control de botnet de aspecto más elegante que permiten al pastor de botnet controlar sus sistemas de víctimas zombis.
exfiltración
entonces, ¿qué más se podría enviar en las consultas DNS?, Bueno, cualquier cosa en teoría, siempre y cuando esté codificada correctamente y no abuse de los límites de tamaño UDP. Una forma de evitar esta última restricción podría ser enviar varios mensajes de registro A y unirlos de alguna manera en el lado del servidor. Sin embargo, surgirían complicaciones en datagramas perdidos o perdidos.
a diferencia de TCP que asegura la retransmisión de paquetes fallidos, UDP no tiene tal mecanismo., Un algoritmo sería necesario para entender cuántos mensajes se enviarán, y comprobar el número correcto llega, pero más complicado que eso, de alguna manera pedir al cliente para retransmitir ciertos segmentos de los datos de nuevo hasta que llegue el 100%. Dependiendo de la cantidad de datos a transmitir – cada PDF en el sistema, por ejemplo – puede tomar una edad, y parecer muy sospechoso para los administradores de red.,
infiltración
por el contrario, la infiltración de datos, ya sea código, comandos o un archivo binario para soltar en el disco y ejecutar podría ser mucho más fácil, especialmente utilizando el tipo DNS de TXT (en contraposición al tipo de registro host A). Los tipos TXT fueron diseñados para proporcionar texto descriptivo, como detalles del servicio, nombres de contacto, números de teléfono, etc. en respuesta a las consultas de DNS TXT para nombres de dominio.
Adivina lo que parece como texto? Base64-codificado sin datos de texto!, La figura 4 a continuación muestra la consulta idéntica que se envía al sitio malicioso como en la Figura 2, sin embargo, el tipo ahora es TXT tanto en la solicitud como en la respuesta, y los datos de respuesta contienen los primeros 300 o más caracteres de un archivo ejecutable binario codificado que podría ser ejecutado por el malware del cliente. Una vez más, utilizando los registros, el adversario sería capaz de saber qué cliente pidió la carga útil, y que la carga útil fue enviada (quién sabe si realmente llegó…).
Figura 4., Ejemplo consulta DNS C2 con respuesta de tipo TXT
pero ¿cómo sabe el implante malicioso cambiar el tipo a TXT o cuándo solicitar lo que haya dentro de los datos de» texto»? Podría ser incorporado a la carga útil para consultar en un cierto punto en su ejecución o después de una cierta cantidad de tiempo, pero en realidad, va a ser impulsado por el actor utilizando el segundo propósito de un control de canal C2.
en mis ejemplos anteriores de comunicación DNS C2 la respuesta del servidor DNS fue NXDOMAIN., Este mensaje, obviamente, llega al sistema cliente (y el malware) y podría ser utilizado un mensaje o instrucción para la carga útil, pero es limitante sin parámetros y detalles. Introduzca NOERROR.
NOERROR, como sugiere el término, significa que todo funcionó bien: su solicitud fue procesada y le espera una respuesta. Con un NOERROR viene una respuesta que puede ser procesada. Por lo general, Este es el IPv4 (para solicitudes de tipo A) o IPv6 (para solicitudes de tipo AAAA) o podría ser TXT, como se muestra en la Figura 4 anterior., Centrándose en un ejemplo simple – la respuesta de la dirección IPv4 – el malware no necesita una IP real para comunicarse con, A diferencia de su navegador que preguntó «¿Dónde está googlecom?”. El malware ya está en comunicación con su destino utilizando el C2 a través de DNS.
para lo que el malware puede usar la respuesta IP es cualquiera de los 4,294,967,296 posibles comandos o instrucciones. Una vez más, manteniendo esto muy simple todavía, es posible que un valor particular en el 4to octeto de la IP, por ejemplo, 100, indicaría al malware para enviar una consulta TXT DNS al dominio del actor para recoger y ejecutar una carga útil., El valor 10 en el primer octeto podría significar desinstalar y borrar los rastros de la carga útil maliciosa del sistema operativo y los registros de eventos. Literalmente, las opciones son infinitas, al igual que los niveles de sofisticación posible.
dado que el adversario tiene control sobre el servidor DNS, y que ciertas aplicaciones de servidor DNS o demonios son altamente configurables, es posible enviar respuestas condicionales al malware en los sistemas víctimas en función de las solicitudes enviadas desde ellos.,
por ejemplo, si la consulta entrante contiene una determinada BANDERA – un carácter – como el primer subdominio del nombre de dominio, podría ser leída por un programa que se ejecuta dentro del servicio DNS en el servidor y proporcionar una respuesta personalizada al cliente. Esto podría ser utilizado para que el malware funcione a través de un conjunto de tareas de forma automática, e informar en consecuencia a los actores para recibir su próxima tarea.
conclusión
DNS es una herramienta muy potente utilizada en casi todas partes que permite a aplicaciones y sistemas buscar recursos y servicios con los que interactuar., El DNS proporciona una base de comunicación que permite que funcionen protocolos de mayor nivel y más potentes, pero puede significar que se pasa por alto desde el punto de vista de la seguridad, especialmente cuando se considera la cantidad de malware que se entrega a través de protocolos de correo electrónico o se descarga de la web mediante HTTP.
por estas razones, DNS es la opción perfecta para los adversarios que buscan un protocolo siempre abierto, a menudo pasado por alto y probablemente subestimado para aprovechar las comunicaciones desde y hacia hosts comprometidos., La unidad 42 Ha Visto múltiples casos de malware, y los actores detrás de ellos, abusando de DNS para tener éxito en sus objetivos, como se discute en este informe.
Las organizaciones pueden defenderse contra el túnel DNS de muchas maneras diferentes, ya sea utilizando la plataforma operativa de seguridad de Palo Alto Networks o la tecnología de código abierto.,lowing:
- bloquear nombres de dominio (o IPs o regiones de geolocalización) basados en la reputación conocida o el peligro percibido;
- reglas alrededor de cadenas de consulta DNS «de aspecto extraño»;
- reglas alrededor de la longitud, el tipo o el tamaño de las consultas DNS salientes o entrantes;
- endurecimiento General de los sistemas operativos del cliente y comprensión de las capacidades de resolución de nombres, así como su orden de búsqueda específico;
- Análisis de comportamiento del Usuario y/o del sistema que detectan se accede a nuevos dominios, especialmente cuando el método de acceso y la frecuencia son anormales.,
- Palo Alto Networks presentó recientemente un nuevo servicio de seguridad DNS centrado en Bloquear el acceso a nombres de dominio maliciosos.
También se puede encontrar más información en la documentación de ATT& CK framework en el sitio web de Mitre. Concretamente, las siguientes técnicas se refieren a los conceptos examinados en el presente informe.,>
Thanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their input on this report.,
Appendix: Toolkit List
| Tool Name | Description |
| dns2tcp | dns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs on Linux. The client can run on Windows. It supports KEY and TXT request types. |
| tcp-over-dns | tcp-over-dns (TCP-over-DNS) was released in 2008., Tiene un servidor basado en Java y un cliente basado en Java. Se ejecuta en Windows, Linux y Solaris. Soporta compresión LZMA y tunelización de tráfico TCP y UDP. |
| OzymanDNS | OzymanDNS está escrito en Perl por Dan Kaminsky en 2004. Se utiliza para configurar un túnel SSH sobre DNS o para la transferencia de archivos. Las solicitudes están codificadas en base32 y las respuestas en registros TXT codificados en base64., |
| iodine | iodine es un programa de tunelización DNS lanzado por primera vez en 2006 con actualizaciones tan recientes como 2010. Fue desarrollado por Bjorn Andersson y Erik Ekman. Iodine está escrito en C y se ejecuta en Linux, Mac OS X, Windows y otros. Iodine ha sido portado a Android. Utiliza una interfaz TUN o TAP en el punto final. |
| SplitBrain | SplitBrain es una variante de OzymanDNS., |
| DNScat-P / dnscat2 | DNScat (DNScat-P) fue publicada originalmente en 2004 y la versión más reciente fue publicado en 2005. Fue escrito por Tadeusz Pietraszek. DNScat se presenta como una herramienta de «navaja suiza» con muchos usos que involucran comunicación bidireccional a través de DNS. DNScat está basado en Java y se ejecuta en sistemas Unix. DNScat soporta un registro y solicitudes de registro CNAME (Pietraszek, 2004)., Dado que hay dos utilidades llamadas DNScat, esta se denominará DNScat-P en este documento para distinguirla de la otra. |
| DNScapy | DNScapy fue desarrollado por Pierre Bienaime. Utiliza Scapy para la generación de paquetes. DNScapy soporta tunelización SSH sobre DNS incluyendo un proxy Socks. Se puede configurar para usar registros CNAME o TXT o ambos aleatoriamente. |
| TUNS | TUNS, un túnel IP sobre DNS, fue desarrollado por Lucas Nussbaum y escrito en Ruby., No utiliza ningún tipo de registro experimental o rara vez utilizado. Solo utiliza registros CNAME. Ajusta la MTU utilizada a 140 caracteres para que coincida con los datos en una solicitud DNS. Los TUNS pueden ser más difíciles de detectar, pero tienen un costo de rendimiento. |
| PSUDP | PSUDP fue desarrollado por Kenton Nacido. Inyecta datos en las solicitudes DNS existentes modificando las longitudes IP / UDP., Requiere que todos los hosts que participan en la red encubierta envíen sus solicitudes DNS a un servicio de Broker que puede retener mensajes para un host específico hasta que una solicitud DNS provenga de ese host. El mensaje se puede enviar en la respuesta. |
| Your Freedom | HTTPS/UDP/FTP/DNS/ECHO VPN & solución de túnel para Windows, Mac OSX, Linux y Android., Omitir proxies y acceder a Internet de forma anónima |
| Hexify | Infoblox desarrolla una herramienta para hacer la prueba de penetración para tunneling DNS., |
Appendix: Malware List
| Malware Name | Description |
| DNS_TXT_Pwnage | A backdoor capable of receiving commands and PowerShell scripts from DNS TXT queries., |
| DNSMessenger | DNSMessenger es un troyano de acceso remoto (RAT) que abre una puerta trasera para que los hackers puedan controlar la máquina comprometida de forma remota |
| oilrig – bondupdater | troyano contra un gobierno de Medio Oriente puede utilizar registros A y registros TXT dentro de su Protocolo de túnel DNS para sus comunicaciones C2 |
