Una visión que poco se ve (que raro no? ) es la de anti-google… bien, eso quiero difundir hoy acá con este post.

Ofrecerles  este libro más que interesante del escritor Gerald Reischl.

He aquí una reseña de su introducción:

“El objetivo de El engaño Google es otro: contribuir a la concienciación y poner en evidencia el dilema en el que viven los usuarios de Internet, las negligencias en las que ha incurrido Europa y dónde debemos fijarnos si queremos sacar provecho de Internet. Partiendo de hechos concretos se demuestra que Google es, desde hace años, el más eficiente registrador de datos del mundo; que existe un gran número de patentes y métodos que permiten rastrear, analizar y clasificar a los inter nautas; que las promesas de no utilizar los datos y borrarlos pasados 18 meses se han quedado en meras palabras y que la clave del éxito está en la información de los usuarios. En este libro también se habla de los planes de Google para el futuro: por qué quiere dar el salto al negocio de los móviles y las telecomunicaciones y por qué quiere dominar el mercado de la publicidad, tanto en Internet como en prensa y televisión. Por otro lado, los proyectos relacionados con la medicina, la genética y el análisis del ADN en los que Google está inmersa también deberían levantar nuestras suspicacias. Hace tiempo que Google ha dejado de ser solamente un buscador y se ha convertido en una de las empresas más ricas del planeta. Sus propietarios poseen una de las mayores fortunas del mundo gracias a un ingenioso diseño de comunicación y a la enorme masa de entusiastas que utilizan Internet. Y en detrimento de la privacidad.”

Que lo disfruten tanto como yo.

Saludos!

convert this post to pdf.

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.

Lo bajo de la web de thinkcore: http://www.thinkcore.com/utilities/networking/NetSS-v1.0.zip

Lo abro… y nada :O no había código, un EXE y un readme.txt…. ¿es justo?

Este programita, es muy simple, envía mensajes anónimos por net send, el famoso mensajero de windows XP… el truco, es muy fácil y simple, por eso no me gustó que no pusieran el código fuente, de algo tan simple, para mostrar a la gente como se puede hacer…

Me dije, ¿ es necesario debuggear y analizar lo que hace ? me dije, si… y aquí estamos

Abrí el ejecutable y me encontré con esto en Olly:

Como veremos para ojos entrenados, esta empacado… es simple de ver… no es un entrypoint “normal”. Si corremos el Peid no nos dará nada, y el rdg tampoco dará nada, así que no importa, lo cargamos en el Olly como vemos y debuggeamos un poco….

Dará vueltas, miles, armando todo nuestro ejecutable final… al final, damos F9 y lo ejecutamos del todo… lo veremos abierto….

Pondremos un breakpoint de acceso en la sección de código de nuestro proceso netss.exe de esta forma:

Ahora hacemos un click en la aplicación y Olly saltará, permitiéndonos volver al proceso principal, y mirar nuestro desempacado en memoria 100% libre de ataduras.

Veremos el código así:

Veremos que necesitamos sacar el análisis ya que Olly no lo interpretó bien….

Ahora si nuestro “EP” tiene más color ¿no amigos?, ahora haremos el volcado con el ollydump, si lo ejecutamos se romperá… ¿ qué está mal?

Si hacemos scroll veremos algo más que puede ser un entrypoint más posible que ese…

Nuestro dump se rompe porque hace un cmp con un valor específico… calculo que lo hace para ver que botón se ha presionado en el formulario, típico de aplicaciones en win32asm, como dicen los autores que lo hicieron.

He aquí más arriba algo más normal del principio de un programa en win32asm, todo definido, el querido GetModuleHandleA, hasta ExitProccess, está todo listo.

¿Cuál es la definición final? Deberemos modificar el Entrypoint, ya que si cargamos el dump con Olly, empezará en la dirección 40102B y no en 401000 que es donde debería empezar…

Para eso abrimos un editor PE cualquiera, probé uno nuevo llamado PEiT (Pe Insight, desde rusia).

Modificamos el valor del Entrypoint y quedará así finalmente:

Finalmente el EP quedará apuntando a 401000, grabamos los cambios, lo probamos y voilá! lo hemos hecho.

Bien, pero el tema era ver como enviamos esos mensajes anónimos, y si miramos un poco el código fuente, nos daremos cuenta que una de las API’s usadas son para enviar con a través del servicio mensajero.

NetMessageBufferSend

Ahora veamos como carga los parámetros cuales son cada uno, y listo, ya sabemos el secreto…

Está todo dicho amigos, la magia, el misterio se terminó… ya sabemos que parámetros y que API del sistema deberemos llamar….

La información debe conocerse, coincido que NO toda a veces, pero este tipo de información ocultarla no tiene sentido amigos… tarde o temprano… se sabe.

Google nos da pocos resultados sobre esta API, encima eso… it’s is a must dar a conocerlo a la gente…

Gracias a todos por leerme, saludos a z0mbie, GriYo, kaze, la gente de indetectables, al hispano #crackers, #Disidents, #hackers, #virus, la gente de crackslatinos, y muchos más, aún seguimos vivos.

Saludos,

SparK.-

convert this post to pdf.