"Microsoft Clairty" no es Microsoft Clarity: desofuscando un script de fraude publicitario por typosquatting

Una extensión de navegador está inyectando JavaScript ofuscado desde msclairty[.]com, un dominio de typosquatting que suplanta a Microsoft Clarity. El script elimina cookies de Google Analytics, rellena cookies de afiliados con el valor pub=twsc, inyecta iframes ocultos hacia discounthero[.]org y secuestra la Fetch API. Sorprendentemente, ninguna herramienta de seguridad marca este dominio. Esta es la primera documentación pública de msclairty[.]com.

¿Qué es msclairty[.]com?

msclairty[.]com es un dominio de typosquatting diseñado para suplantar a Microsoft Clarity (msclarity[.]com / clarity[.]ms), la popular herramienta de analítica y mapas de calor de Microsoft. Dicho de forma sencilla: las letras «i» y «r» en «clarity» se intercambian para crear «clairty», lo que resulta lo suficientemente sutil como para pasar desapercibido en un vistazo rápido a un registro de red o a una etiqueta de script sin levantar sospechas.

El dominio no sirve analítica. En cambio, entrega un payload de JavaScript ofuscado que realiza cookie stuffing de afiliados, eliminación de cookies de seguimiento y secuestro de la Fetch API dentro del navegador del visitante.

¿Cómo se descubrió este script?

En las últimas 48 horas, comenzamos a observar solicitudes de red hacia msclairty[.]com en múltiples sitios web no relacionados dentro de nuestra telemetría. La primera solicitud que registramos fue el 2 de marzo de 2026 a las 21:17 UTC, con un tráfico que aumentó bruscamente durante la mañana del 3 de marzo. El tráfico no proviene de una etiqueta de script comprometida en el código fuente de la página. En cambio, lo inyecta una extensión de navegador. Aún no hemos identificado la extensión específica responsable, pero el patrón de inyección es consistente en todos los sitios afectados: mismo payload ofuscado, mismo dominio, mismo comportamiento, independientemente del inventario de scripts propio del sitio.

El denominador común es el navegador del usuario final, no el código del sitio.

Observamos que el script afecta a sitios de múltiples industrias no relacionadas, incluyendo transporte (como plataformas de reserva de vuelos), plataformas SaaS (como herramientas de gestión de proyectos), portales de gestión deportiva y portales de pago gubernamentales. Los visitantes afectados abarcan múltiples versiones de Chrome (132, 138 y 145) y se originan desde direcciones IP estadounidenses tanto de la costa este como de la oeste. Cada sitio afectado carga el mismo identificador de campaña event.js y recibe el mismo hash de payload, lo que confirma que se trata de una única campaña coordinada que se ejecuta a través de una sola extensión de navegador.

Los IDs de campaña rotan diariamente. Por ejemplo, el 2 de marzo, la URL del loader era event.js?id=dHRcSiYkDj4&date=2026-03-02. El 3 de marzo apareció un nuevo ID de campaña: event.js?id=XGp2NSkTRVs&date=2026-03-03. El parámetro date= coincide con la fecha de cada rotación de campaña. Esto significa que la infraestructura se mantiene activamente y despliega identificadores de campaña nuevos cada día.

Todos los usuarios afectados comparten el mismo fingerprint. En todas las solicitudes de nuestra telemetría, el perfil del navegador es idéntico: Windows 10 x64, Google Chrome de escritorio, sin dispositivos móviles. Ni una sola solicitud proviene de Firefox, Safari, Edge, Brave, macOS, Linux, Android ni iOS. Esta es una extensión exclusiva de Chrome. Las client hints sec-ch-ua confirman Chrome real (no forks de Chromium que reportan de forma diferente), y sec-ch-ua-mobile: ?0 confirma escritorio en cada solicitud. Observamos solo 5 IPs de visitantes únicos en todos los sitios afectados, todas en conexiones residenciales de EE. UU.

El ataque completo sigue un patrón de carga en dos etapas en el que el servidor toma decisiones de segmentación por solicitud sobre qué payload entregar.

Etapa 1: Script loader (event.js)

hxxps://msclairty[.]com/event.js?id=dHRcSiYkDj4&date=2026-03-02
hxxps://msclairty[.]com/event.js?id=XGp2NSkTRVs&date=2026-03-03

El loader event.js pesa 8.599 bytes. El parámetro id= es un identificador de campaña que rota diariamente. El 2 de marzo, el ID de campaña era dHRcSiYkDj4. El 3 de marzo cambió a XGp2NSkTRVs. El parámetro date= coincide con la fecha de cada rotación. El primer loader que capturamos fue modificado por última vez el 2 de marzo de 2026 a las 09:58:50 GMT.

Desofuscamos el loader y encontramos que hace lo siguiente:

1. Secuestro de consola. Sobreescribe los 7 métodos de consola (log, warn, info, error, exception, table, trace) inmediatamente al cargar, antes de que se ejecute ningún payload. Esto significa que cualquier intento de depurar o registrar información queda silenciosamente bloqueado.
2. Comprobación anti-iframe. Compara window.self con window.top y sale si el loader se ejecuta dentro de un iframe. Esto garantiza que solo se ejecute en el contexto de navegación de nivel superior, evitando entornos de análisis o sandbox que usan iframes.
3. Comprobación de cookie de deduplicación. Lee la cookie __tr_luptv usando un helper getCookie(). Si la cookie ya existe, el loader sale. Esta cookie es establecida por el payload tras ejecutarse y cumple dos propósitos: atribución del atacante para el fraude de comisiones y una guardia de «no ejecutar dos veces» que evita la ejecución repetida entre cargas de página.
4. Solicitud de segmentación del lado del servidor. Envía un POST a msclairty[.]com con Content-Type: application/x-www-form-urlencoded que contiene cuatro parámetros: url (la URL de la página actual), referrer (document.referrer), unique_id (el ID de campaña del parámetro id=) y ext: 'twsc' (el identificador de afiliado del atacante, codificado de forma fija). El servidor responde con JSON que contiene un campo data (el nombre de archivo codificado en Base64 para el payload) y un campo type (qué variante ?type= cargar).
5. Inyección dinámica de payload. Construye la URL de la Etapa 2 concatenando la respuesta del servidor: https://msclairty[.]com/js/ + response.data + .js?type= + response.type, crea un elemento <script>, establece su src en esta URL y lo añade a document.head. Esto carga dinámicamente el payload malicioso según las instrucciones del servidor.
6. Hooks de navegación SPA. Hace monkey-patching de history.pushState y history.replaceState para despachar eventos personalizados locationchange, y escucha popstate. En cada navegación del lado del cliente en una aplicación de página única, el loader vuelve a ejecutar la función Info() con la nueva URL, dando al servidor otra oportunidad de entregar un payload. Un debounce de 500 ms (semáforo wait_nw) evita la re-ejecución rápida en cambios de ruta veloces.

El servidor decide el ataque, no el script. El loader envía la URL de la página y el referrer, y el servidor responde con el nombre de archivo del payload codificado y el valor ?type=. Esto significa que diferentes sitios, diferentes páginas o diferentes referrers pueden recibir variantes de payload distintas. Por ejemplo, una página de producto podría recibir type=1 (cookie stuffing silencioso) mientras que una página de pago podría recibir type=5 (redirección forzada). La lógica de segmentación es completamente del lado del servidor e invisible para el análisis del lado del cliente.

Etapa 2: Payload ofuscado

hxxps://msclairty[.]com/js/[Base64-encoded-blob].js?type=[1-5]

El payload pesa 10.007 bytes. El nombre de archivo similar a Base64 se genera en el servidor basándose en la URL de la página y el referrer enviados por el loader. El parámetro ?type=, también elegido por el servidor, selecciona cuál de las cinco variantes de ataque se ejecuta. La función dentro de cada payload recibe un nombre que coincide con su variante (type1(), type2(), type8(), type9(), type11()).

¿Qué herramientas de seguridad marcan msclairty[.]com?

Ninguna. Comprobamos todas las principales plataformas de inteligencia de amenazas y herramientas de seguridad disponibles. A fecha de publicación, ni una sola marca msclairty[.]com como malicioso:

• VirusTotal: 0 de más de 90 detecciones de motores
• urlscan.io: sin resultados de escaneo, sin envíos de la comunidad
• Google Safe Browsing: no marcado
• SecurityTrails: sin historial DNS, sin enriquecimiento WHOIS
• ANY.RUN: sin envíos de sandbox para este dominio
• Hybrid Analysis / Falcon Sandbox: sin resultados
• PhishTank: no listado
• OpenPhish: no listado
• MalwareBazaar: sin muestras
• ThreatFox (abuse.ch): sin entradas de IOC
• Cloudflare Radar: sin datos

Cobertura cero en todas las principales plataformas. En pocas palabras, esta publicación es la primera documentación pública de este dominio siendo utilizado con fines maliciosos.

Cómo cside detectó este script

cside detectó este script de forma autónoma mediante análisis de comportamiento en tiempo de ejecución. Ningún feed de amenazas marcó el dominio. Ningún escáner devolvió el payload. Ninguna firma coincidió. La detección se basó íntegramente en lo que el script hacía dentro del navegador: eliminar cookies de seguimiento, inyectar un iframe oculto, secuestrar la Fetch API y suprimir la consola.

Los scripts de extensiones de navegador están fuera de tu control como propietario de un sitio web. No puedes evitar que una extensión inyecte código en tus páginas. Pero es útil saber que el abuso está ocurriendo. Por ejemplo, el script elimina la cookie de atribución legítima de RedTrack (rtkclickid-store) y la reemplaza con el propio token de afiliado del atacante pub=twsc a través de la cadena de redirección de discounthero[.]org. Si usas RedTrack para el seguimiento de conversiones de afiliados o dependes de una atribución de tráfico precisa, este tipo de fraude roba activamente comisiones de tus afiliados legítimos y nunca lo verías sin visibilidad del lado del cliente.

Usa cside para entender cómo se comporta tu aplicación en el navegador. Detecta señales de fraude por parte de visitantes, agentes de IA y dependencias del lado del cliente.

cside ha compartido esta inteligencia con Microsoft para que puedan proceder con la eliminación de msclairty[.]com por typosquatting malicioso de su marca Clarity. También nos hemos puesto en contacto con RedTrack, ya que su cookie de atribución rtkclickid-store está siendo explícitamente atacada para su eliminación en este ataque y el token de afiliado pub=twsc se está utilizando para reemplazar la atribución legítima de clics de RedTrack con reclamaciones de comisiones fraudulentas.

Empieza gratis o reserva una demo para hablar con nuestro equipo.

¿Por qué las herramientas de IA y los escáneres reciben un 403 de msclairty[.]com?

El servidor detrás de msclairty[.]com funciona con un backend Express (Node.js) con Cloudflare por delante. Las cabeceras de respuesta incluyen x-powered-by: Express, cf-cache-status y access-control-allow-origin: *. El payload está cacheado por Cloudflare con un max-age de 14400 segundos (4 horas).

A pesar de estar en Cloudflare, el servidor bloquea activamente el análisis automatizado. Cuando herramientas basadas en IA como ChatGPT, Claude y Perplexity intentan obtener contenido del dominio, el servidor devuelve una respuesta 403 Forbidden. Lo mismo ocurre con los escáneres de seguridad automatizados y cualquier solicitud que provenga de rangos de IP de centros de datos.

Se trata de un filtrado deliberado basado en rangos de direcciones IP, cadenas de user-agent u otras técnicas de fingerprinting de solicitudes. El servidor solo entrega el payload de JavaScript malicioso cuando la solicitud parece provenir de un navegador real con el referrer, user-agent y cabeceras correctos. Las IPs de centros de datos, los user-agents de bots conocidos y las firmas de solicitudes de herramientas de IA quedan todas bloqueadas.

Este comportamiento anti-investigación también explica por qué VirusTotal, urlscan.io y otras plataformas de escaneo devuelven resultados limpios o ningún resultado en absoluto. Nunca reciben el payload real.

¿Qué revelan las cabeceras de solicitud sobre la extensión de msclairty[.]com?

Cada solicitud en nuestra telemetría comparte un fingerprint de navegador idéntico: Windows 10 x64, Google Chrome de escritorio, sec-ch-ua-mobile: ?0. No hay ni una sola solicitud de Firefox, Safari, Edge, Brave ni ningún navegador móvil. Ni macOS, Linux, Android ni iOS.

Esto es significativo. Si la extensión estuviera disponible en el ecosistema Chromium más amplio, esperaríamos ver user-agents de Edge o Brave en la mezcla, ya que ambos admiten extensiones de Chrome Web Store. El hecho de que cada solicitud reporte «Google Chrome» en las client hints sec-ch-ua y en las cadenas estándar de user-agent de Chrome sugiere que esta es una extensión exclusiva de Chrome o que hasta ahora solo ha sido instalada por usuarios de Chrome.

En los datos aparecen tres versiones de Chrome: 132, 138 y 145. Chrome 132 se lanzó en enero de 2025 y ya está desactualizado. Chrome 138 y 145 son más recientes. La distribución entre versiones descarta un exploit específico de versión y es coherente con una extensión instalada voluntariamente que persiste entre actualizaciones de Chrome.

Otros patrones de cabeceras destacables:

La cabecera sec-fetch-storage-access aparece con los valores active y none en las cargas iniciales del script (sec-fetch-dest: script). Esto indica que la extensión interactúa con la Storage Access API, que regula el acceso a cookies entre sitios. Esto es coherente con una extensión que necesita almacenamiento entre sitios para operar su mecanismo de cookie stuffing.

Todas las solicitudes POST usan content-type: application/json con valores de content-length variables que oscilan entre 604 y 10.246 bytes. Estos son los beacons de event.js que envían datos de vuelta a msclairty[.]com. Los tamaños de payload variables sugieren que el script está exfiltrando diferentes cantidades de datos de página o sesión según el contexto de navegación.

La cabecera dnt: 1 (Do Not Track) está presente en las solicitudes de usuarios de Chrome 145 y Chrome 138, pero ausente en Chrome 132. Esta es una preferencia del usuario, no un comportamiento de la extensión, pero confirma que se trata de usuarios reales con navegadores configurados individualmente.

¿Cuándo se registró el dominio msclairty[.]com?

El certificado SSL de msclairty[.]com fue emitido el 20 de febrero de 2026 a las 20:14:54 UTC. Eso es solo 10 días antes de que observáramos por primera vez tráfico en vivo desde este dominio el 2 de marzo. Se trata de un dominio recién registrado, creado específicamente para esta campaña.

Los detalles de registro WHOIS están ocultos detrás de un servicio de privacidad. No existen registros DNS históricos para este dominio en SecurityTrails ni en bases de datos de DNS pasivo.

¿Qué hace el script de msclairty[.]com?

Tras la desofuscación, el script realiza seis acciones distintas. Ninguna de ellas tiene nada que ver con analítica o mapas de calor.

Paso 1: Detección de DevTools

El script comprueba si las herramientas de desarrollo del navegador están abiertas antes de ejecutar nada. Compara window.outerWidth - window.innerWidth y window.outerHeight - window.innerHeight con un umbral de 120 píxeles. También comprueba Firebug y window.chrome.isInitialized.

Si alguna comprobación indica que alguien está inspeccionando la página, el script sale inmediatamente. Solo se ejecuta para usuarios reales, nunca para desarrolladores o investigadores de seguridad.

Paso 2: Secuestro de consola

El script sobreescribe siete métodos nativos de console: log, warn, info, error, exception, table y trace. Los siete son reemplazados por funciones vacías sin operación. Esto evita que aparezcan advertencias o salidas de depuración si alguien abre las DevTools después de que el script se haya cargado.

Una llamada separada a console.clear() se ejecuta con un temporizador de 3 segundos para borrar cualquier cosa que pudiera haberse registrado antes de que la sobreescritura surtiera efecto.

Paso 3: Eliminación de cookies de seguimiento

El script elimina las siguientes cookies tanto a nivel de ruta como a nivel de dominio raíz:

• _ga (ID de cliente de Google Analytics)
• _gid (ID de sesión de Google Analytics)
• rtkclickid-store (atribución de clics de afiliados de RedTrack)

Este es el comportamiento más importante que hay que entender. Al eliminar la cookie rtkclickid-store de RedTrack, el script borra la atribución legítima de clics de afiliados para ese visitante. Al eliminar también las cookies de Google Analytics, elimina cualquier evidencia de cómo llegó el usuario al sitio. La fuente de tráfico real del visitante desaparece por completo. Esto despeja el camino para que el propio token de afiliado del atacante (pub=twsc) se convierta en la única fuente de atribución.

Paso 4: Inyección de iframe oculto y cookie stuffing de afiliados

Se inyecta en el cuerpo de la página un iframe oculto de 1x1 píxel. El iframe carga la siguiente URL:

hxxps://discounthero[.]org/us/s/red_u_plain.php?t=direct&s=287&d=[target]&pub=twsc

El iframe usa referrerpolicy="noreferrer" para suprimir la cabecera de referrer.

Esto es lo que significa cada parámetro de la URL:

• t=direct: marcador de tipo de tráfico
• s=287: identificador de campaña
• d=[target]: el sitio que está siendo defraudado (el valor cambia por sitio víctima)
• pub=twsc: el ID de editor de afiliado del atacante

El valor pub=twsc es la cuenta de afiliado que recibe la comisión fraudulenta. Este es el núcleo del ataque. El iframe oculto carga silenciosamente una cadena de redirección a través de discounthero[.]org que deposita una cookie de afiliado en el navegador del usuario. Si el usuario visita posteriormente el sitio objetivo y realiza una compra, el atacante detrás de pub=twsc obtiene una comisión que nunca generó. La eliminación de cookies en el paso 3 garantiza que no exista ninguna atribución competidora.

Después de 20 segundos, el iframe es eliminado del DOM. No queda ningún rastro visual en la página.

Paso 5: Secuestro de la Fetch API

Dentro del iframe inyectado, el script hace monkey-patching de window.fetch. Cualquier solicitud fetch que contenga nivtrck[.]com (codificado como bml2dHJjay5jb20= en Base64) es silenciosamente bloqueada con una Promise rechazada.

Esto evita que un servicio de seguimiento competidor registre la fuente de tráfico real. El atacante no solo quiere el crédito por la visita; bloquea activamente a otros rastreadores para que no capturen ningún dato de atribución que pudiera entrar en conflicto con su cookie fraudulenta.

Paso 6: Supresión del referrer y cookie de seguimiento del atacante

Se inyecta una etiqueta `` en el `` de la página, suprimiendo las cabeceras de referrer en todas las navegaciones salientes. Esto oculta el fraude de la analítica posterior en el sitio objetivo.

El script también establece su propia cookie de seguimiento:

__tr_luptv = [marca de tiempo actual menos 300000 milisegundos]

El valor de la cookie es Date.now() - 300000 (hora actual menos 5 minutos), establecido tanto en la ruta raíz como en el dominio raíz del sitio. Esta marca de tiempo con fecha retroactiva probablemente señala a la cadena de redirección de discounthero[.]org que el visitante ya ha sido etiquetado y no debe procesarse de nuevo.

¿Cómo está ofuscado el script de msclairty[.]com?

El código utiliza una pila de ofuscación estándar pero efectiva que derrota a la mayoría de las herramientas de análisis estático:

• Un array de cadenas rotado que contiene aproximadamente 95 entradas codificadas en Base64
• Una función decodificadora que traduce índices del array a cadenas legibles en tiempo de ejecución
• Objetos proxy que envuelven llamadas a funciones y referencias a cadenas detrás de nombres de propiedades aleatorizados
• Un bucle de mezcla IIFE que rota el array hasta que una suma de comprobación coincide, asegurando que el decodificador produzca valores correctos

El código ofuscado parece ruido aleatorio. Ninguna herramienta de análisis estático, escáner de firmas ni detección basada en expresiones regulares identificará comportamiento malicioso a partir del código fuente en bruto. Hay que ejecutar el decodificador para ver lo que hace el script.

¿Qué es discounthero[.]org?

discounthero[.]org es el endpoint de redirección de fraude de afiliados utilizado en este ataque. A diferencia de msclairty[.]com, este dominio tiene presencia establecida en múltiples plataformas de inteligencia de amenazas:

• Alojado en infraestructura de AWS en la IP 3.68.5.1 (AS16509, AMAZON-02), geolocalizado en Alemania
• Clasificado como distribuidor de adware por Gridinsoft
• Marcado como malicioso en análisis de sandbox de ANY.RUN con indicadores de phishing Tycoon 2FA
• Apareció en informes de análisis de Falcon Sandbox junto a dominios de fraude publicitario conocidos
• Reportado por usuarios en múltiples foros de navegadores como fuente de redirecciones de malvertising, incluyendo incidentes en los foros de la comunidad Daz3D
• Utiliza el endpoint de redirección red_u_plain.php con parámetros por campaña (s=, d=, pub=, t=)
• La cadena de redirección fluye a través de gracylifestyle[.]com (Cloudflare) hacia d33old9jdtt77h.cloudfront.net (Amazon CloudFront)

¿Qué es nivtrck[.]com?

nivtrck[.]com es el dominio de seguimiento que el script bloquea activamente mediante el secuestro de la Fetch API. Este dominio no tiene documentación pública en ninguna plataforma de inteligencia de amenazas, informes de sandbox ni bases de datos de historial WHOIS. Puede ser un servicio de seguimiento legítimo cuya atribución el atacante quiere suprimir, o puede pertenecer a una operación de fraude competidora.

Indicadores de compromiso (IOCs) de msclairty[.]com

¿Por qué este ataque elude las herramientas de seguridad tradicionales?

Este ataque elude las herramientas de seguridad tradicionales por dos razones: el vector de inyección y las técnicas de evasión.

El script es inyectado por una extensión de navegador, no está incrustado en el código fuente del sitio. Esto significa que las cabeceras de Content Security Policy no lo bloquearán. Las auditorías de etiquetas no lo encontrarán. Las comprobaciones de Subresource Integrity no aplican. Las herramientas de seguridad del lado del servidor no tienen visibilidad sobre lo que una extensión de navegador inyecta en la página en tiempo de ejecución.

Además, el servidor detrás de msclairty[.]com filtra las solicitudes de forma agresiva. Los escáneres de seguridad, las herramientas de investigación basadas en IA y cualquier solicitud desde una IP de centro de datos o un user-agent de bot conocido reciben una respuesta 403 Forbidden. Incluso si un escáner recuperara de algún modo el payload real, el código fuente ofuscado no contiene firmas reconocibles ni patrones maliciosos conocidos que el análisis estático pudiera marcar.

El script también evade la investigación manual. Detecta las DevTools abiertas y sale. Sobreescribe todos los métodos de consola. Elimina el iframe del DOM después de 20 segundos. Limpia la consola después de 3 segundos.

El loader añade otra capa: engancha history.pushState, history.replaceState y popstate para volver a activarse en cada navegación del lado del cliente en aplicaciones de página única. Cada cambio de ruta envía la nueva URL al servidor para una nueva segmentación. Y dado que el servidor decide qué variante de payload entregar basándose en la URL de la página y el referrer, el análisis estático de un único payload capturado no puede revelar el alcance completo de los ataques de los que es capaz la infraestructura.

¿Cómo se detectan ataques de cookie stuffing de afiliados como este?

La detección basada en listas de bloqueo no funciona contra este tipo de ataque. El dominio es demasiado nuevo para que cualquier feed de amenazas lo haya indexado. La ofuscación derrota el análisis estático. El servidor bloquea los escáneres automatizados y las herramientas de IA con respuestas 403.

El único método de detección fiable es el análisis de comportamiento en tiempo de ejecución: monitorizar lo que hacen los scripts dentro del navegador en lugar de analizar su código fuente o comprobar su dominio contra una lista de bloqueo. La eliminación de cookies, la inyección de iframes ocultos, el secuestro de la Fetch API y la supresión de la consola son todos comportamientos observables que son claramente maliciosos independientemente del aspecto del código fuente o del lugar desde donde se cargó el script.

Para esto está diseñada la monitorización de seguridad del lado del cliente en tiempo real.

¿Qué significa el parámetro ?type=?

La URL acepta un parámetro de consulta ?type= que selecciona qué payload de ataque devuelve el servidor. Hemos confirmado cinco variantes. Cada una escala en agresividad. Las cinco comparten el mismo núcleo de evasión: detección de DevTools (sale si están abiertas, umbral de 150 px), secuestro de consola (7 métodos sobreescritos), eliminación de cookies (_ga, _gid, rtkclickid-store a nivel de ruta y dominio raíz), cookie de atribución del atacante (__tr_luptv = Date.now() - 300000), supresión del referrer mediante meta tag y el mismo objetivo de afiliado (discounthero[.]org con pub=twsc y s=287).

El valor del parámetro ?type= (del 1 al 5) es secuencial, pero los nombres de las funciones internas no lo son. Esta discrepancia revela la verdadera escala de la infraestructura.

?type=1 (función type1()) - Cookie stuffing de afiliados silencioso

Inyecta un iframe oculto de 1x1 hacia discounthero[.]org con pub=twsc. El iframe carga la cadena de redirección de afiliados, deposita la cookie del atacante y se autodestruye después de 20 segundos. La Fetch API es secuestrada para bloquear solicitudes a nivtrck[.]com. El visitante no ve nada.

?type=2 (función type2()) - Cookie stuffing + inyección de contenido

Hace todo lo que hace type=1. Luego obtiene una segunda URL desde una variable de plantilla del lado del servidor {{link2}}, crea un segundo iframe oculto de 0x0, escribe el HTML obtenido en él usando contentWindow.document.write() y falsifica la URL del iframe con history.replaceState. El segundo iframe se autodestruye después de 15 segundos. El marcador de posición {{link2}} se rellena en el servidor por objetivo y podría entregar overlays de phishing, inyección de anuncios o manipulación de página.

?type=3 (función type8()) - Secuestro de clics (piggyback)

Sin iframe. Instala un listener de eventos de clic en document.body. Cuando un visitante hace clic en cualquier etiqueta `` con un href que comienza por «http», el script llama a preventDefault() y luego redirige el navegador a la URL original con la redirección de afiliado de discounthero[.]org añadida como parámetro de consulta. El usuario llega igualmente a su destino previsto, pero la navegación pasa por la cadena de redirección del atacante de camino.

?type=4 (función type9()) - Secuestro de clics (redirección directa)

La misma interceptación de clics que type=3, pero la dirección de la redirección está invertida. En lugar de añadir la URL de afiliado al destino original, envía al usuario directamente a discounthero[.]org con la URL original codificada como parámetro usando encodeURIComponent(). El usuario navega visiblemente a través de la infraestructura del atacante primero, y luego es reenviado a su destino previsto después de que se deposite la cookie de afiliado.

?type=5 (función type11()) - Redirección automática (sin clic requerido)

La variante más agresiva. Sin iframe. Sin interceptación de clics. Después de un retraso de 400 milisegundos, el script redirige forzosamente toda la página usando window.location.search. El usuario es automáticamente redirigido desde la página que estaba viendo hacia la cadena de afiliados de discounthero[.]org. No se requiere ninguna interacción. El retraso de 400 ms es justo el tiempo suficiente para que la eliminación de cookies y la cookie __tr_luptv se establezcan antes de que se ejecute la redirección.

Los nombres de las funciones no son secuenciales. El parámetro ?type= va del 1 al 5, pero las funciones se llaman type1, type2, type8, type9 y type11. Los valores superiores a 5 devuelven respuestas en blanco. Los huecos en la numeración de funciones (type3 hasta type7, type10) probablemente reflejan variantes retiradas o obsoletas de iteraciones anteriores de esta infraestructura. Cinco tipos de payload activos, que escalan desde silencioso hasta forzoso.