Remote Desktop Protocol : Comment utiliser l’écart de fuseau horaire (Time Zone Bias) ?

La plupart des défenseurs savent comment détecter et rechercher des mouvements latéraux RDP suspects, qu’il s’agisse d’une recherche basée sur des utilisateurs connus comme compromis ou sur une alerte provenant d’un antimalware ou de protections EDR associée à un utilisateur spécifique. Vous commencez à avoir la certitude que quelque chose ne va pas : mais quoi exactement ?

L’examen des logs pour vérifier l’horodatage des activités du compte est un moyen classique de détecter un comportement suspect : par exemple, James depuis le siège social se connecte à un contrôleur de domaine à 3h du matin, alors qu’il n’accède généralement qu’aux serveurs Sage, et ce uniquement pendant les heures de bureau. Cependant, il y a bien plus à découvrir sur les connexions : à savoir pas seulement quand l’activité a eu lieu, mais en vérifiant aussi le fuseau horaire d’où l’activité provient. C’est ce qu’on appelle l’écart (‘bias’), et il est capturé sur les versions modernes (Windows 10 / Server 2016 et versions ultérieures) du système d’exploitation de Microsoft. L’ID d’événement 104 est disponible dans les logs de ‘Microsoft Windows Remote Desktop Services RDP Core TS Operational’.

Que voit exactement le défenseur ?

Comme son nom l’indique, cet événement journalise l’écart de fuseau horaire (time-zone bias) par rapport à l’UTC de la machine établissant la connexion. Puisque vous connaissez probablement déjà le(s) fuseau(x) horaire(s) à partir duquel/desquels vos utilisateurs se connecteraient normalement, voir les écarts par rapport à cette zone peut vous aider à identifier les connexions RDP suspectes, simplement parce qu’elles ne proviennent pas de la zone du monde où elles devraient se trouver.

En reprenant James comme exemple, disons que ce dernier est basé à Londres et que vous investiguez une activité suspecte ayant eu lieu au cours des premiers mois de l’année. En janvier ou février, l’écart de fuseau horaire pour James était de zéro heure UTC, donc si James utilise le RDP afin de se connecter au réseau pour une raison quelconque, le décalage temporel du client que vous devriez voir apparaître au niveau des connexions est [0]. Si, soudainement, vous commencez à voir des écarts de fuseau horaire client de [-8] ou [6], ou d’autres valeurs qui diffèrent de la norme pour James, cela pourrait vous aider à détecter les connexions RDP potentiellement suspectes, ou au minimum vous inciter à vous poser d’autres questions essentielles (est-ce qu’il est en déplacement ? Sa machine a-t-elle été volée ?).

Prenons un exemple où les identifiants d’un utilisateur ont été attaqués par phishing, l’attaquant est connecté au VPN, parce que vous n’avez pas activé le MFA, alors que vous savez que vous auriez dû le faire, et il commence à accéder aux appareils à l’aide du RDP. Vous souhaitez consulter alors le fuseau horaire de cette machine attaquante concernant ces événements d’accès.

Il n’existe pas de requête unique qui donne toutes les réponses comme par magie, et celle-ci ne fait pas exception à la règle. Par exemple, les attaquants hébergent souvent leurs machines sur différentes autres machines, situées sur différents fuseaux horaires dans lesquels ils peuvent ou non se trouver physiquement. Et, ces derniers peuvent ne pas correspondre aux fuseaux horaires habituels de vos utilisateurs.

Une autre faiblesse potentielle réside dans les faux positifs. Si votre entreprise fonctionne d’une manière qui rend difficile la détermination d’un fuseau horaire “habituel”, il peut être plus difficile pour vous d’identifier la différence entre le signal et le bruit. Enfin, les faux négatifs sont aussi une possibilité : l’événement enregistre le fuseau horaire sur la machine de l’attaquant, afin que l’attaquant puisse compromettre cette donnée en modifiant le fuseau horaire sur cette machine. Cela dit, l’événement 104 est un événement très important à surveiller : un outil de plus à ajouter à votre arsenal de défenseur.

Écart de fuseau horaire (Time Zone Bias) et Live Discover

L’événement 104 est bien sûr accessible à toute personne examinant les systèmes Microsoft avec des anciennes versions prises en charge (encore une fois, Windows 10 / Server 2016 et versions ultérieures). Les informations contenues dans la dernière section de cet article sont fournies aux lecteurs qui utilisent la fonctionnalité ‘Live Discover’ de Sophos pour effectuer leur travail (néanmoins, nous publierons la requête dont nous allons discuter sur notre Github, afin de fournir une copie accessible à tous). Nous faisons également la démonstration de cette requête et montrons les résultats obtenus sur notre chaîne YouTube.

Pour exécuter une requête de système d’exploitation et renvoyer des informations concernant l’écart de fuseau horaire dans Live Discover, utilisez ce qui suit :

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) 

Le résultat de la requête ressemble aux résultats présentés dans la figure 1 :

Figure 1 : Soit l’utilisateur a découvert un moyen de se téléporter avec son ordinateur en traversant huit fuseaux horaires en 90 secondes, soit quelque chose ne va pas ici.

À gauche dans l’image ci-dessus, nous avons le nom du système endpoint : le même pour les deux entrées de ce log à deux événements. Nous voyons les informations date/heure en UTC, ce qui montre que les deux événements se sont produits à environ une minute et demie d’intervalle. La source est l’endroit où nous avons trouvé cet événement, qui est indiqué par 104 dans la colonne suivante. Et à droite, nous voyons le résultat : le premier événement d’origine à UTC 0, le deuxième à UTC +8, qui est la zone indiquée sur la carte de la figure 2.

Figure 2 : UTC +8 est une zone certainement intéressante, mais elle n’est certainement pas proche de James basé à Londres (image de la carte fournie par nationsgeo.com)

Nous vous recommandons d’exécuter cette requête sur tous les appareils de votre environnement : recherchez autour de vous et identifiez s’il existe des entrées en termes d’écart de fuseau horaire dans les logs ‘RDP Core TS Operational’ qui diffèrent de ce à quoi vous vous attendez à voir généralement.

Remote Desktop Protocol : Présentation de la série d’articles

Partie 1 : Remote Desktop Protocol : Introduction (article, vidéo)
Partie 2 : Remote Desktop Protocol : Un RDP accessible depuis Internet (est dangereux) (article, vidéo)
Partie 3 : Remote Desktop Protocol : Requêtes pour investigation (article, vidéo)
Partie 4 : RDP et écart de fuseau horaire/Time Zone Bias ([article en cours de lecture], vidéo)
Partie 5 : Exécution de la requête RDP externe (article, vidéo)
Partie 6 : Exécution de la requête Login 4624_4625 (article, vidéo)
Dépôt de requêtes sur GitHub : SophosRapidResponse/OSQuery
Dépôt de la transcription des vidéos : sophoslabs/video-transcripts
Playlist YouTube : Remote Desktop Protocol: Présentation de la série d’articles

Billet inspiré de Remote Desktop Protocol: How to Use Time Zone Bias, sur le Blog Sophos.