Índice
En éstos días se ha escuchado hablar mucho sobre Regin, un malware de una calidad superior, como pocos vistos hasta ahora. En éste artículo se pretende profundizar en el funcionamiento de éste malware, el cual es una obra de excelente calidad. Me basaré principalmente en lo comentado por Steve en el episodio #483 del podcast Security Now!
“Regin” viene de “Registry” - Install, descubierto por Symantec en 2008. A continuación se cita el análisis que hicieron sobre éste malware:
En el mundo de las amenazas de malware, sólo unos pocos ejemplos pueden considerarse inigualables y sin igual. Regin es ese tipo de malware.
Regin es un software extremadamente complejo que puede personalizarse con un amplio rango de capacidades que pueden desplegarse dependiendo del objetivo a atacar. Está construido sobre un framework diseñado para mantener operaciones de recolección de datos a largo plazo quedando al margen de todos los radares ( Entiéndanse, antivirus). Lleva a cabo medidas extraordinarias para ocultarse a sí mismo y sus actividades en la máquina afectada. Su sigilo combina técnicas de las más avanzadas que se han visto en uso.*
El principal propósito de Regin es la recopilación de información y se ha visto implicado en operaciones de colección de datos contra organizaciones gubernamentales, empresas, organizaciones docentes y particulares. La complejidad y nivel de sofisticación de Regin hacen pensar que el desarrollo de ésta amenaza ha llevado meses, e incluso años.
Regin es una amenaza multi etapa y modular, lo que significa que tiene un número de compoenentes, cada uno dependiente de otros, para realizar las operaciones de ataque. Éste enfoque modular proporciona la flexibilidad necesaria a los ataques, ya que es posible cargar características personalizadas hechas a medida para cada objetivo individual cuando sea necesario. Algunos “payloads” personalizados son muy avanzados y muestran una gran experiencia en sectores especializados. El diseño modular dificulta el análisis de la amenaza, ya que todos los componentes deben estar disponibles para poder entender completamente cómo funciona el malware.
Período activo y versiones de Regin
Regin estuvo activo durante 2008 y 2011, donde se detuvo, desinstalándose de todos los sistemas infectados. En 2013 se volvió a detectar una nueva versión, bastante mejorada de éste malware.
La versión activa entre 2008 y 2011 fue la 1.0. En 2013, o posíblemente antes, se lanzó la versión 2.0. Todas las versiones 2.0 se han encontrado compiladas para 64-bit.
Principales objetivos
Regin se ha detectado en las principales compañias de telefonía, los módulos del malware desplegados en dichas instalaciones están diseñados para obtener acceso a las llamadas que son redirigidas por la infraestructura telefónica.
Arquitectura de Regin
Se compone de las 6 etapas resumidas en la siguiente tabla:
| Etapas | Componentes |
|---|---|
| Etapa 0 | “Dropper”. Instala Regin en el objetivo |
| Etapa 1 | Carga Drivers |
| Etapa 2 | Carga Drivers |
| Etapa 3 | Carga compresión, cifrado, networking, y los componentes necesarios para gestionar un sistema de archivos cifrado (EVFS) |
| Etapa 4 | Utiliza el EFVS y carga drivers adicionales para su kernel, incluyendo payloads |
| Etapa 5 | Payloads principales y ficheros de datos |
Las etapas más interesantes son las que almacenan los ejecutables y ficheros de datos en las etapas 4 y 5. La etapa inicial 1 es la única que contiene código visible. El resto de etapas se almacenan como bloques de datos cifrados, ya sea en forma de ficheros o dentro de algún área de almacenamiento de ficheros no tradicional, como el registro, atributos extendidos, o sectores al final del disco duro.
A continuación se muetra un gráfico que describe el proceso de infección:
Etapa 0
Una vez que el dropper se ejecuta en el objetivo, se instalará y ejecuta la etapa 1. Es probable que ésta etapa se encargue de configurar varios atributos y claves en el registro que mantengan codificadas versiones de las etapas 2, 3, y posiblemente etapas de la 4 en adelante.
Etapa 1
Es el punto inicial para cargar la amenaza. Se conocen dos ficheroes de esta etapa:
- usbclass.sys (versión 1.0)
- adpu160.sys (version 2.0)
Son drivers del kernel que cargan y ejecutan la etapa 2. Es posible que se registren como un servicio del sistema que se ejecute al iniciar el ordenador.
La etapa 1 simplemente lee y ejecuta la etapa 2 desde un conjunto de atributos extendidos de NTFS, si no se encuentran dichos atributos extendidos, la etapa 2 se ejecuta desde un conjunto de claves del registro.
Etapa 2
Es un driver del kernel que extrae, instala y ejecuta la etapa 3. Ésta etapa no está almacenada en un sistema de ficheros tradicional, sino que se encuentra cifrada en un atributo extendido o en el registro.
Puede encontrarse cifrada en :
Atributos extendidos:
- %Windir%
- %Windir%\fonts
- %Windir%\cursors (possibly only in version 2.0)
Sub claves del registro:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4F20E605-9452-4787-B793- D0204917CA58}
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\RestoreList\VideoBase (possibly only in version 2.0)
Ésta etapa puede ocultar instancias en ejecución de la etapa 1. Una vez hecho, no hay partes visibles del malware. De forma similar a etapas previas, la etapa 2 localiza y carga una versión cifrada de la etapa 3 desde atributos extendidos de NTFS o el registro.
La etapa 2 también puede monitorizar el estado de la amenaza. Ésta etapa crea el fichero msrdc64.dat, el cual parece tener siempre un tamaño de 512B. Sólo se usan los dos primeros bytes, el resto están a cero. El segundo byte indica cuantas instancias se permite ejecutar de forma exclusiva, su valor es 2. Lo cual significa que no más de una instancia debería ejecutarse al mismo tiempo. El primero, cuantas instancias se intentaron ejecutar. Por tanto, hay tres combinaciones.
00 02(No se está ejecutando)01 02(Ejecutándo)02 02(Se estaba ejecutando y se ha iniciado una segunda instancia)
Etapa 3
Es una DDL de modo kernel, cifrada dentro de un atributo extendido o en el registro.
Se puede encontrar en:
Atributos extendidos:
- %Windir%\system32
- %Windir%\system32\drivers
Sub claves del registro:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4F20E605-9452-4787-B793- D0204917CA5A}
El fichero es de 6 a 7 veces mayor que el driver de la etapa 2. Además de cargar la etapa 4, ofrece un framework para etapas de mayor nivel.
A partir de esta etapa, todas estan basadas en un framework modular de módulos de código. Éstos módulos ofrecen funciones mediante una interfaz privada y personalizada. Cada fichero en la etapa 3 y superior pude exportar funcionalidad a otras partes de Regin.
Las primitivas disponibles para la etapa 3 son:
- El orquestador, que parsea ficheros personalizados encontrados en los datos adjuntos a los ficheros ejecutables de las etapas 3 en adelante. Éstos ficheros contienen una lista de las funcionalidades de Regin a ser ejecutadas.
- Rutinas de compresión y descompresión.
- Rutinas de cifrado y descifrado.
- Rutinas para obtener localizaciones de almacenamiento de componentes de mayor nivel (Etapa 4).
- Rutinas para gestionar el sistema de ficheros virtual cifrado usado por la etapa 4.
- Primitivas de red.
Etapa 4
Los ficheros para la etapa 4, cargados por la etapa 3, consisten en un modo usuario del orquestador y múltiples módulos payload del kernel. Se almacenan en dos contenedores EVFS como ficheros:
- %System%\config\SystemAudit.Evt: Contiene los drivers del kernel para la etapa 4
- %System%\config\SecurityAudit.Evt: Versión usuario de la etapa 3. Los ficheros se inyectan en
services.exe.
Etapa 5
Consiste en la la funcionalidad principal de Regin para los payloads. Los ficheros para ésta etapa son los inyectados en services.exe por la etapa 4. También almacenados en el EVFS.
- %System%\config\SystemLog.evt: Contiene DLLs que constituyen el payload de Regin.
- %System%\config\SecurityLog.evt: Ficheros de datos, usados por los componentes de las etapas 4 y 5 para almacenar varios elementos de datos.
- %System%\config\ApplicationLog.evt: Otro contenedor para logs de la etapa 5, referenciados por ficheros de datos de la misma etapa.
- %Windir%\ime\imesc5\dicts\pintlgbp.imd (versión 2.0)
- %Windir%\ime\imesc5\dicts\pintlgbs.imd (versión 2.0)
El payload de Regin implica las DDLs contenidas en el contenedor EVFS SystemLog.evt. La funcionalidad del payload es distinta en función del ordenador objetivo del ataque. Para cada entorno específico, se preparan payloads personalizados. Algunos ejemplos de funcionalidades detectadas hasta ahora son:
- Esnifar tráfico de red de bajo nivel.
- Robar datos mediante varios canales (TCP, UDP, ICMP, HTTP).
- Obtener información del ordenador.
- Robar contraseñas.
- Obtener información de procesos y memoria.
- Escanear el sistema de ficheros.
- Capacidades forenses de bajo nivel (Por ejemplo, recuperar ficheros borrados).
- Manipulación del entorno gráfico (Control remoto del ratón, capturar la pantalla etc).
- Detectar servidores web IIS y robar los logs.
- Esnifar tráfico de red GSM BSC.
Para más información, podéis echar un vistazo a los siguientes enlaces, entre ellos el análisis original de Symantec, y el vídeo del podcast de Security Now!.
Referencias
- Regin: Top-tier espionage tool enables stealthy surveillance, y créditos de las imágenes »» symantec.com
- Análisis de Symantec sobre Regin »» Fichero PDF
¿Has visto algún error?: Por favor, ayúdame a corregirlo contactando conmigo o comentando abajo.