Cómo un único script de seguimiento redirigió pagos de criptomonedas en toda la web

La tecnología publicitaria es la materia oscura de la internet moderna. Es invisible para el usuario promedio, pero ejerce una influencia masiva sobre cómo fluyen los datos a través de la web. Cuando esta capa invisible falla, el impacto se escala instantáneamente a través de miles de sitios web no relacionados. El 27 de julio de 2026, Adform descubrió que uno de sus principales scripts de seguimiento se había vuelto contra sus usuarios. Un compromiso de la cadena de suministro permitió a los atacantes inyectar código malicioso en un archivo JavaScript ampliamente utilizado, transformándolo en una herramienta que reescribe direcciones de carteras de criptomonedas en tiempo real.

Pasé mi mañana analizando las muestras capturadas del script malicioso. El compromiso afecta a trackpoint-async.js, un archivo servido desde la infraestructura de Adform. Debido a que este script está integrado en los encabezados de aproximadamente 1,800 sitios de clientes para facilitar la analítica publicitaria, los atacantes no necesitaron vulnerar a esas empresas individuales. Simplemente envenenaron el pozo. Una vez que el script alterado se cargaba en el navegador de un visitante, comenzaba a monitorear el modelo de objetos del documento (DOM) en busca de patrones específicos que parecieran direcciones de Bitcoin, Ethereum o Tron.

El riesgo invisible de las dependencias de terceros

La arquitectura web moderna se basa en la confianza implícita en los recursos de terceros. Cuando un desarrollador añade una línea de código para llamar a un script de un proveedor global, le otorga a ese proveedor un control significativo sobre la experiencia del usuario. Este incidente es un ejemplo de libro de texto de un ataque a la cadena de suministro donde se explota la relación de confianza. El script en cuestión, trackpoint-async.js, está diseñado para ejecutarse en sitios web completos o secciones específicas. En este caso, los atacantes añadieron dos bloques de código maliciosos al final de la biblioteca legítima.

Desde una perspectiva de riesgo, este es un escenario de pesadilla para cualquier administrador de sitios. Se puede tener una postura de seguridad perfecta, un servidor endurecido y un proceso riguroso de revisión de código interno, pero un único script externo aún puede comprometer a sus usuarios. Los atacantes evitaron el perímetro de la red entrando por una puerta lateral que casi siempre se deja abierta para las herramientas de marketing y analítica. Esto demuestra por qué el concepto de un perímetro de red es un foso de castillo obsoleto. Si permite que scripts externos se ejecuten con altos privilegios en su sitio, efectivamente ha invitado a un extraño a gestionar su seguridad.

Anatomía del compromiso de trackpoint

El análisis técnico de los bloques maliciosos revela un esfuerzo enfocado en secuestrar transacciones financieras. El código utiliza una clave XOR de seis bytes para ofuscar las direcciones de las carteras de reemplazo, una táctica común para evadir la detección básica basada en firmas. Una vez que el script se ejecuta, inicia dos rutas de ataque distintas. El primer bloque se centra en el portapapeles del sistema. Vigila el evento de copia e intenta leer el portapapeles cada cuatro segundos. Si identifica una cadena que coincide con un patrón de cartera de criptomonedas, reemplaza esa cadena con una dirección de cartera propiedad del atacante.

Entre bastidores, el segundo bloque de código es aún más invasivo. Recorre los nodos de texto del documento y monitorea cada campo de entrada, área de texto y elemento editable. Cuando un usuario escribe o pega una dirección en un campo de formulario, el script intercepta el evento y reescribe el valor. Incluso llega a restaurar la posición del cursor después de la reescritura para asegurar que el usuario no note el cambio. Este nivel de manipulación granular asegura que incluso si un usuario evita el portapapeles escribiendo una dirección manualmente, la transacción sigue siendo vulnerable a la redirección.

El portapapeles es un entorno en disputa

El investigador independiente Kevin Beaumont notó un rasgo particularmente agresivo de este malware. Incluso si un usuario nota que la dirección es incorrecta e intenta copiar la dirección de la cartera original nuevamente, el script continúa reemplazándola. Esta persistencia hace que el entorno del navegador en sí mismo no sea confiable. En el caso de una brecha como esta, el navegador se convierte en un agente malicioso que actúa contra los intereses del usuario.

Desde la perspectiva del usuario final, el ataque es casi totalmente silencioso. No hay ventanas emergentes, ni ralentizaciones, ni signos obvios de infección del sistema. El malware no intenta instalar software ni establecer persistencia en el disco duro. Existe solo en la memoria volátil de la pestaña del navegador. Una vez que el usuario cierra la página afectada, el proceso malicioso termina. Sin embargo, el daño ocurre en los segundos que se tarda en hacer clic en un botón de envío. Una dirección alterada en el punto de pago es suficiente para redirigir miles de dólares de una manera que es funcionalmente irreversible en una cadena de bloques descentralizada.

Reconciliando el conflicto del cronograma

Existe una discrepancia entre el informe oficial del incidente y las observaciones independientes. Adform identifica el 27 de julio como la fecha del incidente y afirma que eliminaron el código con prontitud. Kevin Beaumont informó haber visto actividad maliciosa a través de Adform durante al menos una semana antes de esa fecha. Esta brecha de duración es un problema significativo para la evaluación de riesgos. Si el script estuvo activo durante siete días en lugar de uno, el número de visitantes expuestos aumenta en órdenes de magnitud. Adform sirve aproximadamente 1,500 millones de anuncios diariamente en 180 países. Incluso si solo una pequeña fracción de esos anuncios portaba la carga maliciosa, el grupo potencial de víctimas es enorme.

Como contramedida, Adform ha aconsejado a todos los usuarios que borren la caché de su navegador. Este es un paso vital porque la versión maliciosa de trackpoint-async.js puede permanecer almacenada localmente en la computadora de un usuario incluso después de la corrección en el servidor. Si el navegador carga la versión en caché del script, el ataque permanece activo. Esto resalta un fallo persistente en la seguridad web donde la longevidad de una caché puede extender la vida de una amenaza de seguridad mucho después de que se haya implementado un parche.

Evaluando las capacidades de exfiltración

Uno de los aspectos más preocupantes del código es su comunicación con un servidor externo. El script intenta enviar una solicitud HTTP a una dirección IP (84.32.102[.]230) al cargar la página. Esta solicitud incluye el nombre de host y la ruta específica de la página que el visitante está viendo actualmente. Adform declaró que no encontraron evidencia de que las direcciones IP o el historial de navegación de los visitantes llegaran a los atacantes. Sin embargo, el aviso del incidente admite que tal transmisión era técnicamente posible basándose en la construcción del código.

En mi experiencia analizando APTs y brechas en la cadena de suministro, los atacantes rara vez incluyen capacidades de exfiltración de datos sin la intención de usarlas. El nombre de host y los datos de la ruta proporcionan a los operadores un mapa en vivo de qué sitios están sirviendo con éxito su malware. Esto les ayuda a priorizar sus objetivos y medir la efectividad de su compromiso. Hablando proactivamente, debemos asumir que cualquier dato al que el script pudiera acceder fue potencialmente registrado por el servidor de comando y control del atacante.

Medidas defensivas para la web moderna

Este incidente sirve como un recordatorio contundente de que los scripts de terceros son un vector importante de riesgo sistémico. Para defenderse contra esto, las organizaciones deben avanzar hacia un modelo de seguridad granular. El uso de hashes de Integridad de Subrecursos (SRI) es una defensa primaria. El SRI permite a un navegador verificar que un script obtenido no ha sido manipulado. Si el hash del archivo en el servidor no coincide con el hash definido en el código del sitio web, el navegador se niega a ejecutarlo. Si los clientes de Adform hubieran implementado SRI para trackpoint-async.js, la versión maliciosa se habría bloqueado automáticamente.

Otra defensa crítica es la Política de Seguridad de Contenido (CSP). Una CSP bien configurada puede restringir los dominios desde los cuales se pueden cargar scripts y evitar que envíen datos a direcciones IP externas no autorizadas. Si se hubiera implementado una CSP que bloqueara explícitamente las conexiones a la dirección IP del atacante, el intento de exfiltración de datos habría fallado. La seguridad no es una herramienta única, sino una serie de capas superpuestas. Cuando una capa se ve comprometida, las otras deben estar listas para contener el fallo.

En última instancia, la responsabilidad de verificar una transacción recae en el usuario. La defensa más efectiva en este caso específico es la más simple: verifique siempre la dirección de destino a través de un segundo canal o revisando dos veces cada carácter antes de presionar enviar. En un mundo donde el mismo código que utiliza para navegar por la web puede volverse en su contra, la paranoia saludable es un requisito funcional para la vida digital.

Conclusiones clave para líderes de TI

• Audite todos los scripts de terceros que se ejecutan actualmente en sus entornos de producción y elimine cualquiera que no sea crítico para la misión.
• Implemente hashes de Integridad de Subrecursos (SRI) para todas las dependencias externas de JavaScript para evitar la ejecución de código no autorizado.
• Fortalezca las Políticas de Seguridad de Contenido (CSP) para restringir la ejecución de scripts y la exfiltración de datos a dominios conocidos y confiables.
• Aplique un enfoque de confianza cero (Zero-Trust) a los recursos del lado del cliente asumiendo que cualquier dependencia externa puede ser comprometida en la fuente.

Fuentes

• Aviso de incidente de Adform (julio de 2026)
• Marco MITRE ATT&CK: Compromiso de la cadena de suministro (T1195)
• Publicación especial de NIST 800-161: Prácticas de gestión de riesgos de la cadena de suministro de ciberseguridad para sistemas y organizaciones

Descargo de responsabilidad: Este artículo es solo para fines informativos y educativos y no reemplaza una auditoría de ciberseguridad profesional o un servicio de respuesta a incidentes.