El siguiente post es una traducción y adaptación de la publicación ZeroAccess:code injection chronicles escrita por nuestro investigador y colega de ESET , Aleksandr Matrosov.
Para el fin de otoño del 2012, la familia de rootkit Win32/Sirefef y Win64/Sirefef (también conocida como ZeroAccess) fue actualizada. Comenzamos con el seguimiento de la primera muestra actualizada en el comienzo del mes de Mayo cuando un nuevo programa de suscripciones comenzó con la distribución de la nueva versión de ZeroAccess. La versión actualizada de Sirefef no utiliza drivers en modo kernel, como lo hacía anteriormente, y tampoco almacena archivos de forma oculta. El programa de suscripciones reemplaza sus propias elecciones por los resultados de motores de búsqueda populares a modo de monetización. A continuación se adjunta una captura del foro:
De acuerdo a los mensajes del foro, la región más interesante de ZeroAccess es Estados Unidos, Australia, Canadá y el Reino Unido. El precio por cada 1000 instalaciones es de U$S 500. Existe un rango de precios especiales para aquellas instalaciones activas sobre sistemas infectados, dependiendo de los privilegios en dicho sistema. Esto puede apreciarse en la siguiente captura:
En la siguiente imagen puede apreciarse el panel de administración para el nuevo programa de suscripciones, el cual es utilizado para distribuir la nueva versión de ZeroAccess:
En el panel de control existe una funcionalidad que permite verificar la detección por parte de distintos motores antivirus de cada actualización. Esto puede observarse en la siguiente captura:
Inyección de código
En las versiones anteriores, ZeroAccess utilizaba drivers de modo kernel para acceder a los archivos ocultos y para lograr la protección de componentes a través de distintas técnicas. En las últimas versiones, los desarrolladores de ZeroAccess se reusaron a utilizar lo mencionado anteriormente y encontraron técnicas para realizar inyección de código.
A continuación se detalla cómo es el funcionamiento de las técnicas para la inyección de código:
En primera instancia el shellcode (32 o 64 bits dependiendo de la plataforma) es extraída desde un archivo “CAB” que se encuentra almacenado en el dropper (software modificado para instalar el malware cuando se lo ejecuta):
Una carpeta de sistema oculta es creada sobre la ruta de directorios donde se almacena dependiendo de la técnica de inyección de código utilizada (anteriormente ZeroAccess utilizaba archivos ocultos como método para almacenar sus componentes):
- %USERPROFILE%Local SettingsApplication Data
- %WINDOWS%Installer
El shellcode es inyectado dentro de services.exe (administrador de servicios de Windows). El gráfico siguiente refleja el proceso:
La función que lleva a cabo la inyección de código dentro de services.exe puede observarse en la siguiente captura:
En la versión actualizada de ZeroAccess, dos técnicas de inyección de código son utilizadas:
- El primer método utiliza diferentes trucos con ZwOpenThread()/ZwOpenProcess(), modificación directa de memoria y ZwQueueApcThread(). Esto es utilizado por sistemas x86 (32 bits) o en el caso de que otro método retorne en un bad status (estado anormal).
- El segundo método es utilizado por sistemas x64 (64 bits) para brindar modificaciones al administrador de servicios de Windows luego de cambios aplicados al descriptor de seguridad en el archivo services.exe.
En el siguiente paso en lo que respecta la inyección de código en el archivo services.exe, un objeto es creado mediante la llamada ZwCreateSection() y el contenido del archivo es copiado dentro de la sección. A continuación, el dropper escribe el shellcode para reemplazar la función ScRegisterTCPEndpoint() original y borra el soporte ASLR de la cabecera PE (la razón de esta acción es la de estabilizar la ejecución del shellcode).
Las últimas modificaciones de ZeroAccess agregan algunos pasos adicionales con respecto a las acciones realizadas sobre services.exe: Manipulación sobre la sección de relocación (.reloc) y la creación de una llamada a services.exe mediante Thread Local Storage (TLS).
Finalmente se crea un nuevo archivo con el mismo nombre, services.exe, pero es modificado para encajar con el propósito del atacante. Otro nuevo archivo es creado a través de la llamada a la función ZwCreateFile() y completando los atributos extendidos de NTFS desde el buffer con código malicioso proveniente de una dll. El payload malicioso no es almacenado directamente en services.exe, pero es cargada a través del mal uso de opciones de NTFS. Además, la información básica es copiada desde el archivo original (fecha de creación, último acceso, última modificación y atributos de archivo). La shellcode inyectada busca el atributo extendido bajo el nombre de “731” utilizando la función ZwQueryEaFile() y ejecuta el payload. La siguiente capa del shellcode busca el comienzo del modulo dll malicioso, prepara el punto de entrada (entry point) y lo ejecuta. A continuación puede visualizarse un gráfico de la shellcode inyectada desde la segunda capa:
Los productos de ESET detectan las modificaciones en el proceso services.exe como Win64/Patched.B.Gen. En la siguiente captura puede visualizarse el archivo services.exe modificado de acuerdo al programa BinDiff:
En cuanto a ScRegisterTCPEndpoint(), ambas versiones pueden visualizarse en la siguiente imagen:
Estadísticas de detección:
Las estadísticas de detección por región de Win64/Sirefef (izquierda) y Win32/Sirefef (derecha), desde el comienzo del 2012 son las siguientes (de acuerdo a ESET LiveGrid):
Luego de que el desarrollador de ZeroAccess modificara las técnicas de infección y dejara de utilizar los componentes de modo kernel en la última versión, se realizó un seguimiento del crecimiento en las infecciones de sistemas x64:
Asimismo, las estadísticas para Win32/Sirefef y Win64/Sirefef son las siguientes:
ZeroAccess ha demostrado como los desarrolladores de rootkits buscan otros métodos para distribuirlos y encuentran técnicas interesantes para infectar procesos del sistema en modo usuario.
Traducido y adaptado por:
Fernando Catoira
Analista de Seguridad
