Descubriendo APTualizador: el APT que parchea Windows

Área de Innovación y Laboratorio de ElevenPaths    29 julio, 2019

A finales de junio de 2019 asistimos a un incidente en el que los equipos comienzan a reiniciarse prácticamente a la vez y sin causa aparente. En paralelo, Kaspersky detecta la presencia de un archivo llamado swaqp.exe, aparentemente no disponible en ningún agregador de antivirus o plataforma pública en ese momento. Intentamos determinar si este archivo puede ser el causante de los reinicios y si realmente estamos ante una amenaza de malware.

Nos llama la atención que en un primer análisis rápido observamos que la muestra descargaba la actualización de seguridad legítima de Windows KB3033929, aunque lo hacía desde un servidor no oficial. En otras palabras: instalaba el archivo legítimo (firmado por Microsoft) desde un servidor no oficial. No es un comportamiento habitual del malware por dos razones.

  • Los creadores de malware suelen crear sus artefactos minimizando dependencias adicionales (librerías) que podrían no estar incluidas en los equipos de las potenciales víctimas.
  • Por otro lado, el malware no suele estar interesado en que los equipos se encuentren actualizados, y mucho menos intenta actualizarlos con parche alguno. No es el comportamiento habitual en el contexto de una posible muestra de malware.

A partir de aquí, comenzamos a investigar y encontramos el APT al que hemos llamado APTualizador.

¿Por qué actualizar?

Hasta ahora, tenemos un malware que aplica una actualización legítima en el sistema, y que descarga lo que parece un driver (que debe estar firmado para poder ser instalado). ¿Por qué actualizar el sistema operativo de una víctima? Para responder a esta pregunta es necesario comprender los cambios que incluía este parche y cómo se relaciona con la instalación del rootkit.

Si entramos en los detalles del certificado con el que se firmó este ejecutable, podemos ver que se hace uso de SHA256 como algoritmo de hash, aquí comienza a tener sentido el comportamiento del malware. KB3033929 es una actualización de Microsoft aparecida en 2015 como actualización a su vez de un parche de finales de 2014. Las versiones de Windows 8 en adelante, soportan de forma nativa la verificación de firmas con SHA256, pero Windows 7 o Windows 2008 R2, no. Microsoft tuvo que sacar este parche para poder seguir dando soporte a estas versiones (Windows 7 y 2008 R2), mientras que los anteriores (Vista, 2003, XP…) siguen sin poder comprobar firmas creadas con hashes SHA256

De ese modo,  los atacantes aplican el parche KB3033929 para que la verificación de su driver firmado sea válida. Entendemos que los atacantes solo disponían de esta posibilidad de firmado y, por tanto, tuvieron que adaptar la víctima al malware (actualizando las capacidades del sistema operativo) y no al revés.

Para ello, comprobamos la firma del driver:

Sorprendentemente, se encuentra firmado con SHA256, pero también con SHA1. Esto es una práctica habitual en las actualizaciones de Windows, desde hace algún tiempo, por ejemplo, precisamente para que puedan funcionar en Windows 7, 2008 R2 y el resto de sistemas. Pero en el caso de las actualizaciones, los hashes SHA1 están firmados por certificados diferentes a los hashes SHA256 en la misma muestra. En el caso de este malware, tanto el hash SHA1 como el hash SHA256, están firmados por un certificado SHA256.

Esto es un movimiento un poco extraño por parte del atacante. Entendemos que solo disponía de un certificado SHA256, y necesitaba actualizar el sistema para que el Windows víctima pudiese comprobar la validez. El hecho de que esté firmado por SHA1 puede ser una simple prueba previa del atacante.

El rootkit es descargado en la carpeta C:\WINDOWS\SYSTEM32\Drivers, y se crea un servicio a nivel de kernel que referencia al archivo .sys con el mismo nombre que el servicio. El nombre que se le da a este rootkit viene determinado por una unión de fragmentos de nombres de otros drivers que se encuentran en esta carpeta, por lo que la detección a simple vista del fichero podría no ser trivial.

Para asegurarse de la completa actualización de la DLL y la aplicación del parche, los atacantes forzaban el reinicio de la máquina tras la instalación del parche.

Referencias a McAfee y potencial atribución por idioma

A lo largo de la ejecución de la muestra existen constantes referencias a McAfee que hacen cambiar el comportamiento del malware según si los procesos del antivirus están corriendo o no. Buena parte del comportamiento del malware está supeditado a si existe este antivirus en el equipo o no. Esto puede ser un indicio de ataque dirigido.

Como ejemplo, en la primera línea de la imagen siguiente podemos ver una referencia a una función que hemos renombrado como writeLog_if_mcafee. Encontramos al menos otras siete referencias a comprobaciones internas que tienen que ver con la existencia o no de McAfee.

Encontramos además un fragmento de código en el que la muestra comprueba el idioma en el que está configurado el teclado de la víctima y, según este, proseguirán o no con la infección. Esto es habitual, no obstante, el caso encontrado aquí es un poco diferente. En vez de lo anterior, encontramos un rango de hasta 43 idiomas que, mediante códigos numéricos (LANGUAGE IDENTIFIER) consecutivos, se librarían de la infección.

Los países que no se verían afectados y entre los que se encuentra presumiblemente la fuente de la amenaza son los rangos comprendidos entre 0x18 y 0x43.

Esto pudiera indicar que:

  • Los autores se encuentran dentro de este rango, y los demás están incluidos para no dejar clara la atribución del ataque
  • El ataque fue dirigido, puesto que si se tratase de un malware sin víctima definida, no tendría sentido excluir tantas posibles infecciones (hasta 43 códigos diferentes estarían excluidos del ataque). Es importante señalar que la única relación que tienen los códigos entre sí es que son consecutivos, es decir, no constituyen un grupo geográficamente cercano ni políticamente afín.

Este informe ha sido realizado por el equipo de investigadores del CSIRT-SCC (Security Cyberoperations Center) con la colaboración de ElevenPaths.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *