Antes de empezar con el post, decir que si estás leyendo esto vía feeds RSS o por correo electrónico, el anterior post de esta saga: Reversing malware tales: Dropper Dropped ! por motivos largos de explicar, no salió por RSS o mail, así que os animo a que lo veáis ahora si os lo perdisteis.
Dicho lo cual, seguimos con la saga, esta vez hablaremos de tips útiles mientras estamos analizando malware.
Analizar malware no es como analizar un programa normal, lo que se tiene entre manos suele tener un fin bastante determinado: hacer el mal.
En el caso de los droppers, dentro de lo que cabe son 'inocuos' solo van a descargar un fichero y ejecutarlo, pero en la mayoría de casos el payload del 'bicho' suele contener instrucciones para ocultar procesos, capturar pulsaciones de teclado, modificar el registro / ficheros ...
Por lo tanto, hay que tener un escenario lo más controlado posible para analizar un fichero malicioso.
Los análisis estáticos suelen tener poco peligro, pero en el momento en el que vía debugger ejecutas el proceso, por muchos breakpoints que hayas puesto o pienses que tienes controlado 'al bicho', en realidad hay muchas posibilidades de que algo se te escape, al menos a primera vista.
Evidentemente el entorno para analizar malware ha de ser una máquina virtual y hacer uso intensivo de los 'snapshots' para volver a posiciones controladas tras una ejecución. Aun así, andar con snapshots para todo, es bastante tedioso por el tiempo que cuesta en realizarse la operación.
Una alternativa para evitar muchos de esos tediosos 'rollback' es usar el debugger dentro de un entorno 'sandboxed' para que la ejecución del proceso debuggeado quede auto-contenida dentro de el y los posibles daños sean minimizados.
Para ello vamos a usar 'Sandboxie', del que hablamos tiempo atrás.
Una vez instalado, lanzar una instancia de Olly vía Sandboxie es muy fácil
Seleccionamos el 'sandbox' que deseamos emplear para la ejecución
Le decimos a Sandboxie que queremos ejecutar Ollydbg
Como se puede observar, el caption de olly ha sido modificado y aparece entre símbolos de # lo que significa que se encuentra virtualizado por Sandboxie.
Y a partir de aquí, todos los programas que carguemos para debuggear se ejecutarán dentro del sandbox y no podrán dañar el sistema.
Otro punto interesante es que, en la ruta
C:\Sandbox\Administrador\DefaultBox\drive podemos ver los 'restos' que
haya podido dejar el malware que estemos analizando en las diferentes
unidades de disco, lo que puede resultar interesante para descubrir mas ficheros relacionados.
Usar Sandboxie + ollydbg no es la panacea, y evidentemente sigue siendo necesario hacer uso de snapshots, pero con este método nos podemos ahorrar un buen número de interminables momentos de espera mientras la máquina virtual vuelve a un snapshot anterior
5 comments :
Personalmente no me cuesta ningún trabajo restaurar mi máquina virtual de depuración y utilizarla una y otra vez. Cuando analizas malware serio tienes que tener en cuenta que la mayoría está diseñado para detectar depuradores, sandboxes y similares, así que cuanto menos capas añadas, mejor. Ya cuesta bastante trabajo "tunear" el entorno de máquinas virtuales para que el malware no lo detecte. Además hay que tener en cuenta que, por mucho que se niegue, un software no se ejecuta igual bajo condiciones de depuración+sandboxing que en un entorno real. El sandbox altera profundamente el comportamiento de una gran cantidad de malware.
En mi opinión, lo ideal es tener una máquina real sin virtualizar con un sistema de "freezing" que permita volver atrás, eludiendo la virtualización lo máximo posible.
Gracias! Un artículo cojonudo, le falta bastante profundidad y se ha quedado corto pero muy bueno, los de sandboxie te lo van a agradecer, es un producto muy bueno y alternativo a maquinas virtuales
Al final esto es como la ropa, probablemente un abrigo común te sirve para el 90% de los inviernos que vayas a ver, pero en excepcionales ocasiones donde, por ejemplo, viajas a los pirineos necesitas ropa especial con mas enjundia.
A lo que voy es que 9 de cada 10 cosas que se ven 'in the wild' si se dejan debuggear / sandboxear sin un protocolo tan extremo como el que tu dices, que, obviamente es el mas indicado pero mas tedioso / complejo de gestionar.
La idea era explicar el tip, de sandbox + debugger, tal vez habría estado bien lanzar 'algo' y ver como va alterando el sandbox.
Apuntado queda
"My conclusion about Sandboxie is that it is a useful tool. I would run a navigator or a pdf reader sandboxed, to help to protect myself from vulnerabilities, but I wouldn’t run a malware to analyze its behaviour in Sandboxie, unless Sandboxie was running in vmware, bochs or other virtual machine."
http://vallejo.cc/?p=48
Publicar un comentario