Posts Tagged ‘troyano’

MSDN Help Plugin for OllyDbg / Immunity Debugger

Hello everone. Today I’m showing you a new plugin for OllyDbg / Immunuty Debugger that I hope will help you when reversing Windows binaries.

What is OllyDbg?

OllyDbg is a classic user-mode debugger for the Windows operating system. According to many, it’s the idea tool for reverse engineering software when you’re not likely to get a hold of the source code (malware, for example), and it’s also widely used in the cracking scene.

One of its most appealing features is the possibility of loading plugins. While most of them are geared towards binary unpacking and avoiding detection from malicious code, there are plugins readily available for a multitude of tasks.

What is Immunity Debugger?

After many years went by, no updates were available. That meant no fixes for the multiple public exploits available on the Internet. That’s until Immunity decided to buy the source codes to OllyDbg in order to fix and improve it, under the new name Immunity Debugger. Today it seems to be mostly replacing the good old Olly, especially when it comes to exploit development which is where the focus is set for most of the new features and plugins.

So what’s the catch? Well, it turns out most of old Olly’s plugins don’t work anymore. However, if you have their sources you can update them, even make them work in both debuggers. If you don’t things get a bit hairy, although there’s a tool out there that helps quite a lot.
Today’s plugin works correctly under both debuggers, of course. :)

What’s this plugin for?

OllyDbg has been around for some time now, and it’s beginning to show its age. ;) One of it’s low points right now is it’s (rather lack of) Win32 API help support.

I’ll explain. When you’re reversing a binary on Windows you’ll tipically see a bunch of assembly code with Win32 API calls in between. The Win32 API is the low level interface for user-mode applications, so deep down inside, it all boils down to these function calls. There are simply too many of them and it’s impossible to memorize them all, so it’s necessary to consult the Microsoft documentation to know what they do, what arguments they expect, etc.

Now, OllyDbg had always allowed you to consult the documentation thanks to a nifty file called “WIN32.HLP” that was shipped with the SDK for Windows NT, and it contained the most up to date and detailed version… back then. But many OS versions and years went by, Microsoft stopped shipping that file since the new MSDN (Microsoft Developer Network) was all the rage, and what happens now when you try to use the OllyDbg help is that half the times the API you’re looking for doesn’t show up in the help file. :(

This plugin is meant to fill that void. After installing it, when OllyDbg tries to open WIN32.HLP to show the help, the plugin steps in and launches the default web browser instead, pointing it to the corresponding page in MSDN Online. :)

How to install this plugin?

It’s easy, just download the zip file, extract the plugin (OllyMSDN.dll) and copy it to the debugger’s program files folder. For OllyDbg this is tipically “C:Program FilesOllyDbg” and for Immunity Debugger it’s “C:Program FilesImmunity IncImmunity Debugger”.

The next step is to run the debugger, go to the menu “Help” and click on “Select API help file”. Then we have to select the old WIN32.HLP file, or at least any other file as long as it has the exact same name (it’s not going to be used anyway). The name matters because it’s the way the plugin can tell Olly is trying to load the Win32 API help and not just any other help file like, say, the user manual.

Once you’ve done this, the plugin is ready to use.

How to use this plugin?

It’s used just like the good old WIN32.HLP file. That is:

To show the Microsoft documentation, go to the “Help” menu and click on “Open API help file”.

To see the help for an API call in particular, right click on the assembly code line with the function call in the CPU pane and go to “Help on symbolic name”.

Where do I get this plugin?

You can purchase it online with your credit card… nah, no way! It’s 100% free of course! :)

Follow this link to download:

The zip file contains the precompiled Windows binary and the complete source code under GPL v2 license. The sources compile with Visual Studio 2008, I haven’t tried other compilers.

Well, that’s it for today. Enjoy! :)

Follow me on Twitter: @Mario_Vilas | Linkedin:

Análisis binarios con Mandiant Redline

Bueno, todos sabemos que hay en el mercado varias aplicaciones de nuestros queridos “Mandiant”, no lo digo con sarcasmos porque hay varias aplicaciones que me gustan.

Y bien, sacaron a la luz una aplicación llamada Redline, lo que hace es analizar la memoria, como si fuera “Volatility” pero con GUI.

El trabajo de Redline consiste en analizar la memoria y valorándola mostrar qué proceso tiene más posibilidad de ser malware y cuál menos, contando puntos MRI (Malware Risk Index), pues nada vamos a ver qué tal funciona.

La prueba fue realizada en una maquina infectada con Banker, según Kaspersky –

La maquina es de 2 cores y con 1GB de RAM. En más adelante podéis haceros una idea sobre las necesidades de la aplicación.

Bueno, descargamos y vemos que es un .msi, empezamos bien, por todos los santos, nos pide .NET 4.0, bueno que remedio, descargamos, instalamos.

Se instala en un periquete, algo bueno.

Al instalar nos muestra varias opciones de análisis, muy interesante tiene la opción de análisis sobre un “Saved memory File”, que parece a Volatility, elegí el análisis de la maquina local “Analyzing this Computer“. Pinchando ahí vemos que nos permite analizar muchas cositas interesantes como por ejemplo: Hooks, Drivers con sus Exports e Imports, Procesos con sus actividades, etc.

No vamos a jugar con tonterías y pinchamos en “Full Audit” y OK.

Es muy curioso, pero con las características de mi maquina, Redline acabo el análisis en unos 25-30 minutos, curioso la memoria casi no la toca, pero del procesador tira pero que muy bien. Vamos que con un 8008 vais listos =)

Bueno ya tenemos el análisis acabo, vamos a echar un vistazo. Tenemos una lista de procesos, algunos se marcan en rojo, pasos a seguir para el análisis, interesante, seguiremos los pasos.

Un review de los procesos con su valoración, pinchando en cada uno de ellos nos mostrara info más detallada del veredicto.

Vamos a ver porqué están marcados en rojo, pinchamos en uno y nos muestra los factores positivos y negativos por los que valora los procesos. Cuanto más factores negativos mas posibilidad a que lo marque en rojo como sospechoso, bueno buscamos un malware, nos interesan negativos. No puede ser ¡! nos marca un proceso svchost en rojo, porque, por solo 2 factores (indexación de ficheros index.dat).

Y los demás 3 svchost ni si quiera tienen factores negativos, 100% positivo, sin embargo los marca en rojo.

Según mi análisis, mi Banker abrió un iexplorer bajo svchost pero el svchost ni si quiera ha sido detectado, incluso mi iexplorer tenía una conexión establecida con una IP americana con el puerto 80 y por otro lado escuchaba en el puerto 1308 por UDP, pero solo marcó mi iexplorer en 50% sospechoso. El proceso oswin32.exe es nuestro Banker, y también lo marca en gris, jejejeje.

El siguiente paso del análisis que nos indica Redline es verificar las conexiones, vamos a ver, jejejeje mirad, mi iexplorer con sus conexiones pero esta en 50% de amenaza. También con doble clic sobre la conexión os llevara al proceso.

Podemos elegir alguno de los filtros de las conexiones: puertos en escucha, conexiones establecidas o todos.

Bueno, seguimos, el siguiente paso es un Review de las secciones de memoria y DLLs, un punto bastante interesante, hay varios filtros para ver qué es lo que nos interesa, por ejemplo: Mostrar secciones nombradas que se utilizan por menos de 4 procesos, o las mismas secciones pero las que se marcaron en rojo como desconfiados, otro filtros también bastante interesante es el que muestra las secciones de memoria inyectadas.

También una comodidad de Windows, haciendo doble click nos lleva al proceso, si pulsamos sobre las inyecciones que aparecen me lleva al proceso del propio Mandiant Redline :) Es decir, no confía ni si quiera en las inyecciones suyas, jajajajaja

Otro paso que nos dice a seguir Redline es revisar los handles desconfiados.

Aquí también hay filtros de “solo desconfiados” o todos.

Bueno, el siguiente paso son los Hooks, tenemos varios filtros de diferentes tipos de hooks, parece que confía en todos :)

Nada interesante, seguimos.

Y por fin nuestro último paso de nuestro análisis es “Drivers and Devices”, aquí no tenemos ningún filtro, es decir, todo a mano, es una información bastante interesante que nos proporciona. Pinchando en cada uno de ellos nos muestra la info completa sobre él, hasta las funciones que tiene, que importa y que exporta, strings, certificados, etc.

Bueno, hemos seguido los pasos, y parece que no nos ayudaron en nada, claro que si hubiéramos analizado alguno de los pasos anteriores más a fondo seguramente hubiéramos encontrado algo interesante.

Más cositas interesantes, podemos ver secciones de memoria, strings, puertos utilizados o handles de todo tipo por cada proceso, esto ya me gusta más.

Muy interesante en la parte de Detailed Sections tenemos todas las secciones del proceso, a la derecha podremos hacer búsquedas en cada uno de ellos y ver qué es lo que exporta, importa, etc.

Otra cosita muy interesante, los strings de cada proceso, podemos buscar patrones por ahí, por ejemplo yo encontré una keyword de Banco Popular :)

Otra cosa que vi, la pestaña Host, proporciona la información completa sobre los procesos, punto muy interesante son procesos en jerarquía, conexiones establecidas, drivers, hooks, información detallada del equipo y el SO, vamos lo mismo pero en genérico.

Algunos de los puntos más positivos que encontré son: la aplicacion nos permite crear un Agente portable directamente desde el menú de la aplicación, muy útil para un análisis externo y sin necesidad de instalarlo, permite guardar el análisis y seguir con el mismo en otro momento.

Bueno, resumiendo, la aplicación no está nada mal, pero es como utilizar Volatility con GUI o SysInternals TODO EN 1.

La interfaz gráfica es muy amigable y fácil de manejar. Para un análisis yo no lo aconsejaría para una persona que se basara solo en los veredictos de la aplicación ya que Redline da unos Falsos positivos brutales. Un claro ejemplo con los svchost, aparte marca su proceso también como sospechoso en un 24% :)

Podría mejorar el análisis, si mi Banker hubiera cerrado la conexión antes de que lanzara analizar, las conexiones no hubieran aparecido y mi iexplorer no lo hubiera marcado como 50% de sospechoso, pero bueno por otra parte no olvidemos que es un análisis sobre la memoria.

La veo útil en algunas ocasiones y cómoda para utilizar. Sin embargo la interfaz algunas veces en mi equipo tarda en reaccionar, parece que le faltan cores :)

Estoy seguro que la próxima versión será mucho más currada y arreglaran los cálculos de los factores positivo, negativos y de los veredictos.

A disfrutar.

Ataque dirigido Stuxnet

1. Botnet Stuxnet

Existen muchos tipos de ataque automatizado, por ejemplo: ataques masivos donde muchos sistemas son infectados, ataques aleatorios donde no importa que servidor se infecta, la cuestión es conseguir controlar muchos zoombies, también cabe destacar los ataques dirigidos, en los que hay un objetivo concreto, por ejemplo centrales nucleares, y se diseña un malware que infectará máquinas hasta hayarse en un sistema crítico y ejecutar la acción malévola.

La Botnet Stuxnet es un ataque masivo automático y dirigido, altamente peligroso ya que su rutina de propagación explota diversos 0days (vulnerabilidades no públicas) combinado con otras vulnerabilidades públicas altamente efectivas, y el objetivo de este ataque dirigido es espionaje industrial y sabotaje, contra un tipo de infraestructuras concretas de un país concreto, Irán.

1.1. Ataque dirigido a un país

Este gusano, se propagó por todo internet de forma no uniforme, infectando millones de computadoras. En la distribución de número de infecciones por país, se puede apreciar que el ataque iba dirigido a un país en concreto, Irán el cual recibió un 50% de las infecciones aproximadamente.

Según la wikipedia, hay datos no oficiales de que actualmente el malware se está orientando contra la China, en concreto seis millones de infecciones.

1.2. Ataque dirigido a un tipo de infraestructuras

Este software se ha ido propagando por la red de área global Internet y también por redes internas de empresas y organizaciónes hasta caer en sistemas SCADA. Las vulnerabilidades con las que va equipado este malware, hacen que pueda tener gran proliferación por redes locales, hasta llegar a los sistemas que se desea espiar y controlar.

Los sistemas SCADA son utilizados para controlar dispositivos e infraestructuras críticas, como estaciones espaciales, centrales nucleares, etc. Este malware, no sólo es capaz de espiar actividad realizada en estos sistemas, sino que también tiene la intencionalidad de causar daños para sabotear los dispositivos, infraestructuras, etc.

1.3. Conclusiones

Stuxnet, claramente se trata de un cyberataque contra Irán y China, originado probablemente por otros países rivales con intención de obtención de información industrial y sabotaje. Se cree que este malware puede estar diseñado para averiguar qué países cuentan con armamento nuclear, aunque no se puede validar 100% esta información.

En todo caso, por la complejidad en sus algoritmos de ocultación, propagación y su intencionalidad, parece haber sido desarrollado por algún tipo de organización y no un grupo de hackers.

Stuxnet demuestra que a día de hoy, la ciberguerra es posible y que conviene estar preparados.