Cuando puse el serial el programa siguió su camino, me apareció una ventanita que decía c:\windows\system32 ….

Me pareció muy raro y sospeché de un virus… obviamente seguí utilizando el programa, y NOD me avisó que “algo” se quería conectar… algo con nombre como qsyrjrwes.exe en la carpeta Datos de Programa de mi usuario en Windows XP.

Obviamente, escribí en arroba sobre ese EXE, para ver de que se trataba, era un simple downloader, definido como downloader.Win32… Ya postearé el artículo explicando de qué se trata…

Bueno obviamente, el EXE de flashfxp estaba “envuelto” por un dropper, éste sacaba el downloader, y después hacía ejecutar al flashfxp normalmente…

Empezando a mirar el EXE, encontramos algunas strings que se cargan, y mirándolas por arriba, pienso que son strings encriptadas que desencripta en tiempo de ejecución…

Seguramente para evitar que los AV’s detecten el proceso…

Cuando debuggeemos por las strings “.dll” y “.exe”, más precisamente en las direcciones 408D03 y 408D15 veremos estas cosas en la pila:

0012FFAC   01141C30  0
 ASCII “C:\WINDOWS\system32\niksr.dll”

y luego,

0012FFA8   01141CA4  ¤
 ASCII “C:\DOCUME~1\SPARKR~1\CONFIG~1\Temp\setup.exe”

Luego de eso, en estas direcciones podremos ver que el ejecutable creado en la carpeta temporal de nuestro windows, posee un icono de flashfxp… es raro..

00408D39  |. A1 C8A94000    MOV EAX,DWORD PTR DS:[40A9C8]

00408D3E  |. E8 BDFDFFFF    CALL setup-pr.00408B00

En estas dos líneas se ejecuta el EXE liberado en la carpeta temporal de Windows. Igualmente no es el EXE final.

Veremos que entrando al CALL mencionado dos líneas más arriba, y mirando un poco más, se crea un objeto Mutex.

Veamos para que sirve un mutex (una definición de la red…):

“Un mutex funciona exactamente del mismo modo que las secciones críticas. La única diferencia en las implementaciones Win32 es que la sección crítica esta limitada para ser usada con solamente un proceso. Si tienes un programa que usa varios hilos, entonces la sección crítica es liviana y adecuada para tus necesidades. Sin embargo, cuando escribes una DLL, es muy posible que diferentes procesos usen la DLL en el mismo momento. En este caso, debes usar mutexes, en lugar de secciones críticas.”

Veremos en la imagen, que genera un código único, que se utiliza como nombre del mutex, para crearlo, con la API CreateMutexA.

Seguido de esto, parece que nuestro troyano necesita descomprimir una dll denominada bcdsa.dll, veamos:

EAX apunta al string C:\WINDOWS\system32\bcdsa.dll.

El ejecutable busca el archivo bcdsa.dll y si no existe, lo crea.

Luego de crear la DLL, descomprime el segundo EXE como hemos visto que el path estaba en memoria y crea el Thread finalmente con la DLL deseada. Capturemos la DLL, para futuro análisis.

Si vamos a buscar la DLL y vemos propiedades encontraremos una descripción extraña:

O es una librería que necesitará el flashfxp final o es algo más…

Luego de que el Thread es creado, nos aparecerá la ventanita con el mensaje: “c:\windows\system32″, esto es lo que me hizo sospechar de la actividad de este ejecutable. Es una falla de programación importante, ya que se da a conocer muy sencillamente, parece que el programador tenía pocos recursos para poder darse cuenta cuando la DLL estaba cargada en memoria…

Ahora veremos el segundo ejecutable.

Una vez que nuestro amigo está descomprimido veremos que al cargarlo está hecho en C, por eso mismo carga nuestra DLL, que se trata nada más ni nada menos de las MFC, librerías runtime necesarias.

Este EXE, descomprimirá el FlashFXP final, pero además agregará la descompresión de un downloader… para fines non santos…

El ejecutable de FlashFXP será descomprimido en c:\windows\ bajo el nombre de setup.exe

En esta imagen, podemos ver como ejecuta a FlashFXP original y a su vez, descomprime y crea el downloader, cuyo nombre es aleatorio.

Finalmente, tratará de ejecutar el Downloader, como veremos acá:

Por último el proceso termina, llamando a ExitProcess.

Entonces si queremos nuestro EXE final de FlashFXP, directamente lo buscamos en la carpeta Windows de nuestro sistema.

Nos damos cuenta que el EXE es el original, porque al hacer botón derecho y propiedades, veremos los datos originales de la aplicación. Lo cuál ante un usuario atento, se dará cuenta que los otros ejecutables no son los originales.

Es importantísimo poder tener firmado los ejecutables de nuestras aplicaciones, además de poder tener la información guardada como propiedades del ejecutable, de manera que un usuario puede verificar la autenticidad de varias maneras.

Siempre hay que estar atento a actividades extrañas, como por ejemplo la ventana que sale a modo de información avisando que la DLL ya fue creada, para poder continuar la descompresión…. como lo vimos anteriormente.

Eso es todo, espero que les haya servido y gustado.

Nos vemos la próxima.

convert this post to pdf.