Ir al contenido principal

Programadores de Malware ¿Malas prácticas?

Cuando uno se enfrenta al análisis de un nuevo malware, son muchos los frentes que podemos abrir y los enfoques que podemos darle. Como es lógico, un primer paso será identificar que es un malware de aquello que no lo es, y en ocasiones esto es preciso hacerlo con la mayor rapidez posible.

Muchas veces no contamos con el tiempo necesario para hacer un análisis completo a priori, y lo único que necesitamos es tomar decisiones tempranas para iniciar todos los protocolos oportunos ante una nueva muestra "maléfica".

Parece lógico pensar, que un código que inicialmente está ofuscado, empaquetado, o que hace uso de determinadas APIs del sistema, ya tiene una cierta probabilidad de ser malware y por lo tanto empezar a tratarlo de manera especial.

Durante estos días he estado analizando un nuevo malware, posiblemente una variante de tantas que andan circulando en estos días por internet. En concreto, lo que tengo entre manos es un Ransomware, si compañeros, un especimen cuyo único objetivo es económico, para lo cual no se les ocurre nada mejor que cifrar parte de los archivos que se encuentran en tu disco duro (principalmente partes valiosas para el usuario) y por lo tanto, dejarlos inservibles, eso sí, si pagamos una módica cantidad de dinero (normalmente en torno a unos 500 USD$), ya podremos "en teoría" descifrar nuestros archivos para seguir utilizándolos con normalidad. Por supuesto, no recomiendo pagar ni un solo dolar/euro/bitcoin/etc.

Pues bien, el malware del que os hablo (identificado a día de hoy como Ransom:Win32/Tescrypt.D por Microsoft) llegó a una de mis trampas a través de un correo electrónico con un mensaje engañoso relacionado con una cuenta bancaria y un posible descubierto, y con un adjunto en formato ZIP cuyo nombre era algo como SCAN_INVOICE_nnnnn.ZIP

En el mensaje del e-mail se nos insta a abrir el archivo ZIP, ya que en su interior encontraremos más información sobre el tema. Una vez descomprimido me encontré con un archivo javascript cuyo codigo estaba completamente ofuscado, aquí podeis ver parte del mismo:


Después de des-ofuscarlo manualmente, el código obtenido resultó ser un downloader cuya función era descargar de forma totalmente transparente al usuario, el malware en formato binario (.EXE) para su posterior ejecución.


Dicho archivo binario se descargaba de una de las siguientes URLs: "whatdidyaysay . com / 97 . exe?1 y iamthewinnerhere . com / 97 . exe?1"

A partir de aquí analizar este troyano y localizar la parte encargada de cifrar con AES, intercambiar contraseñas RSA, o calcular hashes MD5, etc fue bastante trivial.

Pero lo que quiero comentar aquí, es una de las muchas malas prácticas que siguen en ocasiones los programadores de malware (que por supuesto, no son los únicos). Esta consiste en la reutilización de código, ya sea de otros malwares o directamente de código fuente extraido de la red, muchas veces de herramientas OpenSource, y otras directamente de los ejemplos de código que se incluyen en multitud de libros y fuentes de conocimiento de fabricantes como es el caso de la MSDN.

Pues sí, en esta ocasión, el ransomware Win32/Tescrypt.D hace uso de un código de ejemplo programado en 'C' y disponible en la red, cuya finalidad es tan solo mostrar a los que se inician en el mundo de la programación directa con APIs de windows y 'C' como hacer su primer programa con GUI. En concreto nos encontramos con parte de código en 'C' publicado en un foro, y si buscais por esta cadena dareis con él: "Log Window Test App - by Napalm". Para los más vagos, aquí tenéis el enlace en cuestión "http://www.rohitab.com/discuss/topic/36060-c-win32-gui-example-programs/"

Como decía más arriba, en otras ocasiones copian/pegan literalmente los ejemplos de código que podemos encontrar en la MSDN y el programador/es de este ransomware así lo ha/n hecho. En concreto, parte del código relacionado con criptografía ha sido copiado directamente de la MSDN, aquí podemos ver el código en ensamblador del malware que trata con APIs de criptografía:


y aquí podeis ver el código en lenguaje 'C' extraido de la propia web de Microsoft (MSDN):


Aquí podemos encontrar algunas de las constantes utilizadas en el programa original de la MSDN y su equivalente en hexadecimal, el cual se ve que utilizaron tal cual en el malware:

NTE_BAD_KEYSET = 80090016h
dwProvType = PROV_RSA_FULL = 1
dwFlags = 0x00 en la primera llamada a CryptAdquireContext, para abrir un contenedor de claves existente.
dwFlags = 0x08 = CRYPT_NEWKEYSET en la segunda llamada a CryptAdquireContext

En definitiva, esto viene a demostrar como muchos de los programas, malware en este caso, se construyen a base de copiar/pegar parte de código disponible en la red y esto puede ser ventajoso para el analista de malware y para todas aquellas herramientas que intentan detectar y neutralizar malware.

Comentarios

Entradas populares de este blog

Como usar el TL431 (muy facil)

En este artículo, no vamos a entrar en el funcionamiento interno de este IC, ni tampoco en sus características técnicas, puesto que para esos fines ya existe su hoja de datos correspondiente. Más bien, lo que pretendo aquí es dejar constancia de como podemos utilizar este IC desde un punto de vista práctico, útil y sobre todo de una manera sencilla, con el objetivo de que cualquiera pueda utilizarlo. Si has llegado hasta aquí, probablemente ya sabes que por internet hay mucha información sobre este IC, pero también bastante confusa o excesivamente técnica, sin mostrar tan siquiera un ejemplo de funcionamiento, o como calcular sus pasivos. Pues se acabó, a partir de hoy y después de leer este post, ya te quedará claro como utilizar el TL431 para obtener una tensión de referencia estable y precisa. Vamos al grano y que mejor que empezar aclarando que el TL431 NO ES EXACTAMENTE UN ZENER como se empeñan en decir en muchos sitios, es verdad que se le conoce como el Zener Progra

Expresión Regular para números en Notación Científica (1.5e-10)

No cabe duda que las expresiones regulares tienen un potencial de mucho valor a la hora de analizar textos, ya sea para marcado, búsqueda de patrones, o incluso la programación de un compilador, un analizador de frases, de expresiones matemáticas, etc.   En esta ocasión he tenido que echar mano de ellas para el análisis de textos matemáticos en los cuales aparecen números en Notación Científica (con exponentes del tipo 1.5E-10). Pues bien, una expresión regular que me está funcionando bastante bien es la siguiente:   [-+]?[0-9]*\.?[0-9]+([eE][-+]?[0-9]+)?    Esta expresión regular se puede descomponer en los siguientes bloques, para poder interpretarla con mayor facilidad:  El primer bloque [-+]? está indicando que el número podría estar precedido opcionalmente de un signo - o un signo + El segundo bloque [0-9]* indica que podría aparecer un número de 0 o más dígitos del 0 al 9  El tercer bloque indica que también de manera opcional podría aparecer un pun

Ingeniería Inversa de Firmware en un PIC 16Fxxx de Microchip

Como parece que no tengo mejores cosas que hacer, no se me ocurre otra forma mejor de pasar una tarde de Sábado que hacer un poco de Ingeniería Inversa a un microcontrolador PIC de la casa Microchip.   En esta ocasión se trata de un microcontrolador de la familia 16Fxxx (tipo 16F876, 16F84, etc.) cuyos opcodes tienen un tamaño de 14 bits. El mismo sistema será válido para otros microcontroladores de otras familias o incluso fabricantes, incluso aún cambiando la arquitectura del microcontrolador, la base esencial del análisis será similar en multitud de casos.   Siempre que se me plantea una situación similar, me gusta entender los entresijos de lo que tengo entre manos y, en la medida de lo posible intento empezar "a mano" o "a pelo" en el proceso de obtención de los Nemotécnicos ó, en definitiva las instrucciones en lenguaje ensamblador.   A continuación os muestro un pequeño pedacito de un firmware que he estado analizando, se trata del comienzo del m