EmoCrash: exploit que aprovechaba la vulnerabilidad en Emotet
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
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!