Artimañas de los cibercriminales para evadir detecciones antivirus
A medida que avanza la tecnología, trayendo consigo nuevas medidas de seguridad, los criminales se adaptan y buscan nuevas estrategias para evadir la detección. Estas técnicas no eran muy comunes cinco años atrás y, sin embargo, hoy han dejado de ser la excepción para convertirse en la regla.
Vamos a analizar un documento de Word con macros maliciosas que recibimos hace unos días en nuestro Laboratorio de Investigación de ESET Latinoamérica, y que tiene ciertas particularidades que me gustaría mostrarte. Ya hemos visto en este sitio algunos ejemplos de amenazas de este tipo, como el caso de macro malware en México. Recapitulando ese y otros, veíamos que los documentos de Word tenían macros maliciosas (código en Visual Basic) que se ejecutaban si el usuario hacía clic en el cartel de alerta, otorgando su permiso para la ejecución.
El archivo que analizamos hoy no contiene absolutamente ningún contenido de texto en sí, aunque sí contiene macros que podemos ver con el editor de Visual Basic. Lo primero que me llama la atención es la cantidad de módulos y clases distintas; normalmente estos documentos maliciosos tienen un solo módulo, o dos, como mucho:
El editor nos muestra el código del módulo A0 por defecto y no parece ser malicioso (hasta que empezamos a bajar por el archivo). Luego, con un poco de perspicacia, nos damos cuenta de algo:
- Hay código falso que nunca va a ser ejecutado. Este código se encuentra bien indentado y posee comentarios.
- Hay código malicioso que sí será ejecutado. Lo reconocemos porque no está bien indentado, no tiene comentarios, y los nombres de las variables son sospechosos.
En la imagen de arriba vemos lo mencionado. Todo indica que ese código falso ha sido copiado de algún otro lado, y de hecho es una aplicación no maliciosa para el manejo de archivos CSV que encontramos en github:
Hay subrutinas enteras de este código copiado que nunca van a ejecutarse, pero también se ha mezclado el código en rutinas maliciosas que sí van a ejecutarse, con el uso de condicionales if .. else para los cuales nunca va a cumplirse la condición. Como dijimos antes, la diferencia de indentación y la presencia de comentarios hace más fácil el trabajo del analista. Aquí un ejemplo de este código mezclado (notar también los nombres de variables con productos antivirus):
Otro detalle muy interesante es que el proyecto contiene un Form con controles: labels, text boxes, combo boxes, etc. En las propiedades de estos controles se han escondido strings que luego son usadas para hacer llamadas maliciosas. Por ejemplo: la propiedad Value del TextBox de más abajo es “ratatu”; si buscamos esa string en el código, encontramos una subrutina ratatu en el módulo de clase Ishimitsu.
Asimismo, el código de la subrutina ratatu utiliza la propiedad Text del ComboBox y la función Split para armar un vector de strings que luego serán remplazadas en otro módulo. De igual forma, en otra parte del código se arma otro vector con tres URL desde donde se descarga (con un User Agent personalizado) tres archivos cifrados, que luego son descifrados (XOR y demás operaciones sencillas) y reconstruidos en un ejecutable.
A continuación se ve una parte de la rutina que reconstruye el ejecutable. Notamos las operaciones matemáticas y la llamada a Ashnorog (que no es más que un XOR entre bb y aa):
El análisis puede continuar por remplazo de las strings y variables involucradas, o simplemente realizando debugging. Para concluir, no quiero dejar de notar la cantidad de recursos distintos utilizados para intentar evadir detecciones, como una muestra de la imaginación de los cibercriminales.
Fuente: http://www.welivesecurity.com/
Fecha de consulta: 19 enero 2017
