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

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone

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.

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.

ejecucion-usb-thief

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

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.

Fuente:www.welivesecurity.com

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone