Los dominios similares generados por IA ahora están integrados dentro de scripts de terceros que se ejecutan en sus propiedades web. He aquí por qué su pila actual no puede verlos y qué requiere realmente la detección.
Descargue la Guía de expertos de CISO sobre Typosquatting en la era de la IA →
TL;DR
- Typosquatting ya no es un problema de usuario. Los atacantes ahora incorporan dominios similares dentro de scripts legítimos de terceros. No se requiere una URL mal escrita ni una vulneración del servidor.
- La IA rompió la economía de la defensa. Los LLM generan miles de variantes de dominio convincentes en minutos; el despliegue completo de la campaña lleva menos de diez años. Las cargas de paquetes maliciosos aumentaron 156% el año pasado. La investigación manual está muerta.
- Tu pila de seguridad no puede ver esto. Los firewalls, WAF, EDR y CSP no tienen visibilidad de lo que hacen los scripts aprobados una vez que se ejecutan en el navegador.
- El Ataque a Trust Wallet lo demostró. 8,5 millones de dólares robados en 48 horas a través de una extensión de Chrome troyanizada. No se disparó ninguna alerta, no porque algo fallara, sino porque no había nada mirando.
Esta no es una historia criptográfica
El 24 de diciembre de 2025, los usuarios de Trust Wallet comenzaron a perder dinero. No porque hayan hecho clic en un enlace de phishing. No porque reutilizaron una contraseña débil. No porque hayan hecho nada malo en absoluto.
Un gusano npm autorreplicante llamado Shai-Hulud había pasado meses recopilando credenciales de desarrollador: tokens de GitHub, claves de publicación de npm y credenciales de la API de Chrome Web Store. Esas claves permitieron a los atacantes enviar una versión troyanizada de la extensión Trust Wallet Chrome a través de canales oficiales. La verificación de Chrome pasó.
La extensión maliciosa se ejecutó completamente dentro de los navegadores de los usuarios, capturando silenciosamente frases iniciales y transmitiéndolas a la infraestructura del atacante en un dominio disfrazado de punto final de análisis del propio Trust Wallet. En 48 horas, se habían vaciado 2.500 carteras. Pérdida total: 8,5 millones de dólares. Ningún servidor fue vulnerado. Nunca se disparó ninguna alerta.
Elimine las frases iniciales y lo que queda es esto: un activo confiable entregado por el navegador se modificó silenciosamente para interceptar datos confidenciales del usuario antes de que la aplicación legítima pudiera procesarlos, invisible para los registros del servidor, firewalls, WAF y EDR. No porque esos controles estuvieran mal configurados, sino porque nunca fueron diseñados para observar lo que sucede dentro de una sesión del navegador, ni siquiera una sesión envenenada.
Cambie frases iniciales por datos de tarjetas de pago. Cambie la extensión de Chrome por un píxel de marketing, un widget de soporte o un marco de pruebas A/B. El ataque es idéntico. Una página de pago típica de comercio electrónico ejecuta entre 40 y 60 scripts de terceros. Cada uno es una conexión confiable. Allí podría pasar lo mismo.
Cómo llegó aquí la typosquatting: tres fases
Lo que hace que la Fase 3 sea una evolución genuina no es sólo la sofisticación, sino también la economía. Los LLM pueden generar miles de variaciones de dominio convincentes en minutos. Los ataques homógrafos combinan caracteres latinos, cirílicos y griegos para producir dominios que parecen visualmente idénticos en las barras de direcciones del navegador mientras evaden la detección de distancia de cadena. El registro de dominio, la emisión de SSL y la implementación completa de la campaña ahora demoran menos de diez minutos. Los datos de Sonatype muestran que las cargas de paquetes maliciosos a repositorios de código abierto aumentaron un 156% año tras año, por lo que el volumen por sí solo ha hecho que la investigación manual sea estructuralmente imposible.
Tres ataques que muestran el patrón
La typosquatting apunta a la capa de dominio, el compromiso de paquetes apunta a la cadena de suministro y el abuso del tiempo de ejecución del navegador apunta a lo que hace el código confiable después de ejecutarse.
1. Extensión Trust Wallet para Chrome (diciembre de 2025)
Shai-Hulud recopiló credenciales de desarrollador durante meses antes de lanzar una extensión troyanizada a través de los canales oficiales de Chrome Web Store. La extensión maliciosa capturó frases iniciales y las transmitió a un dominio de análisis similar. 2.500 carteras vaciadas. Se perdieron 8,5 millones de dólares. Tiempo de detección: cero. No existe visibilidad del lado del servidor para la ejecución en tiempo de ejecución del navegador.
2. ataque npm con tiza/depuración (septiembre de 2025)
Un correo electrónico de phishing dirigido a un único responsable del paquete dio a los atacantes acceso a 18 bibliotecas de JavaScript confiablesincluidos chalk y debug, con más de dos mil millones de descargas semanales combinadas. En 16 minutos, se inyectó código malicioso en todos ellos, conectando las API del navegador para interceptar silenciosamente el tráfico de red y las interacciones de billetera. La rápida contención limitó las pérdidas directas a alrededor de 500 dólares. La ventana de exposición no fue la historia. Fueron dos mil millones de descargas.
3. Ataque a la biblioteca Solana Web3.js (diciembre de 2024)
Los atacantes comprometieron una cuenta de acceso de publicación para la biblioteca npm @solana/web3.js a través de una campaña de phishing, luego publicaron versiones maliciosas que contenían una función oculta que interceptaba claves privadas a mitad de la transacción y las exfiltraba a un dominio controlado por el atacante registrado apenas unos días antes del ataque. Cualquier aplicación que se actualizara automáticamente dentro del período de cinco horas enviaba la puerta trasera directamente a sus usuarios. Casi 200.000 dólares se gastaron antes del descubrimiento.
Cómo ocurre el compromiso: la confianza reemplaza al engaño
La ingeniería social clásica necesitaba un ser humano al tanto, alguien que escribiera mal una URL, hiciera clic en un enlace, aprobara un mensaje y confiara en un remitente. El trabajo del atacante era generar confianza en el momento.
La generación actual de ataques se salta ese paso por completo. La confianza ya no se fabrica, se hereda. Su canal de compilación ya confía en npm. Su proveedor ya confía en su CDN. Su navegador ya confía en el proveedor. El atacante no necesita engañar a nadie; sólo necesitan insertarse en cualquier lugar de una cadena de confianza que ya les ha sido otorgada.
Llámelo subversión de la cadena de suministro: el engaño no está dirigido a una persona; está dirigido al gráfico de dependencia.
El punto ciego en su pila de seguridad
Un proveedor de marketing integrado en sus propiedades web hace referencia a una CDN de JavaScript registrada hace seis semanas. SSL válido. Dominio reconocible. Luego, el guión se actualiza silenciosamente.
En su página de pago, el navegador carga silenciosamente el script modificado. Una superposición invisible intercepta las pulsaciones de teclas antes de que lleguen a su aplicación. Los registros de su servidor registran una sesión normal. No hay incendios de alerta.
CSP es el control más citado como defensa. Pero CSP es una lista de invitados, no un monitor de comportamiento. Un script incluido en la lista de permitidos que lee los campos de su formulario de pago y filtra los datos todavía está totalmente permitido, porque el origen es confiable. CSP maneja la conexión. No puede manejar la ejecución.
El comportamiento malicioso en 2026 se difiere al tiempo de ejecución por diseño. Los paquetes de Shai-Hulud permanecieron inactivos durante el escaneo automatizado y solo se activaron bajo condiciones de tiempo de ejecución específicas. El análisis estático no puede detectar cargas útiles cargadas dinámicamente después de que comienza la ejecución.
Lo que realmente requiere la detección
El informe sobre el costo de una vulneración de datos de 2025 de IBM encontró que la vulneración promedio tarda 241 días para identificar. En los ataques a la cadena de suministro en los que el comportamiento malicioso se ejecuta silenciosamente en la memoria del navegador, esa ventana puede ser significativamente más larga, a menos que esté observando el tiempo de ejecución.
La detección requiere observar qué hacen realmente los scripts después de ejecutarse: con qué dominios se comunican, a qué elementos de la página acceden y cómo su comportamiento se desvía de las líneas base establecidas. Se trata de monitoreo del comportamiento en tiempo de ejecución, la única capa de la que carecen actualmente la mayoría de las pilas de seguridad empresarial.
Las características a monitorear para:
- Exfiltración de datos inesperada: Scripts que leen campos de formulario y transmiten valores a dominios fuera de su lista aprobada
- Resolución de dominio dinámico: Scripts que llaman a dominios registrados recientemente o que se resuelven de manera diferente a su línea base
- Deriva conductual: Un script que se comportó normalmente la semana pasada ahora accede a diferentes elementos de la página esta semana.
Detectar un dominio sospechoso en su árbol de dependencia es necesario, pero no suficiente. El problema más difícil es comprender qué hace realmente el script cargado desde ese dominio. La ofuscación generada por IA ahora está diseñada específicamente para derrotar el análisis estático: el código pasa el linting, imita bibliotecas minificadas legítimas y no produce coincidencias de firmas.
Cerrar esa brecha requiere desofuscar el comportamiento en tiempo de ejecución, ejecutar el script en un entorno instrumentado y rastrear su comportamiento real, sin intentar leer su fuente. Eso significa sacar a la luz a qué accede realmente un script: campos de formulario, cookies, puntos finales de la red, independientemente de cuán confusa esté la fuente. Es el enfoque que Reflectiz construyó Desofuscador de IA alrededor, y se detalla en la guía a continuación.
Tu plan de acción
Si no está seguro de por dónde empezar, priorice por exposición: las páginas de pago primero, las páginas de autenticación en segundo lugar y todo lo demás después. He aquí una secuencia práctica:
Esta semana:
- Audite scripts de terceros para dominios CDN registrados recientemente en su cadena de dependencia
- Revise los informes de CSP, no solo las infracciones, sino también lo que realmente están haciendo sus orígenes aprobados.
- Identifique qué páginas manejan datos confidenciales (pago, inicio de sesión, formularios PII) y priorice el monitoreo allí primero.
Este mes:
- Implementar monitoreo del comportamiento en tiempo de ejecución para páginas de pago y autenticación
- Establecer líneas de base de comportamiento para todos los scripts de terceros aprobados.
- Implementar comprobaciones de integridad de subrecursos (SRI) cuando los scripts se autohospedan o se pueden almacenar en caché
Son necesarios un registro de dominio proactivo, un CSP estricto y DMARC aplicado. Cubren el registro de dominio, la entrega de scripts y la suplantación de correo electrónico. Ninguno de ellos cubre lo que sucede después de que un script de proveedor aprobado se modifica silenciosamente. Esa es la brecha que la mayoría de los equipos no ven hasta que es demasiado tarde.
Los controles anteriores le indican qué hacer. Asignarlos a su entorno real, inventario de proveedores y obligaciones de cumplimiento es donde la ejecución se detiene. Reflectiz ha publicado un Guía de expertos CISO con el marco completo: gobernanza de dominio, controles fundamentales, monitoreo del comportamiento en tiempo de ejecución y una hoja de ruta de implementación por fases construida en torno a esa brecha.
Descarga la guía aquí →
¿Encontró interesante este artículo?
Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en
noticias de google,
Gorjeo y
LinkedIn para leer más contenido exclusivo que publicamos.
