Técnicas comunes de defensa del malware

A la hora de analizar malware nos encontramos con que hay amenazas que tienen técnicas de defensa que pueden complicar el análisis. Estas técnicas logran confundir a los analistas más nuevos y emuladores, consumiendo mucho tiempo y en muchos casos posponiendo o abandonando el análisis.

Un truco muy común para detectar un debugger es revisando el campo BeingDebugged en el PEB, o utilizando la API IsDebuggerPresent, o CheckRemoteDebuggerPresent si somos vagos para revisarlo a mano; la cual retorna verdadero si el programa está siendo ejecutado como proceso hijo de un debugger. También se puede utilizar la API NtQueryInformationProcess para revisar el PEB.

Otro truco muy explotado es revisar el campo NtGlobalFlags en el PEB. Si el valor es igual a FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS | FLG_HEAP_ENABLE_TAIL_CHECK, entonces estamos siendo debuggeados.

Creo que este método no está muy documentado. Consiste en reservar memoria en el heap utilizando HeapAlloc pero sin utilizar el flag HEAP_ZERO_MEMORY, y comprobar si los primeros 4 bytes son iguales a 0xbaadf00d. Si es igual, ya saben que está pasando.

Comprobar si hay breakpoints o checkear la integridad de las secciones del ejecutable es una buena técnica para detectar debuggers. A veces, código en el Thread Local Storage puede ejecutarse sin que nos demos cuenta en un debugger ya que se ejecuta antes que el entry point y, los debuggers, inician el análisis en el entry point por defecto.

Un método parecido al anterior es aplicado usando Structured Exception Handlers, ejecutando rutinas maliciosas como manejadores a ciertas excepciones. Estas excepciones suelen ejecutarse cuando el proceso no está siendo debuggeado, pero para el caso que lo esté siendo la ejecución del programa continúa sin levantar la excepción.

Todos los métodos anteriores hablaban sobre la detección de debuggers, pero los programadores de malware ya no se preocupan tanto en ‘alguien’ debuggeando sino en análisis automatizados, como Sandboxie o Cukoo Sandbox.

Se pueden utilizar la instrucción RDTSC o la API GetTickCount para comprobar si se tarda más ciclos/tiempo en realizar una cierta rutina. Este método es muy útil para detectar la ejecución, por ejemplo, en máquinas virtuales.

Al principio, para detectar sandboxes online, los programadores de malware ponían en una lista negra determinada información del sistema operativo de la sandbox online ( entre otros, Anubis o Malwr) como por ejemplo: el Hardware ID, el User ID, nombre de usuario, nombre de host, serial del disco rígido, la ruta de ejecución, el nombre del ejecutable, etc. Las personas que mantenían estas sandboxes online se dieron cuenta y realizaron un sistema que cambia aleatoriamente esa información, entonces los programadores de malware tuvieron que actualizar el arsenal. Si, como el juego del gato y el ratón.

¿Que utilizan ahora?

He visto que utilizan métodos como revisar que programas fueron instalados. Por ejemplo, si no está instalado Microsoft Office o WinRAR el malware piensa que el host puede no ser legítimo, entonces no ejecuta las rutinas maliciosas y se hace pasar por software inofensivo.
Conociendo una rutina de defensa como la mencionada, se me ocurre que pueden utilizar una jugada similar como por ejemplo, revisar si el wallpaper es del wallpaper by default, si hay movimiento del mouse, si el disco rígido es mayor a 80GB, si se conectan dispositivos extraíbles, si estamos siendo ejecutados en carpetas donde el usuario común suele ejecutar programas, como el escritorio.

Para detectar sandboxes de escritorio como sandboxie, generalmente, se suele revisar que dlls fueron cargadas. Si fue cargada una dll relacionada a sandboxie, entonces estamos ejecutados dentro de una sandbox. Pero ¿qué pasa si cambian ese nombre por algo como hajfaf.dll? Bueno, este método de chequear si estamos en una sandbox revisando módulos cargados no es muy bueno, pero es el que más documentado está y el más utilizado por los scriptkiddies.

Un método más complejo y eficiente para detectar si estamos siendo ejecutados en alguna que otra sandbox es revisar si determinadas APIs fueron hookeadas, como por ejemplo NtCreateFile. Sandboxie suele realizar usermode hooks modificando el inicio de la API con un jmp a otra función. Corregir ese hook no significa bypassear la sandbox -por suerte- ya que sandboxie también realiza kernelmode hooks. Los usermode hooks de sandboxie sirven para extender la funcionalidad de sandboxie.

Por otro lado, es muy común encontrar delays o Time-Lock Puzzles en el código malicioso para que el antivirus tarde tiempo en analizar dicho código,  y así  termine el análisis antes de tiempo y diga que el malware en realidad es un archivo limpio.
Un ejemplo, puede ser calcular PI con mucha precisión, es decir, muchos decimales después de la coma y que ese cálculo tarde 10 minutos. Luego se puede utilizar PI para descifrar una rutina. También suelen hashear un hash de un hash ... de un hash md5 muchísimas veces y utilizar el resultado final como llave para descifrar una rutina. 
Autor: OnTheCore