Entre las amenazas más persistentes detectadas por las soluciones de seguridad de ESET se encuentra el malware Win32/Sirefef. Son ya varios los meses en los que esta amenaza se ha colado entre el Top 10 de las más detectadas y uno de los motivos es la actualización constante a la que los creadores de esta amenaza la someten. Para analizar las últimas modificaciones de este malware hemos procedido a adaptar el siguiente análisis de nuestro compañero Aleksandr Matrosov.
A finales de la primavera de 2012, la familia de rootkits Win32/Sirefef y Win64/Sirefef (también conocidos como ZeroAccess) se actualizaron. Empezamos a observar las primeras muestras actualizadas a principios de mayo, cuando empezó un nuevo programa de afiliación para distribuir una nueva versión de ZeroAccess. La versión actualizada de Sirefef no utiliza drivers en modo de kernel, tal y como hacía previamente, y tampoco tiene un almacén de ficheros ocultos. El programa de afiliación sustituye los resultados de los motores de búsqueda por los suyos propios para así obtener beneficios.
Según se comenta en el mensaje del foro verified.ms que vemos arriba, las regiones más interesantes para instalar esta nueva variante de ZeroAccess son los Estados Unidos, Australia, Canadá y el Reino Unido. El precio por instalar esta amenaza en 1.000 máquinas de los Estados Unidos es de 500$. También hay un precio especial por instalaciones activas en una máquina infectada, dependiendo de los privilegios del sistema.
El panel de administración para el nuevo programa de afiliación usado para distribuir la nueva versión de ZeroAccess luce tal que así:
En el centro de mando y control (C&C) hay un apartado especial que revisa la detección por parte de los antivirus tras una actualización del malware.
Técnicas para inyectar código
En su versión anterior, ZeroAccess usaba un driver en modo kernel para acceder a un almacén de ficheros ocultos y para proteger componentes usando técnicas de autodefensa. En la versión más reciente, los desarrolladores de ZeroAccess han rechazado el uso de componentes en modo kernel y han encontrado técnicas interesantes para la inyección de código.
A continuación explicamos cómo funciona la técnica de inyección de código:
- En el primer paso se extrae la shellcode (x86 o x64 dependiendo de la plataforma) de un archivo cab almacenado en el lanzador del malware (dropper).
2. Se crea una carpeta oculta del sistema, donde el nombre que se le asigne depende de la técnica usada por el inyector de código (anteriormente ZeroAccess usó el almacenamiento de ficheros ocultos como un método de almacenar sus componentes):
- «%USERPROFILE%\Local Settings\Application Data\
- «%WINDOWS%\Installer\
3. En el siguiente paso, el shellcode se inyecta en services.exe (gestor de control de servicios):
- El gráfico de la llamada al shellcode inyectado es así:
- La función para inyectar código en services.exe tiene esta apariencia en pseudocódigo:
4. En esta versión de ZeroAccess se usan dos técnicas de inyección de código:
- El primer método usa una técnica con ZwOpenThread()/ZwOpenProcess(), con una modificación directa de la memoria y ZwQueueApcThread(), usada para sistemas x86 o si otro método devuelve un mal estado.
- El segundo método se usa en sistemas x64 para proporcionar modificaciones en el archivo de gestión del control de servicios al descriptor de seguridad en el archivo services.exe.
En el siguiente paso de la inyección de código en el fichero services.exe, se crea un objeto de sección llamando a ZwCreateSection() y se copian los contenidos del fichero dentro de esta sección. Luego el lanzador del malware escribe en shellcode para remplazar la función ScRegisterTCPEndpoint() original y elimina la bandera de soporte ASLR desde una cabecera PE (la razón para realizar esta acción es hacer el shellcode más estable con unas direcciones de funciones preestablecidas).
Alguna de las últimas modificaciones a ZeroAccess realizan pasos adicionales modificando services.exe: manipulaciones de la sección de reubicación (.reloc) y la creación de un callback TLS (almacenamiento local de hilos) a services.exe (ZeroAccess – From Rootkit to Nasty Infection).
5. El punto final es la creación de un nuevo fichero con el mismo nombre (services.exe) pero que ha sido previamente modificado para atender las necesidades del atacante. Se crea un nuevo fichero por la función ZwCreateFile() y se rellenan los parámetros de los atributos del NTFS extendido desde el búfer con el código de la librería dll maliciosa.
El módulo con el código malicioso no se almacena directamente en el fichero services.exe, sino que se carga al utilizar de forma incorrecta ciertas características de NTFS. La información básica también se copia desde el fichero original (fecha de su creación, última vez a la que se accedió, última vez en la que se escribió, fecha de su último cambio y atributos del fichero). El shellcode inyectado en el paso 3 busca un atributo extendido con el nombre “731” usando la función ZwQueryEaFile() y arranca el código malicioso al ejecutarse. La siguiente capa del shellcode busca el origen de modulo de la dll maliciosa, prepara el punto de entrada y lo ejecuta. El gráfico de llamadas de la shellcode inyectada sería así:
Las soluciones de seguridad de ESET detectan las modificaciones en los procesos del sistema services.exe como Win64/Patched.B.Gen. El proceso services.exe modificado de acuerdo al programa BinDiff se muestra en el siguiente gráfico:
El proceso services.exe antes (izquierda) y después (derecha) de las modificaciones maliciosas.
ScRegisterTCPEndpointbefore() antes de las modificaciones (arriba) y después de las modificaciones (abajo).
Estadísticas de detección
Las estadísticas de detección por región, desde principios de año, son las siguientes (según la información recopilada por la tecnología ESET LiveGrid®):
[Detecciones de Win64/Sirefef por región]
[Detecciones de Win32/Sirefef por región]
Después de que el desarrollador de ZeroAccess cambiase las tácticas de infección y dejara de usar componentes en modo kernel en última versión, hemos seguido el crecimiento de las infecciones para x64.
Las estadísticas de detección de Win32/Sirefef y Win64/Sirefef son las siguientes:
ZeroAccess muestra cómo los desarrolladores de rootkits buscan otros métodos de distribución y encuentran interesante el uso de técnicas para infectar el sistema en modo usuario. Ya hemos hablado largo y tendido sobre el tema (Amenazas bootkit: análisis a fondo de ingeniería inversa y defensa) de la ingeniería inversa de bootkits en la reciente conferencia REcon celebrada en Montreal, pero hay más de un camino para el malware complejo para funcionar en sistemas x64, tal y como demuestran las últimas muestras de ZeroAccess.
Josep Albors