Protege lo creado

Otros recursos

  • free.drweb-av.es — utilidades gratuitas, complementos, informadores
  • av-desk.com — un servicio en Internet para los proveedores de servicios Dr.Web AV-Desk
  • curenet.drweb.com — utilidad de desinfección de red Dr.Web CureNet!
Cerrar

Mi biblioteca
Mi biblioteca

+ Añadir a la biblioteca

Soporte
Soporte 24 horas | Normas de contactar

Sus solicitudes

Perfil

Volver a las noticias

Investigación de ataques dirigidos a Institutos de investigación científica rusos

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.

#drweb

¿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:

#drweb

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

#drweb

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
#drweb #drweb
Función de recepción de la información sobre discos
#drweb #drweb
Función de indicar los archivos en la carpeta
#drweb #drweb
Función de recopilación de la información sobre archivos en la carpeta
#drweb #drweb

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.

#drweb

Buscar el proxy en su archivo de registro:

#drweb

Buscar en conexiones activas:

#drweb

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.

#drweb

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.

#drweb

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.

#drweb

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.

BackDoor.Mikroceen.11 BackDoor.Logtu.1
SHA1 Id SHA1 id
ce21f798119dbcb7a63f8cdf070545abb09f25ba intl0113 029735cb604ddcb9ce85de92a6096d366bd38a24 intpz0220
0eb2136c5ff7a92706bc9207da32dd85691eeed5 hisa5.si4 7b652e352a6d2a511f226e4d0cc22f093e052ad8 retail2007
2f80f51188dc9aea697868864d88925d64c26abc josa5w5n 1c5e5fd53fc2ee778342a5cae3ac2eb0ac345ed7 retail
2e50c075343ab20228a8c0c094722bbff71c4a2a enc0225 00ddcc200d1031b8639026532c0087bfcc4520c9 716demo
3bd16f11b5b3965a124a6fc3286297e5cfe77715 520299 b599797746ae8ccf7907cf88de232faa30ec95e6 gas-zhi
5eecdf63e85833e712a1ff88df1341bbf32f4ab8 Strive 2d672d7818a56029b337e8792935195d53576a9d jjlk
bd308f4d1a32096a3b90cfdae45bbc5c13e5e801 R0916
b1be4b2f874c8309f553acce90287c8c6bb2b6b1 frsl.1ply
21ffd24b8074d7cffdf4cc339d1fa8fe892eba27 Wdv
8fbec09e646311a285aee06b3dd45ccf58928703 intz726
19921cc47b3de003186e65fd12b82235030f060d 122764
0f70251abc8c64cbc7b24995c3d32927514d0a4b V20180224
149947544ca4f7baa5bc3d00b080d0e943d8036b SOE
e7f5a33b33e023a82ac9eee6ed40e4a38ce95277 int815
b4790eec7daa9f931bed43a53f66168b477599a7 UOE
ab660a3ac46d563c756463bd1b64cc45f347a1f7 B.Z11NOV20D
d0181759a175fbcc60975983b351f88970f484f9 299520
7a63fc9db2bc1e9b1ef793723d5877e6b4c566b8 WinVideo
13779006d0dafbe4b27bd282230df299eef2b8dc SSLSSL
f53c77695a162c78c68f693f57f65752d17f6030 int007server
924341cab6106ef993b506193e6786e459936069 intl1211
8ebf78c84cd7f66ca8708467a28d83658bcf6710 intl821
f2856d7d138430e164f83662e251ee311950d83c intl821

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

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

#drweb

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

#drweb

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

Nos importa su opinión

Para hacer una pregunta sobre la noticia para la administración del sitio web, indique al principio de su comentario @admin. Si su pregunta es para el autor de algún comentario - indique @ antes de escribir su nombre.


Otros comentarios

Desarrollador ruso de antivirus Dr.Web
Experiencia de desarrollo a partir del año 1992
Dr.Web se usa en más de 200 países del mundo
Entrega de antivirus como servicio a partir del año 2007
Soporte 24 horas

Dr.Web © Doctor Web
2003 — 2021

Doctor Web es un productor ruso de los medios antivirus de protección de la información bajo la marca Dr.Web. Los productos Dr.Web se desarrollan a partir del año 1992.

125124, Rusia, Moscú, c/3 Yamskogo Polya, 2, edif.12А