Denis y su equipo

En abril de este año, presentamos un análisis detallado de un malware que utiliza un túnel DNS para comunicarse con su servidor de administración. Esta investigación sirvió de estímulo para el desarrollo de una tecnología de detección de amenazas similares, que nos ha permitido reunir muchas muestras de malware que usan túneles DNS.

En este artículo analizaremos a los “usuarios” más notables del túnel DNS. Los productos de Kaspersky Lab los detectan tanto con veredictos comunes (Trojan.Denes.UDP.C&C y Backdoor.Win32.Denis.*), como con veredictos “individuales”.

Trojan. Win32. Ismdoor. gen

El primer malware que analizaremos tiene una estructura multinivel de interacción con su servidor de administración, similar al modelo OSI, que lo distingue de otros troyanos descritos. Los autores de Trojan.Win32.Ismdoor.gen de verdad se esmeraron al diseñarlo y desarrollarlo.

Como nivel de transporte utiliza, por supuesto, un túnel DNS. La longitud de los “datagramas” salientes está limitada a 60 caracteres, aunque la configuración del servidor DNS y el propio protocolo tienen la posibilidad de aumentar este valor. Los comandos del servidor se resuelven como una dirección con formato IPv6.

En general, las consultas que se envían al servidor de administración lucen así:

n.n.c.<ID de sesión>.<Dominio del servidor>.com


Estructura de la solicitud y respuesta del “nivel de transporte”

Sobre el protocolo de transporte del túnel DNS se estructur una sesión, que implica la posibilidad de intercambiar paquetes “cortos” y “largos” y que se diferencia del protocolo de transporte por su mecanismo de verificación de mensajes perdidos. Considerando que la sesión de protocolo de transporte finaliza con el intercambio de datos sobre el número de paquetes enviados y recibidos, el protocolo de sesión comprueba la recepción correcta de cada paquete enviado. La elección del método que se utilizará depende del servidor, por ejemplo, se utiliza un protocolo con paquetes “largos” para recibir un archivo de un equipo infectado.

Ejemplo de protocolo para intercambio de mensajes cortos

Mensajes cortos

En este nivel, el funcionamiento del bot se puede dividir en cinco pasos:

  • Anuncio al servidor del Id. de sesión;
  • Envío de mensajes por paquetes;
  • Envío del número de paquetes salientes;
  • Recepción del número de paquetes entrantes;
  • Recepción de los paquetes entrantes.

Ejemplo de sesión:

  1. Anuncio al servidor del Id. de sesión

Cada vez que se abre la sesión, el bot genera un GUID y lo envía al servidor. Este GUID sirve para identificar todas las interacciones posteriores de la sesión, y siempre se lo escribe en el lugar del dominio de tercer nivel. La estructura de la dirección URL en este caso es la siguiente:

n.n.c.<ID de sesión>.<Dominio del servidor>.com

La respuesta positiva es el mensaje A67DDB8A2A17334765443253702AA3. Si es otro, se repetirá el envío.

  1. Envío de un mensaje

Como se mencionó anteriormente, el mecanismo de comunicación seleccionado impone algunas limitaciones al tamaño del paquete. El mensaje saliente se divide en paquetes de una longitud de 60 bytes y se lo transmite como una dirección URL:

<Paquete saliente>.<Número del paquete>.dr.<ID de la sesión>. <Dominio del servidor>.com

Como respuesta debe recibirse A67DDB885A3432576548A2A3707334.

  1. Envío del número de paquetes transferidos

Una vez que se han enviado correctamente todos los paquetes, su número se envía como una consulta del siguiente tipo:

n.<Número de paquetes>.f.<ID de la sesión>.<Dominio del servidor>.com

Debe tenerse en cuenta que la numeración de los paquetes comienza desde 0. La respuesta es 20202020202020202020202020202020.

  1. Recepción del número de paquetes entrantes

Este paso se implementa utilizando una URL similar a:

n.n.fc.<ID de la sesión>.<Dominio del servidor>.com

La respuesta debe ser similar a:

A67D: DB8: 85A3: 4325: 7654: 8A2A :: <Número de paquetes entrantes>

  1. Recepción de paquetes entrantes

La solicitud para recibir un nuevo paquete luce así:

www. <Número del paquete>.s. <ID de la sesión> .<Dominio del servidor>.com

Los mensajes entrantes vienen en forma de paquetes IPv6 de 16 bytes.

Mensajes largos

En este caso, la interacción con el servidor se puede dividir en los siguientes pasos:

  • Envío del número de paquetes en los que se dividió el archivo.
  • Envío del archivo
  • Sondeo periódico del servidor en búsqueda información sobre paquetes perdidos;
  • Reenvío de los paquetes perdidos.

El identificador de sesión se toma de la petición en la que se solicitó el archivo.

  1. Envío del número de paquetes

Petición: n.<Número de paquetes>.<ID de la sesión>.<Dominio del servidor>.com

Respuesta: A67DDB8A2A17334765443253702AA3.

  1. Envío del archivo en paquetes

Petición: <Paquete saliente>.<Número del paquete>.d.<ID de la sesión>. <Dominio del servidor>.com

Respuesta: el servidor no responderá a este mensaje o responderá con un error “Server failure”.

  1. Sondeo periódico del servidor en búsqueda información sobre paquetes perdidos

Periódicamente el bot sondea el servidor:

uff<Número de paquetes>.<Número de paquetes>.<Dominio del servidor>.com

Respuesta: 20202020202020202020202020202020

A continuación se ejecutan los puntos “Obtención del número de paquetes entrantes” y “Recepción de paquetes entrantes” de la sección anterior.

En la respuesta se enumeran, separados por comas, los números de los paquetes no recibidos por el servidor.

  1. Reenvío de los paquetes perdidos

Petición: <Paquete saliente>.<Número del paquete>.dl.<ID de la sesión>. <Dominio del servidor>.com

El nivel de presentación OSI es el responsable de codificar y descodificar los mensajes. La respuesta del servidor contenida en el campo IPv4 se representa como una cadena ASCII regular que es un múltiplo de dieciséis. Las solicitudes DNS que se envían al servidor están codificadas con Base64 con tabla de caracteres redefinida.


Ejemplo del primer mensaje y del mismo mensaje en el cuerpo del “datagrama”

El nivel de aplicación es simplemente un conjunto de llamadas similares a “Get” que se envían al servidor de administración:

  • Verificación de la conexión. La consulta en sí se parece a la cadena “M:CC?”;
  • Registro de la conexión: define los comandos y los Ids. disponibles del equipo infectado y del bot (M:AV?appId=<…>&uniqueId=<…>);
  • Comando de confirmación del registro;
  • Respuesta “generalizada” (M:ME?appId=<…>&message=<…>);
  • Recepción de un comando (M:GAC?appId=8);
  • Confirmación del comando (M:CR?cd=<GUID del comando>);
  • Enviar archivo (M:SF?commandId=CmdResult=<GUID del comando>|||<Resultado de la ejecución del comando>);
  • Recibir archivo (M:GF?).

Como hemos mencionado, el troyano descrito está bien diseñado y bien escrito, y no sólo cuenta con un sistema de comunicación sofisticado, sino también con una carga útil de considerables posibilidades. He aquí una lista de los comandos principales:

  • SI: transmisión de información sobre el sistema infectado;
  • RunNewVersion: actualización;
  • Restart: reinicio;
  • remove : autoeliminación;
  • CreateMimi1Bat: ejecución de Mimikatz;
  • ExecuteKL: activación del keylogger;
  • RemoveKL: eliminación de los archivos creados por ExecuteKL;
  • GetVersion : envío de la versión del malware;
  • PauseUpload: suspende temporalmente la carga de archivos en el servidor;
  • ResumeUpload: reanuda la carga de archivos en el servidor;
  • PauseDownload: suspende temporalmente la descarga de archivos desde el servidor;
  • ResumeDownload : reanuda la descarga de archivos desde el servidor;
  • PWS : crea una captura de pantalla;
  • DownloadFile : descargar un archivo desde el servidor;
  • UploadFile: cargar un archivo en el servidor.

Los demás comandos del troyano son responsables de la lógica de su funcionamiento (cambiar la dirección del servidor de comandos, etc.).

Backdoor.Win32.ClIEcker

Los siguientes ejemplos utilizan otro esquema de trabajo basado en los paquetes ANY DNS. Este mecanismo permite aceptar paquetes DNS de estructura arbitraria enviados desde el servidor. En el troyano no hay ninguna división lógica en subprotocolos: sólo hay solicitudes salientes y entrantes. Pudimos detectar varias modificaciones de este malware, y a continuación describimos las funciones y características presentes en todos ellos.

Una de las características interesantes de Backdoor.Win32.ClIEcker es la forma en que obtiene una dirección IP: utiliza la interfaz COM de Internet Explorer para hacerlo. El troyano contiene una lista de direcciones de sitios donde el visitante puede ver su dirección IP (por ejemplo: http://www.ip-adress.com). El malware selecciona al azar uno, llega a él, encuentra la cadena en el cuerpo de la página donde empieza la dirección IP y la extrae. Con el fin de “disfrazar” la petición al máximo, el troyano también selecciona una dirección de referencia aleatoria y la usa para rellenar la solicitud correspondiente que se envía a Internet Explorer.

No está claro por qué se eligió un método tan complicado: por lo general, los troyanos obtienen la dirección IP de la víctima solicitando datos de sitios que devuelvan una página HTML que contiene la cadena con la dirección IP. Se puede suponer que esto se hizo en un intento de excluir la resolución de la dirección IP de la lista IoC de este malware, o simplemente -sin pensarlo demasiado- la copiaron de un repositorio o foro para luego pegarla en su código.

La situación se agrava por el hecho de que el malware tiene un comando para abrir la página en IE a petición del servidor y para ello utilizar una llamada trivial en formato “iexplore.EXE ya.ru” en lugar de una interacción COM compleja. Debido a esto, nuestro antivirus puede detectar el malware como Trojan-Clicker, pero como ya hemos escrito en un artículo anterior, los troyanos de este grupo suelen utilizar un escritorio virtual para este propósito.

Ejemplos de direcciones para resolver la dirección IP/Direcciones de referentes/Obtención del contenido de la página vía COM

Como consulta de inicio se transmite una serie de parámetros con información del sistema, así como una clave RC4 única creada sobre la base de la información acerca del equipo infectado:

  • Versión del sistema operativo
  • Indicador booleano: que muestra si se utiliza o no una conexión por módem;
  • del troyano;
  • Dirección IP cifrada del usuario;
  • Código de servicio antivirus.

Hay que clarificar el último punto: el troyano contiene una lista de procesos de software de seguridad, donde cada producto tiene su propio bit en el código que se transmite al servidor. Por ejemplo, todos los procesos relacionados con los productos de McAfee se marcarán con el indicador 0X400 en el código de servicio antivirus.

Esta es una descripción de algunos de los comandos:

Código Argumentos Descripción
0 Nombre del archivo Ejecución del archivo descargado.
1 URL Abre la página especificada mediante IE.
2.3 NULL Estos comandos deben recibir el código ejecutable como argumento, guardarlo y ejecutarlo. En el primer caso, se detendrá el funcionamiento del ejemplar que se esté ejecutando. Por alguna razón, su operación está desactivada y el malware, omitiendo el resto de la lista de comandos, envía una nueva solicitud de un nuevo comando.
5 Tiempo de sondeo del servidor en minutos Se contemplan dos períodos diferentes de sondeo del servidor. El primero se aplica si la lista anterior de comandos se ha ejecutado hasta el final. De lo contrario, se utilizará el segundo. Este comando establece el período de espera para la primera opción.
6 NULL Conclusión del trabajo.
7 Período de espera en minutos Pausa del funcionamiento durante el número de minutos especificado.
18 Modificador Si el modificador es >= 0, se ejecuta el siguiente comando de la lista. De lo contrario, el procesamiento de lista se interrumpe.
19 Tiempo de sondeo del servidor en minutos Define el período de sondeo del servidor en caso de que se interrumpa el procesamiento de la lista.
21 NULL Establece el indicador de conexión rápida. Esto permite que el malware sondee el servidor para obtener una nueva lista de comandos inmediatamente después de que se ejecute el anterior.
22 NULL Eliminar el archivo descargado.
23 Nombre del archivo Especifica un nuevo nombre para el archivo descargado.

El comando con el código 8 merece una atención especial porque es el que tiene las principales características del programa. Su tarea es descargar y ejecutar la carga útil. Los argumentos para este comando son los siguientes:

Nombre del argumento Descripción
File_Size Tamaño del archivo a descargar.
SessionID Identificador de sesión.
ServerKey Clave para RC4 recibida desde el servidor.
GetFile_URL URL para descargar el archivo.
DNS_URL Dirección URL del servidor DNS que se usará para crear el túnel DNS.
GetPacketInterval Intervalo de sondeo del servidor para el siguiente paquete.
KeyMod Indicador de cambio de clave.
ReportURL URL del servidor al que se enviará el mensaje que confirma la recepción satisfactoria del archivo.
ExecMode Modificador de ejecución del archivo. Si es mayor que 2, el archivo no se guardará ni se ejecutará. Si es igual a 2, se guardará y ejecutará. De lo contrario, se intentará inyectar el archivo transferido en el proceso de IE.
Packet_Number Número del paquete.

Se utilizan paquetes en el formato DNS TXT para transferir el archivo.

De forma predeterminada, todas las comunicaciones con el servidor se cifran utilizando la clave RC4 generada tomando como referencia la información sobre el equipo infectado. Sin embargo, el servidor puede solicitar un cambio de clave y enviarlo en una solicitud para descargar el archivo. En cualquier caso, para generar un bloque S, la clave se cifra por sí misma y la cadena resultante se utiliza desde ese momento. El bloque S se modifica según el número de cada paquete, gracias a lo cual será único para cada nuevo paquete.

Una vez completado el descifrado, la integridad del archivo resultante se comprueba mediante el algoritmo CRC32.

Backdoor.Win32.Denis

Backdoor.Win32.Denis tiene la estructura más simple y la forma más simple de interacción con el servidor DNS. El nombre de este malware coincide con el nombre del troyano descrito en este artículo, pero es lo único que tienen en común.

Para comunicarse con el servidor DNS, se utiliza un paquete de formato A DNS que limita el tamaño de respuesta a cuatro bytes. Todo parece indicar que este malware es un Trojan-Downloader común y corriente con una velocidad de descarga extremadamente baja. A grandes rasgos, así luce la solicitud que se envía al servidor:

IC<Tipo de contenedor>.<UID>.<Contenedor>.<Dirección del servidor>

Hemos denominado “contenedor” a los resultados empaquetados del funcionamiento del troyano. Dependiendo del comando y la respuesta, la estructura del contenedor puede variar enormemente. UID es el identificador del usuario, que tiene una longitud de 0x20. Es una cadena Base32, que una vez descifrada tiene la siguiente estructura:

Offset Descripción
0x0 – 0xF Contiene el nombre del host del usuario.
0x10 – 0x14 Contiene la dirección IP del usuario.

El contenedor es también una cadena Base32:

Offset Descripción
0x0 – 0x3 Tiempo de creación del mensaje en segundos.
0x4 – 0xB Firma “IACIMAOQ”.
0xC – 0x22 Mensaje.

Sólo existen cuatro tipos de contenedores. El troyano determina cuál es el necesario después de analizar el comando entrante y los resultados de su ejecución:

Tipo Propósito Mensaje Descripción
1 Envío de información sobre el sistema. Información sobre las unidades lógicas en el sistema del usuario. El primer byte indica el número de datos transmitidos. Le siguen pares de bytes: la letra de la unidad lógica y su tipo. La parte restante está llena de caracteres arbitrarios.
2 Envío de información sobre el estado de recepción de un archivo. Tamaño original del archivo, tamaño real del archivo recibido, número de respuestas perdidas Si el archivo que se está cargando ya no existe, se lo crea y el tipo de contenedor se cambia a 1. De lo contrario, se envía un mensaje donde los primeros 4 bytes contienen el tamaño real del archivo que se está enviando, recibido en el mensaje con el código 0XC0. Los siguientes 4 bytes almacenan el tamaño del archivo recibido en un momento determinado. Le siguen 4 bytes con el conteo de mensajes perdidos enviados desde el servidor. La parte restante está llena de caracteres arbitrarios.
3 Envío de la confirmación de recepción satisfactoria de todo el archivo. No Antes de cada interacción de red se compara el tamaño original del archivo con el tamaño del archivo recibido. Si coinciden, el tipo de contenedor se cambia a 4.
4 Envío de la confirmación de la ejecución satisfactoria del comando con el código 0XCB. No NULL

Comandos

Código Argumentos Descripción
0x7F Se almacena en el cuarto byte. Número de minutos. Esperar el número de minutos especificado. Envío del contenedor de tipo 1.
0xC0 Se almacena en los últimos tres bytes. Tamaño del archivo cargado. Recepción del tamaño del archivo cargado.
Envío del contenedor de tipo 2.
0xCB NULL Cambia el nombre del archivo ejecutable actual a
< APPDATA>\ IACIMAOQ.
Envío del contenedor de tipo 4.
0xA El segundo byte almacena el número de paquete. El tercero y el cuarto son el par de bytes del archivo cargado. Recepción de parte del archivo y su escritura posterior, envío del contenedor de tipo 1.

Como se observar después de leer la descripción de los comandos, el troyano está destinado a descargar y ejecutar archivos.

MD5

15b36b1e3a41ad80bbd363aea8f2d704 — Trojan.Win32.Ismdoor.gen
1FD599FB9FA62EB91511002771D78104 — Backdoor.Win32.ClIEcker
1f3a2c48a7f5c2c31e71f552d74c3543 — Backdoor.Win32.Denis

Publicaciones relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *