jueves, 8 de mayo de 2014

Un poco de malware y los binarios de Autoit

Hace un par de días pasaron por mis manos unos servidores frescos de la botnet Zeus, estos venían cifrados por Crypters. La utilización de Crypters es una práctica muy común para evitar las detecciones antivirus, pero que no solo dificultan este trabajo, sino también el de los reversers que tratan de identificar el tipo de malware que se encuentra detrás del ejecutable cifrado. Servicios como Intelligence de Virustotal ponen a nuestro alcance todo el poder de los patrones YARA, los cuales se forman con cadenas Ascii o ristras de opcodes en hexadecimal pertenecientes a segmentos del malware, permitiendo identificarles mediante unas sencillas reglas.

El caso es… ¿Cómo detectamos automáticamente un malware en particular cuando este se encuentra cifrado por un Crypter?

Sencillamente hay que ejecutar la muestra en una SandBox, para determinar mediante su comportamiento la posible identificación del mismo, siempre y cuando este contenga unos patrones comunes respecto al resto. Francamente no hay que ser muy inteligente para comprarse un Crypter priv8, ya os lo digo yo que un amigo mío me lo ha contado… y llevar una configuración del servidor de la botnet diferente a la que viene por defecto.

¿Qué podemos utilizar como patrón de comportamiento?

En especial esas configuraciones por defecto, que los delincuentes utilizan sin llevar a cabo ni un ápice de modificación, posiblemente debido sus dotes en esto de la seguridad informática… sino que le pregunten a Kristina Svechinskaya.

Volviendo a las muestras de Zeus, decidí echarle el vistazo a una de ellas, la cual llamó especialmente mi atención, ya que esta poseía un peso bastante superior a lo normal. Las muestras de Zeus dependiendo de su versión, rondan los 80-140 KB esta sin embargo ocupaba 980 KB. Podría tratarse del tamaño del icono o de cualquier otro de sus recursos, pero no era nada de eso, sino que se trataba de un ejecutable cifrado con un Crypter desarrollado con Autoit. Este lenguaje me parece muy interesante, ya que es gratuito y salvo que las GUI que permiten crear sus interfaces suelen ser bastante tediosas, el resto de peculiaridades a nivel de desarrollo ponen un gran número de opciones a nuestro alcance. El lenguaje es en esencia un BASIC, inclusive en Wikipedia lo describen como un “Visual Basic Killer” pues bien no solo es un Killer en este aspecto, sino que los desarrolladores de malware están empezando cada vez más a utilizarlo y a aprovecharse de todas sus funcionalidades… aunque no creo que destronen a mi querido Visual Basic 6, ¡Resistencia! Jajaja

Supongo que sé lo que estáis pensando… ¿Pero qué cojones nos estás contado?

Realmente las cosas que me han empujado a realizar esta entada son los binarios generados con este lenguaje de desarrollo tan peculiar, y es que por defecto no utiliza APIs externas, ya que este las porta todas junto a sus librerías. Mirando la “Import Table” con Lordpe nos encontramos con el siguiente panorama.


He querido marcar el API de IsDebuggerPresent, ya que esta aparte de estar presente por defecto, también es utilizada en todas las compilaciones, con lo que cualquier aplicación sea malware o no, tendrá un plus de seguridad extra contra la presencia de debuggers. Este hecho me hace recordar a las declaraciones de Brian Dye CEO de Symantec, hablando sobre los antivirus y la manera en la que están cambiando su estrategia para evitar que los delincuentes, tengan acceso a nuestra información. De la misma manera que hace Juniper Networks para engañar a los atacantes incluyendo información falsa asumiendo que los crackers entrarán en sus sistemas.

¿Qué pasará con Autoit si un solo binario contiene todas las librerías y todas sus APIs? ¿Qué pasará si contiene métodos Anti-Debugging por defecto?

Sencillamente la estructura de todos los binarios es tan similar, que tendrán que dejarse llevar en cierta medida por auténticas Heurísticas sobre la ejecución de la aplicación en el sistema, no como las que se encuentra en más de un antivirus, las cuales se rigen tan solo por la utilización de ciertas APIs y de forma complementaria basadas en firmas para no incrementar drásticamente el número de falsos positivos, como publiqué en esta entrada con las firmas condicionales.

Como bien me ha comentado mí compañero Dani Kachakil, en un reto se encontró con un binario en Autoit el cual era posible de decompilar con gran facilidad, con lo que se puede optar por realizar la búsqueda de firmas sobre shellcodes que se encuentren en el contenido de la propia decompilación de estos binarios, que puede ser una buena idea siempre y cuando sus strings no se encuentren ofuscadas.


He encontrado publicaciones de gente que destaca con este lenguaje en foros como en indetectables.net, es el caso del desarrollador M3 con post como el siguiente... la verdad es que no me gusta cuando sube gente a dar charlas de seguridad nombrando negativamente el nivel de estos foros, seguro que ninguno de ellos intentó demostrar su nivel para alcanzar una zona privada y ver el material del cual se dispone. La diferencia entre estos foros y los Underground, sencillamente es que en la mayoría de los casos, en este último se encuentran cinco delincuentes y lo tienen cerrado al público, hablo porque lo conozco.

La evasión a IsDebuggerPresent no deja de ser bastante sencilla, la siguiente imagen muestra detrás del CALL en la dirección 40D5B6, la función que utiliza para mover los resultados al registro EAX. En la dirección 40D5BC se realiza la comparación con TEST y finalmente un salto JNZ en la siguiente dirección 40D5BE decide con el valor contenido en EAX, saltar dependiendo de si no es igual o si no es cero. Llegando en último lugar a la alerta generada con un MenssageBox que avisa de la detección de un debugger para finalizar la ejecución.


La modificación de la instrucción contenida en la dirección de memoria 40D5BE, se realizará con un salto JE que revertiría la acción, ya que esta instrucción sirve para dar un salto si el valor contenido en EAX es igual o si es cero.


Jump is NOT taken…


Pues eso, seguimos con la ejecución de nuestro servidor de Zeus y como ni este ni el Crypter contienen medidas Anti-Sniffing, Anti-Debugging, Anti-Sandboxing… podemos permitirnos reversear el cifrado o abrir un WireShark y ver las peticiones que realiza a los ficheros de configuración, que descargan las inyecciones para las páginas bancarias.


Les invito esta noche a ver un debate sobre Hacking Ético en el cual participaré. A las 22:00 GMT+2 - 23:00 GMT+2.

https://plus.google.com/u/0/events/civmdrj5n2hbdkijiqgmn49v550

Saludos 4n4les! ;)

1 comentario:

  1. Muy buena, me gustaría tener mas contacto con tigo para que me aclararas dudas de algunos malwares :P

    ResponderEliminar