La mayoría de los defensores están familiarizados con la forma de encontrar y buscar movimientos laterales RDP sospechosos, ya sea basándose en usuarios comprometidos conocidos o en una alerta de las protecciones antimalware o EDR asociadas a un usuario concreto. Estás empezando a pivotar desde el aviso inicial de que algo va mal; ¿y ahora qué?
Examinar los registros para comprobar las marcas de tiempo de actividad de las cuentas es una forma típica de detectar comportamientos extraños: por ejemplo, James, el de la oficina central, conectándose a un controlador de dominio a las 3 de la madrugada, cuando normalmente solo accede a los servidores de Sage, y estos solo en horario laboral. Sin embargo, hay más cosas que saber sobre los inicios de sesión: no solo cuándo se produjo la actividad, sino la zona horaria desde la que se originó. Esto se conoce como sesgo, y se captura en las versiones modernas (Windows 10 / Server 2016 y posteriores) del sistema operativo de Microsoft. El ID de evento 104 está disponible en el registro de eventos Operativo RDP Core TS de los Servicios de Escritorio Remoto de Microsoft Windows.
¿Qué ve el defensor?
Como cabría esperar por el nombre, este evento registra el desvío de la zona horaria respecto a UTC de la máquina que realiza la conexión. Como probablemente ya conozcas la(s) zona(s) horaria(s) desde la(s) que normalmente se conectan tus usuarios, ver las desviaciones de esa zona puede ayudarte a identificar conexiones RDP sospechosas, simplemente porque no proceden de la parte del planeta que deberían.
Tomando de nuevo a James como ejemplo, supongamos que James tiene su sede en Londres y que estás investigando una actividad sospechosa en los primeros meses del año. En enero o febrero, el sesgo de zona horaria para James sería de cero horas UTC, así que si James utiliza RDP para conectarse a la red por cualquier motivo, el sesgo de hora cliente que deberías ver en sus inicios de sesión es [0]. Si, de repente, empiezas a ver sesgos de zona horaria de cliente de [-8], o [6], u otros valores que difieran de la norma para James, eso podría ayudarte a detectar conexiones RDP potencialmente sospechosas o, como mínimo, más preguntas que valga la pena plantearse: ¿está de viaje? ¿le han robado la máquina?
Pongamos un ejemplo en el que las credenciales de un usuario han sido suplantadas, el atacante ha iniciado sesión en la VPN (porque no tienes activada la MFA, aunque sabes que deberías) y empieza a acceder a los dispositivos utilizando RDP. Entonces empezarías a ver la zona horaria de esa máquina atacante para esos eventos de acceso.
No hay una única consulta que dé mágicamente todas las respuestas. Por ejemplo, los atacantes suelen alojar sus máquinas en varios equipos, situados en varias zonas horarias en las que pueden o no estar físicamente ubicados. Aun así, es probable que difieran de las zonas horarias normales de tus usuarios.
Otro punto débil potencial reside en los falsos positivos; si tu organización funciona de un modo que hace difícil discernir cómo es una zona horaria “normal”, puede que te resulte más difícil precisar la diferencia entre señal y ruido. Por último, los falsos negativos son una posibilidad; el suceso registra la zona horaria de la máquina del atacante, por lo que éste puede socavar estos datos cambiando la zona horaria de esa máquina. Dicho esto, el Evento 104 es un evento beneficioso que debes vigilar: una herramienta más en tu caja de herramientas de defensa.
Sesgo de zona horaria y Live Discover
El evento 104 está disponible, por supuesto, para cualquiera que examine sistemas Microsoft de las versiones compatibles (de nuevo, Windows 10 / Server 2016 y posteriores). La información de la sección final de este post está destinada a aquellos lectores que utilicen Live Discover de Sophos para realizar su trabajo. No obstante, publicaremos la consulta que vamos a comentar en nuestro Github, donde cualquiera puede obtener una copia. También mostramos esta consulta y sus resultados en nuestro canal de YouTube.
Para ejecutar una consulta OS y devolver información sobre el sesgo de la zona horaria en Live Discover, utiliza lo siguiente:
SELECT strftime('%Y-%m-%dT%H:%M:%SZ',datetime) AS Datetime, source, eventid, JSON_EXTRACT(data, '$.EventData.TimezoneBiasHour') AS TimezoneBiasHour FROM sophos_windows_events WHERE source = 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational' AND eventid IN (104)
El resultado de la consulta es el que se muestra en la Figura 1:
A la izquierda de la imagen anterior, tenemos el nombre del endpoint, el mismo para ambas entradas de este registro de dos sucesos. Vemos la información de fecha/hora en UTC, que muestra que los dos sucesos ocurrieron con un minuto y medio de diferencia. La fuente es donde encontramos este evento, que se muestra como 104 en la siguiente columna. Y a la derecha, vemos el resultado: el primer suceso se originó en UTC 0, el segundo en UTC +8, que es la zona indicada en el mapa de la Figura 2.
Te recomendamos que ejecutes esta consulta en todos los dispositivos de tu entorno: echa un vistazo e identifica si hay entradas con sesgo de zona horaria en el registro de eventos RDP Core TS Operational que difieran de lo que normalmente esperarías.
Protocolo de escritorio remoto: la serie
Parte 1: Protocolo de escritorio remoto: introducción (post, vídeo)
Parte 2: RDP expuesto (es peligroso) (post, vídeo)
Parte 3: consultas para la Investigación (post, vídeo)
Parte 4: factor zona horaria RDP ([estás aquí], vídeo)
Parte 5: ejecución de la consulta RDP externa (post, vídeo)
Parte 6: ejecución de la consulta de inicio de sesión 4624_4625 (post, vídeo)
Repositorio de consultas en GitHub: SophosRapidResponse/OSQuery
Repositorio de transcripciones: sophoslabs/video-transcripts
Lista de reproducción de YouTube: Protocolo de escritorio remoto: la serie
Dejar un comentario