Autores
En abril de este ano, presentamos un analisis detallado de un malware que utiliza un tunel DNS para comunicarse con su servidor de administracion. Esta investigacion sirvio de estimulo para el desarrollo de una tecnologia de deteccion de amenazas similares, que nos ha permitido reunir muchas muestras de malware que usan tuneles DNS.
En este articulo analizaremos a los “usuarios” mas notables del tunel 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 interaccion con su servidor de administracion, similar al modelo OSI, que lo distingue de otros troyanos descritos. Los autores de Trojan.Win32.Ismdoor.gen de verdad se esmeraron al disenarlo y desarrollarlo.
Como nivel de transporte utiliza, por supuesto, un tunel DNS. La longitud de los “datagramas” salientes esta limitada a 60 caracteres, aunque la configuracion del servidor DNS y el propio protocolo tienen la posibilidad de aumentar este valor. Los comandos del servidor se resuelven como una direccion con formato IPv6.
En general, las consultas que se envian al servidor de administracion lucen asi:
n.n.c.<ID de sesion>.<Dominio del servidor>.com
Estructura de la solicitud y respuesta del “nivel de transporte”
Sobre el protocolo de transporte del tunel DNS se estructur una sesion, que implica la posibilidad de intercambiar paquetes “cortos” y “largos” y que se diferencia del protocolo de transporte por su mecanismo de verificacion de mensajes perdidos. Considerando que la sesion de protocolo de transporte finaliza con el intercambio de datos sobre el numero de paquetes enviados y recibidos, el protocolo de sesion comprueba la recepcion correcta de cada paquete enviado. La eleccion del metodo que se utilizara 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 sesion;
- Envio de mensajes por paquetes;
- Envio del numero de paquetes salientes;
- Recepcion del numero de paquetes entrantes;
- Recepcion de los paquetes entrantes.
Ejemplo de sesion:
- Anuncio al servidor del Id. de sesion
Cada vez que se abre la sesion, el bot genera un GUID y lo envia al servidor. Este GUID sirve para identificar todas las interacciones posteriores de la sesion, y siempre se lo escribe en el lugar del dominio de tercer nivel. La estructura de la direccion URL en este caso es la siguiente:
n.n.c.<ID de sesion>.<Dominio del servidor>.com
La respuesta positiva es el mensaje A67DDB8A2A17334765443253702AA3. Si es otro, se repetira el envio.
- Envio de un mensaje
Como se menciono anteriormente, el mecanismo de comunicacion seleccionado impone algunas limitaciones al tamano del paquete. El mensaje saliente se divide en paquetes de una longitud de 60 bytes y se lo transmite como una direccion URL:
<Paquete saliente>.<Numero del paquete>.dr.<ID de la sesion>. <Dominio del servidor>.com
Como respuesta debe recibirse A67DDB885A3432576548A2A3707334.
- Envio del numero de paquetes transferidos
Una vez que se han enviado correctamente todos los paquetes, su numero se envia como una consulta del siguiente tipo:
n.<Numero de paquetes>.f.<ID de la sesion>.<Dominio del servidor>.com
Debe tenerse en cuenta que la numeracion de los paquetes comienza desde 0. La respuesta es 20202020202020202020202020202020.
- Recepcion del numero de paquetes entrantes
Este paso se implementa utilizando una URL similar a:
n.n.fc.<ID de la sesion>.<Dominio del servidor>.com
La respuesta debe ser similar a:
A67D: DB8: 85A3: 4325: 7654: 8A2A :: <Numero de paquetes entrantes>
- Recepcion de paquetes entrantes
La solicitud para recibir un nuevo paquete luce asi:
www. <Numero del paquete>.s. <ID de la sesion> .<Dominio del servidor>.com
Los mensajes entrantes vienen en forma de paquetes IPv6 de 16 bytes.
Mensajes largos
En este caso, la interaccion con el servidor se puede dividir en los siguientes pasos:
- Envio del numero de paquetes en los que se dividio el archivo.
- Envio del archivo
- Sondeo periodico del servidor en busqueda informacion sobre paquetes perdidos;
- Reenvio de los paquetes perdidos.
El identificador de sesion se toma de la peticion en la que se solicito el archivo.
- Envio del numero de paquetes
Peticion: n.<Numero de paquetes>.<ID de la sesion>.<Dominio del servidor>.com
Respuesta: A67DDB8A2A17334765443253702AA3.
- Envio del archivo en paquetes
Peticion: <Paquete saliente>.<Numero del paquete>.d.<ID de la sesion>. <Dominio del servidor>.com
Respuesta: el servidor no respondera a este mensaje o respondera con un error “Server failure”.
- Sondeo periodico del servidor en busqueda informacion sobre paquetes perdidos
Periodicamente el bot sondea el servidor:
uff<Numero de paquetes>.<Numero de paquetes>.<Dominio del servidor>.com
Respuesta: 20202020202020202020202020202020
A continuacion se ejecutan los puntos “Obtencion del numero de paquetes entrantes” y “Recepcion de paquetes entrantes” de la seccion anterior.
En la respuesta se enumeran, separados por comas, los numeros de los paquetes no recibidos por el servidor.
- Reenvio de los paquetes perdidos
Peticion: <Paquete saliente>.<Numero del paquete>.dl.<ID de la sesion>. <Dominio del servidor>.com
El nivel de presentacion 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 multiplo de dieciseis. Las solicitudes DNS que se envian al servidor estan codificadas con Base64 con tabla de caracteres redefinida.
Ejemplo del primer mensaje y del mismo mensaje en el cuerpo del “datagrama”
El nivel de aplicacion es simplemente un conjunto de llamadas similares a “Get” que se envian al servidor de administracion:
- Verificacion de la conexion. La consulta en si se parece a la cadena “M:CC?”;
- Registro de la conexion: define los comandos y los Ids. disponibles del equipo infectado y del bot (M:AV?appId=<…>&uniqueId=<…>);
- Comando de confirmacion del registro;
- Respuesta “generalizada” (M:ME?appId=<…>&message=<…>);
- Recepcion de un comando (M:GAC?appId=8);
- Confirmacion del comando (M:CR?cd=<GUID del comando>);
- Enviar archivo (M:SF?commandId=CmdResult=<GUID del comando>|||<Resultado de la ejecucion del comando>);
- Recibir archivo (M:GF?).
Como hemos mencionado, el troyano descrito esta bien disenado y bien escrito, y no solo cuenta con un sistema de comunicacion sofisticado, sino tambien con una carga util de considerables posibilidades. He aqui una lista de los comandos principales:
- SI: transmision de informacion sobre el sistema infectado;
- RunNewVersion: actualizacion;
- Restart: reinicio;
- remove : autoeliminacion;
- CreateMimi1Bat: ejecucion de Mimikatz;
- ExecuteKL: activacion del keylogger;
- RemoveKL: eliminacion de los archivos creados por ExecuteKL;
- GetVersion : envio de la version 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 demas comandos del troyano son responsables de la logica de su funcionamiento (cambiar la direccion 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 division logica en subprotocolos: solo hay solicitudes salientes y entrantes. Pudimos detectar varias modificaciones de este malware, y a continuacion describimos las funciones y caracteristicas presentes en todos ellos.
Una de las caracteristicas interesantes de Backdoor.Win32.ClIEcker es la forma en que obtiene una direccion 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 direccion IP (por ejemplo: http://www.ip-adress.com). El malware selecciona al azar uno, llega a el, encuentra la cadena en el cuerpo de la pagina donde empieza la direccion IP y la extrae. Con el fin de “disfrazar” la peticion al maximo, el troyano tambien selecciona una direccion de referencia aleatoria y la usa para rellenar la solicitud correspondiente que se envia a Internet Explorer.
No esta claro por que se eligio un metodo tan complicado: por lo general, los troyanos obtienen la direccion IP de la victima solicitando datos de sitios que devuelvan una pagina HTML que contiene la cadena con la direccion IP. Se puede suponer que esto se hizo en un intento de excluir la resolucion de la direccion 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 codigo.
La situacion se agrava por el hecho de que el malware tiene un comando para abrir la pagina en IE a peticion del servidor y para ello utilizar una llamada trivial en formato “iexplore.EXE ya.ru” en lugar de una interaccion COM compleja. Debido a esto, nuestro antivirus puede detectar el malware como Trojan-Clicker, pero como ya hemos escrito en un articulo anterior, los troyanos de este grupo suelen utilizar un escritorio virtual para este proposito.
Ejemplos de direcciones para resolver la direccion IP/Direcciones de referentes/Obtencion del contenido de la pagina via COM
Como consulta de inicio se transmite una serie de parametros con informacion del sistema, asi como una clave RC4 unica creada sobre la base de la informacion acerca del equipo infectado:
- Version del sistema operativo
- Indicador booleano: que muestra si se utiliza o no una conexion por modem;
- del troyano;
- Direccion IP cifrada del usuario;
- Codigo de servicio antivirus.
Hay que clarificar el ultimo punto: el troyano contiene una lista de procesos de software de seguridad, donde cada producto tiene su propio bit en el codigo que se transmite al servidor. Por ejemplo, todos los procesos relacionados con los productos de McAfee se marcaran con el indicador 0X400 en el codigo de servicio antivirus.
Esta es una descripcion de algunos de los comandos:
| Codigo | Argumentos | Descripcion |
| 0 | Nombre del archivo | Ejecucion del archivo descargado. |
| 1 | URL | Abre la pagina especificada mediante IE. |
| 2.3 | NULL | Estos comandos deben recibir el codigo ejecutable como argumento, guardarlo y ejecutarlo. En el primer caso, se detendra el funcionamiento del ejemplar que se este ejecutando. Por alguna razon, su operacion esta desactivada y el malware, omitiendo el resto de la lista de comandos, envia una nueva solicitud de un nuevo comando. |
| 5 | Tiempo de sondeo del servidor en minutos | Se contemplan dos periodos 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 utilizara el segundo. Este comando establece el periodo de espera para la primera opcion. |
| 6 | NULL | Conclusion del trabajo. |
| 7 | Periodo de espera en minutos | Pausa del funcionamiento durante el numero 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 periodo de sondeo del servidor en caso de que se interrumpa el procesamiento de la lista. |
| 21 | NULL | Establece el indicador de conexion rapida. Esto permite que el malware sondee el servidor para obtener una nueva lista de comandos inmediatamente despues 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 codigo 8 merece una atencion especial porque es el que tiene las principales caracteristicas del programa. Su tarea es descargar y ejecutar la carga util. Los argumentos para este comando son los siguientes:
| Nombre del argumento | Descripcion |
| File_Size | Tamano del archivo a descargar. |
| SessionID | Identificador de sesion. |
| ServerKey | Clave para RC4 recibida desde el servidor. |
| GetFile_URL | URL para descargar el archivo. |
| DNS_URL | Direccion URL del servidor DNS que se usara para crear el tunel DNS. |
| GetPacketInterval | Intervalo de sondeo del servidor para el siguiente paquete. |
| KeyMod | Indicador de cambio de clave. |
| ReportURL | URL del servidor al que se enviara el mensaje que confirma la recepcion satisfactoria del archivo. |
| ExecMode | Modificador de ejecucion del archivo. Si es mayor que 2, el archivo no se guardara ni se ejecutara. Si es igual a 2, se guardara y ejecutara. De lo contrario, se intentara inyectar el archivo transferido en el proceso de IE. |
| Packet_Number | Numero 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 informacion 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 si misma y la cadena resultante se utiliza desde ese momento. El bloque S se modifica segun el numero de cada paquete, gracias a lo cual sera unico 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 mas simple y la forma mas simple de interaccion con el servidor DNS. El nombre de este malware coincide con el nombre del troyano descrito en este articulo, pero es lo unico que tienen en comun.
Para comunicarse con el servidor DNS, se utiliza un paquete de formato A DNS que limita el tamano de respuesta a cuatro bytes. Todo parece indicar que este malware es un Trojan-Downloader comun y corriente con una velocidad de descarga extremadamente baja. A grandes rasgos, asi luce la solicitud que se envia al servidor:
IC<Tipo de contenedor>.<UID>.<Contenedor>.<Direccion 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 | Descripcion |
| 0x0 – 0xF | Contiene el nombre del host del usuario. |
| 0x10 – 0x14 | Contiene la direccion IP del usuario. |
El contenedor es tambien una cadena Base32:
| Offset | Descripcion |
| 0x0 – 0x3 | Tiempo de creacion del mensaje en segundos. |
| 0x4 – 0xB | Firma “IACIMAOQ”. |
| 0xC – 0x22 | Mensaje. |
Solo existen cuatro tipos de contenedores. El troyano determina cual es el necesario despues de analizar el comando entrante y los resultados de su ejecucion:
| Tipo | Proposito | Mensaje | Descripcion |
| 1 | Envio de informacion sobre el sistema. | Informacion sobre las unidades logicas en el sistema del usuario. | El primer byte indica el numero de datos transmitidos. Le siguen pares de bytes: la letra de la unidad logica y su tipo. La parte restante esta llena de caracteres arbitrarios. |
| 2 | Envio de informacion sobre el estado de recepcion de un archivo. | Tamano original del archivo, tamano real del archivo recibido, numero de respuestas perdidas | Si el archivo que se esta cargando ya no existe, se lo crea y el tipo de contenedor se cambia a 1. De lo contrario, se envia un mensaje donde los primeros 4 bytes contienen el tamano real del archivo que se esta enviando, recibido en el mensaje con el codigo 0XC0. Los siguientes 4 bytes almacenan el tamano del archivo recibido en un momento determinado. Le siguen 4 bytes con el conteo de mensajes perdidos enviados desde el servidor. La parte restante esta llena de caracteres arbitrarios. |
| 3 | Envio de la confirmacion de recepcion satisfactoria de todo el archivo. | No | Antes de cada interaccion de red se compara el tamano original del archivo con el tamano del archivo recibido. Si coinciden, el tipo de contenedor se cambia a 4. |
| 4 | Envio de la confirmacion de la ejecucion satisfactoria del comando con el codigo 0XCB. | No | NULL |
Comandos
| Codigo | Argumentos | Descripcion |
| 0x7F | Se almacena en el cuarto byte. Numero de minutos. | Esperar el numero de minutos especificado. Envio del contenedor de tipo 1. |
| 0xC0 | Se almacena en los ultimos tres bytes. Tamano del archivo cargado. | Recepcion del tamano del archivo cargado. Envio del contenedor de tipo 2. |
| 0xCB | NULL | Cambia el nombre del archivo ejecutable actual a < APPDATA>\ IACIMAOQ. Envio del contenedor de tipo 4. |
| 0xA | El segundo byte almacena el numero de paquete. El tercero y el cuarto son el par de bytes del archivo cargado. | Recepcion de parte del archivo y su escritura posterior, envio del contenedor de tipo 1. |
Como se observar despues de leer la descripcion de los comandos, el troyano esta destinado a descargar y ejecutar archivos.
MD5
15b36b1e3a41ad80bbd363aea8f2d704 — Trojan.Win32.Ismdoor.gen
1FD599FB9FA62EB91511002771D78104 — Backdoor.Win32.ClIEcker
1f3a2c48a7f5c2c31e71f552d74c3543 — Backdoor.Win32.Denis
Autores
En la misma categoría
Denis y su equipo