Resumen

El Security Lab de Hornetsecurity presenta detalles sobre las webshells tras la operación de distribución de Emotet, incluyendo información sobre la descarga de cargas útiles y cómo, del 22 al 24 de julio de 2020, las cargas útiles de Emotet fueron sustituidas por código HTML con GIFs en sus URLs de descarga. El análisis muestra que la cantidad de descargas del contenido malicioso mediante las URLs de descarga de Emotet es significativo y que el pico observado asciende a 50.000 descargas por hora, demostrando que la gente sí que hace clic en los correos de Emotet. Más adelante, el análisis muestra que las páginas web comprometidas no solo se comprometen una, sino varias veces, y por parte de distintos autores, y que los esfuerzos de los administradores de dichas páginas web suelen ser insuficientes, lo cual permite que las descargas maliciosas de Emotet vuelvan a habilitarse.

Detalles

Emotet es uno de los emisores de malspam más prolíficos. Distribuye su malware mediante correos de malspam que contienen, o bien archivos adjuntos maliciosos con macros de VBA, o bien enlaces de descarga de dichos documentos maliciosos. A continuación, estos documentos maliciosos descargan el paquete de Emotet desde las URLs de descarga de Emotet. Estas descargas se alojan en sitios web comprometidos. Con este fin, los responsables de Emotet emplean malware de webshell en ellos. Estas webshells se emplean para subir nuevas cargas útiles a los sitios web comprometidos, bien se trate de documentos maliciosos distribuidos mediante enlaces maliciosos en correos electrónicos o del paquete de Emotet. Como los sitios web comprometidos acaban añadidos a listas negras o sus administradores los eliminan, los responsables emplean de 300 a 400 URLs al día.

Análisis técnico

En este análisis echaremos un vistazo a las webshells de Emotet.

La webshell S.A.P.

Teniendo acceso al sistema de archivos de un sitio web comprometido por Emotet, acceder a la webshell empleada por Emotet es muy sencillo. Sin embargo, con un poco de suerte, aprovechando errores de configuración en los sitios web comprometidos y las actividades de otros actores del mundo de las webshells, es posible obtener ejemplos de las webshells de Emotet sin necesidad de acceso a los servidores comprometidos.

Al principio, las webshells de Emotet se alojan en el directorio un nivel por encima de aquél que contiene la descarga de Emotet (es decir, bien un documento malicioso o el archivo ejecutable comprimido de Emotet). Por ejemplo, si la URL de descarga de Emotet es https://www.example.com/wp-includes/LYnUiE/, la webshell suele estar en https://www.example.com/wp-includes/. Sin embargo, también hemos observado webshells en otros directorios. A continuación, tratamos de aprovechar errores en la configuración de los sitios web comprometidos. Si hay suerte, incluso, el directorio que contiene la webshell puede ser un directorio abierto, es decir, un directorio permite el acceso a sus contenidos como en el siguiente ejemplo:

Directorio de Emotet abierto

En este ejemplo, import.php es la webshell de Emotet y lpyc42 es el directorio que alojará la carga útil de Emotet. Se han observado webshells de Emotet con los siguientes nombres: user.php, common.php, import.php, update.php, link.php, license.php, menu.php, image.php, options.php, tools.php, core.php, edit.php, functions.php, config.php y wp-list.php.

Obviamente, el acceso a la webshell está protegido. Así, al solicitar el archivo import.php, el servidor web ejecuta el código PHP y solo distribuye su resultado. Sin embargo, en algunos servidores, observamos archivos PHP que se habían renombrado, añadiéndoseles la extensión adicional .suspected.

Directorio abierto de Emotet con webshell renombrada (ignórense todas las demás webshells del directorio)

En realidad, lo más probable es que el que haya renombrado los archivos sea otro malware llamado Vigilante Malware Cleaner. El primero en descubrir y documentar Vigilante Malware Cleaner fue Bruce Ediger en 2019 [VigilanteMalwareCleaner]. La existencia de esta táctica de renombrado se remota como mínimo a 2015. El malware Vigilante Malware Cleaner parece infectar sitios web ya comprometidos, para luego buscar archivos potencialmente maliciosos entre los archivos PHP disponibles, desactivarlos añadiendo el apéndice .suspected a sus nombres de archivo y así excluirlos de la lista de archivos que el servidor ejecuta como código PHP. Esto provoca que el servidor entregue directamente los contenidos de los archivos (es decir, el código fuente de la webshell). Aprovechando esto podemos descargar el código PHP de la webshell de Emotet. Antes de permitir acceso a la webshell, el código consulta un parámetro llamado f_pp que se emplea para descodificar la webshell.

Webshell de Emotet codificada

Este parámetro f_pp sirve de contraseña a la webshell. Mediante análisis con OSINT, descubrimos que la webshell codificada es idéntica a otra hallada y descodificada por otro investigador en enero [EmotetWebshellSamples].

Para mostrar al lector lo que vería alguien que accediese a esta webshell con el parámetro f_pp correcto, ejecutamos el código PHP en un sistema de pruebas:

Webshell S.A.P. v.2.1 de Emotet

La webshell se identifica como webshell S.A.P., versión v.2.1. La webshell permite al atacante a buscar, cargar y descargar archivos. Permite ejecutar comandos arbitrarios. También ofrece cómodas herramientas para descargar bases de datos SQL desde el servidor, realizar análisis de red y/o robar contraseñas mediante fuerza bruta.

El hecho de que el proceso de descodificación dependa del parámetro f_pp como contraseña y de que hayamos encontrado varias muestras de exactamente el mismo código de webshell codificado hallado en enero es un firme indicio de que Emotet reutiliza contraseñas para sus webshells.

Infiltración de GIFs

Aunque no disponemos de registros ni de otras pruebas forenses de los sistemas en cuestión, en base a los hallazgos descritos, compartimos de la opinión de otros investigadores de que el reciente incidente en que las descargas de Emotet fueron sustituidas por código HTML con GIFs se debe a un fallo de seguridad de las webshells de Emotet. Esta hipótesis está respaldada por el hecho de que Emotet parece haber cambiado de webshell el 27 de julio de 2020, y de que las infiltraciones de GIFs se detuvieron en esa fecha. Sin embargo, el 31 de julio de 2020 se observaron indicios de nuevas infiltraciones de GIFs. Puede tratarse del tiempo que tardó el responsable de los GIFs en averiguar la nueva contraseña. Sin embargo, las nuevas infiltraciones de GIFs no son frecuentes, por lo que la estrategia que esté utilizando Emotet para defenderse de ellas estaría funcionando. Los GIFs empleados pueden interpretarse como una declaración hacia los responsables de Emotet acerca de que los autores de los GIFs siguen al acecho y decididos a seguir interfiriendo en la operación de Emotet:

GIF "Emotet está siendo vigilado"

GIF "Emotet está siendo vigilado"

En sitios web comprometidos por Emotet posteriormente hemos hallado variantes de la siguiente webshell en múltiples ocasiones:

Posible nueva webshell de Emotet

Aunque no estemos seguros de que ésta sea la nueva webshell de Emotet, cabe destacar que hay una actividad febril en el mundo de las webshell. Así, por ejemplo, hemos observado un servidor web que había sido objeto de dos infiltraciones de GIFs y tenía dos webshells renombradas con la extensión.suspected (probablemente) con Vigilante Malware Cleaner, así como una nueva descarga de Emotet activa, y todo esto en tan solo un directorio (otras partes del servidor contenían aún más webshells).

Directorio de Emotet abierto con 2 GIFs infiltrados

Esto significa que el sitio web no se usó para descargas de Emotet ni una ni dos, sino al menos tres veces (el 23 y el 28 de julio de 2020). El sitio web seguiría haciendo de servidor para cargas útiles de Emotet si no fuera porque, afortunadamente, se superó su límite de ancho de banda.

La descarga de Emotet dejó de funcionar por superarse el límite de ancho de banda

Existe la posibilidad de que los responsables de los GIFs estén obteniendo acceso gracias a una vulnerabilidad del sitio web en sí, o que incluso estén relacionados con el malware Vigilante Malware Cleaner. Lamentablemente, como proveedores de seguridad para correo electrónico, no disponemos de suficiente información acerca de las circunstancias de los sitios web comprometidos como para emitir diagnósticos concluyentes.

Estadística de descargas

En lo que respecta a las cuotas de descarga, existe un modo de monitorizar las estadísticas de descargas de cargas útiles de Emotet de modo externo. Emotet emplea código PHP para recopilar estadísticas de descarga agrupadas por los sistemas operativos indicados en la cadena de texto de los agentes de usuario de los navegadores que efectúan las descargas. Estos datos estadísticos se envían en forma de objeto JSON a un subdirectorio del directorio de descarga de cargas útiles de Emotet denominado $path , '/.' . sha1(basename($path)):

Estadística de descargas de Emotet

Por tanto, la estadística de https://www.example.com/wp-includes/LYnUiE/ puede consultarse en https://www.example.com/wp-includes/LYnUiE/.a2dd7d055bb668528c29e16f789755fb3aae277b.

Al consultar el código de webshell de Emotet previamente compartido [EmotetWebshellSamples], los números corresponden a los sistemas operativos Windows (4), Linux (3), Apple (2), Android (1) y «desconocido» (0) hallados en cadenas de texto de agentes de usuario:

Código PHP de estadísticas de Emotet

Procedimos a recopilar dichas estadísticas. Los contadores se ponen a cero cada vez que los servidores de nivel 2 de Emotet envían actualizaciones de documentos maliciosos y archivos ejecutables de descarga a los sitios web comprometidos a través de las webshells. Por tanto, cuando una nueva cuenta era superior a la anterior, tomamos la diferencia como la cantidad de descargas efectuadas entre las consultas. Si una cuenta era inferior a la anterior, partimos de la base de que se había puesto a cero y tomamos la nueva cuenta como la cantidad de descargas desde nuestra última consulta. También ignoramos las estadísticas de descargas detenidas, es decir, descargas que ya no se ponen a cero. Recopilamos datos con una frecuencia de 1 minuto. Emotet actualizaba los documentos aproximadamente cada 10 minutos. Como Emotet ataca al sistema operativo Windows, solo tenemos en cuenta las estadísticas de descargas para dicho sistema operativo. Durante 12 horas del 29 de julio de 2020 obtuvimos estadísticas de 739 URLs de descarga de Emotet (533 de las cuales registraron descargas activas en el periodo analizado). Los datos pueden visualizarse del siguiente modo:

Descargas de Emotet el 29 de julio de 2020

Esto es un diagrama de columnas apiladas en que la cantidad de descargas de cada URL se representa individualmente, mientras que el total muestra la cantidad acumulada sobre todas las URL de descarga. Cada color representa una URL de descarga de Emotet distinta. Obviamente, estas cifras incluyen descargas realizadas por investigadores en el campo de la seguridad y sistemas de seguridad automáticos tales como sandboxes. También perdemos las descargas que tienen lugar antes de que Emotet ponga a cero los contadores entre nuestras consultas. Con todo, las cifras ofrecen un cuadro interesante de las descargas de Emotet y, por tanto, de la tasa de clics de Emotet. Durante nuestra observación, la mayor cantidad de descargas de Emotet acumuladas en una hora fue de 50.000.

Al dividir las URLs de descarga por las cargas útiles entregadas (en base a un análisis del tipo MIME), podemos ver que la mayoría de las descargas corresponden al documento malicioso de Emotet. El paquete de Emotet se descarga bastante menos a menudo:

Descargas de Emotet el 29 de julio de 2020

Si ordenamos los números de descargas por el tiempo trascurrido tras la primera observación de la URL, vemos que el número de descargas de cada URL alcanza su máximo durante la hora que sigue a su primera observación. En ese momento, cada una de las URLs de Emotet observadas obtuvo alrededor de 200 descargas por hora. Sin embargo, las URLs continúan obteniendo descargas incluso 12 horas tras la primera observación de la URL. Por tanto, cada URL de descarga bloqueada o eliminada supone reducir las víctimas potenciales de Emotet, incluso si se hace a las 12 horas.

El siguiente diagrama de líneas ilustra el rendimiento de descarga individual de las URLs:

Descargas de Emotet alineadas por la hora a la que se observó por primera vez su URL

Apilando las cifras de descargas de URLs, la tendencia descendente puede observarse con claridad. Al cabo de 9 horas, la cantidad de descargas cae hasta a un tercio de la cifra observada recién descubierta la URL:

Descargas de Emotet alineadas por la hora a la que se observó por primera vez su URL como gráfico apilado

Pensamos que una parte del pico inicial puede atribuirse a sistemas de seguridad escaneando el malspam de Emotet y, por tanto, descargando los documentos maliciosos de Emotet desde sus URLs de descarga. Esto se confirma separando de nuevo los datos en URLs de distribución de documentos maliciosos y URLs que distribuyen el paquete de Emotet:

Descargas de Emotet alineadas por la hora a la que se observó por primera vez su URL

La cantidad de descargas del paquete de Emotet asciende más lentamente hasta su máximo que las descargas del documento malicioso, lo cual respalda nuestra hipótesis. Además, no hay ningún descenso brusco en las descargas de paquetes de Emotet.

De media, el paquete de Emotet se descargó unas 1500 veces por hora, mientras que los documentos maliciosos de Emotet se descargaban a un ritmo de unas 7500 veces por hora.

Intentos de limpieza fallidos

Durante un análisis más detallado de las URLs de descarga, observamos asimismo múltiples intentos de limpieza fallidos. A menudo, los administradores de los sitios eliminan el directorio que contiene la descarga de Emotet. Sin embargo, se olvidan de eliminar todas las webshells. En tal caso, los responsables de Emotet solo tienen que regenerar los archivos eliminados durante su siguiente actualización de cargas útiles. También hemos observado a Emotet empleando de nuevo un sitio web comprometido con anterioridad.

Otros errores observados

Tratándose de una operación tan extensa, es inevitable que los responsables de Emotet cometan errores. Uno de los errores es permitir que un tercero desmantele sus descargas de cargas útiles. Otros errores incluyen haber estropeado la expresión regular de sustitución, por lo que observamos URLs de descarga distribuyendo documentos maliciosos de Emotet con nombres de archivos incorrectos, tales como InvJP0732{:REGEX:.doc, INVOICE-Q84{:REGEX:.doc, invoice-UBO7631{:REGEX:.doc, etc. Estamos convencidos de que la parte {:REGEX: debería ser {:REGEX:[0-9]{3,6} (o algo similar), una sintaxis especial empleada por los procesos de generación de Emotet para aumentar la base de nombres de archivos mediante un patrón de caracteres aleatorio pero restringido. Esos patrones {:REGEX:[...] también se han filtrado con anterioridad en nombres de archivos adjuntos y son parte del proceso de automatización de Emotet. Hay que tener en cuenta que, dependiendo del navegador, el símbolo : de los nombres de archivo pueden sustituirse por _, pues : no es un carácter válido en el sistema operativo Windows. Vigilando muy de cerca la operación Emotet, con el tiempo, se observan muchos errores de ese tipo, y los conocimientos obtenidos pueden emplearse para mejorar nuestras defensas contra ella.

Conclusión y soluciones

Como muestra este análisis del Security Lab de Hornetsecurity, Emotet no solo se envía a gran escala, sino que sus contenidos maliciosos se descargan en volúmenes significativos.

Recomendamos que bloquee las URLs de Emotet conocidas en sus redes. Si visitar cualquier página web no es una actividad necesaria para su empresa, puede bloquear los dominios y no solo las URLs específicas. Esto aporta una mayor protección, pues, como se ha demostrado, Emotet y otros delincuentes pueden volver a utilizar los sitios web comprometidos, bien obteniendo acceso a ellos mediante webshells utilizadas previamente, o volviendo a infectarlos mediante el vector de acceso inicial (por ejemplo, una vulnerabilidad de WordPress o una contraseña débil). El bloqueo debería mantenerse incluso después de eliminada la descarga de Emotet, ya que el sitio podría seguir estando comprometido. Es muy probable que nunca necesite acceder a ninguno de esos sitios web en absoluto, por lo que mantenerlos bloqueados no debería causar ninguna inconveniencia.

El servicio Spam and Malware Protection de Hornetsecurity, con las tasas de detección más elevadas del mercado, ya detecta y bloquea correos de Emotet en base a indicadores conocidos. Advanced Threat Protection de Hornetsecurity amplía esta protección detectando amenazas aún desconocidas.

 

Referencias