TOLLBOOTH: ¿Cuál es el tuyo, el mío IIS?

Introducción

En septiembre de 2025, Texas A&M University System (TAMUS) Cybersecurity, un proveedor gestionado de detección y respuesta en colaboración con Elastic Security Labs, descubrió la actividad posterior a la explotación por parte de un actor de amenazas de habla china que instaló un módulo IIS malicioso, al que llamamos TOLLBOOTH. Durante este tiempo, observamos un marco de webshell bifurcado por Godzilla, el uso de la herramienta de monitoreo y administración remota (RMM) GotoHTTP, junto con un controlador malicioso empleado para ocultar su actividad. El actor de amenazas explotó un servidor sitio web IIS mal configurado que usaba ASP.NET claves de máquina que se encuentran en recursos públicos, como la documentación de Microsoft o las páginas de soporte de StackOverflow.

Microsoft informó por primera vez de una cadena similar de eventos en febrero, a principios de este año. Nuestro equipo cree que esta es la continuación de la misma actividad de amenazas que AhnLab también detalló en abril, basada en malware y comportamientos similares. Durante este evento, pudimos aprovechar nuestra asociación con Texas A&M System Cybersecurity para recopilar información sobre la actividad. Además, a través de la colaboración con Validin, aprovechando su infraestructura de escaneo global, determinamos que las organizaciones de todo el mundo se vieron afectadas por esta campaña. En el siguiente reporte se detallarán los eventos y las herramientas que se usan en este clúster de actividades, conocido como REF3927. Nuestra esperanza es crear más conciencia sobre esta actividad entre los defensores y las organizaciones, ya que se está abusando activamente de ella a escala mundial.

Conclusiones clave

• Los actores de amenazas están abusando de los servidores IIS mal configurados mediante claves de máquina expuestas públicamente
• Los comportamientos posteriores al compromiso incluyen el uso de un controlador malicioso, herramientas de monitoreo remoto, volcado de credenciales, implementación de webshell y malware IIS
• Los actores de amenazas adaptaron el proyecto de rootkit "Oculto" de código abierto para ocultar su presencia
• El objetivo principal parece ser instalar una puerta trasera IIS, llamada TOLLBOOTH, que incluye capacidades de encubrimiento SEO y webshell
• Esta campaña incluyó la explotación a gran escala en todas las geografías y verticales de la industria

Descripción general de la campaña

Vector de ataque

El mes pasado, Elastic Security Labs y Texas A&M System Cybersecurity investigaron una intrusión que involucraba un servidor Windows IIS mal configurado. Esto estaba directamente relacionado con un servidor configurado con ASP.NET claves de máquina que se publicaron previamente en el Internet. Las claves de máquina empleadas en las aplicaciones de ASP.NET se refieren a las claves criptográficas empleadas para cifrar y validar datos. Estas claves se componen de dos partes, ValidationKey y DecryptionKey, que se emplean para proteger ASP.NET funciones como las cookies de ViewState y autenticación.

ViewState es un mecanismo empleado por las aplicaciones sitio web ASP.NET para conservar el estado de una página y sus controles en las solicitudes HTTP. Dado que HTTP es un protocolo sin estado, ViewState permite recopilar datos cuando la página se envía y se vuelve a procesar. Estos datos se almacenan en un campo oculto (__VIEWSTATE) en la página que está serializado y codificado en Base64. Este campo ViewState es susceptible a ataques de deserialización, lo que permite a un atacante falsificar cargas útiles empleando las claves de máquina de la aplicación. Tenemos razones para creer que esto es parte de una campaña oportunista dirigida a los servidores sitio web de Windows que emplean claves de máquina expuestas públicamente.

A continuación se muestra un ejemplo de este tipo de ataque de deserialización, que se muestra a través de una solicitud POST en un entorno virtual mediante un generador de carga de deserialización .NET de código abierto. El campo __VIEWSTATE contiene una carga útil codificada en URL y codificada en Base64 que realizará una whoami y escribirá un archivo en un directorio. Con una solicitud de explotación exitosa, el servidor responderá con un HTTP/1.1 500 Internal Server Error.

Actividad posterior al compromiso

Tras el acceso inicial a través de la inyección de ViewState, se observó REF3927 implementando webshells, incluido un marco de shell de Godzilla, para facilitar el acceso persistente. A continuación, enumeraron los privilegios e intentaron (sin éxito) crear sus propias cuentas de usuario. Cuando fallaron los intentos de creación de cuentas, el actor cargó y ejecutó la herramienta GotoHTTP Remote Monitoring and Management (RMM). El actor de amenazas creó una cuenta de administrador e intentó volcar las credenciales con Mimikatz, pero Elastic Defend lo impidió.

Con los intentos de expandir aún más el alcance de la intrusión bloqueados, el actor de amenazas implementó su módulo IIS de secuestro de tráfico, TOLLBOOTH, como un medio para monetizar su acceso. El actor también intentó implementar una versión modificada del rootkit Hidden de código abierto para ofuscar su malware. En la intrusión observada, Elastic Defend impidió que se ejecutaran tanto TOLLBOOTH como el rootkit.

Análisis de Godzilla EKP

Una de las principales herramientas empleadas por este grupo es un framework bifurcado por Godzilla llamado Z-Godzilla_ekp escrito por ekkoo-z. Esta herramienta se aprovecha del proyecto anterior de Godzilla al agregar nuevas funciones, como un complemento de omisión de AMSI, y enmascarar su tráfico de red para que parezca más legítimo. Este kit de herramientas permite a los operadores generar cargas útiles de ASP.NET, Java, C# y PHP, conectarse a destinos y proporciona diferentes opciones de cifrado para ocultar el tráfico de red. Este framework emplea un sistema de plugins impulsado por una GUI con muchas características, entre ellas:

• Capacidades de detección/enumeración
• Técnicas de escalada de privilegios
• Ejecución de comandos/ejecución de archivos
• Cargador de shellcode, meterpreter, ejecución de PE en memoria
• Gestión de archivos, utilidad de compresión
• Complemento de robo de credibilidad (lemon) - Recupera las credenciales de FileZilla, Navicat, WinSCP y Xmanager
• Raspado de contraseñas del navegador
• Escaneo de puertos, configuración de proxy HTTP, toma de notas

A continuación se muestra un ejemplo de tráfico de red que muestra el tráfico del operador al webshell (error.aspx) empleando Z-Godzilla_ekp. El webshell tomará los datos cifrados con AES codificados en Base64 de la solicitud HTTP POST y, a continuación, ejecutará el ensamblado .NET en memoria. Estas solicitudes se disfrazan incrustando los datos cifrados en parámetros HTTP POST para mezclar con el tráfico de red normal.

Análisis de rootkits

El atacante ocultó su presencia en la máquina infectada mediante la implementación de un rootkit de kernel. Este rootkit funciona junto con una aplicación de espacio de usuario llamada HijackDriverManager, cuyas cadenas de interfaz están escritas en chino, para interactuar con el controlador. Para este análisis, examinamos tanto el rootkit malicioso como el código del proyecto original de código abierto "Oculto" del que se derivó. Internamente, llamamos al rootkit HIDDENDRIVER y a la aplicación de espacio de usuario HIDDENCLI.

Este software malicioso es una versión modificada del rootkit de código abierto Hidden, que estuvo disponible en GitHub durante años. El autor del malware realizó modificaciones menores antes de la compilación. Por ejemplo, el rootkit emplea Direct Kernel Object Manipulation (DKOM) para ocultar su presencia y mantener la persistencia en el sistema comprometido. El controlador compilado todavía tiene "oculto" dentro de la cadena de ruta de compilación, lo que indica que usaron el proyecto de rootkit "Oculto".

Tras la carga inicial en el kernel, el controlador prioriza un serial de pasos de inicialización críticos. Primero invoca siete funciones de inicialización:

• InitializeConfigs
• InitializeKernelAnalyzer
• InitializePsMonitor
• InitializeFSMiniFilter
• InitializeRegistryFilter
• InitializeDevice
• InitializeStealthMode

Para preparar sus componentes internos antes de rellenar su objeto controlador y los campos asociados, como las funciones principales.

En las secciones siguientes se detallará cada una de estas siete funciones críticas de inicialización, detallando su propósito.

InicializarConfigs

La acción inicial del rootkit es ejecutar la función InitializeConfigs . El único propósito de esta función es leer la configuración del rootkit desde la clave de servicio del controlador en el registro de Windows, que se rellena con la aplicación del espacio de usuario. Estos valores se extraen y se colocan en variables de configuración global que luego serán empleadas por el rootkit.

En la tabla siguiente se resumen los parámetros de configuración que el rootkit extrae del registro:

InicializarKernelAnalyzer

Su propósito es escanear dinámicamente la memoria del kernel para encontrar las direcciones de los PspCidTable y ActiveProcessLinks que se necesitan.

El PspCidTable es la estructura del kernel que sirve como una tabla para los ID de proceso e hilo, mientras que ActiveProcessLinks debajo de la estructura _EPROCESS sirve como una lista doblemente enlazada que conecta todos los procesos que se están ejecutando actualmente. Permite que el sistema rastree y atraviese todos los procesos activos. Al eliminar entradas de esta lista, es posible ocultar procesos de herramientas de enumeración como Process Explorer.

LookForPspCidTable

Busca la dirección PspCidTable desmontando la función PsLookupProcessByProcessIdcon la biblioteca Zydis y analizándola.

BuscarActiveProcessLinks

Esta función determina el desplazamiento del campo ActiveProcessLinks dentro de la estructura _EPROCESS . Emplea valores de desplazamiento codificados específicos para diferentes versiones de Windows. Tiene un proceso de escaneo rápido que se basa en estos valores codificados para encontrar el campo ActiveProcessLinks , que será validado por otra función. En caso de que no lo encuentre con los valores codificados, adopta un enfoque de fuerza bruta comenzando desde un desplazamiento relativo codificado hasta el desplazamiento máximo posible.

InicializarPsMonitor

InitializePsMonitor Configura el motor de monitoreo y manipulación de procesos del rootkit. Este es el corazón de su capacidad para ocultar procesos.

Primero inicializa tres estructuras de árbol AVL para contener información (reglas) para excluir, proteger y ocultar procesos. Emplea RtlInitializeGenericTableAvl para búsquedas de alta velocidad y las rellena con datos de la configuración. A continuación, configura diferentes devoluciones de llamada del kernel para monitorear el sistema mediante el conjunto de reglas.

Registro de la devolución de llamada del administrador de objetos con (ObRegisterCallbacks)

Este gancho registra las funciones ProcessPreCallback y ThreadPreCallback . El Administrador de objetos del kernel ejecuta este código antes de completar cualquier solicitud para crear o duplicar un identificador en un proceso o subproceso.

Cuando un proceso intenta obtener un identificador en otro proceso, se llama a la función de devolución de llamada ProcessPreCallback . Primero verificará si el proceso de destino es un proceso protegido (en la lista). Si es el caso, en lugar de no otorgar acceso, simplemente degradará sus derechos sobre el proceso protegido con el acceso establecido en SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION.

Esto garantizará que los procesos no puedan interactuar con el proceso protegido, inspeccionarlo o eliminarlo.

El mismo mecanismo se aplica a los subprocesos.

Devolución de llamada de creación de procesos(PsSetCreateProcessNotifyRoutineEx)

El rootkit registra una devolución de llamada con la API de PsSetCreateProcessNotifyRoutineEx en la creación del proceso. Cuando se inicia un nuevo proceso, esta devolución de llamada ejecuta una función CheckProcessFlags que comprueba la imagen del proceso con la lista configurada de rutas de acceso de imagen. A continuación, crea una entrada para este nuevo proceso en su tabla de seguimiento interna, estableciendo sus marcas excluded, protectedy hidden en consecuencia.

Comportamiento basado en indicadores:

• Excluidos
  • El rootkit ignorará el proceso y simplemente dejará que se ejecute como se esperaba.
• Protegido
  • El rootkit no permitirá que ningún otro proceso obtenga un manejo privilegiado, similar a lo que sucede en ProcessPreCallback.
• Escondido
  • El rootkit ocultará el proceso mediante la manipulación directa de objetos del kernel (DKOM). La manipulación directa de las estructuras del kernel de un proceso en el mismo instante de su creación puede ser inestable. En la devolución de llamada de creación de procesos, si es necesario ocultar un proceso, se desvincula de la lista ActiveProcessLinks. Sin embargo, establece una bandera postponeHiding que se explicará a continuación.

La devolución de llamada de carga de imagen (PsSetLoadImageNotifyRoutine)

Esto registra el LoadProcessImageNotifyCallback usando PsSetLoadImageNotifyRoutine, que el kernel llama cada vez que se carga una imagen ejecutable (un .exe o .dll) en la memoria de un proceso.

Cuando se carga la imagen, la devolución de llamada comprueba la marca postponeHiding ; si se establece, llama a UnlinkProcessFromCidTable para eliminarlo de la tabla de ID de proceso maestro (PspCidTable).

InicializarFSMiniFilter

La función define sus capacidades en el FilterRegistration structure(FLT_REGISTRATION). Esta estructura le dice al sistema operativo qué funciones llamar para qué tipos de operaciones del sistema de archivos. Registra devoluciones de llamada para las siguientes solicitudes:

• IRP_MJ_CREATE: Intercepta cualquier intento de abrir o crear un archivo o directorio.
• IRP_MJ_DIRECTORY_CONTROL: Intercepta cualquier intento de enumerar el contenido de un directorio.

FltCreatePreOperation(IRP_MJ_CREATE)

Esta es una devolución de llamada previa a la operación, cuando un proceso intenta crear / abrir un archivo, se activa esta función. Comprobará la ruta con su lista de archivos que se ocultarán. Si se encuentra una coincidencia, cambiará el resultado de la operación de la solicitud IRP a STATUS_NO_SUCH_FILE, indicando al proceso solicitante que el archivo no existe, excepto si el proceso está incluido en la lista de excluidos.

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

Esta es una devolución de llamada posterior a la operación; El gancho implementado esencialmente intercepta la escucha de directorios generada por el sistema y la modifica eliminando los archivos enumerados como ocultos.

InitializeRegistryFilter

Luego de ocultar sus procesos y archivos, el siguiente paso del rootkit es borrar las entradas del Registro de Windows. La función InitializeRegistryFilter logra esto mediante la instalación de una devolución de llamada de filtrado del Registro para interceptar y modificar las operaciones del Registro.

Registra una devolución de llamada mediante la API de CmRegisterCallbackEx, empleando el mismo principio que con los archivos. Si la clave o el valor del Registro está en la lista oculta del Registro, la función de devolución de llamada devolverá el estado STATUS_NOT_FOUND.

InitializeDevice

La función InitializeDevice realiza la inicialización del controlador necesaria y configura una IOCTL communication para que la aplicación del espacio de usuario pueda comunicar con ella directamente

A continuación se muestra una tabla que describe cada comando IOCTL controlado por el controlador.

InitializeStealthMode

Luego de configurar con éxito su configuración, procesar devoluciones de llamada y filtros del sistema de archivos, el rootkit ejecuta su rutina de inicialización final: InitializeStealthMode. Si la marca de configuración Kbj_YinshenMode está habilitada, ocultará todos los artefactos asociados con el rootkit, incluidas las claves del Registro, el archivo .sys y otros componentes relacionados, empleando las mismas técnicas descritas anteriormente.

Variaciones de código

Si bien el malware se basa en gran medida en el código fuente HIDDENDRIVER , nuestro análisis identificó varias alteraciones menores. En la siguiente sección se desglosan las notables diferencias de código que observamos.

El código original de la función IsProcessExcluded excluye sistemáticamente el proceso del sistema (PID 4) de las operaciones del rootkit. Sin embargo, el rootkit malicioso tiene una lista de exclusión para nombres de procesos adicionales, como se ilustra en la captura de pantalla proporcionada.

La devolución de llamada del código original para filtrar la información del sistema (incluidos archivos, directorios y registros) usaba la función IsDriverEnabled para comprobar si las funcionalidades del controlador estaban habilitadas. Sin embargo, el rootkit observado introdujo una verificación automática adicional de la lista blanca para los procesos con el secuestro del nombre de imagen, que corresponde a la aplicación del espacio de usuario.

Uso de RMM

La herramienta GotoHTTP es una aplicación legítima de supervisión y administración remota (RMM), implementada por el actor de amenazas para mantener un acceso más fácil al servidor IIS comprometido. Su arquitectura "Browser-to-Client" permite al atacante controlar el servidor desde cualquier navegador sitio web estándar a través de puertos sitio web comunes (80/443) enrutando todo el tráfico a través de la propia plataforma de GotoHTTP, evitando la conexión directa de la red a la propia infraestructura del atacante.

Los RMM continúan aumentando en popularidad para su uso en múltiples puntos de la cadena de muerte cibernética y por varios actores de amenazas. La mayoría de los proveedores de antimalware no los consideran maliciosos de forma aislada y, por lo tanto, no los bloquean por completo. RMM C2 también fluye solo a sitios web legítimos de proveedores de RMM y, por lo tanto, tiene la misma dinámica para protecciones y monitoreo basados en la red.

Bloquear la masa de RMM actualmente activos y permitir solo el RMM preferido de la compañía sería el mecanismo de protección óptimo. Sin embargo, este paradigma solo está disponible para compañías con el conocimiento técnico adecuado, herramientas defensivas, políticas organizacionales maduras y coordinación entre departamentos.

Análisis del módulo IIS

Se observó que el actor de amenazas implementaba versiones de 32 bits y 64 bits de TOLLBOOTH, un módulo IIS malicioso. TOLLBOOTH fue discutido previamente por Ahnlab y el investigador de seguridad, @Azaka. Algunas de las capacidades clave del malware incluyen encubrimiento SEO, un canal de administración y un webshell de acceso público. Descubrimos que las versiones nativas y gestionadas por .NET se implementaban en la naturaleza.

Estructura de configuración de malware

TOLLBOOTH recupera su configuración dinámicamente de hxxps://c[.]cseo99[.]com/config/<victim_HTTP_host_value>.json, y la creación del archivo de configuración JSON de cada víctima es manejada por la infraestructura del actor de amenazas. Sin embargo, hxxps://c[.]cseo99[.]com/config/127.0.0.1.json respondió, mostrando una falta de comprobaciones anti-análisis, lo que nos permitió recuperar una copia de un archivo de configuración para su análisis. Se puede ver en este GitHub Gist y haremos referencia a cómo se usan algunos de los campos según corresponda.

Para los módulos nativos, la configuración y otros archivos de caché temporales se comprimen con Gzip y se almacenan localmente en una ruta codificada de forma rígida C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\. Para el módulo gestionado, estos están cifrados con AES con 0123456789ABCDEFde clave YourSecretKey123 e IV, comprimidos con Gzip y almacenados en C:\\Windows\\Temp\\AcpLogs\\.

Webshell

TOLLBOOTH expone un webshell en la ruta de /mywebdll , que requiere una contraseña de hack123456! para la carga de archivos y la ejecución de comandos. El envío de formularios envía una solicitud de POST al punto de conexión /scjg .

La contraseña está codificada en el binario, y esta característica de webshell está presente tanto en v1.6.0 como en v1.6.1 de la versión nativa de TOLLBOOTH.

La funcionalidad de carga de archivos contiene un error que se deriva de su análisis secuencial y dependiente del orden de multipart/form-data campos. El formulario HTML estándar está estructurado de tal manera que el campo de entrada del archivo aparece antes de los campos de entrada del directorio. El servidor que procesa las partes de la solicitud intenta controlar los datos del archivo antes que el directorio de destino, lo que crea un conflicto de dependencia que hace que se produzca un error en las cargas estándar. Al reordenar manualmente las partes multipart/form-data , aún se puede activar una carga de archivos exitosa.

Canal de gestión

TOLLBOOTH expone algunos puntos finales adicionales para fines de administración/depuración de operadores C2. Solo se puede acceder a ellos configurando el agente de usuario en uno de los siguientes (aunque es configurable):

Hijackbot
gooqlebot
Googlebot/2.;
Googlébot
Googlêbot
Googlebót;
Googlebôt;
Googlebõt;
Googlèbot;
Googlëbot;
Binqbot
bingbot/2.;
Bíngbot
Bìngbot
Bîngbot
Bïngbot
Bingbót;
Bingbôt;
Bingbõt;

El punto de conexión /health proporciona una forma rápida de evaluar el estado del módulo, devolviendo el nombre del archivo para acceder a la configuración almacenada en c[.]cseo99[.]com, la información del espacio en disco, la ruta de instalación del módulo y la versión de TOLLBOOTH.

El punto de conexión /debug proporciona más detalles, incluido un resumen de la configuración, el directorio de caché, la información de solicitud HTTP, etc.

Se puede acceder a la configuración analizada en /conf.

El punto final /clean permite al operador borrar la configuración actual eliminando los archivos de configuración almacenados localmente (clean?type=conf) para actualizarlos en el servidor de la víctima, borrar cualquier otro caché temporal que use el malware (clean?type=conf) o borrar ambos, todo en la ruta de C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ (clean?type=all).

Encubrimiento SEO

El objetivo principal de TOLLBOOTH es el encubrimiento SEO, un proceso que consiste en presentar contenido optimizado para palabras clave a los rastreadores de los motores de búsqueda, mientras lo oculta de la navegación casual del usuario, para lograr clasificaciones de búsqueda más altas para la página. Una vez que un visitante humano hace clic en el enlace de los resultados de búsqueda mejorados, el malware lo redirige a una página maliciosa o fraudulenta. Esta táctica es una forma efectiva de aumentar el tráfico a páginas maliciosas en comparación con alternativas como el phishing directo, porque los usuarios confían más en los resultados de los motores de búsqueda que aplicar que en los emails no aplicar.

TOLLBOOTH diferencia entre bots y visitantes comprobando los encabezados User Agent y Referer para los valores definidos en la configuración.

Tanto los módulos nativos como los gestionados se implementan de manera casi idéntica. La única diferencia es que los módulos nativos v1.6.0 y v1.6.1 comprueban tanto el agente de usuario como el referente con la lista de seoGroupRefererMatchRules , y el módulo .NET v1.6.1 comprueba el agente de usuario con la lista de seoGroupUaMatchRules y el referente con la lista de seoGroupRefererMatchRules .

Según la configuración actual, los valores de seoGroupUaMatchRules y seoGroupRefererMatchRules son googlebot y google, respectivamente. Un rastreador de GoogleBot tendría una coincidencia de agente de usuario y no una coincidencia de referencia, mientras que un visitante humano tendría una coincidencia de referencia pero no una coincidencia de agente de usuario. Mirar la lista de respaldo que contiene tanto bing como yahoo sugiere que esos motores de búsqueda también fueron atacados en el pasado.

El fragmento de código a continuación es responsable de crear una página llena de enlaces llenos de palabras clave que verán los rastreadores de los motores de búsqueda.

El módulo construye una granja de enlaces en dos fases. En primer lugar, para crear densidad de vínculos internos, recupera una lista de palabras clave aleatorias de los URI de recursos definidos en el campo de configuración affLinkMainWordSeoResArr . Para cada palabra clave, genera un "enlace local" que apunta a otra página de SEO en el mismo sitio web comprometido. A continuación, construye la red externa recuperando "recursos de enlace de afiliados" del campo affLinkSeoResArr . Estos recursos son una lista de URI que apuntan a páginas de SEO en otros dominios externos que también están infectados con TOLLBOOTH. Los URI se parecen hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> en la configuración. Luego, el módulo crea hipervínculos desde el sitio actual a estas otras víctimas. Esta técnica, conocida como link farming, está diseñada para inflar artificialmente las clasificaciones de los motores de búsqueda en toda la red de sitios comprometidos.

A continuación se muestra un ejemplo de lo que vería un bot rastreador al visitar la página de destino de un servidor sitio web infectado con TOLLBOOTH.

Los prefijos de ruta de URL de las páginas de SEO contienen palabras o frases del campo de configuración seoGroupUrlMatchRules . También se hace referencia a esto en la lógica de redirección del sitio dirigida a los visitantes. Estos son actualmente:

• stock
• invest
• summary
• datamining
• market-outlook
• bullish-on
• news-overview
• news-volatility
• video/
• app/
• blank/

Las plantillas y el contenido de las páginas de SEO también se recuperan externamente de los URI que se parecen hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> en la configuración. Aquí hay un ejemplo de cómo se ve una de las páginas de SEO:

Para la lógica de redirección de usuarios, el módulo primero recopila una huella digital del visitante, incluida su dirección IP, agente de usuario, referente y la palabra clave objetivo de la página SEO. Luego envía esta información a través de una solicitud POST a hxxps://api[.]aseo99[.]com/client/landpage. Si la solicitud se realiza correctamente, el servidor responde con un objeto JSON que contiene un landpageUrlespecífico, que se convierte en el destino de la redirección.

Si la comunicación falla por cualquier motivo, TOLLBOOTH recurre a la construcción de una nueva URL que apunta al mismo punto final C2, pero en su lugar codifica la información del visitante directamente en la URL como parámetros GET. Finalmente, la URL elegida, ya sea de la respuesta exitosa de C2 o de la alternativa, se incrusta en un fragmento de JavaScript (window.location.href) y se envía al navegador de la víctima, lo que obliga a una redirección inmediata.

Secuestrador de páginas

Para los módulos nativos, si la ruta de URI contiene xlb, TOLLBOOTH responde con una página de cargador personalizada que contiene una etiqueta de script. El atributo src de este script apunta a una URL generada dinámicamente, mlxya[.]oss-accelerate[.]aliyuncs[.]com/<12_random_alphanumeric_characters>, que se emplea para recuperar una carga útil de JavaScript ofuscada de la siguiente etapa.

La carga útil desofuscada parece ser una herramienta de reemplazo de página que se ejecuta en función de palabras clave de activación específicas (por ejemplo, xlbh, mxlb) que se encuentran en la URL. Una vez activado, se pone en contacto con uno de los puntos finales controlados por el atacante en asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= o ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key=, anexando la URL de la página actual como un parámetro codificado en Base64 para identificar el sitio comprometido. Luego, el script usa document.write() para borrar completamente el DOM de la página actual y reemplazarlo con la respuesta del servidor. Si bien la carga útil final no se pudo recuperar en el momento de escribir este artículo, esta técnica está diseñada para inyectar contenido controlado por el atacante, más comúnmente una página HTML maliciosa o una redirección JS a otro sitio malicioso.

Segmentación de campañas

Al realizar el análisis de TOLLBOOTH y su webshell asociado, identificamos múltiples mecanismos para identificar víctimas adicionales a través de métodos de cobro activos y semipasivos.

Luego nos asociamos con @SreekarMad de Validin para aprovechar su experiencia y su infraestructura de escaneo en un esfuerzo por desarrollar una lista más completa de víctimas.

En el momento de la publicación, se identificaron 571 víctimas del servidor IIS con infecciones activas de TOLLBOOTH.

Estos servidores están distribuidos globalmente (con una excepción importante, que se describe a continuación) y no encajan en ningún cubo vertical de la industria. Por estas razones, junto con la gran escala de la operación, se nos hace creer que la selección de víctimas no es dirigida y aprovecha el escaneo automatizado para identificar servidores IIS que reutilizan claves de máquina listadas públicamente.

La colaboración con Validin y Texas A&M System Cybersecurity produjo una gran cantidad de metadatos sobre las víctimas adicionales infectadas por TOLLBOOTH.

También se puede emplear la explotación automatizada, pero TAMUS Cybersecurity señaló que la actividad posterior a la explotación parecía ser interactiva.

Validin descubrió otros dominios potencialmente infectados vinculados a través de las configuraciones de enlaces de agricultura de SEO, pero cuando se comprobó la interfaz de webshell, la encontró inaccesible en algunos. Luego de realizar una investigación manual más profunda de estos servidores, determinamos que fueron, de hecho, infectados por TOLLBOOTH, pero los propietarios solucionaron el problema o los atacantes se echaron atrás.

El análisis posterior reveló que muchos de los mismos servidores se reinfectaron. Tomamos esto para indicar que la remediación fue incompleta. Una explicación plausible es que simplemente eliminar la amenaza no cierra la vulnerabilidad que deja abierta la reutilización de la clave de la máquina. Por lo tanto, es probable que las víctimas que omitan este paso final se vuelvan a infectar a través del mismo mecanismo. Consulte la sección "Corrección de REF3927" a continuación para obtener más detalles.

Geografía

La distribución geográfica de las víctimas excluye notablemente cualquier servidor dentro de las fronteras de China. Se identificó un servidor en Hong Kong, pero albergaba un dominio .co.uk . Este probable geofencing se alinea con los patrones de comportamiento de otras amenazas criminales, donde implementan mecanismos para garantizar que no apunten a los sistemas en sus países de origen. Esto mitiga su riesgo de enjuiciamiento, ya que los gobiernos de estos países tienden a hacer la vista gorda, si no a respaldar abiertamente, la actividad delictiva dirigida a extranjeros.

Modelo Diamante

Elastic Security Labs emplea el modelo Diamond para describir las relaciones de alto nivel entre adversarios, capacidades, infraestructura y víctimas de intrusiones. Si bien el modelo Diamond se usa más comúnmente con intrusiones individuales y aprovecha los subprocesos de actividad (sección 8) para crear relaciones entre incidentes, un adversario centrado (sección 7.1.4) permite un solo diamante.

Remediando REF3927

La corrección de la infección en sí se puede completar a través de las mejores prácticas de la industria, como volver a un estado limpio y abordar el malware y los mecanismos de persistencia. Sin embargo, frente a un posible escaneo y explotación automatizados, la vulnerabilidad de la clave de máquina reutilizada permanece para cualquier mal actor que quiera apoderar del servidor.

Por lo tanto, la corrección debe incluir la rotación de claves de máquina a una nueva clave generada correctamente .

Conclusión

La campaña de REF3927 destaca cómo un simple error de configuración, como el uso de una clave de máquina expuesta públicamente, puede conducir a un compromiso significativo. En este evento, Texas A&M University System Cybersecurity y el cliente afectado tomaron medidas rápidas para remediar el servidor, pero según nuestra investigación, sigue habiendo otras víctimas atacadas con las mismas técnicas.

La integración del actor de amenazas de herramientas de código abierto, software RMM y un controlador malicioso es una combinación efectiva de técnicas que demostraron ser exitosas en sus operaciones. Los administradores de entornos de IIS expuestos públicamente deben auditar sus configuraciones de claves de máquina, garantizar un registro de seguridad estable y aprovechar las soluciones de detección de endpoints como Elastic Defend durante posibles incidentes.

Lógica de detección

Reglas de detección

• Detección de Sitio web Shell: Proceso de script secundario de procesos sitio web comunes

Normas de prevención

• Ejecución sospechosa a través de los servicios de Windows
• Posible inyección de Shellcode a través de un WebShell
• Ejecución desde directorio sospechoso

Firmas YARA

Elastic Security creó las siguientes reglas de YARA para evitar el malware observado en REF3927:

• Windows.Trojan.Tollbooth
• Windows.Trojan.HiddenCli
• Windows.Trojan.HiddenDriver

REF3927 a través de MITRE ATT&CK

Elastic usa el marco MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas emplean contra las redes empresariales.

Táctica

La táctica representa el porqué de una técnica o subtécnica. Es el objetivo táctico del adversario: la razón para realizar una acción.

• Acceso inicial
• Ejecución
• Evasión de defensa
• Acceso a credenciales
• Colección
• Exfiltración

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Exploit Public-Facing Application
• Componente de software de servidor: Componentes de IIS
• Volcado de credenciales de SO
• Hide Artifacts: Hidden Files and Directories
• Datos del sistema local
• Rootkit
• Cuentas válidas

Observaciones

En esta investigación se discutieron los siguientes observables .

Referencias

A lo largo de la investigación anterior se hizo referencia a lo siguiente:

• https://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/
• https://asec.ahnlab.com/en/87804/
• https://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/
• https://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters
• https://github.com/ekkoo-z/z-godzilla_ekp
• https://x.com/azakasekai_/status/1969294757978652947

Adenda

HarfangLab publicó su borrador de investigación sobre esta amenaza el mismo día en que se publicó esta publicación. En él, hay información complementaria adicional:

• https://x.com/securechicken/status/1980715257791193420
• https://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/