Étant donné que les investigateurs voient de nombreux artefacts RDP au cours des opérations de réponse aux incidents, ils ont naturellement développé quelques outils privilégiés pour rechercher de telles activités. Dans cet article, nous allons examiner de manière générale certaines des options qui s’offrent aux défenseurs. Dans la dernière partie de cette série, nous aborderons quelques-unes de nos solutions préférées, en passant en revue certaines des requêtes typiques utilisées par les investigateurs de Sophos X-Ops pour rendre ces dernières efficaces.
Tout d’abord, les défenseurs doivent se familiariser avec les événements de connexion de session locale 21 à 40, qui couvrent les ID typiques dans les logs d’événement opérationnel au niveau du ‘Terminal Services Local Session Manager’ qui affiche les connexions, les déconnexions, les reconnexions et les activités similaires. Ils doivent également connaître la requête 1149 RDP Logins, qui recherche dans les logs d’événement opérationnel du ‘Terminal Services Remote Connection Manager’ l’ID d’événement 1149 (comme son nom l’indique) afin de repérer les connexions RDP réussies.
Redondance ? Peut-être, mais pour une bonne raison. Il se peut que l’attaquant ait effacé l’un des logs d’événement mais pas l’autre, ce qui fait de cette potentielle différence un artefact intéressant (au cours de l’année 2023, l’équipe de réponse aux incidents de Sophos X-Ops a noté que les logs avaient été effacés dans environ 32 % des cas traités). Ou bien il se peut qu’il y ait eu une erreur lors de la journalisation (logging) de cet événement pour une raison quelconque, et qu’un log d’événement a été correctement traité mais pas l’autre. Puisque les deux logs existent, les interroger tous les deux n’est pas une perte de temps.
La requête appelée “RDP Logins from External IPs” est également utile pour détecter les activités inappropriées. Le nom indique clairement ce que fait la requête : elle recherche les connexions RDP à partir d’adresses IP externes, en vérifiant les deux logs d’événement que nous venons de mentionner (cette requête n’affichera pas les connexions entrant via un VPN, car ces connexions se voient attribuer des adresses provenant du pool IP VPN).
Une requête moins couramment utilisée et très utile pour les défenseurs est “4624_4625 Login Events”. Celle-ci recherche dans les logs d’événement de sécurité, comme son nom l’indique, les évènements 4624 (indiquant une connexion réussie) ou les évènements 4625 (indiquant un échec de connexion). Ces requêtes sont particulièrement utiles lors de la recherche de connexions au niveau du réseau : dans les logs, il s’agit d’une connexion de type 3. En revanche, une connexion RDP ou une connexion de type ‘Terminal Services‘ (interactivité à distance) est une connexion de type 10.
Lorsque nous recherchons un éventuel mouvement latéral RDP, cette requête peut nous aider à identifier les échecs de connexion lorsque le NLA (Network Level Authentication) est activé. Avec le RDP, si vous ne parvenez pas à vous connecter et que l’authentification au niveau du réseau ou NLA est activée, vous verrez apparaître le chiffre 4625 indiquant un échec au niveau d’une connexion de type 3.
La requête suivante sera utile lors de la recherche d’appareils sur lesquels le NLA n’est pas activé (pour faciliter le copier-coller, nous mettrons également une copie de cette requête et d’autres requêtes utiles sur notre Github) :
SELECT path, name, data, strftime('%Y-%m-%dT%H:%M:%SZ',datetime(mtime,'unixepoch')) AS last_modified_time FROM registry WHERE key LIKE 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' AND name = 'SecurityLayer' AND data = 0
L’utilisation de cette requête comme présenté peut être un peu déroutante, car il s’agit d’une connexion au niveau du réseau qui est généralement associée à un élément comme (par exemple) SMB, plutôt qu’à un événement qui montrerait un mouvement latéral via le RDP. Cependant, si le NLA est activé, le log affiche l’échec de la tentative : une connexion RDP a été tentée mais a échoué (4625). Un échec de connexion RDP où le NLA est activé apparaît comme une connexion de type 3, car elle s’authentifie au niveau du réseau avant d’établir la session RDP.
Voir des événements de connexion ayant échoué tels que ceux-ci peut vous alerter concernant des tentatives lancées sur votre réseau. Ils peuvent également vous alerter sur de mauvaises configurations au sein de votre environnement. Les investigateurs recherchent souvent des erreurs de configuration lorsqu’ils répondent aux incidents ; en particulier, la désactivation du NLA, ainsi que le paramètre “DisableRestrictedAdmin” pour le mode administrateur restreint, constituent une configuration mauvaise et dangereuse (et courante), car elle supprime plusieurs couches de protections potentielles. Les défenseurs peuvent donc utilement interroger le registre pour rechercher la clé et la valeur spécifiques qui indiquent que le NLA est désactivé, peut-être en trouvant et en corrigeant l’erreur avant que les problèmes n’apparaissent vraiment.
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 en cours de lecture], vidéo)
Partie 4 : RDP et écart de fuseau horaire (Time Zone Bias) (article, 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: Queries for Investigation, sur le Blog Sophos.
