Descargar en PDF

2 de abril de 2021

Introducción

A finales de septiembre del año 2020 el laboratorio de virus de Doctor Web fue contactado por un Instituto de investigación científica ruso solicitando ayuda. Los empleados del Instituto de investigación científica prestaron atención a algunos problemas técnicos que podían ser causados por la presencia del malware en uno de los servidores de la red local. Durante la investigación los analistas de virus detectaron que el Instituto de investigación científica fue sometido a un ataque dirigido a través de backdoors especiales. El análisis de los detalles del incidente demostró que la red de la empresa había sido comprometida mucho antes de contactar a nuestra empresa y, según los datos que tenemos, por más de un grupo APT.

Los datos recibidos durante la investigación demuestran que el primero grupo APT ha comprometido la Intranet del Instituto en otoño del año 2017. La infección primaria se realizaba a través de BackDoor.Farfli.130 — una modificación del backdoor, también conocido como Gh0st RAT. Más tarde, en otoño del año 2019 en la red fue instalado Trojan.Mirage.12, y en junio de 2020 — BackDoor.Siggen2.3268.

El segundo grupo de hackers ha comprometido la red del instituto en abril del año 2019 como más tarde, esta vez la infección empezó por la instalación del backdoor BackDoor.Skeye.1. Durante la investigación también detectamos que más o menos en el mismo periodo — en mayo del año 2019 — Skeye fue instalado en la red local de otro Instituto de investigación científica ruso.

Mientras tanto, en junio del año 2019 la empresa FireEye publicó un informe sobre un ataque dirigido al sector público de algunos países de Asia Central usando este backdoor. Más tarde, de agosto a septiembre del año 2020 los analistas de virus de Doctor Web detectaron la instalación de varios troyanos por este grupo en la red de la empresa, incluido el backdoor DNS BackDoor.DNSep.1, no detectado anteriormente, así como otro, ampliamente conocido BackDoor.PlugX.

Además, en diciembre del año 2017 en los servidores del Instituto de investigación científica que nos contactó fue instalado BackDoor.RemShell.24. Los representantes de esta familia anteriormente habían sido descritos por los expertos de Positive Technologies en la investigación de Operation Taskmasters. Sin embargo, no disponemos de los datos que permitan detectar de forma inequívoca qué grupo APT de los dos usó este backdoor.

¿Quién realiza los ataques?

La actividad del primer grupo APT no nos permite identificar de forma inequívoca a los atacantes como un grupo de hackers de los descritos más arriba. Así mismo, el análisis del malware usado y de la infraestructura demostró que este grupo que lleva dedicándose a sus actividades a partir del año 2015 como mínimo.

El segundo grupo APT que atacó al Instituto de investigación científica, en nuestra opinión, es TA428, anteriormente descrita por los investigadores de la empresa Proofpoint en el material Operation Lag Time IT. Lo confirman los hechos siguientes:

1. En el código de backdoors BackDoor.DNSep y BackDoor.Cotx hay afinidad y similitudes claras;
2. BackDoor.Skeye.1 y Trojan.Loader.661 se usaban en el marco del mismo ataque, así mismo, el último es una herramienta conocida de TA428;
3. 3. Los backdoors que analizamos en el marco de estos ataques, tienen similitudes de direcciones de servidores de control y la infraestructura de la red con los backdoors usados por el grupo TA428.

Ahora vamos a ver la afinidad detectada con más detalle. En el grafo se observa una parte de la infraestructura usada en el ataque con similitudes de backdoors Skeye y otro backdoor APT conocido — PoisonIvy:

En este grafo, se observan las similitudes de la infraestructura de backdoors Skeye y Cotx:

El análisis detallado del backdoor DNSep y su posterior comparación con el código del backdoor Cotx permitieron detectar la similitud tanto de la lógica común de procesamiento de comandos del servidor de control, como en la realización concreta de algunos comandos.

Otro descubrimiento interesante de esta investigación fue el backdoor Logtu cuya muestra describimos anteriormente en una investigación de un incidente en Kirguizia. La dirección de su servidor de control coincidió con la dirección del servidor del backdoor Skeye — atob[.]kommesantor[.]com. Por lo tanto, también realizamos un análisis comparativo de BackDoor.Skeye.1 con las muestras de BackDoor.Logtu.1 y BackDoor.Mikroceen.11.

Las descripciones técnicas detalladas del malware detectado pueden consultarse en la versión PDF de la investigación y en la biblioteca de virus Dr.Web.

Análisis comparativo del código BackDoor.DNSep.1 y BackDoor.Cotx.1

Aunque los canales de conexión con el servidor de control de Cotx y DNSep son muy distintos, hemos conseguido detectar coincidencias interesantes del código de ambos backdoors.

La función que se encarga del procesamiento de comandos del servidor de control recibe la siguiente estructura como argumento:

struct st_arg
{
  _BYTE cmd;
  st_string arg;
};

Así mismo, su la función requerida recibe varios argumentos, todos ellos se indican en el campo arg divididos por |.

El conjunto de comandos BackDoor.Cotx.1 es más amplio que en caso de BackDoor.DNSep.1, e incluye todos los comandos del último.

En la tabla más abajo se observa la coincidencia casi completa de algunas funciones de backdoors. Así mismo, hay que tomar en cuenta que en Cotx se usa la codificación Unicode, y en DNSep — ANSI.

BackDoor.DNSep.1	BackDoor.Cotx.1
Procesador del comando para enviar un listing del catálogo o la información del disco
Función de recepción de la información sobre discos
Función de indicar los archivos en la carpeta
Función de recopilación de la información sobre archivos en la carpeta

Los datos recibidos como resultado del análisis permiten suponer que al crear el backdoor DNSep su autor tenía acceso a los códigos fuente de Cotx. Como estos recursos no son públicos, suponemos que el autor o el grupo de autores de DNSep tiene algo que ver con el grupo TA428. Esta versión la confirma también el hecho de que la muestra de DNSep fue localizada en la red comprometida de la empresa víctima junto con otros backdoors conocidos de TA428..

Análisis comparativo del código de backdoors Skeye, Mikroceen, Logtu

Durante la investigación del backdoor Skeye hemos detectados que la dirección de su servidor de control también se usa por el backdoor de la familia Logtu. Para el análisis comparativo usamos las muestras anteriormente descritas de BackDoor.Logtu.1 y BackDoor.Mikroceen.11.

Funciones de logging

El logging en todos los casos es ofuscado de alguna forma.

• BackDoor.Mikroceen.11 — mensajes en formato %d-%d-%d %d:%d:%d <msg>\r\n se escriben en el archivo %TEMP%\WZ9Jan10.TMP, donde <msg> — es una línea de texto aleatoria. En la muestra 2f80f51188dc9aea697868864d88925d64c26abc 2f80f51188dc9aea697868864d88925d64c26abc los mensajes se guardan en el archivo 7B296FB0.CAB;
• BackDoor.Logtu.1 — mensajes en formato [%d-%02d-%02d %02d:%02d:%02d] <rec_id> <error_code>\n<opt_message>\n\n antes de escribir en el archivo %TEMP%\rar<rnd>.tmp se cifran por la operación XOR con la clave 0x31;
• BackDoor.Skeye.1 — mensajes en formato %4d/%02d/%02d %02d:%02d:%02d\t<rec_id>\t<error_code>\n se guardan en el archivo %TEMP%\wcrypt32.dll.

La lógica general de secuencia de escritura de mensajes en el registro también es similar para las tres muestras:

• El inicio de ejecución se registra;
• en Logtu y Mikroceen en el log se registra la conexión directa al servidor de control;
• en cada caso de indica a través de qué proxy se realiza la conexión al servidor;
• en caso de un error en la etapa de recepción de proxy de alguna fuente en el log se registra una entrada aparte.

Cabe destacar que el logging tan detallado y al mismo tiempo ofuscado es muy poco frecuente. La ofuscación consiste en lo siguiente: en el registro se guardan algunos códigos de mensajes y en algunos casos los datos extra. Además, en este caso se observa un esquema común de secuencia de registro de los eventos:

• inicio de ejecución;
• intento de conexión directa;
• recepción de las direcciones de proxy;
• registro sobre la escritura a través de algún servidor.

Búsqueda del servidor proxy

La secuencia de conexión al servidor de control también es similar para todas las 3 muestras. Al principio, cada backdoor intenta conectarse al servidor directamente, y en caso de un error puede usar los servidores proxy cuyas direcciones se obtienen de tres orígenes excepto el incrustado.

Recibir las direcciones de servidores proxy de BackDoor.Mikroceen.11:

• del archivo %WINDIR%\debug\netlogon.cfg;
• del archivo de registro propio;
• al buscar las conexiones a hosts remotos a través de los puertos 80, 8080, 3128, 9080 en la tabla TCP.

Buscar el proxy en su archivo de registro:

Buscar en conexiones activas:

Recibir las direcciones de servidores proxy de BackDoor.Logtu.1:

• del registro HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• de la sección del registro HKU por SID del usuario activo;
• a través de WinHTTP API WinHttpGetProxyForUrl al crear solicitud a google.com.

Recibir las direcciones de servidores proxy de BackDoor.Skeye.1:

• de la sección Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• de la sección HKU por SID del usuario activo;
• al buscar conexiones a hosts remotos a través de los puertos 80, 8080, 3128, 9080 en la tabla TCP.

Coincidencias de la infraestructura de red

Algunas muestras usaban de forma conjunta la misma infraestructura de red. Un fragmento del grafo permite observar la conexión entre las familias.

Identificadores

En las muestras de Logtu y Mikroceen hay líneas usadas como IDs de compilaciones o versiones. El formato de algunas de ellas coincide.

Además, en muchas muestras este ID es igual al valor TEST o test.

Un ejemplo en BackDoor.Logtu.1 9ea2488f07bf3edda23d9b7759c2d0c3c8501f92):

Un ejemplo en BackDoor.Mirkoceen.11 ((81bb895a833594013bc74b429fb1f24f9ec9df26):

De esta forma, el análisis comparativo permitió detectar las siguientes similitudes de las familias investigadas:

• lógica de llevar el registro de eventos y su ofuscación;
• lógica de conectarse al servidor de control y algoritmos de búsqueda de direcciones proxy;
• la infraestructura de red usada.

Resumen

Durante el análisis de los ataques a los Institutos de investigación científica rusos nuestros analistas de virus detectaron y describieron varias familias de backdoors dirigidos, incluidas las muestras anteriormente desconocidas. Cabe destacar el funcionamiento continuo oculto del malware en la red comprometida de la empresa víctima — la presencia no autorizada del primer grupo APT permanecía desapercibida a partir del año 2017.

La peculiaridad es la presencia de similitudes del código y de la infraestructura de red de las muestras analizadas. Admitimos que las conexiones detectadas indican que los backdoors analizados pertenecen a los mismos grupos de hackers.

Los expertos de la empresa Doctor Web recomiendan controlar con regularidad el funcionamiento de los recursos de red importantes y al mismo tiempo prestar atención a los errores que pueden indicar la presencia del malware en la red. El peligro básico de los ataques dirigidos radica no solo en el compromiso de datos, sino también en la presencia continua de los malintencionados en la red corporativa. Este escenario permite controlar el funcionamiento de la empresa durante años y en el momento requerido acceder a la información sensible. En caso de sospechas de actividad maliciosa en la red, recomendamos contactar con el laboratorio de virus Doctor Web que ofrece servicios de análisis de incidentes informáticos vinculados a virus. Las medidas tomadas de forma oportuna permiten reducir el daño y prevenir las consecuencias negativas de los ataques dirigidos.

Indicadores del compromiso