El día a día trabajando en ciberseguridad en el lado defensivo puede ser muy monótono a veces: descubre IOC (Indicador de Compromiso), carga IOC, generar indicadores; revisar alerta, marcar alerta como falso positivo, buscar culpable de falso positivo, etc.
Pero de repente aparecen una joyitas que, a veces son detalles chicos, son interesantes de compartir con todos como por ejemplo esta campaña de “Web Skimming” que no la habíamos visto antes y no hemos detectado ningún otro sitio que este afectado (todavía).
Como comenzó todo
Esta joyita aparece por una alerta de IOC (Indicador de Compromiso). En un principio parece algo totalmente aleatorio, pero la alerta era de un dominio catalogado en Virustotal como malicioso:
Como VT es “dios” y todo lo que diga hay que tomarlo literalmente como la palabra infalible (favor noten el sarcasmo), se había agregado en el pasado dentro de los listados de dominios a bloquear. Gracias a eso esta alerta apareció como un “hecho prevenido” por nuestros sistemas de seguridad.
Lamentablemente quise averiguar un poco más allá del porqué saltó la alerta y del porqué este sitio estaba calificado como malicioso.
Lo primero que validé son las IPs del dominio y pude ver que es el típico sitio que está siendo distribuido por Cloudflare, por lo que no se puede sacar ninguna conclusión inicial:
Lo otro que intenté buscar fue el origen de la llamada, pero el sistema que alertó no es muy amigable, solo nos dice que fue el proceso de Chrome.exe que gatilló el intento de navegación al sitio y fue bloqueado, pero como no teníamos más información “rápidamente” tuvimos que buscar en el proxy.
Fue ahí cuando encontramos que había sido una llamada a una URL un poco más completa:
https://pixelqiwiwallet.top/outletseagarden/metrics.jsEsta URL parecía muy “normal”, con el nombre de “metrics.js” parecía una URL de analítica que carga un archivo Javascript que solamente busca analizar los visitantes del sitio. De hecho, estaba incrustada directamente en el código fuente del sitio de origen:
Aún así, con un poco más de tranquilidad, me di el trabajo de querer revisar el contenido del Javascript, capaz que sea algo inocuo, pero algo me decía que no me podía quedar solamente con el nombre del archivo, entonces había que mirar el archivo.
Mirando el archivo Javascript
Al descargar el archivo me encuentro con algo bastante “feo”, y este tipo de cosas siempre pintan para algo mal:
Como podemos notar, existe un código que sí es Javascript, pero tiene muchas variables con valores en su representación hexadecimal (por ejemplo los “\x20” son espacios), además complican mucho el análisis superficial que quería hacer con referencias enredadas a las variables que están usando por lo que tenía que darle una vuelta por otro lado.
Aquí es donde uno agradece el trabajo realizado anteriormente por la comunidad y usé un defuscador de Javascript bastante bueno llamado “synchrony” que lo pueden encontrar acá: Versión Online o Github.
Gracias a su excelente ayuda podemos tener algo mucho más legible, que además nos aporta mucho al objetivo final del código. Por ejemplo tenemos los siguientes extractos:
Esto nos indica cosas bien interesantes, por ejemplo, si parafraseamos el código anterior:
- Cada segundo, valida si es que se cumple la función de “allChecked”, y además se encuentra en el flujo de webpay, si es así ejecuta la función “renderForm”
- Además, valida si es que no existe el botón de envío de formulario, lo crea con la función “renderBtn”.
Además, en la función de “renderForm” existe por supuesto una inclusión de código HTML que lamentablemente al revisarlo podemos ver que es un típico formulario de “ingrese su tarjeta de con todos los datos acá por favor”
Además, otra cosa interesante es que estos campos, están siendo constantemente guardados en el localstorage, para poder tomarlos en cualquier momento en el futuro:
Luego la función “renderBtn” también tiene contenido interesante, al botón original de generar compra (o “place_order”) le agregan un funcionamiento:
Este botón ahora carga toda la información guardada en el localStorage (incluido los datos de tarjeta guardados en el formulario anterior), y los envía a la variable “url5555” que la encontramos al inicio del código deofuscado:
El sitio de recolección de datos
Si vemos la información que tiene públicamente nuestra biblia de Virustotal tenemos que éste tiene que ser malicioso:
Además, también podemos ver que el sitio está siendo distribuido por Cloudflare:
Al analizar un poco más el sitio de recolección de datos me parece interesante, porque justamente no tiene mucha información. Por ejemplo tiene un login:
Lo extraño es que al analizar el sitio original con el archivo .js, tenemos el mismo login y en la misma ruta:
Lo que llama aún más la atención es que si buscamos la ruta del archivo metrics.js que revisamos anteriormente está en ambos dominios.
Esto nos da para pensar que para ambos dominios está respondiendo el mismo servidor web por detrás.
Sobre los sitios afectados
No hicimos mucho hincapié con el sitio inicial en donde se generó la conexión y que asumimos que está infectado para no generar repercusión negativa contra el sitio, que al parecer es de una pyme o empresa pequeña en Chile.
Si buscamos algún otro sitio que puede estar infectado con este mismo “payload” vemos que las interacciones con estos dominios son muy pocas, por lo que es una campaña que está comenzando o que por lo menos no ha sido muy masiva.
Lo que sí podemos concluir es que por lo menos comenzó en Octubre del 2025 porque es la fecha de la primera interacción encontrada en la infección de un sitio de Filipinas.
¿Será una campaña internacional?
Conclusiones iniciales
Creemos que esta es una campaña nueva de un ataque bastante viejo (Web Skimming) que lo llaman Magecart, por asociación al nombre que se le dió a varios colectivos antiguos que usaban o abusaban de esta técnica (para los asiduos a Mitre, sería la T1119).
Como pueden ver esta es una campaña que aún no se termina de investigar completamente, y que tiene muchas aristas interesantes que seguir investigando, por ejemplo:
- Sobre las víctimas:
- ¿Cuántas personas fueron afectadas?
- ¿Cuántas tarjetas se han podido llevar?
- Sobre los atacantes
- ¿Quién(es) está(n) detrás de este ataque?
- ¿De donde es (son) los atacantes? ¿Son extranjeros? (lo más probable)
- Sobre la arquitectura
- ¿Qué otros dominios están siendo servidos por el mismo servidor web?
- ¿Cuáles son los otros endpoints de la API?
- ¿Cuál es la contraseña de ese login? ¿Qué hace esa plataforma? ¿Es un panel de administración?
Son preguntas que, si es que tienen respuesta, las tendremos en un siguiente artículo.
Como siempre, los IOCs los tenemos compartidos publicamente con nuestro repositorio en el siguiente link: https://ioc.finsin.cl/
Muchas gracias por leer hasta acá.
FINSIN 
Deje un comentario