lightbulbs in combat
Búsqueda de Ciberamenazas

Abuso del acceso web de RD: cómo contraatacar

Perspectivas y recomendaciones de investigación a partir de un reciente cúmulo de casos de respuesta a incidentes

Desde el comienzo de 2024, el equipo de Detección y Respuesta Gestionadas (MDR) de Sophos X-Ops ha respondido a múltiples incidentes en los que el vector de acceso inicial se ha identificado como un portal expuesto de acceso web al Escritorio Remoto de Microsoft que carecía de protección de autenticación multifactor (MFA). Este artículo proporciona una idea general de lo que hemos observado cuando se abusa de este portal, aporta información sobre cómo llevamos a cabo estas investigaciones y ofrece algunas recomendaciones y estrategias de mitigación para ayudar a cualquier otra persona que pueda encontrarse (o simplemente anticiparse) a la misma situación.

¿Qué es el portal de acceso web de RD?

La arquitectura de los Servicios de Escritorio Remoto de Microsoft se compone de varios roles distintos, como se muestra en la Figura 1.

Una captura de pantalla que muestra seis funciones distintas dentro de la arquitectura RDA
Figura 1: ejemplo de las funciones instaladas en un host expuesto de Servicios de Escritorio Remoto (RDS)
  • El rol Agente de conexión a Escritorio remoto (Agente de conexión a RD) gestiona las conexiones entrantes de escritorio remoto a las granjas de servidores RD Session Host y enruta las conexiones a un host adecuado.

  • El rol Puerta de enlace de Escritorio remoto (Puerta de enlace a RD) es responsable de conceder a los usuarios de redes públicas acceso a los escritorios y aplicaciones Windows alojados en el clúster RDS. Este rol suele instalarse en el mismo host que el rol Acceso web a RD, del que se habla más adelante.

  • El rol Licencias de Escritorio remoto (Licencias de RD) gestiona las licencias de usuario y permite a los usuarios conectarse a los servidores RD Session Host que alojan los escritorios virtuales o las aplicaciones.

  • Por último, el portal de inicio de sesión de Acceso web a Escritorio remoto (Acceso web a RD) es el medio por el que los usuarios y en estas investigaciones los actores de la amenaza, se autentifican y llegan en última instancia al Host de Sesión de Escritorio Remoto (RD Session Host), que es el objetivo en esta fase. Desde el host de Sesión RD, se pueden lanzar diversos tipos de actividades, ya que el atacante ha conseguido en ese punto acceder al interior del sistema. El MITRE ATT&CK lo clasifica como T1133, Acceso Inicial y Servicios Remotos Externos.

Este artículo se centra en los roles Puerta de enlace a RD, Acceso web a RD y RD Session Host. Para una visión más amplia de cómo se puede abusar del Protocolo de Escritorio Remoto (RDP) y cómo lo hacen los atacantes, consulta la serie sobre RDP que publicamos a principios de este año.

¿Qué ocurre cuando se abusa del Acceso web a RD?

Cuando un host de Acceso web a RD está expuesto a Internet, permite a los usuarios iniciar sesión con sus credenciales de dominio para acceder a un host de sesión RD o a una aplicación virtualizada que les permite trabajar desde cualquier lugar y acceder a recursos empresariales críticos. Si estos servidores no están adecuadamente protegidos al estar expuestos directamente a Internet, pueden ser objeto de abuso por parte de actores de amenazas para acceder a un dominio. Los portales de inicio de sesión suelen forzarse para obtener credenciales de usuario legítimas, que luego se utilizan para iniciar sesión, crear persistencia e intentar escalar privilegios o incluso moverse lateralmente dentro del patrimonio.

La página de inicio de sesión por defecto descrita en el texto
Figura 2: página de inicio de sesión por defecto de un portal de Acceso web a RD

Tras una autenticación correcta, al usuario se le presentarán opciones para conectarse a un RD Session Host publicado o a una aplicación virtual. Si solo se presentaran aplicaciones virtuales, un actor malicioso necesitaría “salirse” de la aplicación contenida para ejecutar código en el host subyacente.

Una pantalla que muestra que el servicio sólo tiene una aplicación publicada, y esa es Calc
Figura 3: un portal web RD que presenta solo una aplicación virtual publicada

El ejemplo de la Figura 3 muestra un portal Web RD en el que solo se ofrece una aplicación, la calculadora de Windows. Una vez que el usuario seleccione la aplicación, se descargará un archivo .RDP preconfigurado para lanzar la aplicación Calculadora. Dado que en este caso no existe la opción de conectarse a un Host de Sesión RD publicado, el objetivo de los actores de amenazas en esta situación es determinar una forma de ejecutar código en el servidor remoto que aloja la aplicación de la calculadora.

Una técnica que ha sido observada por MDR aprovecha la funcionalidad integrada de Accesibilidad de Windows para obtener acceso a un símbolo del sistema. Cuando la ventana de la aplicación Calculadora tiene el foco, el actor puede pulsar la tecla Mayúsculas de su teclado cinco veces para que aparezca el prompt de Teclas especiales. Este indicador se cargará desde el host remoto de la Sesión RD. Dentro de la ventana de Teclas especiales, hay una opción para iniciar el elemento del Panel de control de opciones de accesibilidad. Esto inicia el Panel de Control de Windows, que en la mayoría de los casos hará que el Panel de Control clásico se cargue en una ventana del Explorador de Windows. Desde la barra de búsqueda del Explorador de Windows, el actor puede ahora simplemente escribir “cmd.exe” y pulsar intro para cargar un símbolo del sistema interactivo en el host de la Sesión RD y comenzar a actuar sobre sus objetivos.

Si se le presenta la opción de conectarse a un RD Session Host, el actor se conectará directamente a una Sesión de Escritorio Remoto interactiva con una experiencia de usuario gráfica, desde la que podrá seguir persiguiendo sus objetivos. Cuando se establece una conexión directa desde el host de Acceso Web RD a cualquiera de los hosts de sesión, los registros de autenticación mostrarán un inicio de sesión RDP interactivo desde el host de Acceso Web RD, aunque este sirve como proxy para la conexión desde la máquina del actor al RD Session Host.

En cuatro de los cinco incidentes de Acceso web a RD que MDR analizó para este artículo, el equipo de MDR respondió a detecciones activadas en la fase de descubrimiento del ataque, cuando el actor o actores de la amenaza ejecutaron el comando “nltest / domain_trusts” para enumerar si existía alguna confianza de Active Directory en los objetivos. El quinto caso que analizamos también se activó con este comportamiento, pero primero se disparó con un evento diferente, exclusivo de ese caso. Los actores suelen ejecutar comandos de descubrimiento para comprender mejor el entorno y la infraestructura subyacente del dominio Active Directory al que han conseguido acceder.

Una captura de pantalla que muestra varios comandos registrados
Figura 4: ejemplos de comandos de descubrimiento tras una conexión exitosa

Tras la investigación de estos incidentes, el equipo de MDR observó intentos constantes de fuerza bruta dirigidos al proceso IIS que sirve al portal de Acceso web a RD, que finalmente dieron lugar a que el actor de la amenaza obtuviera acceso.

Una captura de pantalla que muestra una serie de intentos de fuerza bruta contra IIS
Figura 5: ejemplos de actividad de fuerza bruta contra el proceso IIS de RDWebAccess

A lo largo de la fase de triaje de la respuesta a un incidente, el equipo de MDR toma las medidas adecuadas para desactivar a los usuarios afectados y desconectar las sesiones activas para contener la amenaza lo antes posible. Si varias cuentas muestran signos de compromiso, MDR también aislará el host de Acceso web a RD para, en última instancia, detener cualquier acceso posterior a través de ese vector de acceso inicial. El equipo de MDR hace uso de numerosas consultas para ayudar en el proceso de investigación y ha incluido muchas de ellas en la siguiente sección de la Guía de Investigación.

Guía de Investigación

En esta sección, proporcionamos una serie de consultas que los investigadores pueden utilizar en casos en los que se sospeche un abuso del Acceso web a RD. Las consultas de esta sección han sido desarrolladas por el equipo de MDR de Sophos y pueden ejecutarse en el portal de Sophos Central, navegando al Centro de análisis de amenazas -> Live Discover. Para los lectores que no utilicen actualmente Sophos Central, los consejos generales siguen siendo válidos, pero los procesos deben llevarse a cabo según la tecnología que utilices.

Identificar portales de Acceso web a RD expuestos mediante OSINT

A menudo, una revisión de las superficies de ataque externas revela numerosos servicios que están expuestos a Internet. La siguiente búsqueda en Shodan puede identificar servidores RDWeb expuestos.

hostname:<insert company domain name here> path=/RDWeb/

Identificar servidores RD Gateway mediante Live Query

Los servidores RD Gateway pueden identificarse por la presencia del servicio Remote Desktop Gateway denominado ‘TSGateway’. Se trata de una consulta endpoint, por lo que tendrás que seleccionar todos los servidores en línea dentro de Sophos Central Live Discover para ver qué hosts tienen instalado el rol RD Gateway.

SELECT
    name,
    display_name,
    start_type,
    path,
    status
FROM services
WHERE name = 'TSGateway'

Revisar los registros de RD Gateway

Una vez que se haya determinado que un host gestionado está ejecutando la función RD Gateway, puedes aprovechar la consulta que aparece a continuación a través de Sophos Central Live Discover para obtener los eventos de conexión más recientes de los registros de eventos de Windows de RD Gateway. Estos registros devolverán los eventos de conexión y desconexión del usuario afectado y revelarán la dirección IP de origen remoto responsable de la conexión a la sesión. Una vez determinada la dirección IP de origen, se recomienda encarecidamente que la bloquees en el perímetro de tu red. Se trata de una consulta endpoint, por lo que tendrás que seleccionar solo los hosts que se mostraron en la consulta anterior (Identificar servidores RD Gateway utilizando Live Query) para que ejecuten el rol RD Gateway.

SELECT
strftime('%Y-%m-%d %H:%M:%S',swe.datetime) AS Datetime,
swe.time,
swe.eventid AS EventID,
CASE 
WHEN eventid = 200 THEN 'Client Connected' 
WHEN eventid = 303 THEN 'Client Disconnected'
END AS Description,
JSON_EXTRACT(swe.data, '$.UserData.Username') AS Username,
JSON_EXTRACT(swe.data, '$.UserData.AuthType') AS AuthType,
JSON_EXTRACT(swe.data, '$.UserData.IpAddress') AS IpAddress,
JSON_EXTRACT(swe.data, '$.UserData.Resource') AS Resource,
JSON_EXTRACT(swe.data, '$.UserData.BytesReceived') AS BytesReceived,
JSON_EXTRACT(swe.data, '$.UserData.BytesTransfered') AS BytesTransfered,
JSON_EXTRACT(swe.data, '$.UserData.SessionDuration') AS SessionDuration,
JSON_EXTRACT(swe.data, '$.UserData.ConnectionProtocol') AS ConnectionProtocol
FROM sophos_windows_events as swe
WHERE source = 'Microsoft-Windows-TerminalServices-Gateway/Operational'
AND eventid IN (200,303)
AND swe.time > $$starttime$$
--AND swe.time > )$$starttime$$ AND swe.time < $$endtime$$
ORDER BY swe.time

Observa la información sobre la fecha y la hora al final de la consulta. Deberá ajustarse al marco temporal de la investigación. En la GUI de Sophos Central, se puede seleccionar utilizando el tipo de variable de fecha; haz clic en el calendario para seleccionar las horas de inicio y fin.

Revisar los registros de IIS

Por defecto, IIS escribe sus registros en UTC y utiliza el formato ‘AAAA-MM-DD hh:mm:ss’. Los minutos y los segundos se han omitido intencionadamente en el siguiente patrón grep, para que capturemos una hora completa de registros en torno a los eventos de inicio de sesión. También tendrás que actualizar el valor ‘file.path’ para que refleje la fecha del registro de IIS que quieres revisar. El formato para esto es simplemente AAMMDD (por ejemplo, 240223 para el 23 de febrero de 2024).

Una vez que hayas ejecutado la consulta anterior y conozcas la fecha y hora de los inicios de sesión correctos de los registros de eventos de la pasarela RD, puedes modificar la consulta siguiente para obtener los registros IIS circundantes. Esto te dará datos sobre la hora de inicio de sesión en IIS, y sobre lo que el actor podría haber pulsado mientras estaba conectado al portal web. Como la dirección IP de origen se conoce por los resultados de la consulta anterior, esa información también puede utilizarse como filtro “grep.pattern” para mostrar todos los registros IIS que contengan esa dirección. Se trata de una consulta endpoint, por lo que tendrás que seleccionar el host específico dentro de Sophos Central Live Discover.

SELECT grep.*
FROM file
CROSS JOIN grep ON (grep.path = file.path)
WHERE
file.path LIKE 'C:\inetpub\Logs\LogFiles\W3SVC%\u_exYYMMDD.log'
AND grep.pattern = 'YYYY-MM-DD hh: '

Revisar en busca de indicios de actividad de fuerza bruta

Los intentos de fuerza bruta hacia un portal Web RD pueden verse filtrando los eventos de inicio de sesión al proceso Windows IIS, w3wp.exe, como se ve en la Figura 5 (arriba, sección anterior). Se trata de una consulta del lago de datos de Sophos Central; al igual que con la consulta para revisar los registros del portal RD (arriba), las opciones de intervalo de tiempo para acotar la consulta se pueden configurar desde la GUI central.

SELECT
meta_hostname, date_format(from_unixtime(CAST(event_timestamps AS bigint)), '%Y-%m-%d %H:%i:%S') AS event_timestamp, eventid, subject_username, subject_domain, target_username, target_domain, target_logon_id, subject_logon_id, logon_type, logon_process, authentication_package, transmitted_services, key_length, name, remote_address, remote_port, description, provider_name, source
FROM
xdr_data
WHERE
event_timestamps NOT LIKE '%,%'
AND 
query_name IN ('windows_event_successful_logon','windows_event_invalid_logon')
AND name LIKE '%w3wp.exe%'
AND meta_hostname = '$$hostname$$'

Lista de aplicaciones publicadas en RD Web a través del Registro de Windows

Revisa el Registro de Windows para obtener una lista de aplicaciones publicadas o hosts de sesión, junto con las restricciones de permisos que puedan existir para esos elementos de la lista. Se trata de una consulta endpoint, por lo que tendrás que seleccionar el host específico dentro de Sophos Central Live Discover.

SELECT path, data, type, strftime('%Y-%m-%d %H:%M:%S',datetime(mtime,'unixepoch')) AS modified_time
FROM registry
WHERE path LIKE 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\%%'

Revisar el historial de cuentas comprometidas en todo el dominio

Una vez identificada una cuenta comprometida que inicia sesión a través del portal Web RD, se puede utilizar la siguiente consulta para investigar la actividad del usuario. Esto te ayuda a descubrir si el actor de la amenaza se ha trasladado a otros hosts de la red en función de los resultados. Esta es una consulta del lago de datos de Sophos Central. Ten en cuenta que tendrás que proporcionar el nombre de usuario completo en la penúltima línea de la consulta.

SELECT
 meta_hostname,
 date_format(from_unixtime(time), '%Y-%m-%d %H:%i:%s') as date_time,
 username, cmdline, name, path, sophos_pid, parent_name,parent_cmdline,parent_path, parent_sophos_pid, uid, gid,file_size, sha1, sha256
 FROM
 xdr_ext_data
 WHERE
 query_name = 'running_processes_windows_sophos'
 AND username = '$$username$$'
 ORDER BY date_time DESC

Recopilar información sobre la cuenta comprometida

La siguiente consulta del lago de datos de Sophos Central puede utilizarse para obtener más información sobre la cuenta comprometida.

SELECT
meta_hostname,uid, gid, username, description, directory, shell, type, uuid
FROM
xdr_data
WHERE
query_name = 'user_accounts'
AND username = ‘$$username$$’

Junto con la consulta anterior, estos comandos PowerShell pueden utilizarse para examinar un usuario de dominio o local con el fin de obtener más propiedades de la cuenta de usuario, como el último cambio de contraseña, la cuenta habilitada, etc. Al igual que con la consulta anterior, ten en cuenta que tendrás que proporcionar el nombre de usuario completo en la penúltima línea de la consulta.

Acciones de Respuesta MDR

Los incidentes relacionados con un host de Acceso web a RD expuesto requieren que se tomen medidas rápidas para neutralizar la amenaza antes de que se produzca cualquier movimiento lateral. Por ello, nuestro equipo de MDR suele realizar las siguientes acciones de respuesta para llevar los sistemas comprometidos a un estado de contención lo antes posible.

  • Aislar los hosts afectados, incluido el RD Gateway, para detener nuevos intentos de autenticación contra el portal de acceso expuesto

  • Anotar y bloquear la dirección IP de origen que se utilizó para iniciar sesión ilegítimamente en el portal

  • Desactivar los usuarios de dominio afectados

  • Bloquear los hashes ejecutables maliciosos en Sophos Central

  • Implementar políticas de control de aplicaciones en Sophos Central para restringir la ejecución de herramientas de las que se suele abusar

  • Enviar archivos maliciosos y desconocidos a SophosLabs para que los clasifique y cree nuevas detecciones

Recomendaciones y estrategias de mitigación

Aunque el Acceso web a RD es útil como medio para que los usuarios se conecten a recursos empresariales desde ubicaciones remotas, hay algunas recomendaciones críticas que deben aplicarse para reducir la superficie de ataque de los sistemas expuestos. Las tres acciones siguientes, ejecutadas antes de un ataque, pueden mitigar la eficacia del mismo:

  • Implantar la autenticación multifactor y asegurarse de que se aplica a todos los usuarios del dominio.

  • Revisar la configuración de las aplicaciones publicadas y los hosts de Sesión de RD para asegurarse de que solo se han publicado los elementos esperados y aprobados, y solo a los usuarios que se espera que tengan acceso a ellos. Considera la posibilidad de crear un objeto de política de grupo para denegar el acceso a cmd.exe y PowerShell a todos los usuarios que no lo necesiten.

  • Si es posible, restringe el acceso a Internet al portal de acceso solo a las direcciones IP de origen aprobadas.

Si no se pueden aplicar las recomendaciones y estrategias de mitigación anteriores y debes seguir utilizando un clúster RDS, considera la posibilidad de proteger el portal de Acceso web a RD detrás de una VPN, con MFA activada y aplicada. Esto evita la exposición directa del portal a Internet y reduce así la superficie de ataque de la aplicación expuesta.

Conclusión

El análisis de la popularidad actual del abuso del Acceso web a RD o de qué actor(es) de amenaza podría(n) estar eligiendo esta técnica, está fuera del alcance de este artículo. Sin embargo, señalamos que el acceso a Escritorio Remoto sin protección a través de Internet es una mala elección conocida, al igual que la falta de MFA en los sistemas que vimos. Artículos como este no pretenden avergonzar a las víctimas de los ataques; más bien, esperamos proporcionar información sobre cómo investigar tales incursiones, al tiempo que animamos a los lectores a seguir las prácticas recomendadas de seguridad y, tal vez, evitar acabar en esta situación.