Tunelización de red con … QEMU?

Los ciber atacantes tienden a dar preferencia a las herramientas legitimas para ejecutar varios pasos de su actividad, esto gracias a que dichas herramientas les permiten evadir sistemas de detección al mismo tiempo que minimizan los costos del desarrollo de malware.

Escaneo de redes, capturar el contenido de la memoria de procesos, exfiltrar información, ejecutar archivos remotamente, e incluso, encriptar unidades, todo esto puede ser realizado con software confiable. Para ganar terreno dentro de una infraestructura comprometida y desarrollar el ataque, los adversarios pueden usar malware instalado previamente o conectarse a la red junto con los empleados mediante los servidores RDP de la compañía o la VPN corporativa (para conseguir esto, los atacantes deben adquirir cuentas con los privilegios necesarios). Otra forma de conectarse a la red interna de una organización atacada incluye el uso de utilitarios para configurar túneles o redirigir los puertos de red entre sistemas corporativos y los servidores de los adversarios, lo que permite a los atacantes evadir (conocido como “bypasear”) los controles NAT y Firewall para conseguir acceso a los sistemas internos. Es sobre esta última categoría de software que quisiera discutir en este post.

Estadísticas

En la actualidad, no hacen falta utilidades capaces de establecer un túnel de red entre dos sistemas. Algunas permiten conectarse directamente, mientras que otras usan sistemas proxy, los cuales ocultan la dirección IP de los servidores del atacante. La siguiente es una lista de utilitarios que hemos identificado durante la respuesta a incidentes de ciber seguridad en los últimos tres años:

• Stowaway
• ligolo
• 3proxy
• dog-tunnel
• chisel
• FRP
• ngrok
• gs-netcat
• plink
• iox
• nps

Las aplicaciones más frecuentes son ngrok y FRP. Los utilitarios de este tipo contabilizan el 10% del total de herramientas identificadas en los ataques.

QEMU como herramienta de tunelización

Durante una reciente investigación desarrollada hace algunos meses atrás en una gran empresa, detectamos actividad maliciosa poco común ejecutada en un sistema de la infraestructura. Iniciamos el análisis de los artefactos, solamente para encontrar que el adversario había desplegado y ejecutado las siguientes actividades:

• Ejecución de la aplicación Angry IP Scanner.
• Ejecución de Mimikatz para extraer contraseñas, hashes y tiquetes de Kerberos, así como para ejecutar ataques contra el Directorio Activo.
• El emulador de hardware QEMU.

Los dos primero se explican por si solos, pero QEMU trajo consigo algunas preguntas: ¿Qué uso tendrían los actores maliciosos para un virtualizador?

Conseguimos obtener el comando de ejecución de QEMU desde la memoria del sistema comprometido. Encontramos también que fue iniciado sin un LiveCD o imagen de disco, lo que es muy inusual para QEMU. Estos fueron los argumentos usados por los atacantes para ejecutar QEMU:

donde <IP> correspondía a una dirección IP externa.

Demos un vistazo a los argumentos utilizados:

• -m 1M: Especifica el tamaño de RAM habilitado para la máquina virtual. Corresponde a 1MB en este caso, totalmente insuficiente para la mayoría de los sistemas operativos.
• -netdev user,id=lan,restrict=off: Crea una interfaz de red virtual con el nombre lan y tipo usuario, lo que permite a la máquina virtual comunicarse con el mundo exterior a través de la pila de red del sistema host. La opción restrict=off remueve las restricciones de conexiones entrantes (inbound) y salientes (outbound).
• -netdev socket,id=sock,connect=<IP>:443: Crea una interfaz de red de tipo socket con el nombre sock, la cual provee una conexión a un servidor remoto en la IP especificada y el puerto 443.
• -netdev hubport,id=port-lan,hubid=0,netdev=lan: Agrega un puerto al concentrador virtual con hubid=0, que está vinculado a la interfaz de red virtual lan.
• -netdev hubport,id=puerto-sock,hubid=0,netdev=sock: Similar al comando anterior, este agrega un puerto más al concentrador virtual vinculado a la interfaz de red virtual sock.
• -nographic: inicia QEMU sin interfaz gráfica con salida por consola.

La dirección IP en los argumentos llamó nuestra atención inmediatamente: se trataba de una dirección externa y no relacionada a la compañía atacada, así que consultamos la documentación de QEMU. Encontramos que QEMU soporta conexiones entre máquinas virtuales: la opción -netdev crea dispositivos de red (backend) que luego pueden conectarse a la máquina virtual. Cada uno de los numerosos dispositivos de red se define por su tipo y soporta opciones adicionales. A continuación, se encuentra una descripción de los valores -netdev que fueron utilizados.

user (user network stack)

Esta es la forma más simple de conectar una máquina virtual a una red. El tráfico pasa a través de la pila de red del sistema host y la máquina virtual se conecta a la red como si fuese una aplicación regular en la máquina host.

Aquí, mynet0 es el ID de backend de red y e1000 es un adaptador (frontend) dentro de la máquina virtual.

hubport (virtual hub)

Conecta múltiples dispositivos de red similar a un concentrador de red.

socket

Este conecta máquinas virtuales directamente a través de sockets de red para crear topologías de máquinas virtuales o enlazar máquinas virtuales en distintos hosts.

# VM1

# VM2, conectada a la VM1

VM1 escucha en el Puerto 1234, mientras que la VM2 se conecta a ese puerto. Esta fue la ruta usada por los atacantes: lanzaron un “cliente” en el sistema comprometido y lo conectaron a su servidor para abrir un acceso a la red corporativa, donde el “cliente” estaba ejecutándose. No produjo ningún efecto de desempeño en el sistema comprometido, ya que el adversario no estaba usando una imagen de disco o LiveCD durante la ejecución de QEMU.

No teníamos forma de determinar de forma fiable cómo ejecutaban QEMU los atacantes en su propio servidor, así que decidimos probar la técnica descrita anteriormente en un laboratorio formado por tres sistemas:

• InternalHost, ubicado dentro de la red, sin acceso a Internet y ejecutando un servidor RDP en el puerto 3389. Simula un sistema aislado sin acceso a Internet.
• PivotHost, ubicado en la red, pero con acceso a Internet. Simula el sistema que ha sido accedido por los atacantes y usado para llegar al sistema InternalHost conectado a la misma red.
• AttackerServer alojado en la nube, simulando el servidor del adversario.

EL objetivo era llegar al sistema InternalHost desde el sistema AttackerServer. La imagen a continuación presenta el diagrama general del túnel:

Diagrama de tunel de red

Habilitamos QEMU en el sistema AttackServer para poner en marcha una máquina virtual usando un LiveCD de Kali Linux. Configuramos un dispositivo de red de tipo socket en la VM funcionando como adaptador de red escuchando en el puerto 443.

Otra copia de QEMU fue ejecutada en el sistema PivotHost conectada a través del socket de red al puerto 443 en el sistema AttackerServer alojado en la nube. También conectamos un dispositivo de red de tipo usuario, combinado con un socket a través de un concentrador. Las opciones de inicialización de QEMU fueron similares a las previamente usadas por los adversarios.

Una vez iniciado, QEMU configurará una red tunelizada desde el sistema PivotHost hasta el sistema AttackerServer, o más precisamente, a la máquina virtual de Kali Linux. Kali podrá escanear la subred a la que PivotHost se encuentra conectada.

Salida del escaneo de la subred

El escaneo identifica el sistema InternalHost, con la IP de red 192.168.56.109. La utilidad NMAP confirma que el puerto 3389 estaba abierto. Posteriormente, intentamos conectarmos al sistema InternalHost usando el servicio RDP:

Conexión RDP confirmada al Sistema InternalHost

QEMU no usa ninguna encripción adicional al momento de configurar el tráfico tunelizado. Transmite paquetes encapsulados no encriptados: los paquetes de capa de aplicación, enviados al servidor, contienen el tamaño de las tramas de Ethernet encapsulados (4 bytes, resaltados en amarillo en la siguiente imagen), seguidos por la trama Ethernet propiamente dicha (resaltada en rojo).

Ejemplo de una trama Ethernet encapsulada

En la imagen anterior, el tamaño de la trama Ethernet encapsulada es de 89 bytes (0x59). Este valor es seguido por la trama Ethernet encapsulada.
Mediante una captura de tráfico, interceptada en el sistema PivotHost, pudimos obtener el tráfico encapsulado, eliminando los primero 58 bytes (para TCP: 14 bytes de Ethernet + 20 bytes de la dirección IP + 20 bytes de las cabeceras TCP + 4 bytes del tamaño interno del paquete).

Esto puede realizarse haciendo uso de la aplicación editcap del paquete Wireshark después de remover todos los paquetes que no contenían ningún tráfico encapsulado en el archivo PCAP.

El resultado final fue una captura PCAP conteniendo el tráfico transmitido mediante el túnel:

Paquete original transmitido mediante el tunel

Además, comprobamos que esta técnica para lograr la persistencia de la red era realmente eficaz. Adicional a los anteriormente mencionados tipos de red, QEMU soporta muchos otros, los cuales pueden también ser empleados por actores maliciosos.

Conclusiones

El uso de herramientas legítimas por actores maliciosos para ejecutar diferentes pasos dentro de sus ataques no es nada nuevo en la respuesta a incidentes profesional. Aunque tenemos que admitir que los atacantes en ocasiones aparecen con nuevas e ingeniosas técnicas usando aplicativos poco probables, como el caso de QEMU. Esto respalda aún más el concepto de protección multinivel, que abarca tanto una protección fiable de los puntos finales como soluciones especializadas para detectar y proteger contra ataques complejos y selectivos, incluidos los perpetrados por personas/humanos. Solamente un modelo de seguridad comprehensivo que incluya monitoreo de red (NDR, NGFW) y de punto final (EDR, EPP) habilitado 24/7, desarrollado por expertos miembros de un SOC, puede llegar a detectar anomalías de forma temprana y bloquear este tipo de ataques en sus etapas iniciales. Nuestro servicio MDR está en capacidad de detectar el tipo de actividad sospechosa de QEMU en cuestión, y se ha generado las reglas de IDS a la plataforma KATA (Kaspersky Anti Targeted Attack) con el veredicto Backdoor.Agent.QEMU.C&C.