El arte de la ocultación: una nueva campaña de Magecart explota 404 páginas
Resumen ejecutivo
El grupo de inteligencia sobre seguridad de Akamai detectó una campaña de robo de información web de Magecart dirigida a una amplia lista de sitios web, incluidas grandes organizaciones de los sectores alimentario y minorista.
Esta campaña destaca por sus tres técnicas avanzadas de ocultación, una de las cuales nunca habíamos visto antes (en concreto, consiste en manipular la página de error 404 predeterminada del sitio web para ocultar código malicioso), que plantea desafíos únicos para la detección y la mitigación.
Las otras dos técnicas de ocultación muestran las tácticas cambiantes que utilizan los atacantes para evitar la detección y alargar la cadena de ataque.
A medida que los ataques de robo de información web se vuelven cada vez más sofisticados, las organizaciones deben permanecer atentas y explorar enfoques avanzados para protegerse contra estas amenazas en constante evolución.
Introducción
Una nueva campaña de robo de información web de Magecart, sofisticada y encubierta, ha sido dirigida a los sitios web de Magento y WooCommerce. Algunas de las víctimas de esta campaña están asociadas con grandes organizaciones de los sectores alimentario y minorista.
Las pruebas que hemos descubierto revelan que esta campaña ha estado activa durante un par de semanas y, en algunos casos, incluso más tiempo. Esta campaña consiguió sorprendernos con una técnica de ocultación de alto nivel que no habíamos detectado previamente.
La nueva campaña
Los ataques de Magecart suelen comenzar explotando las vulnerabilidades de los sitios web objetivo o infectando los servicios de terceros utilizados por estos sitios web. En esta campaña, todos los sitios web de las víctimas que detectamos fueron explotados directamente, ya que el fragmento de código malicioso se inyectó en uno de sus recursos propios.
En algunos casos, el código malicioso se insertaba en las páginas HTML; en otros casos, se ocultaba en uno de los scripts propios que se cargó como parte del sitio web.
Al igual que en muchas otras campañas de Magecart, la infraestructura de ataque de esta campaña consta de tres partes principales: cargador, código de ataque malicioso y exfiltración de datos (Figura 1).
Cargador : fragmentos de código JavaScript cortos y ocultos responsables de cargar el código malicioso completo del ataque
Código de ataque malicioso : código JavaScript principal que ejecuta el ataque; detecta entradas confidenciales, lee los datos, interrumpe el proceso de tramitación de compra e inyecta formularios falsos
Exfiltración de datos : método que se utiliza para transmitir los datos robados al servidor de mando y control (C2) del atacante
El propósito de dividir el ataque en tres partes es ocultarlo de forma que resulte más difícil detectarlo. Esto permite la activación del flujo completo del ataque solo en las páginas específicas a las que va dirigido; es decir, debido a las medidas de ocultación utilizadas por el atacante, la activación del flujo completo de ataque solo puede producirse donde el atacante pretendía ejecutarlo. Esto hace que el ataque sea más discreto y más difícil de detectar por parte de los servicios de seguridad y las herramientas de análisis externas que podrían estar instaladas en el sitio web al que va dirigido el ataque.
Aunque la mayoría de las campañas de Magecart comparten similitudes en lo que respecta al flujo y las etapas, lo que diferencia a una campaña de otra son las diversas técnicas de ocultación que emplean los atacantes. Estas técnicas se utilizan para ocultar la infraestructura del ataque, ocultar los rastros, complicar la detección, aplicar ingeniería inversa y, en última instancia, prolongar el ataque.
Tres variaciones de la campaña
Hemos detectado tres variaciones diferentes de esta campaña, lo que demuestra la evolución del ataque y las mejoras que los atacantes han realizado a lo largo del tiempo para evitar la detección y mitigación de esta campaña:
Las dos primeras variaciones son bastante similares, solo con diferencias menores en la parte del cargador.
La tercera versión es única porque los atacantes utilizaron la página de error 404 predeterminada del sitio web para ocultar su código malicioso; se trata de una técnica de ocultación creativa que nunca habíamos visto antes.
Echemos un vistazo más de cerca a los detalles técnicos de las tres variaciones de esta campaña.
Variación uno
Nuestra investigación comenzó cuando detectamos algunos fragmentos de código sospechosos, detectados por nuestras herramientas de supervisión de inteligencia contra amenazas, en el sitio web de una empresa importante. Al analizar estos fragmentos, descubrimos que eran cargadores JavaScript con codificación maliciosa que todavía estaban presentes y activos en el sitio web. Este descubrimiento nos llevó a investigar más a fondo, revelando toda la campaña con sus variaciones e impacto en numerosos sitios web.
El cargador de la variación uno: la punta del iceberg
El ataque de robo de información inyectó correctamente una etiqueta de imagen HTML incorrecta con un atributo onerror en el sitio web explotado (Figura 2). Este atributo contiene un fragmento de código oculto de cargador malicioso codificado en Base64. El atributo src intencionadamente vacío de la etiqueta de imagen está diseñado para evitar solicitudes de red y activar la ejecución de una devolución de llamada onerror en línea que contiene el fragmento de código JavaScript malicioso oculto.
El uso de etiquetas de imagen para ejecutar código JavaScript es una técnica menos común y más sofisticada. Puede ser de ayuda para que el ataque de robo de información eluda las medidas de seguridad, como los analizadores externos que normalmente analizan el tráfico de red, los cuales no se activan en este caso específico. El código oculto se ejecutará en el contexto de la página como si fuera un script nativo propio iniciado por la propia página.
Fig. 2: Cargador de la variante uno (etiqueta de imagen HTML con formato incorrecto con un atributo onerror que contiene código de cargador malicioso)
Código de cargador descodificado: tiempo de ejecución
Una vez que se ha ejecutado el código oculto codificado en Base64 en tiempo de ejecución, este se transforma en JavaScript sencillo y pasa a ser el responsable de iniciar un canal WebSocket (figura 3). Este canal sirve como enlace de comunicación bidireccional entre el navegador y el servidor C2 del atacante.
Se ha observado el uso de WebSockets en los ataques de Magecart en varias campañas recientes. WebSocket se considera un método de comunicación más silencioso y flexible, lo que permite al atacante utilizar un solo canal de red para diversos fines. Esto incluye enviar diferentes partes del ataque del servidor C2 al navegador (y viceversa), así como facilitar las actividades de exfiltración de datos en determinados escenarios.
Otro aspecto destacable del código es la detección de bots, que comprueba si el agente de usuario está bajo control de automatización. Si este es el caso, el código termina su ejecución. Se trata de una técnica antibots inteligente destinada a evitar los analizadores y los entornos de pruebas de seguridad externos que podrían detectar el ataque.
Fig. 3: Código JavaScript descodificado en tiempo de ejecución del cargador de la variante uno
Flujo de comunicación de WebSocket
Una vez establecido el canal WebSocket, el primer mensaje se envía desde el servidor C2 del atacante al navegador. Este mensaje se transmite como una cadena codificada en Base64, que contiene un comando JavaScript de una línea que indica al explorador que devuelva la dirección URL actual de la página.
El propósito de este paso es habilitar el servidor C2 para determinar si la página actual es una página de tramitación de compra (confidencial) o cualquier otra página que no sea de tramitación de compra. De este modo, el atacante puede ajustar los siguientes pasos en consecuencia.
Esta sencilla validación en el servidor permite al atacante activar el ataque solo en las páginas relevantes a las que va dirigido, evitando así la posible exposición en páginas no confidenciales. Este es otro ejemplo que pone de relieve los esfuerzos que realiza el ataque de robo de información para eludir la detección por parte de los servicios de seguridad y los analizadores externos.
Cuando el servidor C2 identifica una URL de página de tramitación de compra, el flujo continúa a la siguiente fase. En este paso, se envía otro mensaje al navegador. Es una cadena larga codificada en Base64, que contiene todo el código de ataque. Una vez descodificado, se revela un código JavaScript largo y oculto (Figura 4).
Este código es responsable de llevar a cabo diversas actividades maliciosas en la página confidencial a la que va dirigida el ataque con el propósito de leer los datos confidenciales personales y de la tarjeta de crédito del usuario y transmitirlos de vuelta al servidor C2 del ataque de robo de información.
Los siguientes mensajes de exfiltración de datos ocultos que contienen los datos confidenciales robados recopilados por el código malicioso se envían del navegador al servidor C2. Como se ha mencionado anteriormente, el uso del mismo canal WebSocket para cargar el código malicioso completo y exfiltrar los datos robados hace que el proceso sea más silencioso e implica menos solicitudes de red que los métodos de comunicación más tradicionales, como las solicitudes de recursos HTML, XHR o de recuperación.
Fig. 4: Flujo de WebSocket en páginas de tramitación de compra
Variación dos
El cargador de la variación dos: misma dama, vestido nuevo
La principal diferencia entre la variación uno y la dos reside en el componente cargador. En la variación dos, el ataque de robo de información inserta un script en línea con un fragmento de código que se asemeja bastante al fragmento de código de Meta Pixel, un conocido servicio de seguimiento de la actividad de los visitantes de Facebook, con algunas líneas adicionales en su interior (Figura 5).
Estas líneas añadidas son la parte real del cargador, mientras que el código de Meta Pixel que le rodea es una cubierta engañosa para que parezca que es un fragmento de código legítimo y no sospechoso.
Esta técnica de ocultación, que hace que los fragmentos de código malicioso parezcan servicios conocidos, como Google Tag Manager o Facebook, ha adquirido popularidad en campañas recientes de Magecart. Permite que los ataques de robo de información eludan el análisis estático que realizan analizadores e investigadores externos.
Fig. 5: Cargador de la variante dos (script en línea disfrazado de fragmento de código de Meta PIxel con un cargador malicioso en su interior)
Solicitud de una imagen
Cuando inspeccionamos cuidadosamente las líneas sospechosas dentro del falso fragmento de código Meta Pixel, parecía que recuperaba una imagen PNG del directorio del sitio web. La solicitud de red parecía una solicitud típica de una imagen inocente alojada en el sitio web. Sin embargo, cuando examinamos el contenido real de esta imagen, quedó claro que no era tan inocua como parecía (Figura 6).
Fig. 6: Solicitud de imagen de red para una imagen que ha sido manipulada por el atacante y que contiene código malicioso
Fragmento de código JavaScript malicioso dentro de un binario de imagen
Los datos binarios de la imagen PNG contienen una cadena codificada en Base64 adjunta al final del archivo binario de imagen (Figura 7). Posteriormente, el fragmento de código del cargador extrae esta cadena, la descodifica y la ejecuta (figura 8). La cadena descodificada representa un fragmento de código JavaScript idéntico al que se encuentra en el atributo onerror del cargador en la variación uno.
Los pasos posteriores del flujo permanecen sin cambios. Este fragmento de código se transforma en código JavaScript sin formato en tiempo de ejecución, el código inicia el canal WebSocket en el servidor C2 del atacante y el resto de la secuencia le sigue como se ha descrito anteriormente.
Fig. 7: Datos binarios de la imagen que contiene el código malicioso oculto
Fig. 8: El código malicioso, que inicialmente se codificó en Base64 y se ocultó dentro de la imagen, aparece después de la descodificación
Variación tres
Pasemos ahora a la mejor parte. Aunque hemos visto ataques similares, este es único y nos sorprendió bastante.
El cargador de la variación tres: igual, pero totalmente diferente
A primera vista, este cargador parece similar al cargador de la variación dos, pero podrá observar (como hicimos nosotros) que se trata de un escenario completamente diferente. En algunos casos, este cargador se disfraza de fragmento de código de Meta Pixel, como se observa en la variación dos (Figura 9). Pero en otros casos, se inyecta en scripts aleatorios en línea en la página (Figura 10).
El primer aspecto destacado de este cargador es una solicitud de recuperación a una ruta relativa denominada 'icons'.
Fig. 9: Cargador de la variación tres (fragmento de código malicioso oculto dentro de un fragmento de código que imita el aspecto de Meta Pixel)
Fig. 10: Cargador de la variación tres (fragmento de código malicioso oculto dentro de un script en línea arbitrario)
¿Un error 404? ¿En serio?
Después de ejecutar el cargador, el ataque envía una solicitud de recuperación a /icons, que es una ruta relativa que no existe realmente. Esta solicitud generó el error "404 Not Found" (Figura 11). Al realizar el análisis del HTML devuelto en la respuesta, este parecía la página 404 predeterminada del sitio web (Figura 12). Esto resultaba confuso y nos hizo preguntarnos si el ataque de robo de información ya no estaría activo en los sitios web de víctimas que detectamos.
Fig. 11: Solicitud iniciada por el cargador a una ruta inexistente que devuelve el error 404
Fig. 12: HTML de página de error predeterminada
Nunca se debe subestimar al cargador
Dimos un paso atrás para volver a analizar el cargador y encontramos la pieza que faltaba del rompecabezas. El cargador contenía una coincidencia de regex para la cadena "COOKIE_ANNOT", que se suponía que debía realizarse en la página de error 404 devuelta como parte de la solicitud icons.
Así pues, realizamos la búsqueda de esta cadena dentro del HTML 404 devuelto y ¡voilá! Descubrimos un comentario oculto al final de la página que contenía la cadena "COOKIE_ANNOT" (Figura 14). Junto a esta cadena se concatena una cadena larga codificada en Base64. Esta cadena codificada representa el código de ataque JavaScript completo oculto. El cargador extrae esta cadena del comentario, la descodifica y ejecuta el ataque, que está diseñado para robar la información personal introducida por los usuarios.
Simulamos solicitudes adicionales a rutas inexistentes y todas devolvieron la misma página de error 404 que contenía el comentario con el código malicioso codificado. Estas comprobaciones confirman que el atacante modificó eficazmente la página de error predeterminada de todo el sitio web y ocultó el código malicioso en ella.
Fig. 13: Variación tres del cargador (coincidencia de regex para la cadena "COOKIE_ANNOT")
Fig. 14: Comentario codificado malicioso que estaba oculto en el HTML de la página de error
Exfiltración de datos
Formulario falso
A diferencia de las variaciones uno y dos, los atacantes emplearon una técnica de exfiltración de datos común diferente en la variación tres: la inyección de un formulario falso (Figura 15). Esta técnica se utiliza normalmente cuando el ataque de robo de información carece de acceso a entradas confidenciales.
Esto puede ocurrir cuando un sitio web utiliza un servicio de pago de terceros que implementa el formulario de pago dentro de un iframe de terceros o una página externa. Para evitar estos escenarios, el atacante crea un formulario falso que se asemeja mucho al formulario de pago original y lo superpone (una técnica que está adquiriendo más popularidad). Así es exactamente como se exfiltran los datos robados en la variante tres.
Fig. 15: Formulario falso inyectado por el código malicioso
Cuando el usuario envía datos al formulario falso del atacante, se presenta un error, el formulario falso se oculta, se muestra el formulario de pago original y se solicita al usuario que vuelva a introducir sus datos de pago (Figura 16).
Fig. 16: El formulario falso se oculta y se solicita al usuario que vuelva a introducir su información
Solicitud de imagen con datos robados
El envío del formulario falso inicia una solicitud de red de imagen al servidor C2 del atacante, que lleva toda la información personal y de la tarjeta de crédito robada como una cadena codificada en Base64 en el parámetro de consulta (figura 17). Cuando se descodifica, esta cadena revela la verdadera intención de la solicitud y se ve claramente el flujo de ataque completo.
Fig. 17: Solicitud de red de imagen con los datos robados incluidos como un parámetro de consulta de cadena codificada en Base64
Lecciones extraídas de la variación tres: el caso 404
Esta técnica de ocultación es sumamente innovadora y algo que no hemos visto en anteriores campañas de Magecart. La idea de manipular la página de error 404 predeterminada de un sitio web específico puede ofrecer a los ciberdelincuentes de Magecart varias opciones creativas para mejorar la ocultación y la evasión.
En algunos de los casos que hemos identificado, el cargador malicioso ya se había eliminado de las páginas de los sitios web afectados en el momento de la redacción de este documento. Sin embargo, el comentario malicioso permanecía en la página predeterminada 404, lo que podría permitir que el ataque de robo de información se reactivara fácilmente. Esto pone de relieve la complejidad de la detección, y la importancia de la mitigación, de este enfoque.
La solicitud a la ruta propia que lleva a la página 404 es otra técnica de evasión que puede eludir los encabezados de la política de seguridad de contenido y otras medidas de seguridad que puedan estar analizando activamente las solicitudes de red en la página. Sin duda, esta es una de las estrategias más sofisticadas de Magecart que hemos detectado recientemente.
Client-Side Protection & Compliance de Akamai frente al ataque de robo de información
Como parte de nuestra investigación en esta campaña, realizamos una simulación de este ataque de robo de información frente a nuestra solución Client-Side Protection & Compliance de Akamai, que analiza el comportamiento de ejecución de JavaScript en tiempo de ejecución para defenderse de amenazas JavaScript y mitigar los ataques al cliente.
La solución detectó correctamente el sofisticado ataque de robo de información y activó un evento de gravedad alta para su mitigación inmediata. En un escenario real en el que Client-Side Protection & Compliance está activado en una página web concreta, la Figura 18 ilustra la alerta que recibiría el propietario del sitio web para poder investigar rápidamente la amenaza y responder en tiempo real con varias opciones de mitigación.
Fig. 18: Alerta de simulación de Client-Side Protection & Compliance después de detectar el ataque de robo de información
Conclusión
Esta campaña refuerza el hecho de que las técnicas de robo de información web evolucionan constantemente. Estas son cada vez más sofisticadas, lo que hace que la detección y la mitigación mediante análisis estáticos y análisis externos sean cada vez más difíciles. Los atacantes de este dominio siempre encuentran mejores métodos para ocultar sus ataques en los sitios web de las víctimas y consiguen eludir las diferentes medidas de seguridad que podrían exponerlos.
El nivel de complejidad en el que se hace hincapié en esta investigación debería recordar a las organizaciones que deben mantenerse atentas a los vectores de ataque de robo de información web y que deben buscar de forma activa enfoques nuevos y avanzados para hacer frente a este tipo de ataques.
IoC
Pmdresearch[.]com
secures-tool[.]com
adsometric[.]com
cngresearch[.]com
