La versión 4.0 del troyano bancario Dridex implementa tecnicas de AtomBombing
Una de las cosas menos conocidas acerca de los virus informáticos es el hecho de que el malware es muy similar al software normal, con frecuencia pasa por los mismos ciclos de desarrollo y recibir actualizaciones constantes.
Aunque la mayoría de los operadores de malware se esfuerzan por mantener la mayor cantidad de su código fuente y los detalles operativos oculta, Dridex siempre ha incrustado su número de versión del software malicioso en su fuente, la cual, a su vez, ha permitido a los investigadores a realizar fácilmente un seguimiento de su evolución.
Dridex alcanza v4 dos años después de su lanzamiento
Este número de versión incluia los binarios y archivos de configuración Dridex que ha permitido a los investigadores crear una línea de tiempo de las principales versiones Dridex. Por ejemplo, sobre la base de los números de versión, Dridex v1 puso en marcha a finales de 2014 y sólo duró hasta los primeros días de 2015.
Dridex v2 era tan efímera como v1, y sólo sobrevivió hasta abril de 2015, cuando fue sustituido por Dridex v3.
La versión v3 era una versión mucho más estable, que Dridex actualiza de forma incremental en pequeños trozos durante los últimos dos años.
Según los expertos, el código fuente del troyano recibió tantas actualizaciones que se pasó de un troyano bancario que se basó en webinjects a la utilización de los ataques de redirección, dos técnicas muy diferentes.
No obstante, a pesar de ello importantes cambios, el resto de las operaciones de Dridex sigue siendo el mismo, a menudo confiando en hVNC para establecer conexiones ocultas a los anfitriones, que se utilizan para controlar los ordenadores infectados a través de los escritorios virtuales que no se ven.
De acuerdo con expertos de IBM, para los creadores del software malicioso Dridex v4, mantienen la mayor parte de las mismas tecnologías de versiones v3 recientes, utilice ataques de redirección para interceptar el tráfico de usuarios, y redirigir a los usuarios a un clon del portal bancario real utilizando un servidor proxy instalado localmente. hVNC entró en juego más adelante, pero sólo si los atacantes se topó con las víctimas con los datos preciosos y necesarios de acceso RAT similar a las máquinas infectadas.
Los expertos dicen que lo que ha cambiado en Dridex v4 es la forma en que el troyano bancario carga su código malicioso en la memoria del host.
Esto puede parecer algo trivial para los observadores casuales, pero esto es un gran problema para los investigadores de seguridad ya que esta es una de las maneras que detectan la actividad del troyano.
En las versiones anteriores de Dridex, los atacantes se basa en diversas llamadas API de Windows para cargar fragmentos de su código malicioso en la memoria del usuario y luego en los procesos del navegador del usuario.
Los productos de seguridad sabían que al observar cómo un par de llamadas a la API de Windows, a menudo usados por una multitud de familias de malware, podrían detectar una amplia gama de comportamientos maliciosos y detenerlo o contenerlo.
Dridex cambia a la novedosa técnica AtomBombing
v4 Dridex tiene este mecanismo de inyección proceso que se basó en un par de llamadas a la API de Windows vistos intensily. De acuerdo con IBM, Dridex v4 ahora utiliza una técnica descubierta por los investigadores enSilo a finales de octubre de 2016.
Este nuevo y un tanto innovadora técnica de inyección de código se llama AtomBombing. En una explicación muy simple, la técnica se basa en almacenar fragmentos de código malicioso dentro de tablas Atom.
Las tablas Atom son específicas para el sistema operativo Windows y permiten que las aplicaciones puedan almacenar el nombre de una cadena y un valor asociado. Atom funcionacon un caché para que las cadenas y las entradas de uso general puede acceder a todas las aplicaciones, no sólo los que crearon los datos.
Investigadores de enSilo descubrieron que los atacantes podrían almacenar código malicioso en estas tablas Atom y después invocarlos sin necesidad de utilizar el mismo ol 'llamadas a la API de Windows.
Cuando enSilo publicó su investigación sobre AtomBombing año pasado, dijeron que estaban revelando esta vía de ataque, ya que Microsoft no podía arreglar el problema, ya que habría implicado reescribir grandes porciones de todo el sistema operativo de Windows, algo que era poco práctico.
Investigadores de EnSilo querían fabricantes de antivirus para tomar nota de cómo trabajó el ataque y desplegar soluciones de detección y mitigación.
Según IBM, la tripulación Dridex parecía ser consciente de las razones de enSilo, ya que sólo se utiliza la primera mitad del enSilo prueba de concepto de explotar, mientras que para la segunda mitad escribieron su propio código.
La técnica se sigue utilizando en tablas de átom para cargar código malicioso en una porción RWX (lectura-escritura-ejecución) de la memoria de la computadora de la víctima, pero debido a que no utiliza la misma API y llamadas a funciones, que evita los mecanismos de detección AtomBombing construidas alrededor enSilo de recomendaciones.
