Español | English
rss facebook linkedin Twitter

El troyano Dexter

Dexter es un conocido troyano orientado al robo de tarjetas en los TPV. Aunque las primeras versiones fueron vistas en Diciembre de 2012, una nueva versión, conocida como Dexter v2 o StarDust fue descubierta en Diciembre de 2013. Entre las funciones de StarDust se encuentran la localización de pistas de las bandas magnéticas de las tarjetas de crédito en memoria y funciones de keylogger. En este artículo vamos a analizar las técnicas de comunicación del troyano con su control panel.

StartDust utiliza peticiones POST para el envío de datos. Los parámetros del POST son cifrados mediante XOR con una cadena aleatoria creada durante la instalación del malware y luego codificados en Base64. Sin embargo, la clave XOR es enviada con los parámetros con un simple Base64, por lo que el cifrado podría considerarse simplemente como una ofuscación de los datos. A cada petición, el servidor responde en una Cookie, que puede incluir comandos para el control del troyano (actualizarse, desinstalarse, forzar un chequeo de memoria, etc.)


La función que crea el cuerpo de la petición, recoge ciertos datos de la máquina y genera la cadena para el POST:

Los parámetros se van añadiendo a request_body usando la función encode_param(char *param, char *value, char * request_body), la cual codifica los valores de los parámetros con XOR y Base64 y añade el parámetro y el valor codificado a la cadena destino. Por último se añade el parámetro val con la clave usada para la codificación XOR, codificada únicamente con Base64.


La función de codificación por XOR muestra defectos de diseño, aunque es suficiente para ocultar las cadenas, no lo es desde un punto de vista criptográfico.


La clave de codificación que genera el bot es de 5 bytes, sin embargo el uso de la función XOR la reduce a una longitud efectiva de 1 byte. Siendo los bucles principales de la siguiente manera:


for(i=0; i
    for(j=0; j
        string[i] ^= xor_key[j];
    }
}


Debido a la propiedad conmutativa de XOR, el bucle interior podría expandirse como:

string[i] ^= xor_key[0] ^ xor_key[1] ^ xor_key[2] ^ xor_key[3] ^ xor_key[4] 

O lo que es lo mismo:

xor_value = xor_key[0] ^ xor_key[1] ^ xor_key[2] ^ xor_key[3] ^ xor_key[4];
for(i=0; i
    string[i] ^= xor_value;
}


Lo que convierte en la práctica la longitud de la clave XOR a un valor de 1 byte.

Volviendo al análisis de las comunicaciones, en caso de que exista el fichero strokes.log, que es generado por el keylogger lo descifra con la misma función xor_encode usando una clave propia que aparece en los 4 primeros bytes del fichero. Una vez descifrado, genera el parámetro ks codificándolo de nuevo, esta vez con la clave XOR del resto de parámetros.


Si es la primera vez que se comunica con la dropzone, añade los parámetros unm, cnm, query y spec con el usuario, nombre de la maquina, la versión del sistema operativo y la arquitectura (“32 bits” o “64 bits”) de la máquina infectada.

Tras enviar la petición, lee la cookie response, cifrada de la misma manera que la petición y procesa la respuesta en busca de comandos.



La respuesta tiene el siguiente formato:

    #[comando1][;comando2][…]$

Pudiendo enviarse una respuesta vacía con la cadena '#$'
Los comandos aceptados por el malware son:

  • checkin: fuerza el envió de datos de tarjetas
  • scanin: fuerza el escaneo de memoria en busca de tarjetas
  • uninstall: desinstala el troyano
  • download: descarga un fichero de la url especificada
  • update: descarga una nueva versión del troyano y se instala 


El uso de cookies para enviar la respuesta desde el servidor es una manera original de esconder las comunicaciones del troyano durante un análisis dinámico o inspeccionado el tráfico en red, aunque los parámetros del POST deberían ser suficientes para que un IDS detecte la presencia del troyano.

Marcos Agüero
S21sec ecrime



(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login