Resumen: desofuscación de JavaScript
- La desofuscación de JavaScript es el proceso de revertir un script ofuscado a código legible por humanos para poder auditar su comportamiento. La ofuscación la usan tanto proveedores legítimos (para proteger su propiedad intelectual) como atacantes (para ocultar payloads maliciosos).
- El conjunto de herramientas estándar combina manipulación de AST, ejecución simbólica y reconstrucción del grafo de control de flujo. Las herramientas ya existentes manejan patrones de ofuscación comunes; los ofuscadores personalizados requieren un análisis a medida.
- En tiempo de ejecución, el código malicioso ofuscado igual tiene que revelarse cuando accede a elementos del DOM o abre conexiones de red. El monitoreo en sesión detecta el comportamiento incluso cuando la desofuscación estática falla.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
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 usa 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 usan herramientas como los ofuscadores de JavaScript para proteger su código y su propiedad intelectual y evitar que se lo roben. 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 suele bastar para eludir escáneres de seguridad simples y hace que el análisis manual de los scripts sea mucho más difícil.
¿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 por debajo. 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 permite cargar scripts, pero no ofrecen ninguna visibilidad sobre el payload de los propios scripts. 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 dirá que el contenido del script es malicioso. Como proviene de una fuente aprobada, confiará en él 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 empezado a observar cada vez más ataques que inyectan código ofuscado en sitios y que a menudo se comunican con un servidor de comando y control para recibir más instrucciones. Esto puede exponer un sitio a amenazas como publicidad maliciosa y redirecciones, scripts de cryptojacking y kits de exploits para navegadores, todos ellos 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 a las que hay que prestar atención 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 de este tipo tendrán el aspecto de _0x5e o aa1122bbcc y rara vez tendrán identificadores con significado. Las bibliotecas legítimas pueden minificar código que se parezca 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 suelen ser indicadores claros de que el script intenta ocultar algo. En el pasado, se ha visto a atacantes insertar texto aleatorio o usar varias 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 que suele usar el malware para desempaquetar el payload real. Los scripts legítimos modernos rara vez 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 forma 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 `` 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 hace de repente una solicitud fetch() o XHR a un dominio que no tiene relación con el sitio, esto suele ser un indicador de comportamiento malicioso. Los atacantes suelen usar sus propios servidores como puntos de exfiltración o control, y cualquier aparición de esos 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 a menudo mediante la creación de elementos invisibles o superpuestos, el establecimiento de valores de z-index extremadamente altos (para cubrir la página con un campo o aviso fraudulento) y la inyección de formularios y escuchadores de eventos. cside informó recientemente sobre un ataque que tuvo lugar en CoinMarketCap que usó 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, vaciándolas de cualquier criptomoneda que contuvieran.
Ofuscación polimórfica en ataques con 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 los antivirus. En el ecosistema de 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 distintos a nivel de código. Esto hace que métodos de detección como las firmas basadas en hash y los filtros estáticos basados en IOC se queden cortos, y en general resulta increíblemente difícil protegerse contra ello. 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 a tu sitio frente a ataques polimórficos. Estas protecciones pueden validar de dónde proviene el script y si ha sido modificado, pero no ofrecen ninguna visión de 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. Normalmente hace falta 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 indentarlo añadiendo 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 codifica datos con frecuencia usando hex, Base64, etc., usar herramientas de decodificación sencillas puede recuperar las cadenas originales. Muchos analistas de seguridad usan scripts en Python o sitios como Dencode.com para decodificar formatos comunes.
- Refactorización y sustitución manual: a veces, la forma más fácil es la más manual: tras usar un embellecedor de código, leer el código y reemplazar estáticamente los nombres de variables o funciones ofuscados por su significado real puede ayudar a entender la intención detrás de algunas funciones.
- Análisis de AST: para scripts muy complejos, los investigadores de seguridad suelen recurrir a scripts desarrollados a medida 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 recorrer programáticamente 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 buenas 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, así que las organizaciones pueden combinar sandboxing dinámico, análisis estático de código e inteligencia de amenazas para entender el JavaScript a escala.
- Análisis dinámico mediante sandboxing: un enfoque para determinar qué hace un código sospechoso es ejecutarlo en un entorno controlado (usando, por ejemplo, un navegador que recorre el código paso a paso) y observar qué hace. Cuando un script ofuscado se ejecuta ahí, el sandbox suele poder registrar comportamientos que parecen maliciosos. ¿Intenta el script modificar el formulario de pago? ¿Hace una llamada AJAX a un dominio sospechoso o conocido como malicioso? ¿Genera iframes ocultos o consume una cantidad significativa de CPU? Como 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 muy útil porque no requiere entender el código y en su lugar observa directamente los resultados maliciosos, pero puede ser detectado por malware avanzado y este puede modificar su comportamiento en consecuencia.
- Análisis estático con inteligencia artificial y modelos de lenguaje de gran tamaño: 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 decidir si son maliciosos, incluso estando ofuscados. Usar modelos de lenguaje de gran tamaño para obtener una línea base de la actividad del script se ha vuelto cada vez más popular, ya que permite a un analista de seguridad distinguir rápidamente entre lo que podría ser 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 normalizar el código a algo legible. Este enfoque de doble capa nos ayuda a detectar amenazas evasivas que podrían aparecer solo una vez que el código se ha desempaquetado. A diferencia de muchos escáneres tradicionales, cside usa modelos de detección basados en atributos para ver cómo interactúa un script 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á muy 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 del día a día.
- Skimmers de tarjetas de crédito de 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 de 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 ello mientras se mezclaba con scripts legítimos. Los atacantes de Magecart suelen usar 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 sobre cómo terminamos con el dominio usado en el ataque!).
- Scripts de cryptojacking: el auge de los mineros de criptomonedas en el navegador también trajo consigo el uso de código ofuscado para llevar a cabo sus ataques. En un ataque de cryptojacking, un atacante inyecta un script que usa 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 frecuentes durante el último año y han cambiado mucho en la forma en que se ejecutan.
- Inyección mediante Progressive Web App y redirecciones: en 2025, cside informó sobre un ataque que usó una Progressive Web App para redirigir a usuarios móviles a una estafa de contenido para adultos 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 suelen quedar fuera del radar 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 Script Method de cside: cside obtiene los scripts externos de terceros en nuestra propia infraestructura, lo que nos permite interceptar, analizar y detener ataques de JavaScript antes de que se ejecuten en el navegador del usuario. cside permite la monitorización en tiempo real del comportamiento de los scripts en cada carga de página, sin modificar la base de código 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 las capas de ofuscación o inyectan payloads dinámicos.
- Restringir y validar las fuentes de los scripts: usar cabeceras de Content Security Policy (CSP) para controlar estrictamente desde dónde se pueden cargar los scripts es otra forma excelente de proteger tu sitio contra ataques no deseados. Usar una regla CSP para incluir en la lista blanca solo tus dominios y las CDN conocidas, bloqueando todo lo demás, es un gran 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 formar a tus equipos de seguridad, junto con tus equipos de desarrollo, sobre estas tendencias y las mejores prácticas para protegerse frente a ellas. Sigue los informes de inteligencia de amenazas y actualiza tus propios patrones de detección en consecuencia. Asegúrate de contar con 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 avisas? 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 las usan con frecuencia los atacantes para ocultar payloads dañinos, lo que hace que sea más difícil que nunca detectar, analizar y responder a amenazas potenciales. Tener la capacidad de desofuscar JavaScript y monitorizar su comportamiento ya no es opcional. Es absolutamente crítico.
En cside, hemos construido nuestra tecnología para dar a los equipos visibilidad sobre lo que realmente ocurre dentro de los scripts de terceros. A medida que los ataques del lado del cliente siguen 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 del riesgo que suponen tus scripts de terceros de JavaScript, ponte en contacto con nosotros y explora más contenido de nuestro blog de inteligencia de amenazas para mantenerte al día sobre los patrones de ataque.
