Un nuevo troyano USB con autodefensa única evade la detección

Recientemente se ha detectado un troyano in the wild en dispositivos USB para robar datos, cuyas características únicas lo diferencian de los demás tipos de malware tradicionales con el mismo fin. Cada instancia de ejecución del troyano se basa en propiedades del dispositivo USB específico donde está instalado. Además, no deja ninguna evidencia en el sistema infectado. Por otra parte, emplea un mecanismo especial para protegerse ante la copia o reproducción, lo que lo hace aún más difícil de detectar.

En este artículo examinaremos los detalles técnicos de este interesante malware, que denominamos USB Thief.

“LO QUE REALMENTE HACE A ESTE MALWARE ÚNICO ES SU MECANISMO DE AUTODEFENSA”

Mientras que otros tipos de malware utilizan tácticas más tradicionales para conseguir que los usuarios lo ejecuten (como archivos de ejecución automática Autorun o accesos directos especialmente diseñados), USB Thief también emplea otra técnica. Su método se basa en la práctica cada vez más común de almacenar versiones portátiles de aplicaciones populares como Firefox, Notepad ++ y TrueCrypt en las unidades USB.

Para aprovechar esta creciente tendencia, el malware se inserta en la cadena de ejecución de este tipo de aplicaciones, ya sea como un complemento (plugin) o como una biblioteca de vínculos dinámicos (DLL). En consecuencia, cada vez que se ejecuta la aplicación correspondiente, el malware también se ejecuta en segundo plano.

Sin embargo, lo que realmente hace que este malware sea único es su mecanismo de autodefensa.

El mecanismo de protección

El malware está conformado por seis archivos. Cuatro de ellos son ejecutables y los otros dos contienen datos de configuración. Para protegerse de la copia o la ingeniería inversa, el malware utiliza dos técnicas. En primer lugar, algunos de los archivos individuales están cifrados con AES de 128 bits; en segundo lugar, sus nombres de archivo se generan a partir de elementos criptográficos.

La clave de cifrado AES se calcula a partir del ID único del dispositivo USB donde se aloja, y de ciertas propiedades de disco de dicha unidad USB específica. Por lo tanto, el malware solo se puede ejecutar con éxito desde ese dispositivo USB en particular.

El nombre del siguiente archivo en la cadena de ejecución del malware se basa en el contenido real del archivo y en la fecha y hora de su creación. Son los primeros cinco bytes del hash SHA512 calculado a partir de los atributos mencionados (el contenido del archivo más ocho bytes correspondientes a la fecha y hora de su creación).

Debido a esto, los nombres de archivo son diferentes para cada instancia del malware. Por otra parte, si se copia el malware a una ubicación diferente, se reemplaza la fecha y hora de creación del archivo, por lo tanto, las acciones maliciosas asociadas con la ubicación anterior no pueden ejecutarse. Para comprender mejor la técnica de nomenclatura, mira la imagen más abajo.

Analizar este malware fue todo un reto, dado que no teníamos acceso a ningún dispositivo USB malicioso. Tampoco teníamos el dropper, así que no pudimos crear una unidad USB convenientemente maliciosa bajo condiciones controladas para su análisis minucioso.

Solo pudimos analizar los archivos enviados, por lo que fue necesario adivinar el ID de dispositivo único por fuerza bruta y combinarlo con las propiedades comunes del disco USB. Por otra parte, después de descifrar con éxito los archivos del malware, tuvimos que averiguar el orden correcto de los ejecutables y de los archivos de configuración, ya que el proceso de copia del malware al enviarnos los archivos de muestra había cambiado la fecha y hora de creación del archivo.

El flujo de ejecución de malware es bastante simple. Cada loader, a su vez, carga y ejecuta el siguiente loader identificado por un hash calculado de acuerdo a la técnica de nomenclatura descrita arriba. No obstante, la ejecución debe comenzar siempre con el primer loader, de lo contrario, el programa malicioso finaliza automáticamente.

Primer loader

El primer loader es tan solo el punto de partida del malware y su principal objetivo es engañar al usuario para que lo ejecute. Esto se puede logar de varias formas, pero la más interesante en este caso es el uso de aplicaciones portátiles. Ya hemos observado una instancia de Notepad++ portátil infectada por un complemento malicioso, así como una instancia de TrueCrypt portátil infectada por una biblioteca “RichEd20.dll” maliciosa. Este loader también comprueba si se está ejecutando desde un dispositivo USB y si no está protegido contra escritura, lo que es importante, ya que el payload almacenará allí mismo los datos robados.

Segundo loader

Para encontrar el segundo loader, se utiliza el hash de la primera etapa. A continuación, se encuentra el archivo de configuración utilizando su propio hash. El archivo de configuración contiene el nombre cifrado del proceso padre que debe verificarse. Su objetivo es evitar los procesos de depuración, es decir que finalizará la actividad del malware si se está ejecutando bajo un proceso padre diferente, por ejemplo, un depurador. Por último, el hash del archivo de configuración se utiliza para calcular el nombre del tercer loader.

Tercer loader

El tercer loader se encarga de hacer algunos controles para detectar programas antivirus. Si uno de los procesos en ejecución es “avpui.exe” (software de seguridad de Kaspersky) o “AVKTray.exe” (software de seguridad de G Data), se detiene la ejecución del malware de inmediato.

Para encontrar el archivo de configuración, se emplea la misma técnica utilizada por su predecesor, al igual que el payload ejecutable. También crea una canalización con nombre que se utiliza para pasar los datos de configuración al payload. El nombre de la canalización está conformado por los primeros 30 bytes de un hash SHA512 calculado a partir del nombre del equipo.

Payload

Por último, el payload implementa la funcionalidad real del robo de datos. El ejecutable se inyecta en un nuevo proceso “%windir%\system32\svchost.exe -k netsvcs”. Los datos de configuración incluyen información sobre los datos que se deben recopilar, cómo se deben cifrar y dónde se deben almacenar.

El destino de salida debe ser siempre el mismo dispositivo extraíble. En el caso analizado, se configuró para robar todos los archivos de datos como imágenes o documentos, el árbol entero de registro de Windows (HKCU), las listas de archivos de todas las unidades y la información extraída por medio de una aplicación importada de código abierto llamada “WinAudit”. Para cifrar los datos robados usa criptografía de curva elíptica.

Conclusión

“NO SERÍA DIFÍCIL REDISEÑAR EL MALWARE PARA QUE EL PAYLOAD DE ROBO DE DATOS PASE A TENER CUALQUIER OTRO PROPÓSITO MALICIOSO”

Además del concepto interesante de un malware con autodefensa y múltiples etapas de ejecución, el payload (relativamente simple) para el robo de datos es muy potente, sobre todo porque no deja ninguna evidencia en el equipo infectado. Una vez que se quita el USB del sistema, nadie puede descubrir que los datos fueron robados. Además, no sería difícil rediseñar el malware para que el payload de robo de datos pase a tener cualquier otro propósito malicioso.

Como se observa en las estadísticas de ESET, el malware no está muy extendido. Sin embargo, posee la capacidad de ser utilizado en ataques dirigidos, sobre todo en equipos que no están conectados a Internet por razones de seguridad.

Nuestra detección:

Payload: Win32/PSW.Stealer.NAI trojan
Loaders: Win32/TrojanDropper.Agent.RFT trojan

Hashes SHA1 de binarios descifrados:

2C188C395AB32EAA00E6B7AA031632248FF38B2E
B03ABE820C0517CCEF98BC1785B7FD4CDF958278
66D169E1E503725A720D903E1DFAF456DB172767
4B2C60D77915C5695EC9D3C4364E6CD6946BD33C
76471B0F34ABB3C2530A16F39E10E4478CB6816D

Fuente: http://www.welivesecurity.com/

Fecha de consulta: 01 Abril 2016