El trabajo de análisis requiere de una lucha continua contra código desconocido, ofuscado y cifrado. Recientemente me encontraba peleándome con un VBScript que, cómo no, se encontraba ofuscado (al menos dos capas de protección). Tras superar la primera protección y empezar con la segunda, comprobé que el método de descifrado en este punto no era trivial. Esto se sumaba a una aversión, por cuestiones meramente personales, por este lenguaje. Un análisis dinámico me podía dar la secuencia de comandos que finalmente se ejecutaban, pero perdía entonces visibilidad de todo cuanto había ocurrido por mitad. Y… ¿quién sabe? A lo mejor hay alguna técnica antianálisis por mitad que modifica el comportamiento del script para contactar contra otra infraestructura diferente. Siempre con el modo paranoico encendido.
Decidí que iba a atajar el asunto de raíz. Tanto el primer script como el segundo descifrado, después de desprotegerse, hacían uso de la función ‘Execute’ de VBScript para dar vida a su código antes protegido. Internamente, el proceso que ejecuta el script (‘wscript.exe’ en este caso), tendría que manejar el buffer descifrado y pasarlo a otra función que se encargue de ejecutarlo. Pero… ¿Dónde se encontraba susodicha función?
Con fines didácticos, en lugar de analizar la aplicación usando el modo rápido, voy a suponer que desconocemos la estructura del propio ‘wscript.exe’ y de las funciones de las librerías que carga. En primer lugar, ¿Qué hace el script y qué espero ver al analizar ‘wscript.exe’?
Ilustración 1: Script inicial cifrado
