Ideas, información y conocimientos compartidos por el equipo
de Investigación, Desarrollo e Innovación de BASE4 Security.
Desde la mirada de un atacante, nuestra infraestructura es el espacio en donde se ejecutará su pieza de malware, seguramente con objetivos diversos (desde incorporar nuestros dispositivos a una
DNS Sinkhole es una técnica reconocida en donde se proveen resultados manipulados a consultas de dominios considerados maliciosos. Esto permite posteriormente redirigir al atacante a un sistema de destino diferente (controlado por nosotros).
Tradicionalmente, los distintos servicios que integran la protección de la conectividad ofrecían (y ofrecen) la posibilidad de realizar un bloqueo preventivo de estas consultas. Con esta técnica podemos dar un paso más y tomar esa simple petición DNS realizada por nuestro dispositivo infectado y utilizarla a nuestro favor.
Tal como venimos explorando en anteriores posts, esta es solo una de la variedad de técnicas enfocadas en la Defensa Activa (HoneyPots, Beaconing ). En específico, podemos ubicar el DNS Sinkholing en el contexto del Framework MITRE Engage y ATT&CK como una técnica donde hacemos manipulación de nuestra red , claramente con el objetivo de prevenir que el atacante avance con sus operaciones, pero además perjudicar las operaciones en curso como puede ser la fuga de datos.
Llega un momento en el ciclo de ejecución de cualquier pieza de Malware en donde se hace contacto con el exterior , ya sea para reportar un estado de activación, hacer un envío de datos, o para buscar nuevas órdenes (por supuesto que cada escenario es diverso, si se nos permite generalizar). Es en este momento en que aquel malware se expone en nuestra red.
Por otro lado, típicamente, las consultas DNS se realizan a través de una red compleja, por lo que detectar la IP desde la cual la consulta del dominio malicioso ha sido realizada no resulta sencillo desde el punto de vista de nuestros NGFW. La técnica de DNS Sinkholing provoca al equipo infectado para que este se comunique directamente a nuestra IP de detección o IP Sinkholing, y es ahí donde capturamos la dirección de nuestro dispositivo comprometido para comenzar las tareas de remediación.
Antes de avanzar, es importante resaltar que esta tarea no es siempre efectiva porque sólo da resultados para los casos en los que los dominios utilizados por los adversarios ya están detectados por los proveedores de las listas de bloqueo. Además, existen montones de alternativas tan simples como utilizar una IP fija (lo que anularía por completo nuestra medida). También, se utilizan otro tipo de técnicas ingeniosas en donde se hace uso de dominios con buena reputación para la comunicación externa o la generación aleatoria de nuevos dominios, aunque “ para nuestra suerte”, basta con una sola acción registrada por nuestra técnica para detectar un equipo infectado en nuestro ambiente y comenzar las tareas de mitigación.
Contamos con numerosos productos open source y comerciales que nos permiten hacer un bloqueo de las consultas DNS realizadas a nombres de sitios infectados. Algunos servicios que podemos utilizar para esta protección son: Cloudfare, OpenDNS, AmazonRoute53, Checkpoint, y Fortinet. Sin embargo, esto sólo resulta en la mitad del provecho que podemos obtener de esta técnica. Algunos proveedores han facilitado nativamente la opción de ofrecer una respuesta para aquella consulta maliciosa con un resultado alterado (como en el caso de Palo Alto). Compartiremos en este caso una pequeña implementación sobre Amazon AWS.
Su configuración se presenta bastante simple a través de una serie de “Reglas de Grupo” dentro de los VPC. De esta forma, todas las consultas DNS son procesadas según las reglas definidas:
Se puede destacar esta implementación por su facilidad de configuración, e integración con la infraestructura ya desplegada en la nube. Con estas reglas, todas las consultas DNS que sean detectadas en el VPC asignado y correspondan a dominios maliciosos serán sobrescritas con nuestra IP de Sinkhole.
Para los amantes del Open Source encontramos Pi-Hole, un micro SO que podemos integrar a nuestros servidores DNS ya implementados (desde Microsoft DNS on premise hasta Cloud DNS de Google) y ofrecer una extensión de las funcionalidades actuales para protegernos con esta técnica.
Pi-Hole puede ser utilizado como un DNS forwarder para interceptar las consultas externas y responder basado en las configuraciones. A diferencia de la implementación anterior, en donde solo contábamos con listas de malware de AWS, en este caso podemos hacer integración con una serie de proveedores de DNS con los que ya contemos:
Después de algunas configuraciones simples sobre el modo de bloqueo del dispositivo, tenemos listo el redireccionamiento de las peticiones de dominios maliciosos:
Una vez puesto en funcionamiento Pi-Hole, nos permite visualizar cada consulta para obtener algunos detalles. En este caso tomamos alguno de los dominios listados como maliciosos para realizar una serie de pruebas:
Por supuesto que este escenario solo nos muestra la mitad de la historia. Para completarla deberíamos utilizar algún servicio que permita un monitoreo constante, por ejemplo, para las peticiones HTTP y HTTPS, que típicamente son utilizadas para la comunicación con los C2.
Pueden encontrar referencias para la implementación de un HoneyPot aquí