Un incidente reciente vuelve a poner el foco en la seguridad de los scripts que se cargan desde plataformas publicitarias. Según la información publicada, los atacantes lograron provocar un cambio de direcciones cripto en el navegador de los visitantes al adulterar un archivo JavaScript que se distribuía a través de un recurso compartido.
La clave del problema es que el código malicioso no actuaba como una amenaza “tradicional” que instala software de forma evidente, sino como una manipulación en el lado del navegador: reescribía direcciones de Bitcoin, Ethereum y Tron para que, durante el tiempo en que la página estaba abierta, el usuario pudiera terminar copiando o enviando fondos a un destinatario distinto.
Qué pasó: el script se modificó para reescribir direcciones
De acuerdo con el reporte, el ataque consistió en alterar un archivo JavaScript usado por un servicio de tecnología publicitaria. El archivo modificado acabó funcionando como una herramienta del navegador capaz de localizar patrones de direcciones de cripto y reemplazarlas.
El proveedor detectó el incidente el 27 de julio de 2026, eliminó el código malicioso y avisó a sus clientes. A partir de esa corrección, cualquier persona que hubiera visitado un sitio que cargaba el script afectado en esa fecha y hubiera copiado una dirección (Bitcoin, Ethereum o Tron) pudo terminar con una dirección diferente insertada por el código.
Por qué el ataque pudo afectar a sitios no relacionados
Una parte importante del caso es el mecanismo de distribución. El recurso comprometido se servía desde un dominio de la plataforma publicitaria, y su implementación permitía ejecutar el código en una página concreta, en secciones múltiples o de forma incondicional en todo el sitio.
Al comprometer un recurso compartido, los atacantes obtuvieron una vía para llegar a múltiples “sitios descendientes” sin tener que vulnerar cada uno por separado. En términos prácticos, esto encaja con lo que suele conocerse como compromiso de la cadena de suministro: el daño no depende de que el sitio de destino esté comprometido, sino de que cargue un componente alterado.
Cómo se produce el cambio de direcciones cripto en el navegador
El archivo señalado (trackpoint-async.js) contenía una biblioteca legítima con dos bloques maliciosos añadidos. Estos bloques incluían cadenas de reemplazo ofuscadas mediante una clave XOR de seis bytes.
La primera parte del comportamiento se enfocaba en el portapapeles y en un punto temporal: mientras la página afectada permanecía abierta, el código intentaba detectar eventos de copia. Cada pocos segundos (según el análisis, aproximadamente cada cuatro), el script buscaba leer el contenido del portapapeles e identificar direcciones que coincidieran con patrones previstos. Si encontraba coincidencias, las sustituía.
Además, también realizaba una solicitud HTTP al cargar la página, incluyendo información sobre el host y la ruta en la que estaba el visitante. En el material disponible no se confirma si esa solicitud llegó realmente al operador, porque la muestra capturada no permite cerrar esa incógnita con certeza.
Reemplazo no solo por copiar: también en campos de formulario
El alcance del ataque era más amplio de lo que sugiere un escenario “solo si copias”. El segundo bloque recorría los nodos de texto del documento y reescribía valores en elementos como inputs, textareas y zonas con contenido editable.
También se indicaba que el script intentaba restaurar la posición del cursor después del reemplazo, reduciendo la probabilidad de que el usuario notara cambios bruscos. Para reforzar el engaño, el código enlazaba el “value setter” de ciertos elementos de entrada, de modo que incluso escrituras programáticas fueran interceptadas mientras el usuario interactuaba con la página.
Adicionalmente, el script intervenía en eventos comunes como copiar, cortar y pegar, y controlaba eventos relacionados con la entrada del usuario. En conjunto, esto apuntaba a que el cambio de direcciones cripto podía ocurrir tanto al copiar/pegar como al introducir la dirección manualmente en un formulario.
Variación de direcciones y advertencia del investigador
Un investigador independiente divulgó el compromiso y señaló una particularidad: aunque el usuario notara que la dirección era incorrecta y copiara de nuevo la del monedero, el reemplazo podía seguir ocurriendo una y otra vez mientras estuviera activa la página afectada.
Según la descripción técnica, las cadenas de reemplazo para Bitcoin, Ethereum y Tron estaban “hardcodeadas” dentro del bloque malicioso, pero las direcciones que aparecían en el intercambio podían variar entre casos. Esa variabilidad agrega dificultad para detectar el problema únicamente inspeccionando una sola dirección “tipo”.
Lo que dijo el proveedor: caché, verificación y alcance del exfiltrado
Tras corregir el incidente, el proveedor comunicó instrucciones concretas. Recomienda a las personas afectadas limpiar la caché del navegador, porque el archivo alterado podría haber quedado almacenado incluso después de la corrección.
Además, pidió revisar cualquier dirección de monedero antes de enviar fondos. La idea es simple: verificar que la dirección que aparece en el campo o que se prepara para el envío coincide con la que el usuario pretendía usar.
En cuanto a privacidad, el proveedor indicó que no encontró evidencia de que el código transmitiera direcciones IP o información sobre los sitios visitados. Aun así, en su aviso se añadía que el análisis técnico sugería que tal transmisión podría haber sido posible. Es decir: no está demostrado el envío de esos datos, pero tampoco se descarta por completo el diseño observado.
Estado de la investigación: fechas, impacto y señales de compromiso
El calendario público del incidente no está completamente cerrado. El proveedor marcó el 27 de julio como la fecha afectada, mientras que el investigador mencionó que observó actividad maliciosa durante el período de aproximadamente una semana previa. Esa diferencia temporal dificulta estimar con rigor cuántos usuarios estuvieron expuestos.
También faltan datos clave para dimensionar el impacto: cuántos sitios incluían el recurso afectado, cuántas cargas de página recibieron realmente el archivo adulterado y si los atacantes lograron desviar fondos. Por el momento, la información pública no identifica indicadores de compromiso.
En cuanto a la magnitud del negocio, el proveedor reportó cifras generales del servicio (por ejemplo, número de clientes y la escala de anuncios servidos), pero esos datos describen la plataforma en general, no el alcance específico del incidente.
Qué significa que la página debiera permanecer abierta
El propio análisis del comportamiento sugiere que el código estaba orientado a operar mientras la página afectada permanecía visible. No se reporta evidencia de que estuviera diseñado para instalar software adicional o establecer persistencia más allá de la sesión/uso en curso.
Esto es importante para entender el riesgo: el cambio de direcciones cripto se materializaba cuando el usuario interactuaba y el script seguía activo en el contexto de la página comprometida.
Cómo protegerse si visitaste sitios con el script afectado
Con lo que se conoce hasta ahora, hay medidas prácticas que los usuarios pueden tomar. Si estuviste en sitios que pudieron cargar el recurso afectado durante la fecha indicada, considera actuar de la siguiente forma:
- Limpia la caché del navegador para reducir el riesgo de que se reutilice el archivo alterado.
- Verifica la dirección de tu monedero antes de enviar fondos, comparándola con el origen esperado (por ejemplo, revisando en tu propia interfaz de confianza).
- Si detectas una discrepancia, no asumas que “volver a copiar” arregla el problema; el aviso del investigador sugiere que el reemplazo podía repetirse mientras la página afectada siguiera abierta.
- Evita realizar transferencias de alto valor desde una página cuya integridad no puedas confirmar.
Estas recomendaciones no eliminan por completo la incertidumbre sobre el alcance, pero reducen el riesgo operativo mientras la investigación avanza.
Conclusión
Este caso ilustra cómo un incidente en un componente compartido puede terminar causando un cambio de direcciones cripto en el navegador sin necesidad de que el usuario instale nada. Al adulterar un archivo JavaScript distribuido por una plataforma publicitaria, el atacante pudo manipular el portapapeles, interceptar eventos y modificar campos de formulario mientras la página afectada permanecía abierta.
La respuesta del proveedor —eliminación del código, notificación y recomendación de limpiar la caché y revisar direcciones— apunta a reducir el impacto para quienes visitaron sitios durante el período señalado. Entretanto, siguen pendientes aspectos como el número exacto de exposiciones y si hubo desvíos de fondos, lo que mantiene el caso abierto para una revisión posterior.
Fuente: https://thehackernews.com/2026/08/hackers-poison-adform-script-to-swap.html
