Archivo .sys utilizado en el ataque Aurora - Análisis externo del archivo

En primer lugar, me gustaría dar las gracias a MalwareIntelligence donde escribo como investigador por facilitarme este archivo.

En el ataque Aurora, se había utilizado un archivo .sys, denominado msconfig32.sys.

Yo estaba muy curioso sobre lo que hace este controlador, y por qué nadie en el mundo lo había analizado.

Había tenido un terrible viaje para obtener el archivo. Nadie lo tenía. Nadie quería compartirlo. Tuve mucha suerte ya que en MalwareIntelligence teníamos los contactos adecuados para obtener este archivo.

Como le he dicho a un gran número de personas, hay muchas razones para utilizar controladores en este tipo de ataque, pero está bastante claro que los atacantes no iban a ocultarse de sus conexiones. Lo único que podría tener es pensar en escribir un controlador para obtener información sobre el estado físico de la versión de pantalla (Debido a que los atacantes utilizan parches de VNC, un controlador puede consultar el estado de la pantalla, y si se cerró / stand by es seguro para trabajar, también, este tipo de controlador podría haber salvado a los puntos de restauración del equipo antes de que el atacante comience a buscar archivos dentro del ordenador, y una vez que la pantalla es de seguridad, restaurar todo a su estado original - más de esta idea está en mi presentación en ihackbanme.com.

Pero parece que este no es el caso. Eso es lo que estaba buscando. Que lo que he estado tratando de buscar, pero había estado allí todo el tiempo. El archivo .sys, no era un controlador.

Primero echemos un vistazo rápido a los archivos (el archivo .sys es un PE):

¿Y bien? ¿Qué es eso? ¿Por qué hay 0x20 en todo el archivo? se supone que debe ser 0x00 en esas zonas .. Obviamente es un XOR. Se tiene una base como un EP, pero seguro que tiene un aspecto diferente, XOR o algún tipo de lucha contra la posibilidad de realizar ingeniería inversa sobre él. Esa es la primera mirada.

Echemos un vistazo a + - el mismo tamaño de otros, válida, controlador de Microsoft:

¿Puedes notar la diferencia? ¿Dónde por lo general está 0x00 hay 0x20. Extraño. Veamos más en el archivo msconfig32.sys:

Espera! ?!@@#$ ¿Por qué existen archivos .dll mencionado después de la marca de los recursos? No te has visto que en un controlador antes de ... Vamos, tome de nuevo un vistazo a un controlador válida de nuevo:

Nosotros no vemos ese tipo de cosas, sin embargo, seguimos viendo 0x20 en lugar de partes donde debe haber 0x00...

Extraño. Tal vez es un .exe en su lugar? No hay que rendirse! Vamos a tratar de cargar y ver si el controlador puede ser cargado como está. He optado por utilizar SCM (Service Control Manager), construido en el mecanismo para cargar los controladores, en vez de escribir un gestor de mí mismo. El conductor puede ser cargado de muchas maneras, incluyendo el reemplazo de otros sistemas de archivo, el registro rápido en el Registro de Windows o de otras maneras (se puede encontrar algo más de información en el libro Rootkit - Subverting The Windows Kernel - Página 40 : The quick and dirty way to load a driver, o páginas 46,47. Enjoy).

He decidido utilizar SCM, y cargar el controlador de la SC. Así que vamos a hacerlo:

En primer lugar he hecho una nueva verificación para ver que no ha cambiado el archivo, el archivo que necesitaba era msconfig32.sys involucrado en el ataque Aurora con el siguiente md5: 7a62295f70642fedf0d5a5637feb7986), después de que lo he hecho, he escrito un comando sc para cargar el controlador desde: C:\msconfig32.sys.

El comando y los controles se adjuntan en el cuadro siguiente:

El controlador especificado no es válido?! ¿Qué tal? El archivo no es ciertamente un controlador .sys válida (como es, puede ser cambiado un poco para aparentar ser un archivo .sys). Entonces, ¿qué es?

Tratar el método ordinario de abrir el archivo en PEExplorer/IDA/Olly/Analizadores PE no funcionaría, ya que el archivo está bastante deteriorado, de una manera la cabecera se encuentra totalmente dañada y la manera en que el archivo se comporta algo está ahí, pero no es un sistema de archivos habitual.

Así que ... Vamos a tratar de meterse con un poco, tal vez operación XOR de nuevo con 0x20, dio nada. Otras ideas que he intentado (tratado tantos que ni siquiera puedo escribir a todos ellos), no van bien. El archivo parece estar corrupto.

Intentar cargar como una DLL, o la apertura bajo .exe falla.

Traté de jugar con un poco más, y encontré que un CERT publicó un aviso en el que han escrito las siguientes cosas:

ad_1_.jpg

MD5: CD36A3071A315C3BE6AC3366D80BB59C Byte Size: 34816

Appears to be packed executable. Significant portion of file is XOR'd 0x95

Hay otro archivo, con .jpg, y no es un jpg. El archivo se XOR'd con 0x95. ¿Te suena? Sí lo hace. Creo que es el mismo tipo de método utilizado, pero esta vez, ellos han llamado a su archivo .sys en su lugar.

O, el archivo se está descargando, paso tras paso, y hasta que termine la descarga que crear primero un archivo, lleno de 0x20s y sobrescribe con el archivo real. Que podría haber explicado el tamaño de la misma (4kb).

Así que he comprobado, es el archivo comprimido? ¿Cómo puedo comprobar, sin saber qué tipo de compresión se utiliza? Lo más fácil es tomar la carga del archivo PE, y la escribiré en otro archivo. Después lo he hecho, he intentado comprimir de nuevo, y adivinen qué? El archivo, después de la compresión, es más grande que el original. Es decir, parte de la carga útil fue comprimida.

Todavía no podía entender lo que contenía. Voy a seguir con la investigación y esperamos que encuentre algo :). Lástima que no era un controlador real, aunque ...

Espero que te haya gustado mi análisis externo, porque no podía examinar el archivo (como lo fue "corrompido", o al menos-no en un formato válido). a veces es todo lo que se puede hacer. Aunque, ahora sabemos que este archivo no fue un impulso real (pero aún así, podría haber contenido una dentro - comprimido).

¿alguna idea?

Itzhak Avraham
Malware Researcher in MalwareIntelligence