«Firefox Send» envía el malware Ursnif

«Firefox Send» envía el malware Ursnif

Resumen

El 07.07.2020 Mozilla desactivó temporalmente su servicio de envío de Firefox debido a un abuso de malware. El Security Lab de Hornetsecurity explica cómo el malware abusó de Firefox Send. Para ello, analizaremos una campaña de malware que difunde una variante del malware Ursnif. La campaña utilizó el servicio de envío de Firefox para alojar su descargador malicioso y enviar estos enlaces maliciosos de Firefox a las víctimas. Tal abuso hizo que Mozilla desactivara el servicio de envío de Firefox, ya que el servicio carece actualmente de una función de denuncia. Esto significa que, aunque los investigadores de seguridad encontraran estos enlaces maliciosos, no se podría informar a Mozilla para desactivarlos. Sin embargo, nuestro análisis muestra además que el malware ya está abusando de otros servicios, por lo que la desactivación de Firefox Send  – aunque fue la decisión correcta – no tiene ningún efecto en las campañas de malware.

Antecedentes

El 07.07.2020 Mozilla desactivó temporalmente su servicio de envío de Firefox debido a un abuso de malware. Esto se debió principalmente a que el servicio no ofrece una forma de denunciar dichos abusos. Es probable que Mozilla reactive el servicio una vez que se complete el «trabajo de mejora del producto», como se indica en el mensaje que aparece actualmente al intentar acceder al sitio web de Firefox Send:

Firefox Send temporarily disabled

Para explicar por qué Mozilla deshabilitó temporalmente su servicio de envío de Firefox, el Security Lab de Hornetsecurity analizará una campaña de malware que distribuye una variante del malware Ursnif.

Análisis

La campaña utiliza una mezcla de malspam en un enlace y adjunto distribuyendo un archivo VBScript que descarga el malware Ursnif. La campaña aprovecha el secuestro de hilos de conversaciones de correo electrónico, es decir, los actores detrás del ataque enviarán su malware como respuesta a las conversaciones de correo electrónico existentes de sus víctimas. Un ejemplo de correo electrónico que utiliza el servicio de envío de Firefox para alojar la carga dañina tiene el siguiente aspecto:
 

Initial email leveraging email conversation thread hijacking

Las partes redactadas contienen un hilo de conversación de correo electrónico robado al que la campaña responde con su enlace malicioso y un mensaje corto. Los mensajes suelen decir que un documento ha sido actualizado y puede ser descargado desde el enlace de envío de Firefox. El grado en que el mensaje malicioso, encaja en el hilo de conversación del correo electrónico secuestrado, parece depender del azar, es decir, el mensaje hará referencia a los documentos actualizados independientemente de la finalidad del hilo de conversación.
 
El enlace de envío de Firefox llevará a un archivo VBScript. El archivo VBScript descarga una variante de Ursnif, probablemente desarrollada a partir de otra variante de Ursnif llamada ISFB para la cual el código fuente está disponible públicamente.
 

El  07-07-2020 Mozilla decidió desactivar temporalmente el envío de Firefox, porque el servicio no cuenta con un mecanismo para reportar el abuso. Esto significa que los enlaces de descarga no pueden ser reportados a Mozilla por los investigadores de seguridad. Es importante disponer de una función de denuncia de abusos para un servicio en línea, especialmente porque la naturaleza centrada en la privacidad de Firefox Send ofrece muchas oportunidades de abuso. Por ejemplo, los enlaces pueden estar protegidos por una contraseña. Se puede restringir el número de descargas, así como el tiempo que éstas estarán disponibles:

Firefox Send privacy restrictions

Esto significa que un atacante puede limitar la cantidad de descargas a una para sus víctimas. En caso de un compromiso exitoso, un equipo de respuesta a incidentes no puede descargar más la carga original de malware para reconstruir la infección. Si el malware borra sus archivos después de la infección será difícil de rastrear tal ciberataque.
 
 
Otro problema surge para el uso legítimo del servicio y el software de seguridad que escanea tales enlaces de descarga de una sola vez. Si el software de seguridad descarga el archivo para escanearlo, el destinatario real no podrá descargar más el archivo, ya que el software de seguridad ya ha utilizado la única descarga disponible.
 
 
Por estas razones, es muy probable que el servicio de envío de Firefox siga siendo abusado una vez que regrese. La función de denuncia de abusos será útil principalmente para denunciar los enlaces que permiten realizar múltiples descargas y que se utilizan durante un período de tiempo más largo. Informar sobre los enlaces de descargas únicas podría ayudar a Mozilla a frenar el abuso, detectando patrones en la forma en que los actores que están detrás del abuso interactúan con su servicio y luego los bloquean.
 
Pero incluso si el servicio de envío de Firefox debería implementar mejores protecciones contra el abuso, la discutida campaña de malspam no depende en absoluto del servicio de envío de Firefox. La campaña utilizó el servicio de envío de Firefox a partir del 06-01-2020 (transición del uso de enlaces de Google Drive) hasta el día en que fue desactivado:

Ursnif malspam campaign using Firefox Send exclusively over extended period of time

Sin embargo, la campaña ha utilizado los enlaces de Google Drive y Dropbox antes de utilizar los enlaces de Firefox Send. También ha utilizado archivos adjuntos ZIP cifrados en lugar de enlaces de descarga y tan pronto como se desactivó el servicio de envío de Firefox se cambió a este esquema de archivos adjuntos ZIP cifrados:

Initial email using encrypted ZIP attachment

Tanto Google Drive como Dropbox permiten informar de abusos, sin embargo, siguen siendo objeto de abusos por parte de malware. Esto significa que cuando Firefox Send regrese, también se abusará de él nuevamente.

Conclusión y medidas defensivas

Si bien aplaudimos a Mozilla por haber desactivado temporalmente el servicio de envío de Firefox, hasta que se implemente una función de denuncia de abusos, el análisis de la discutida campaña contra el correo basura indica que el servicio de envío de Firefox es sólo uno de los muchos servicios de los que se abusa para la distribución de malware, y la adición de la función de denuncia de abusos no detendrá dicho abuso.
 
 
Para protegerse contra esos ciberataques, especialmente contra el secuestro del hilo de la conversación del correo electrónico, los usuarios deben ser cautelosos cuando reciben una respuesta no solicitada de un interlocutor que trata de atraerlos para que abran enlaces u otros documentos, ya sea adjuntos directamente al correo electrónico o a través de un servicio de alojamiento de archivos, especialmente cuando esos documentos no encajan en la conversación y/o se entregan a través de un mecanismo inusual, por ejemplo, si los documentos suelen compartirse a través de una solución de intercambio de archivos internos de la empresa, los usuarios deben ser especialmente cautelosos al abrir archivos compartidos a través de servicios externos.

El servicio de Hornetsecurity Spam and Malware Protection, con las tasas de detección más altas del mercado, ya detecta y bloquea todas las variaciones de los correos electrónicos reseñados que actualmente distribuyen la variante de malware Ursnif. Aquí también es importante que los usuarios no se dejen engañar por el secuestro del hilo de la conversación del correo electrónico. El servicio Advanced Threat Protection amplía esta protección detectando también amenazas aún desconocidas. Cuando se utiliza el servicio de cifrado de Hornetsecurity no es necesario un servicio de terceros como Firefox Send para cifrar los documentos enviados. Los correos electrónicos salientes se cifran automáticamente con una de las tecnologías de cifrado más comunes (PGP, S/MIME o TLS), según la política establecida y la disponibilidad de los certificados correspondientes, sin ninguna otra intervención del usuario.

Referencias

El Security Lab de Hornetsecurity publica nuevas cifras: cerca del 70% de todos los correos son no deseados

El Security Lab de Hornetsecurity publica nuevas cifras: cerca del 70% de todos los correos son no deseados

Cada día se envían unos 300.000 millones de correos electrónicos; se prevé que el número de correos enviados y recibidos con fines privados y comerciales aumente a 361.600 millones para 2024. Sin embargo, no todos los correos electrónicos que terminan en los buzones de los usuarios son deseados, y los correos electrónicos no deseados no sólo contienen publicidad cuestionable, sino a menudo adjuntos y enlaces maliciosos.
Los expertos del Security Lab de Hornetsecurity han analizado cuántos correos electrónicos son realmente deseados por los usuarios y qué peligros pueden acechar en sus bandejas de entrada. Para ello, se han basado en los correos electrónicos recibidos en el sistema para el año 2020 y han llegado a conclusiones interesantes: sólo el 28% de los correos podían ser clasificados como «limpios», es decir, inofensivos por los filtros de Hornetsecurity, por lo que más del 70% de todos los correos electrónicos dirigidos no eran deseados por el destinatario.

¿Qué correos electrónicos ya están bloqueados de antemano?

Un total del 67% de los correos electrónicos entrantes son bloqueados de antemano por los mecanismos de filtrado de Hornetsecurity: esto significa que estos correos ni siquiera han sido clasificados como dañinos o no deseados debido a varios factores. En junio de 2020, el Security Lab de Hornetsecurity analizó las razones para bloquear los correos electrónicos entrantes. A continuación, echamos un vistazo a las más importantes:

En primer lugar, el 58% son correos electrónicos que podrían clasificarse como spam de antemano utilizando una lista de agujeros negros en tiempo real.

En segundo lugar, el 12% son correos electrónicos que intentan usar los servidores de correo de Hornetsecurity como retransmisión abierta. La retransmisión abierta es el proceso por el cual, un servidor de correo electrónico entrega correos electrónicos de los que no es responsable. Por ejemplo, si example.com tiene un servidor de correo electrónico, sólo debería aceptar correo electrónico para mustermann@example.com. Un servidor de retransmisión abierto también aceptaría correo para otros dominios, como @test.com. Estos relés abiertos a menudo se utilizan para enviar spam con direcciones de remitentes falsas.

En el 5,9% de los e-mails bloqueados por Hornetsecurity no se pudo encontrar la dirección correcta del remitente – los ciberdelincuentes intentan ocultar su identidad o pretender ser otra persona. Un ejemplo: en el caso de mustermann@example.com, si el dominio example.com no existe, el correo electrónico se bloquea.

En el 5,3% de los correos electrónicos bloqueados se encontró contenido dañino. El contenido malicioso incluye archivos adjuntos como *.xls, *.doc, *.pdf que contienen software malicioso, pero también enlaces que conducen a páginas web maliciosas o comprometidas.

Zu den restlichen Gründen, weshalb E-Mails im Voraus von Hornetsecurity blockiert werden, zählen unter anderem technische Fehler, Greylisting oder wenn eine E-Mail einen nicht existierenden User addressiert.

¿Qué amenazas se encuentran en los correos electrónicos que no fueron bloqueados de antemano?

La proporción de spam, malware y otras amenazas en los correos electrónicos no bloqueados también es interesante. Para esta evaluación, los expertos en ciberseguridad comprobaron el número total de correos electrónicos entrantes menos los correos electrónicos bloqueados.

Alrededor del 10% de estos correos analizados eran spam y alrededor del 3% eran correos de información. Los expertos de Seguridad Informática del Security Lab también fueron capaces de encontrar malware en alrededor del 1% de todos los correos electrónicos entrantes, e incluso algo menos del 0,1% fue detectado por el servicio de Advanced Threat Protection de Hornetsecurity. Se trata de ataques como el fraude del CEO, spearphishing o los ataques que utilizan nuevos tipos de malware, que sólo fueron detectados por el ATP Sandbox de Hornetsecurity y no por los filtros clásicos. A la inversa, esto significa que más del 10% de los correos electrónicos que no se bloquean de antemano, contienen spam o archivos adjuntos y contenidos perjudiciales para el usuario.

Conclusión

Aunque la mayoría de los correos electrónicos dañinos pueden ser bloqueados, las empresas no deberían sentarse de brazos cuzados : los ciberdelincuentes encuentran constantemente nuevas formas de enviar correos electrónicos maliciosos a los usuarios y sus ciberataques siguen siendo a menudo exitosos.

Las webshells tras Emotet

Las webshells tras Emotet

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

Escudo de Privacidad: ¿El fin del intercambio transatlántico de datos?

Escudo de Privacidad: ¿El fin del intercambio transatlántico de datos?

El 16 de julio de 2020, el Tribunal de Justicia de la Comunidad Europea (TJCE) anuló el marco de protección de datos entre los EE.UU. y Europa. Aunque esto no significa el fin inmediato de la transferencia de datos entre los dos continentes, tiene consecuencias de gran alcance. Echemos un vistazo rápido.

Escudo de Privacidad – ¿Qué contiene?

El Acuerdo de Datos entró en vigor a principios de 2016 como sucesor del Acuerdo de Puerto Seguro. El objetivo del Escudo de Privacidad, según sus creadores, era otorgar seguridad jurídica no sólo para proporcionar un mayor nivel de protección de los ciudadanos, sino también para las empresas europeas que intercambian datos con los EE.UU. Así, las empresas estadounidenses estarían obligadas a almacenar los datos de los ciudadanos de la UE sólo mientras se utilizaran para el propósito original. Los expertos en protección de datos criticaron este acuerdo desde el principio, ya que sospechaban que no ofrecería ningún cambio significativo en comparación con el anterior acuerdo de puerto seguro.

Por ejemplo, el Escudo de Privacidad ofrecía enfoques para una mejor protección de los datos, pero aún estaba lejos de alcanzar el estándar europeo. En particular, los servicios secretos de EE.UU. podían acceder a los datos de los ciudadanos de la UE sin ninguna restricción. Este hecho llevó al TJCE a declarar inválido el Escudo de Privacidad.

Fin del Escudo de Privacidad – ¿Y ahora qué?

¿Pueden seguir fluyendo los datos entre los EE.UU. y Europa? Está claro que la eliminación del acuerdo del Escudo de Privacidad crea confusión. En primer lugar, es importante darse cuenta de que hay que hacer una distinción entre los particulares y las empresas. Los individuos privados pueden seguir enviando correos electrónicos privados a los EE.UU. o hacer una reserva en un sitio web de EE.UU. Pero, la situación es diferente para las empresas.

Alrededor de 5.000 empresas se ven directamente afectadas por la decisión del TJCE, ya que invocan el Escudo de Privacidad cuando transfieren datos a los EE.UU. Entre ellas se encuentran empresas como Facebook, Microsoft y Amazon. Para poder asegurar el intercambio de datos legales a EE.UU., las empresas pueden usar las cláusulas contractuales estándar que se han dado hasta la fecha. Pero, la pregunta es: ¿siguen siendo válidas, aunque no puedan excluir el acceso de los servicios secretos?

Los expertos en protección de datos de Alemania empiezan a hablar de la independencia digital de Europa. Por ejemplo, la experta berlinesa en protección de datos Maja Smoltczyk pide a los responsables de la transferencia de datos personales de los EE.UU. que cambien a proveedores de servicios de la UE con el fin de garantizar un nivel adecuado de protección de datos.

Por lo tanto, cabe suponer que no habrá «avances» en el debate sobre la protección de datos para superar la incertidumbre jurídica.

¿Qué significa esto para los clientes de Hornetsecurity?

En principio, Hornetsecurity proporciona su servicio principal en Alemania dentro de los centros de datos seguros de ese país. No hay intercambio de datos con los EE.UU. y por lo tanto, Hornetsecurity no se ve directamente afectada por esta decisión.

Todos los subcontratistas de un tercer país comisionados por Hornetsecurity, que han nombrado el Escudo de Privacidad como base para la transmisión de datos, también disponen de bases legales alternativas, de modo que si una base legal ya no es aplicable, una de las otras posibilidades se hará cargo. Las otras dos variantes para la transferencia de datos desde el Espacio Económico Europeo a otros países, especialmente los Estados Unidos, son las normas corporativas vinculantes / reglamentos internos vinculantes de protección de datos y las cláusulas contractuales estándar de la UE. Nuestros clientes encontrarán la información exacta sobre nuestros subcontratistas en el Acuerdo de Procesamiento de Orden del Anexo 3.

Emotet ha vuelto

Emotet ha vuelto

Resumen

El pasado 17 de julio de 2020 los expertos del Security Lab de Hornetsecurity han detectado el regreso del malware Emotet en forma de malspam. El malspam de Emotet que estaba resurgiendo ya estaba bloqueado por las reglas de detección existentes. La actual ola de malspam de Emotet vuelve a utilizar documentos macro maliciosos que se propagan ya sea a través de archivos adjuntos o mediante enlaces de descarga maliciosos. Como de costumbre, las macros VBA del documento descargan el cargador de Emotet que el Security Lab de Hornetsecurity ha analizado previamente [EmotetLoader].

 

Antecedentes

Como se informó anteriormente, el regreso de Emotet era inevitable. La red de bots de Emotet no ha enviado malspam desde el 7 de febrero de 2020. Aunque hubo otras actividades en la red de bots, como se puede ver en la siguiente cronología, el Security Lab de Hornetsecurity no ha observado malspam desde el mes de febrero de este año.

Emotet recent eventsEl 17 de julio de 2020 nuevos correos electrónicos de Emotet fueron bloqueados por los sistemas de filtrado de correo electrónico de Hornetsecurity. Uno de esos correos electrónicos tiene el siguiente aspecto:

Emotet malspam email

El correo electrónico tiene un documento de Word adjunto, sin embargo, también existen otros correos electrónicos con enlaces de descarga maliciosos a los documentos de Word maliciosos. Al abrir el documento se le indica al usuario que haga clic en el botón «Enable Editing» (o como los autores de Emotet lo llaman «Enable Edition») y que haga clic en los botones del banner «Enable Content»:

Emotet DOC attachment

Si el usuario hace esto, se convierte en una victima directa de Emotet.

Análisis técnico

Como se informó anteriormente, la típica cadena de infección de Emotet es la siguiente:

Emotet infection chain

Ya informamos sobre el cargador de Emotet como parte de un análisis sobre sus actualizaciones. Como en ese momento Emotet no enviaba malspam, no pudimos esbozar los documentos maliciosos que se suelen utilizar en las infecciones de Emotet.

Las macros VBA están ofuscadas. El macro construirá un comando Powershell a partir de cadenas ofuscadas incrustadas en el macro VBA:

Emotet Powershell command

La de codificación del comando codificado en Base64 revela las 5 URL de descarga del cargador de Emotet:

Emotet download URLs

El documento intentará descargar el cargador de Emotet de cada una de estas 5 URLs:

Emotet DNS queries

En caso de que una de las 5 descargas tenga éxito, se ejecuta el cargador de Emotet, que hemos analizado previamente en otro artículo [EmotetLoader].

Conclusión y soluciones

A diferencia de lo que se especulaba anteriormente, Emotet no tiene nuevos trucos, al menos no cuando se trata de malspam.

Para protegerse contra el malware Emotet, el CERT de los EE.UU. recomienda «implementar filtros en la pasarela de correo electrónico para filtrar los correos electrónicos con indicadores de malspam conocidos» [USCERT].

El servicio Spam and Malware Protection de Hornetsecurity, con las tasas de detección más altas del mercado, ya ha detectado y bloqueado el malspam reemergente de Emotet. Asimismo, Advanced Threat Protection de Hornetsecurity amplía esta protección al detectar también ciberamenazas aún desconocidas.

Además de bloquear los correos electrónicos entrantes de Emotet, los defensores pueden utilizar la información pública disponible del equipo de Cryptolaemus, un grupo voluntario de personas del campo de seguridad informática que se unen para luchar contra Emotet. Proporcionan nueva información diariamente a través de su sitio web [CryptolaemusWeb]. Allí puedes obtener la última lista de IPs C2 para encontrar y/o bloquear el tráfico C2. Para actualizaciones en tiempo real puedes seguir su cuenta de Twitter [CryptolaemusTwitter].

Referencias

Indicadores de compromiso (IOCs)

Hashes

SHA256 Descripción
99d8438c947cac7ca363037f1436ecab4e7fa4609c9c59f6fd5006a050d361aa Documento malicioso
5d2c6110f2ea87a6b7fe9256affbac0eebdeee18081d59e05df4b4a17417492b Documento malicioso
c5949244e5d529848c2323545a75eec34e6ba33c6519d46359b004d6717a68a5 Documento malicioso

URLs

  • hxxps[:]//www.elseelektrikci[.]com/wp-content/hedk3/
  • hxxps[:]//www.rviradeals[.]com/wp-includes/LeDR/
  • hxxps[:]//skenglish[.]com/wp-admin/o0gf/
  • hxxps[:]//www.packersmoversmohali[.]com/wp-includes/pgmt4x/
  • hxxps[:]//www.tri-comma[.]com/wp-admin/MmD/

DNSs

  • www.elseelektrikci[.]com
  • www.rviradeals[.]com
  • skenglish[.]com
  • www.packersmoversmohali[.]com
  • www.tri-comma[.]com
Los deepfakes se están convirtiendo en una amenaza para las empresas

Los deepfakes se están convirtiendo en una amenaza para las empresas

Cada vez más a menudo, aparecen vídeos engañosamente reales en los que los famosos dicen o hacen cosas inesperadas : Barack Obama, por ejemplo, ataca a su sucesor, o Mark Zuckerberg confiesa que ha transmitido todos los datos de usuarios de Facebook. Pero ellos nunca hicieron eso. Estos son los llamados vídeos deepfake, que han sido hechos con ayuda de inteligencia artificial.

Aunque en la mayoría de los casos estos vídeos son reconocidos como falsos de manera relativamente rápida, esta tecnología está mejorando constantemente y representa un peligro potencial importante.
Cada vez es más difícil detectar si la información es falsa, además los ciberdelincuentes también están utilizando “deepfakes” para atacar a empresas con nuevas estafas: por ejemplo, The Wall Street Journal informó sobre una empresa británica no especificada que fue víctima de un ataque deepfake. En este caso, la voz del CEO de la empresa matriz alemana fue imitada como si fuera auténtica utilizando un software basado en Inteligencia Artificial (IA) y consiguieron que el jefe de la compañía británica transfiriera 243.000 dólares americanos a una cuenta bancaria extranjera.

Como consecuencia de estos desarrollos, Hornetsecurity quiere analizar en el siguiente artículo el tema de los “deepfakes”.

¿Qué es un deepfake?

Los “deepfakes” son archivos de vídeo y audio manipulados que imitan las características biométricas de las personas como: la apariencia, las expresiones faciales o la voz de una manera engañosamente real. El término se compone de Deep Learning, que describe una tecnología especial de IA, y Fake.

Para crear vídeos Deepfake, las redes neuronales artificiales, que tienen una cierta capacidad de aprendizaje, se alimentan con material de imagen o vídeo. Basado en el material de origen, el software de IA puede aprender a representar a la persona e incluso imitarla en un contexto diferente. La calidad del resultado depende, por un lado, de la extensión del material de origen y de cuántas capas ha utilizado la red neuronal, es decir, cuán «profunda» es. Para crear la imitación, dos algoritmos funcionan en la interacción: mientras que uno crea la falsificación, un segundo comprueba el resultado en busca de errores. La autenticidad de la falsificación aumenta con el número de repeticiones de este proceso de aprendizaje.
Pero no sólo los vídeos pueden ser falsificados con Inteligencia Artificial y Deep Learning, también se pueden crear falsificaciones de voces usando un método similar.

¿Por qué aumenta el número de Deepfakes?

No hace mucho tiempo que las caras en los vídeos sólo podían ser reemplazados por efectos CGI elaborados por expertos a altos costes. En la actualidad, esto también es posible para cualquier persona de TI gracias a un software de IA de libre acceso como DeepFaceLab. Incluso el uso de un hardware de alto coste ya no es necesario. Los usuarios que tienen una tarjeta gráfica demasiado débil pueden, por ejemplo, utilizar Colab de Google para tener hasta doce horas de formación de IA llevado a cabo en la nube. Una vez que el programa ha sido alimentado con material crea la manipulación automáticamente, en la medida de lo posible . Además, los mecanismos de aprendizaje profundo están en constante evolución y requieren cada vez menos grabaciones. Si bien varias horas de secuencias de vídeo serían necesarias, algunas IA solo necesitan unas pocas imágenes para intercambiar rostros.

El proceso de imitar una voz es similar: programas como Lyrebird necesitan sólo unos minutos de material de audio para generar imitaciones creíbles.

Mientras que los famosos han sido, hasta ahora, los principales objetivos: el caso descrito al principio muestra que los ciberdelincuentes también están utilizando la tecnología para atacar a las empresas.

¿Qué ataques deepfake pueden esperar las empresas?

Los expertos en ciberseguridad de Hornetsecurity ven un alto potencial de riesgo en dos áreas en particular: una estafa es el llamado fraude del CEO, en el que los ciberdelincuentes se hacen pasar por ejecutivos enviando correos electrónicos con una dirección personal y tratan de persuadir a los empleados a pagar grandes sumas de dinero. Con la tecnología “deepfake” ahora es posible aumentar drásticamente la credibilidad de esta estafa del fraude del CEO mediante archivos adjuntos de vídeo o audio falsos.

Debido al rápido desarrollo de la tecnología, también es concebible que los estafadores puedan incluso ponerse en contacto con los empleados directamente por teléfono o videollamada y hacerse pasar por el director general en tiempo real. El caso de la empresa británica mencionada al principio de este artículo, muestra que este procedimiento ya se ha aplicado con éxito en la práctica: un hacker se hizo pasar por el director general y llamó a su superior de la empresa matriz alemana y, según sus instrucciones, transfirió 243.000 dólares americanos a un supuesto proveedor.

Otra táctica que también podría convertirse en un problema: los ciberdelincuentes crean deepfakes en los que los ejecutivos hablan de su propia empresa y anuncian, por ejemplo, la insolvencia de la empresa. Amenazando con enviar el material a los medios de comunicación o publicarlo en las redes sociales.

¿Cómo se pueden detectar y prevenir los ciberataques deepfake?

En cuanto a los ciberataques deepfakes que ingresan a la empresa a través de correo electrónico, existe la posibilidad de que los filtros de spam y malware bloqueen el email y eviten que se abran los archivos de audio o vídeo adjuntos o vinculados. Sin embargo, los filtros no son capaces de reconocer deepfakes per se, pero pueden analizar los mensajes, por ejemplo, para determinar si el dominio, la dirección IP o el remitente está en la lista negra o si contienen vínculos o archivos adjuntos maliciosos.

Cuanto más concentrado e individual sea el atacante, mayor será la probabilidad de que el ataque alcance su objetivo. El ciberataque se vuelve particularmente peligroso si se lleva a cabo por teléfono o videollamada, ya que no existen mecanismos de seguridad que puedan intervenir en este caso.

Por lo tanto, los expertos en seguridad informática de Hornetsecurity hacen hincapié en que es crucial sensibilizar a los empleados y gerentes de las empresas sobre este nuevo escenario de ciberamenazas. Sólo teniendo un elevado nivel de conciencia, podremos proporcionar una protección efectiva para este tipo de ciberataques.