SOCKS over RDP: utilisation de soxy en environnement restreint

Dans le cadre d'un audit interne sur un environnement VDI (Virtuel Desktop Infrastructure) restreint, nous avons testé l'existence d'un nouvel outil permettant de proxifier du contenu à travers le protocole RDP pour contourner les règles de filtrage mises en place.

Découverte de SOXY

Il existe quelques outils pour réaliser ce type de communication. Notamment, SocksOverRDP, ica2tcp, ou encore rdp2tcp. Cependant, ces projets manquent de stabilité pour effectuer une mission sur le long terme.

C'est pour cela que récemment, l'équipe sécurité d'Airbus a créé l'outil soxy qui permet de résoudre ces problèmes de stabilité. Il a été présenté lors du SSTIC 2025, la vidéo de présentation est disponible ici avec les slides de présentation. Cet article se concentre sur l'usage de soxy pour établir une communication SOCKS. Cependant il est bien plus complet, pour découvrir toutes ces fonctionnalités, nous vous conseillons de lire le readme disponible sur la page github du projet.

Fonctionnement de SOXY : les canaux virtuels

Soxy se base sur les canaux virtuels du protocole RDP pour établir un proxy SOCKS. Pour résumer, un canal virtuel RDP est un tunnel de communication entre le client et le serveur RDP. Il peut être utilisé pour faire transiter des données spécifiques à côté du bureau à distance.

En détournant ce canal, il est possible d’y faire passer le trafic d’un proxy SOCKS : côté client, les connexions réseau sont redirigées vers ce canal virtuel, et côté serveur, une application reçoit les requêtes SOCKS et les exécute en établissant les connexions à la place du client. Ainsi le client peut faire passer son trafic réseau à travers la session RDP, comme un tunnel sécurisé, sans ouvrir de port supplémentaire sur le réseau.

Utilisation de SOXY

Le fonctionnement de l'outil repose sur deux éléments, le backend de soxy qui va être exécuté sur le VDI. Pour cela, le projet propose un binaire au format exécutable ou une librairie (DLL). Dans notre cas, nous utiliserons la DLL. Le second élément repose sur le frontend, qui va être déployé sur le client qui établit la connexion RDP sur le VDI.

Dans le cas de l'audit, c'est la suite offensive exegol qui sera utilisée avec le client xfreerdp. Il faudra ajouter la librairie libsoxy.so à l'outil xfreerdp pour pouvoir l'appeler lors de l'exécution.

L'outil xfreerdp est utilisé pour se connecter en RDP sur le serveur de rebond avec la ligne de commande suivante :

$ xfreerdp /u:<user> /p:<password> /v:<Serveur de rebond> /cert-ignore /dynamic-resolution /log-level:INFO /drive:pentest,/workspace /vc:soxy  

L'option /vc permet de préciser un canal virtuel à utiliser. Dans le cas suivant, c'est soxy qui est choisi.

De plus, un partage de fichier est monté entre la VM offensive et le serveur de rebond via l'option /drive pour accéder à la librairie soxy.dll. Cette DLL sera exécutée à distance ici, car nous avions rencontré des difficultés avec la solution de sécurité mise en place sur le serveur.

Maintenant, il est possible de communiquer avec d'autres protocoles que le protocole RDP depuis la VM Offensive en passant par le canal virtuel. Par exemple, le protocole SMB est maintenant atteignable avec l'exemple de NetExec ci-dessous, alors que ce protocole n'était pas accessible précédemment dû aux restrictions imposées par le VDI :

Nous avons maintenant un accès beaucoup moins restreint que précédemment, et donc nous pouvons communiquer avec ce serveur de rebond sur d'autres protocoles que le protocole RDP. De plus, cet accès nous permet de pivoter dans une nouvelle zone qui n'était pas disponible depuis la zone bureautique. Le schéma ci-dessous résume les actions réalisées pour obtenir cet accès distant :

Accès à des services web depuis le proxy SOCKS

Si derrière cette machine de rebond, d'autres serveurs avec des services web sont accessibles, il est possible de configurer l'outil Burp Suite pour accéder à ces services via le proxy SOCKS.

Pour cela, depuis l'onglet Proxy (1), il suffit de sélectionner l'option Proxy settings (2). Ensuite dans la liste de configurations disponible, il faut descendre jusque dans la table Network puis Connections (3). De là, il sera possible d'éditer la configuration du Proxy SOCKS de Burp disponible en bas de la page (4). Avant de fermer la fenêtre, bien vérifier que les options "Use SOCKS proxy" et "Do DNS lookup over SOCKS proxy" soient bien cochées.

Conclusion

L'utilisation de soxy démontre les limites réseaux, même dans des environnements strictement cloisonnés comme les infrastructures VDI avec des règles de filtrages complexes. Celle-ci peuvent être contournées en utilisant des options spécifiques du protocole RDP. En transformant une simple session bureau à distance en une passerelle, cet outil redonne la main aux auditeurs pour explorer des zones inaccessibles autrement et ainsi déployer leurs arsenal offensif à travers ce tunnel.

Cette technique permet également de proposer des types de missions différentes en mode Assumed Breach. Dans le cas où les conditions initiales de l'audit seraient telles qu'un attaquant ait réussi à obtenir les identifiants de connexion d'un utilisateur ayant accès à un serveur de type VDI. Ainsi, l'audit se concentrerait sur les ressources internes qui sont accessibles depuis cette instance pour évaluer le risque de ce scénario.

L'objectif de ce test ressemble à un test d'intrusion interne avec la nuance que celui-ci sera un peu plus scénarisé et composé d'objectifs définis au préalable sur la zone à auditer. Souvent ces zones ne sont pas observées lors des audit internes, car les auditeurs passent par d'autres chemins plus rapides ou qui ne nécessitent pas l'accès à ces VDIs.