Análisis de Hopscotch y Legspin de Regin

Con amenazas de alto perfil como Regin, los errores son increíblemente raros. Sin embargo, cuando se trata de humanos escribiendo códigos, algunos errores son inevitables. Entre las cosas más interesantes que observamos en la operación del programa malicioso Regin, están los nombres de código olvidados de algunos de sus módulos.

Estos son:

• HOPSCOTCH
• LEGSPIN
• WILLISCHECK
• U_STARBUCKS

Decidimos hacer un análisis profundo de dos de estos módulos: Hopscotch y Legspin.

A pesar del nivel general de sofisticación (y a veces incluso de sobre-ingeniería) de la plataforma Regin, estas herramientas son sencillas, directas y ofrecen interfaces de consolas interactivas a los operadores de Regin. Lo que las hace interesantes es el hecho que se las desarrolló hace muchos años y que quizás se crearon incluso antes de la misma plataforma Regin.

El módulo Hopscotch

Este módulo contiene otro binario, guardado como recurso 103:

Este módulo ejecutable se diseñó como una herramienta interactiva autónoma para movimientos laterales. No contiene exploits pero en vez de ello depende de credenciales previamente adquiridas para auto-autenticarse en la máquina remota mediante APIs estándar.

El módulo recibe el nombre de la máquina atacada y un nombre de un fichero remoto opcional desde la entrada normal (operador). Los atacantes pueden elegir entre varias opciones para su ejecución y la herramienta ofrece respuestas para lectura humana y sugerencias de posibles entradas.

Este es un ejemplo de la ejecución de ‘Hopscotch’ en una máquina virtual:

El módulo puede recurrir a dos rutinas para auto-autenticarse en la máquina atacada: conectarse al recurso normal llamado “IPC$” (método llamado “NET USE”) o ingresar como un usuario local (“SU”, o “switch user”) que tiene los permisos necesarios para realizar otras acciones.

Después extrae una carga maliciosa ejecutable desde sus recursos y la escribe en un lugar en la máquina atacada. El lugar predeterminado para la carga es: %target%ADMIN$SYSTEM32SVCSTAT.EXE. Una vez hecho esto, se conecta con el administrador de servicio de la máquina remota y crea un nuevo servicio llamado “Service Control Manager” para ejecutar la carga. El servicio se inicia inmediatamente y tras ejecutarse por un segundo, se detiene y se elimina.

El módulo establece un canal bidireccional de comunicación cifrada con la carga remota SVCSTAT.EXE usando dos tubos nombrados. Uno sirve para enviar entradas desde el operador a la carga, y el otro escribe los datos desde la carga a la salida normal. Los datos se cifran con el algoritmo RC4 y el intercambio de llaves inicial se asegura con cifrado asimétrico.

Una vez hecho esto, la herramienta elimina el archivo remoto y cierra las sesiones autenticadas, eliminando así todo rastro de la operación.

El módulo de carga SVCSTAT.EXE lanza su copia en el proceso dllhost.exe. Después prepara los correspondientes tubos nombrados en la máquina atacada y espera la entrada de datos. Una vez que el módulo original se conecta con el tubo, establece el cifrado de la comunicación por el tubo y espera la entrada del shellcode.

El ejecutable se inyecta y se ejecuta en un nuevo proceso de dllhost.exe o svchost.exe, con sus entradas y salidas redirigidas a la extensión remota que inició el ataque. Esto le permite al operador controlar el módulo inyectado e interactuar con él.

El módulo Legspin

Este módulo también se desarrolló como una utilidad autónoma de línea de comandos para la administración de ordenadores. Cuando se ejecuta de forma remota se convierte en una poderosa puerta trasera. Vale la pena hacer notar que el programa posee soporte completo de consola y presenta una salida en colores cuando se ejecuta a nivel local. Incluso es capaz de distinguir entre consolas compatibles con Windows Console API y terminales compatibles con TTY que aceptan códigos de escape para colores.

Salida “Legspin” en una ventana de consola normal con resaltados en colores

Además de la marca de tiempo de compilación que se encuentra en los encabezados PE, hay dos referencias que apuntan a 2003 como el año real de su compilación. El programa imprime dos etiquetas de versiones:

• 2002-09-A, mencionada como “lib version”
• 2003-03-A

Además, el programa usa las funciones API heredadas, como “NetBIOS” que se introdujo en Windows 2000 y se menospreció en Windows Vista.

Una vez que arranca e inicializa, le proporciona al operador un símbolo de sistema interactivo, a la espera de la entrada de comandos. La lista de comandos disponibles es bastante extensa y les permite a los operadores realizar muchas tareas administrativas. Algunos de los comandos requieren información adicional que se le pide al operador, y los comandos proporcionan una descripción de texto de los parámetros disponibles. En realidad el programa es un shell administrativo que el atacante/usuario debe operar manualmente.

El módulo Legspin que recuperamos no posee un mecanismo C&C incorporado. En lugar de ello, depende de la plataforma Regin para redirigir las entradas/salidas de la consola a/desde los operadores.

Conclusiones

A diferencia de otros módulos de Regin, Legspin y Hopscotch parecen ser herramientas autónomas desarrolladas mucho antes. En particular, la puerta trasera Legspin data de 2003,š e incluso quizás de 2002. Vale la pena remarcar que no todas las instalaciones de Regin contienen el módulo Legspin; en la mayoría de los casos, los atacantes manejan a sus víctimas mediante otras funciones de la plataforma Regin.

Esto significa que Legspin pudo haberse usado independientemente de la plataforma Regin, como una sencilla puerta trasera junto a un empacador de salidas/entradas.

Aunque más detalles de Regin van saliendo a la luz, todavía queda mucho por conocer. Una cosa está clara: lo que sabemos de Regin es, probablemente, información retirada que ha sido remplazada por nuevos módulos y técnicas con el pasar del tiempo.