¡Estimados amigos de visionarios!
Hoy vamos a mostrar un proceso muy interesante, y por desgracia, habitual, en el que vemos como organizaciones criminales realizan la tarea de post-explotación de datos sensibles mediante el DNS.
Vamos a intentar explicar los conceptos, mostrar alguna herramienta y alguna medida de seguridad.
Para empezar, ¿qué es el concepto de exfiltración? Muy sencillo, robar información. Es habitual en los últimos casos de Ransomware encontrar ataques en los que no solo cifran la empresa, haciendo inservible el sistema, sino que roba una base de datos con información para extorsionar a la empresa por esa vía. Si te gusta Mitre, la táctica.
Muchas empresas cuentan con medidas de Data Lost Prevention, aunque no lo creas, puede que tu Firewall de nueva generación tenga algún indicador, o tu sistema de correo…
En vez de enviar un correo el malo con un docx… emplean el dns. Lo normal es que los equipos tengan habilitada la salida hacia el dns abierta, igual que hacia el puerto 80 (para ver webs) y lo que el administrador haya permitido…por cierto, ¿tú bloqueas el tráfico de salida de tus equipos o dejas que naveguen hacía puertos raros? seguimos…
Imagina que quieres enviar la siguiente información: Joaquin molina es el hacker mas guapo del mundo.
Imagina que monto un server dns falso por internet, y en un equipo vulnerado, pregunto:
Quien es joaquin.eldominioquetengohacker.com
Quien es molina.eldominioquetengohacker.com
Quien es es.eldominioquetengohacker.com
Quien es el.eldominioquetengohacker.com
Quien es hacker.eldominioquetengohacker.com
Quien es mas.eldominioquetengohacker.com
Quien es guapo.eldominioquetengohacker.com
Quien es del.eldominioquetengohacker.com
Quien es mundo.eldominioquetengohacker.com
Al servidor dns falso le llegaran las preguntas. Da igual que responda… solo tiene que procesar las peticiones y componer el mensaje…
Digamos que en este caso se usan los subdominios, pero en nuestra POC vamos a usar el campo TXT, un tipo de registro que me permite escribir información.
Este tipo de registros y el concepto es usado largo y tendido por los grupos criminales también para hacer el Command & Control.
Pues con esto tenemos el concepto, ahora la tool. Hay varias herramientas en el rico ecosistemas de github, pero en esta ocasión nos decantamos por https://github.com/Arno0x/DNSExfiltrator . La herramienta tiene una parte servidor, un script en Python y una parte cliente, que se puede ejecutar desde un Powershell, binario, compilarlo…
El proceso comienza poniendo nuestro servidor dns “falso” a escuchar.
Hay que tener claro algunos conceptos básicos de DNS. Cuando desde un cliente tu preguntas por un dominio, el sistema lo primero que hace es buscar si tiene esta información en local, cache, o en el fichero host, sino, se va a ir al servidor DNS que tiene configurado en sus propiedades tcp/ip y va a buscar el registro NS asociado al dominio, el Name Server, cuando sepa el Name Server, realizará la pregunta del tipo que sea, Txt, Q, etc… y devolverá los resultados.
Vamos a lanzar la tool desde el lado cliente, para exfiltrar un fichero txt.
El sistema hace un zip en memoria con la clave que le pasamos, cifra el resultado con un algoritmo rc4 y clave la misma que indicamos, y normaliza el resultado en base64url para poder lanzar las consultas, respetando mayúsculas y minúsculas… Esto es lo que pasa por debajo.
En un formato más amigable…
Con esto hemos conseguido pasar el fichero entre dos equipos, mediante transporte DNS.
La propia herramienta nos permite hacer un poquito más difícil la detección, y escondiendo nuestro servidor detrás de un CDN, como Cloudflare. De esta manera podemos hacer la petición dns sobre http contra el cdn, y así que no cante que kinoesguapo.com está en la ip…
No obstante, como siempre en Visionarios, el propósito de este post no es mostrar solo el ataque, sino comprender todos los conceptos y sobre todo la mitigación.
Se me ocurren muchas maneras, pero fijaros en la última captura: mirar el tamaño de la consulta, como es normal, preguntar por una “ristra” de caracteres raros pesa mucho más que si preguntamos por “Telepizza.com” que son menos caracteres… fijaros la diferencia del tamaño del payload…
Por si quieres perder un poco de tu vida, puedes leer el RFC1035 del dns para comprobar que, quitando cabeceras, un paquete udp solo podría enviar alrededor de 512bytes, si queremos exfiltrar más información, tendremos que realizar nuevas consultas. El sistema lo controla haciendo un Split de las peticiones y enumerándolas, anteponiendo al texto cifrado un numerador.
Entonces, podríamos crear un baseline o un modelo de ML, lo que más nos apetezca, para identificar cuando tenemos uno o varios payloads “pesados” y encima tenemos un equipo realizando muchas consultas contra un servidor… que encima no está dentro de los “autorizados”, aunque esto no es necesario del todo.
Por ejemplo, en mi POC he usado un dns active directory con una zona nueva, y he creado el registro NS que apuntaba a mi máquina Linux. En un entorno real, no creo que tengas esta opción, y tendrás que usar como dns externo uno que no sea el dc, uno real registrado para que tu dc pueda consultarlo, o salir por otro dns. En cualquier caso, bloquear el tráfico dns saliente en el perímetro solo al dc, para mi, ¡es perfecto!
Ahora vamos a la detección, por ejemplo, podemos usar Sentinel para ver consultas dns mediante Sysmon y meterle una columna para ver el tamaño de esta.
SysmonParser
| where EventID ==22
| project dns_query_name,process_path, Computer,TimeGenerated
| extend strlen (dns_query_name)
| order by strlen_dns_query_name
Podemos hacer alguna guarrería, por ejemplo, ver la media del tamaño y mostrar consultas que sobrepasen por ejemplo por dos veces ese valor.
let media_payload = SysmonParser
| where EventID ==22
| project dns_query_name,process_path, Computer,TimeGenerated
| summarize avg(strlen (dns_query_name)) ;
SysmonParser
| where EventID ==22 and strlen (dns_query_name) > toscalar(media_payload)*2
| project dns_query_name,process_path, Computer,TimeGenerated
| extend strlen (dns_query_name)
| order by strlen_dns_query_name
Lo suyo sería monitorizar este valor constantemente, y cambiar el valor, ya que en este caso mi media real serían unos 40 bytes, pero como he metido tropecientas consultas de exfiltración, la media me ha subido. No obstante, para procesos de hunting esta aproximación es buena. Para el día a día quizás un workbook con una tabla y los valores ordenados por tamaño, para el día a día del analista…
Terminamos por aquí con este proceso ofensivo, defensivo, monitorización, etc…
¡Sigue Aprendiendo!
Si quieres que te ayudemos a poner en marcha este tipo de proyecto, no dudes en contactar con nosotros. También puedes aprovechar las formaciones existentes para ampliar tus conocimientos 👇🏼
>> Más info
