La ofuscación de JavaScript consiste en transformar código JavaScript normal y legible por humanos en una forma intencionalmente difícil de leer y comprender. La ofuscación se utiliza generalmente para ocultar el significado del código y, como resultado, hace que sea extremadamente difícil seguir o realizar ingeniería inversa sobre sus funciones. A diferencia del cifrado de código, la ofuscación no requiere un algoritmo ni una clave privada para ejecutarse. La lógica y la funcionalidad del código permanecen exactamente iguales, pero el código está lleno de nombres de funciones vagos y opacos, estructuras programáticas extrañas y cadenas codificadas.
Los desarrolladores a veces utilizan herramientas como los ofuscadores de JavaScript para proteger su código y su propiedad intelectual y evitar que sea robado. Pero desde una perspectiva de seguridad, especialmente en el contexto de scripts de terceros, el código ofuscado es una señal de alarma enorme. Los atacantes suelen usar esta ofuscación para ocultar su código malicioso —que puede ser desde malware, lógica de robo de datos o código de explotación— dentro de lo que parece un revoltijo aleatorio de texto. Esto por sí solo puede eludir escáneres de seguridad simples y dificultar considerablemente el análisis manual de los scripts.
¿Por qué es importante desofuscar JavaScript para la seguridad?
En lo que respecta a la seguridad web, la visibilidad del payload —es decir, la capacidad de ver e inspeccionar el código que se ejecuta en tu sitio— es absolutamente crítica. Desofuscar JavaScript (revertir o decodificar el código) proporciona a un analista de seguridad una comprensión clara del script y de lo que está ejecutando internamente. Si no puedes ver a través de esta ofuscación, estás efectivamente ciego ante lo que ese código podría estar haciendo.
Depender únicamente de medidas de seguridad superficiales no es suficiente para proteger tu sitio. Por ejemplo, las cabeceras de Content Security Policy pueden restringir desde dónde se pueden cargar los scripts, pero no ofrecen ninguna visibilidad sobre el payload de los scripts en sí. Si un host de terceros se ve comprometido y comienza a servir malware ofuscado —como reportamos en 2024 con el ataque a Polyfill—, una CSP no te indicará que el contenido del script es malicioso. Como proviene de una fuente aprobada, lo confiará y no marcará el contenido potencialmente malicioso que se está sirviendo.
Otra razón por la que la visibilidad del payload es crítica es la naturaleza dinámica de la mayoría de los ataques del lado del cliente. Como se describe en nuestro informe de ataques del lado del cliente del Q2, cside ha comenzado a observar cada vez más ataques que inyectan código ofuscado en sitios que frecuentemente se comunican con un servidor de comando y control para recibir instrucciones adicionales. Esto puede exponer un sitio a amenazas como publicidad maliciosa y redirecciones, scripts de cryptojacking y kits de exploits para navegadores, todos controlados dinámicamente por un tercero.
¿Cuáles son las señales de alerta comunes en JavaScript que hay que vigilar?
Código ilegible o incomprensible
Una de las mayores señales de alerta es que el código de un script sea un enredo sin sentido de caracteres, largos arrays numéricos y funciones extrañas que no se parecen a ningún código legible por humanos. Los atacantes suelen ocultar cadenas codificándolas mediante hexadecimal, Base64 y escapes Unicode, dividiéndolas en fragmentos ilegibles. Variables como _0x5e o aa1122bbcc raramente tienen identificadores con significado. Las bibliotecas legítimas pueden minificar código que se asemeje a esto, pero normalmente no estarán profundamente ofuscadas con datos basura.
Datos codificados o basura en cadenas
Los scripts maliciosos suelen ocultar cadenas críticas (como URLs, palabras clave o payloads de JavaScript) codificándolas e insertando datos basura en ellas. Por ejemplo, pueden tener una URL ofuscada mediante codificación hexadecimal y dispersar múltiples subcadenas basura constantes a lo largo de ella para dificultar la decodificación. Funciones como atob(), unescape() y rutinas personalizadas que transforman cadenas son indicadores claros de que el script intenta ocultar algo. En el pasado, se ha sabido que los atacantes insertan texto aleatorio o utilizan múltiples capas de codificación para ocultar variables como eval y document.cookie.
Generación dinámica de funciones (eval y similares)
Otra señal de alerta en un script es el uso de funciones como eval(), el constructor Function() o setTimeout() y setInterval(). Esto a menudo significa que el script está construyendo código en tiempo de ejecución, una técnica favorita del malware para desempaquetar el payload real. Los scripts legítimos modernos raramente usan eval() debido a sus implicaciones de seguridad y rendimiento, por lo que su presencia en un script de terceros debería levantar sospechas. De manera similar, crear elementos de script en el DOM dinámicamente mediante document.createElement('script') es otra forma de inyectar código malicioso. Si detectas código que construye una etiqueta <script> con una URL externa sospechosa, esa es una señal de advertencia importante de que tu sitio puede estar comprometido.
Conexiones externas sospechosas
Cualquier script de terceros que haga referencia a dominios o IPs externos no relacionados con la función del sitio es un indicio claro de comportamiento malicioso. Por ejemplo, si un script ofuscado realiza de repente una solicitud fetch() o XHR a un dominio no relacionado con el sitio, esto suele ser un indicador de comportamiento malicioso. Los atacantes frecuentemente utilizan sus propios servidores para la exfiltración o como puntos de control, y cualquier aparición de estos dominios en código de terceros es una señal de alerta.
Trucos de manipulación del HTML y el DOM
El JavaScript malicioso ofuscado suele manipular la página de formas sigilosas. Esto se observa frecuentemente mediante la creación de elementos invisibles o superpuestos, el establecimiento de valores de z-index extremadamente altos (para cubrir la página con una entrada o aviso fraudulento) y la inyección de formularios y escuchadores de eventos. cside reportó recientemente un ataque que tuvo lugar en CoinMarketCap que utilizó una ventana emergente maliciosa con un valor de z-index alto para engañar a los usuarios y hacer que conectaran sus carteras a un tercero malicioso, vaciando sus carteras de cualquier criptomoneda que contuvieran.
Ofuscación polimórfica en ataques JavaScript
Una de las técnicas más avanzadas y evasivas que los atacantes pueden usar para ocultar la verdadera intención de su script es la ofuscación polimórfica. La ofuscación polimórfica es código que cambia su estructura cada vez que se entrega el payload, aunque el comportamiento subyacente permanezca igual. Esta técnica está tomada del desarrollo de malware tradicional, donde los binarios polimórficos mutan su apariencia para evadir la detección de antivirus. En el ecosistema JavaScript basado en navegador, los atacantes logran una evasión similar rotando nombres de variables, reestructurando funciones, alterando el flujo de control e intercalando código basura aleatorio a lo largo del script.
Esto significa que dos payloads con la misma intención —como extraer datos de un formulario de pago en un sitio web— pueden verse completamente diferentes a nivel de código. Esto hace que los métodos de detección como las firmas basadas en hash y los filtros estáticos basados en IOC sean insuficientes y, en general, increíblemente difíciles de proteger. Dado que el código es dinámico y cambiante, las defensas perimetrales como Content Security Policy (CSP) y Subresource Integrity (SRI) no pueden ofrecer suficiente protección contra ataques polimórficos. Estas protecciones pueden validar de dónde proviene el script y si ha sido modificado, pero no ofrecen ninguna información sobre lo que el script realmente hace en tiempo de ejecución.
¿Qué herramientas y tecnologías desofuscan JavaScript?
La desofuscación es esencialmente un ejercicio de ingeniería inversa para transformar las cadenas y funciones codificadas en algo legible por humanos. A menudo se requiere una combinación de las siguientes técnicas para desofuscar completamente un script:
- Embellecedores o formateadores de código: Herramientas como JSBeautify, deobfuscate.io, JSnice y de4js pueden tomar un script empaquetado o minificado y volver a sangrar el código para añadir saltos de línea, convirtiéndolo en un fragmento de código correctamente estructurado. Esto no suele eliminar la ofuscación, pero hace que la disposición del código sea más legible.
- Utilidades de decodificación de cadenas: Como el código ofuscado frecuentemente codifica datos usando hex, Base64, etc., el uso de herramientas de decodificación simples puede recuperar las cadenas originales. Muchos analistas de seguridad utilizan scripts de Python o sitios como Dencode.com para decodificar formatos comunes.
- Refactorización y sustitución manual: A veces, la forma más sencilla es la más manual: después de usar un embellecedor de código, leer el código y reemplazar estáticamente los nombres de variables u funciones ofuscadas por su significado real puede ayudar a comprender la intención detrás de algunas funciones.
- Análisis AST: Para scripts muy complejos, los investigadores de seguridad suelen recurrir al desarrollo de scripts personalizados para analizar y transformar el código. Usar un analizador de JavaScript para obtener el Árbol de Sintaxis Abstracta (AST) de un script permite a un investigador navegar programáticamente por la estructura y eliminar capas de ofuscación. Este enfoque puede ayudar a simplificar automáticamente cosas como el aplanamiento del flujo de control o la codificación elaborada de funciones, aunque requiere sólidas habilidades de programación.
¿Se puede analizar automáticamente el JavaScript ofuscado?
El análisis automático y el sandboxing son indispensables para manejar grandes volúmenes de JavaScript ofuscado y detectar amenazas en tiempo real. Analizar manualmente cada script suele ser poco práctico, por lo que las organizaciones pueden emplear una combinación de sandboxing dinámico, análisis estático de código e inteligencia de amenazas para abordar la comprensión del JavaScript a escala.
- Análisis dinámico mediante sandboxing: Un enfoque para determinar qué hace el código sospechoso es ejecutarlo en un entorno controlado (usando un navegador que recorra el código paso a paso, por ejemplo) y observar su comportamiento. Cuando se ejecuta un script ofuscado allí, el sandbox puede registrar comportamientos que parezcan maliciosos. ¿Intenta el script modificar el formulario de pago? ¿Realiza una llamada AJAX a un dominio sospechoso o conocido como malicioso? ¿Genera iframes ocultos o utiliza una cantidad significativa de CPU? Dado que el sandbox observa las acciones del script, puede marcar patrones incluso si el código estaba ofuscado. Algunos sandboxes incluso pueden engancharse al motor de JavaScript para volcar el código desofuscado una vez que el script se ha desempaquetado en memoria. El enfoque dinámico es excelente porque no requiere comprender el código y en su lugar observa directamente los resultados maliciosos, aunque puede ser detectado por malware avanzado que modifique su comportamiento en consecuencia.
- Análisis estático con inteligencia artificial y modelos de lenguaje de gran escala: En el lado estático del análisis, las herramientas de seguridad suelen usar coincidencia de patrones e inteligencia artificial para examinar el texto y el comportamiento de los scripts y determinar si son maliciosos, incluso si están ofuscados. El uso de modelos de lenguaje de gran escala para obtener una línea base de actividad del script se ha vuelto cada vez más popular, ya que permite a un analista de seguridad distinguir rápidamente entre un script minificado y uno malicioso.
En cside, nuestro pipeline de análisis automático evalúa tanto el JavaScript ofuscado como el desofuscado ejecutando reglas de detección antes y después de la normalización del código a una forma legible. Este enfoque de doble capa nos ayuda a detectar amenazas evasivas que podrían aparecer solo una vez que el código se desempaqueta. A diferencia de muchos escáneres tradicionales, cside utiliza modelos de detección basados en atributos para ver cómo un script interactúa con la API del DOM y qué elementos puede crear, modificar y adjuntar. Estos atributos de comportamiento nos permiten detectar cambios sospechosos incluso si el script está fuertemente ofuscado o se genera en tiempo de ejecución.
¿Cuáles son algunos ejemplos reales de ataques con JavaScript malicioso ofuscado?
El JavaScript ofuscado ha estado en el centro de muchos ataques reales sobre los que cside ha informado, desde brechas de alto perfil hasta campañas de malware cotidianas.
- Skimmers de tarjetas de crédito Magecart: Magecart es un término genérico para grupos que históricamente han inyectado JavaScript malicioso en sitios de comercio electrónico para robar datos de tarjetas de pago. En el ataque a British Airways en 2018, los atacantes comprometieron scripts de terceros e insertaron código de skimmer ofuscado. Este código estaba diseñado para robar información de tarjetas de crédito en las páginas de pago y enviarla a servidores controlados por los atacantes, todo mientras se mezclaba con scripts legítimos. Los atacantes de Magecart utilizan habitualmente la ofuscación de scripts para codificar funciones y ocultar la verdadera intención de la lógica del código. Para más información sobre el ataque a British Airways, cside publicó un informe especial sobre el ataque (¡y cómo terminamos con el dominio utilizado en el ataque!).
- Scripts de cryptojacking: El auge de los mineros de criptomonedas en el navegador también vio el uso de código ofuscado para implementar sus ataques. En un ataque de cryptojacking, un atacante inyecta un script que utiliza silenciosamente la CPU de un visitante para minar criptomonedas. Para evitar una detección fácil (más allá del pico en el uso de CPU del usuario), el código solía estar ofuscado o servirse desde una CDN de contenido comprometida. cside publicó recientemente cómo los ataques de cryptojacking se han vuelto más prominentes en el último año y han cambiado considerablemente en la forma en que se ejecutan.
- Inyección de Progressive Web App y redirecciones: En 2025, cside informó sobre un ataque que utilizó una Progressive Web App para redirigir a usuarios móviles a una estafa de contenido adulto chino. El payload de este ataque ya se había visto antes, pero la entrega a través de una Progressive Web App fue un vector de ataque increíblemente singular. Aunque las PWA a menudo se ignoran en el ámbito de la seguridad del lado del cliente, también son susceptibles a los ataques del lado del navegador que cside observa con frecuencia.
¿Cuáles son las mejores prácticas para la monitorización y defensa continua de la seguridad de JavaScript?
Mantener tu aplicación web a salvo del código malicioso de terceros no es un esfuerzo puntual, sino que requiere una monitorización continua y buenas prácticas para minimizar el riesgo.
- El proxy de cside: El proxy de cside actúa como intermediario entre tu sitio y los scripts externos de terceros, permitiéndonos interceptar, analizar y detener ataques de JavaScript antes de que se ejecuten en el navegador del usuario. Nuestro proxy permite la monitorización en tiempo real del comportamiento de los scripts en cada carga de página, sin modificar el código base de la aplicación ni ajustar los requisitos de Content Security Policy. Al inspeccionar los scripts tanto en su forma ofuscada como normalizada, el proxy puede aplicar reglas y marcar anomalías, incluso cuando los atacantes rotan capas de ofuscación o inyectan payloads dinámicos.
- Restringir y validar las fuentes de scripts: Usar cabeceras de Content Security Policy (CSP) para controlar estrictamente desde dónde se pueden cargar los scripts es otra forma fantástica de proteger tu sitio contra ataques no deseados. Usar una regla CSP para incluir en la lista blanca solo tus dominios y CDNs conocidas, bloqueando todo lo demás, es un excelente primer paso para asegurar el JavaScript que se ejecuta en tu sitio. Combinar CSP con comprobaciones de subresource integrity (SRI) —que pueden detectar si un archivo ha sido alterado e impedir su ejecución— puede garantizar que solo cargas lo que pretendes cargar.
- Mantente informado y forma a tu equipo: El panorama de amenazas evoluciona increíblemente rápido, y continuamente surgen nuevos trucos de ofuscación y técnicas de ataque. Invierte en la formación de tus equipos de seguridad, junto con tus equipos de desarrollo, sobre estas tendencias y las mejores prácticas para protegerse contra ellas. Sigue los informes de inteligencia de amenazas y actualiza tus propios patrones de detección en consecuencia. Asegúrate de tener un plan de respuesta a incidentes específico para incidentes del lado del cliente; por ejemplo, si de repente detectas un skimmer ofuscado en tu sitio, ¿a quién alertas? Prepararse para estos escenarios garantiza una respuesta que puede minimizar el daño si se gestiona correctamente.
Reflexiones finales
En el ecosistema de navegadores actual, el JavaScript de terceros es tanto una necesidad como un riesgo para los sitios web. Las técnicas de ofuscación pueden servir a código legítimo, pero también son utilizadas frecuentemente por atacantes para ocultar payloads dañinos, lo que hace que sea más difícil que nunca detectar, analizar y responder a amenazas potenciales. La capacidad de desofuscar JavaScript y monitorizar su comportamiento ya no es opcional. Es absolutamente crítica.
En cside, hemos construido nuestra tecnología para dar a los equipos visibilidad sobre lo que realmente está ocurriendo dentro de los scripts de terceros. A medida que los ataques del lado del cliente continúan evolucionando, invertir en visibilidad del payload y monitorización en tiempo real es la mejor defensa que puedes desplegar hoy. Si estás listo para tomar el control de tu riesgo de JavaScript de terceros, ponte en contacto con nosotros y explora más de nuestro blog de inteligencia de amenazas para mantenerte al día sobre los patrones de ataque.
