En las redes organizacionales es común que, a pesar de las medidas preventivas desplegadas, alguna pieza de malware escape a los diversos controles del sistema de seguridad para finalmente instalarse en los terminales activos. En estas ocasiones, una de las actividades que el programa malicioso realizará con casi absoluta certeza tras su instalación será el establecimiento de una conexión con los servidores remotos del atacante, para descargar componentes necesarios, realizar actualizaciones, o bien enviar la información valiosa que ha conseguido robar del terminal infectado.
Aunque puede llegar a ser un desafío, el desarrollo y mantención de un sistema de detección proactiva de estos canales de comunicación C&C (Command & Control) puede brindar grandes beneficios a la hora de identificar fallas en nuestro sistema y vectores de ataque recurrentes. En este post veremos el resultado de aplicar un esquema del estilo.
Fundamentos de diseño
En cualquier red interna con un relativamente estricto control de acceso, el tráfico podrá alcanzar Internet sólo a través de un proxy web, bloqueándose todas aquellas conexiones que intenten hacerlo desde las mismas estaciones de trabajo.
Si bien las técnicas de desarrollo de malware mejoran cada día y hoy podemos apreciar amenazas capaces de identificar la presencia de proxies, la vasta mayoría de los códigos maliciosos intentará establecer una conexión directamente al exterior, que terminará siendo rechazada por el gateway firewall.
Utilizando esto a nuestro favor, estableceremos una regla en el cortafuego que redirija el tráfico a bloquearse a un servidor sinkhole, para poder escuchar los puertos más comúnmente utilizados en C&C, interactuar con las peticiones entrantes, y obtener registros detallados. Esta regla forzará un DNAT (Destination Network Address Translation), cambiando la IP de destino original por la IP del servidor, y el terminal de trabajo establecerá una conexión exitosa con éste y no con la Internet.
De la teoría, a la práctica…
Una vez realizado el esquema de direccionamiento, se creó un laboratorio de trabajo con las siguientes características:
- Firewall: IPCop 2.1.5, IP 198.168.0.1/24 (Interfaz a la red Interna), IP 172.16.0.1/16 (Interfaz a la Red Servidor), IP 10.0.2.2/24 (Interfaz a la Internet).
- Servidor sinkhole: Ubuntu 14.04, IP 172.16.0.2/16, Apache 2.4 (con ModSecurity para el registro de peticiones por puertos 80 y 443), Red Servidor.
- Servidor Proxy: Ubuntu 14.04, IP 192.168.0.101/24, Squid3, Red Interna.
- Estación de Trabajo: Windows 7, IP 192.168.0.142/24, Configuración de proxy para peticiones del navegador, Red Interna.
Con el objeto de obtener registros verdaderamente detallados, se buscó almacenar la siguiente información: fecha y hora, IP de origen, puerto de origen, IP de destino, puerto de destino, nombre de dominio solicitado, User-Agent, cookies, payload del paquete.
Cabe mencionar que la dirección original de destino es modificada en el proceso de DNAT, pero podemos recuperarla por el campo Host del paquete en protocolos como HTTP y HTTPS. Por motivos de brevedad, nos acotaremos a estos protocolos.
Desarrollo de la prueba
Se infectó el terminal de trabajo con una variedad de troyanos y bots a fin de evaluar qué tan valiosa información podíamos obtener de su comportamiento. A continuación podemos ver parte del archivo de auditoría producido por ModSecurity a lo largo de la captura:
En este caso se observa un alto número de puerto y además, en la URL, una petición de descarga de un archivo .exe. Se muestran resaltados números campos útiles para una futura investigación.
Luego, podemos automatizar la recolección de datos sobre el fichero de auditoría mediante un simple script, para lograr una vista global del tráfico bloqueado por el firewall, obteniendo una salida parecida a la que seguidamente se presenta:
En base a estos registros podemos generar scripts que detecten indicios de comportamiento malicioso, como ser número alto de peticiones a ciertos hosts, utilización de direcciones IP en vez de nombres de dominio, o de nombres de dominio muy largos y sin sentido producidos tal vez por un algoritmo DGA (Domain Generation Algorithms).
Conclusiones
Este enfoque aprovecha el hecho de que la mayor parte del tráfico C&C será bloqueado por el firewall, y sólo un pequeño porcentaje logrará colarse por el servidor Proxy. Puede ser adaptado fácilmente a otros varios protocolos como FTP, IRC, y SMTP, muy utilizados por los autores de malware.
La experiencia cumplió con lo esperado, y hemos confirmado que muchas piezas de valiosa información pueden ser así recopiladas para identificar tráfico sospechoso, y generar una respuesta efectiva. Sin lugar a dudas, la implementación de estos esquemas en pos de la detección proactiva es una buena medida a tomar como complemento de soluciones antivirus, IPSs (Intrusion Prevention Systems) y sistemas de gestión de actualizaciones.
