Así como los atacantes pueden aprovechar las fallas en el software legítimo para causar daño, los defensores también pueden aplicar ingeniería inversa al malware para descubrir sus vulnerabilidades y luego explotarlas para derrotar al malware. La dificultad, por supuesto, es cómo compartir las noticias sobre la vulnerabilidad con otros mientras se mantiene en secreto para los delincuentes y que no repararen la falla. Los investigadores de Binary Defense han estado haciendo exactamente eso desde el 6 de febrero, y ahora es el momento de compartir los detalles de manera más pública.

Emotet es un malware basado en correo electrónico muy prolífico y de gran éxito, con un enfoque principal en el robo de correo electrónico y la carga de malware adicional como servicio. Más comúnmente identificado por sus tres botnets distintas y un flujo de código bastante ofuscado, Emotet es una amenaza única y persistente para organizaciones de todos los tamaños.

Binary Defense desarrolló un Killswitch aprovechando un simple desbordamiento de búfer que se encuentra en el proceso de instalación de Emotet y lo compartió libremente con la comunidad infosec, evitando los canales públicos para garantizar el máximo tiempo de actividad del exploit antes de que los actores de amenazas detrás de Emotet parchearan su malware para cerrar la vulnerabilidad. Este killswitch estuvo vivo entre el 6 de febrero de 2020 y el 6 de agosto de 2020 o 182 días.

El "nuevo" mecanismo de persistencia de Emotet

A principios de febrero de este año, Emotet lanzó una revisión masiva de la base de código, cambiando varios de los mecanismos de instalación y persistencia e introduciendo una máquina de estado polimórfica en su flujo de código. Esto agregó una capa de ofuscación al cargador, lo que dificulta el análisis. Uno de los cambios clave fue la eliminación de la lista de palabras y el algoritmo de generación de archivos utilizado por Emotet durante las instalaciones anteriores de Emotet.

En su lugar, había un nuevo algoritmo que generaba un nombre de archivo para guardar el malware en cada sistema víctima, utilizando un nombre de archivo de sistema EXE o DLL elegido al azar del directorio System32. Este nombre de archivo se cifró (codificó) con una clave XOR y se guardó en un valor de registro establecido en el número de serie del volumen de la víctima. Además, la clave XOR se configuró en el número de serie del volumen en formato Little-Endian.

Killswitch, V1

Cuando Emotet verificaba en el Registro el marcador de instalación, encontraría el valor nulo recién generado y generaría el nombre del EXE ".exe". Luego, buscaría la ubicación de instalación normal para este archivo ejecutable (%AppdataLocal%, C:\Windows\System32, C:\Windows\Syswow64, según el entorno). Si no lo encuentra, colocará un archivo en la ubicación de instalación normal llamado ".exe". Sin embargo, cuando el malware intenta ejecutar ".exe", no podría ejecutarse porque "." se traduce al directorio de trabajo actual para muchos sistemas operativos.

Si bien este mecanismo funcionaba, era muy complicado y aún así permitía que Emotet se instalara; solo impedía que Emotet se ejecutara con éxito y se conectara a la red. Preocupado por la falta de despliegue debido al desorden del mecanismo de protección, y la preocupación adicional de que dificulta la limpieza, Binary Defense continuó experimentando con ese Killswitch

Killswitch V2

Aproximadamente 48 horas después de que Emotet lanzara la versión más reciente del cargador, Binary Defense completó la segunda versión del Killswitch. Esta versión aprovechó un simple desbordamiento de búfer descubierto en la rutina de instalación de Emotet que hizo que Emotet se bloqueara durante la instalación del malware. Además, aparecerían dos registros de fallos con el ID de evento 1000 y 1001, que podrían usarse para identificar puntos finales con binarios de Emotet desactivados y muertos después de la implementación del interruptor de interrupción (y el reinicio de la computadora).
Empaquetada en un buen script PowerShell utilizable (que llamamos EmoCrash), esta utilidad identificaría la arquitectura del usuario y luego generaría el valor de registro de instalación correspondiente para el número de serie del volumen del usuario. Luego generaría un búfer de 0x340 (832) bytes, que guardaría en los datos del nuevo valor de registro.

Este pequeño búfer de datos era todo lo que se necesitaba para bloquear Emotet, e incluso podría implementarse antes de la infección (como una vacuna) o en mitad de la infección (como un interruptor de muerte).

Lanzamiento de exploits

Con una increíble cantidad de coordinación entre las comunidades Infosec y CERT, especialmente aquellos en Team Cymru que ayudaron inmensamente con esto, Binary Defense comenzó a distribuir el script de explotación EmoCrash a defensores de todo el mundo el 12 de febrero de 2020, con instrucciones estrictas de no publicarlo. Como nuestro objetivo era maximizar el tiempo de uso del exploit y al mismo tiempo evitar alertar a los delincuentes, Binary Defense estableció las reglas de divulgación de información en TLP:Green, que limita la divulgación a canales no públicos. .

Cuando comenzamos a divulgar el exploit a la comunidad, recibimos muchos comentarios útiles, incluida una solución a algunos problemas de compatibilidad que surgieron con las implementaciones de Windows 7, aportados por el CERT en la Universidad de Frankfurt en Alemania. Nos gustaría ofrecer nuestro más sincero agradecimiento y reconocimiento a los miembros de la comunidad de seguridad de la información de todo el mundo que trabajaron para ayudar a mantener este interruptor asesino en secreto para los atacantes mientras lo distribuyen ampliamente a los defensores.

Emotet entra en "modo de desarrollo" y muere el Kill Switch

Alrededor del 7 de febrero, Emotet entró en un período de tiempo en el que dejaron de enviar spam y comenzaron a trabajar en el desarrollo de su malware. Este período de tiempo se extendió del 7 de febrero al 17 de julio de 2020. Si bien su distribución de spam se detuvo por completo, no estuvieron "inactivos" durante este tiempo, ya que continuaron lanzando algunas actualizaciones binarias básicas y actualizaciones de protocolo. Además, se observó que Emotet usaba Trickbot para cargas desde el 2 de abril de 2020.

El 17 de julio de 2020, Emotet finalmente volvió a enviar spam después de su período de desarrollo de varios meses. E 6 de agosto, se envió una actualización del cargador central que finalmente eliminó el código de valor de registro vulnerable, efectivamente "matando" a EmoCrash.

Solo por diversión, James Quinn envió un informe de vulnerabilidad al programa CVE de MITRE para ver si le asignarían un número CVE. Obviamente fue negado, ya que la divulgación pública habría sido exactamente lo contrario de lo que se deseaba, pero fue divertido obtener una negación de MITRE al respecto.

Fuente: Binary Defense