octoberfest7/dns_tunnelingOutil de tunneling DNS utilisant PowerShell et Nslookup pour exfiltrer des données et livrer des charges utiles via les enregistrements DNS TXT/MX, contournant Constrained Language Mode et les défenses des points de terminaison.
Inspiré par des travaux récents impliquant les beacons DNS de Cobalt Strike, combinés à une volonté de tenter de contourner Microsoft Defender for Endpoint, j'ai passé du temps à étudier comment le DNS pourrait être utilisé pour transférer une charge utile vers une machine cible. Je souhaitais également me mettre au défi en essayant de le faire d'une manière qui soit possible même lorsque PowerShell est en mode langage contraint. Cette recherche ciblait des implémentations plus récentes de Windows (c'est-à-dire Win10+, Server 2019+), mais comme vous le verrez plus tard, cela pourrait être possible sur des versions antérieures.
Le tunneling DNS est une technique qui existe depuis longtemps et qui est utilisée par divers attaquants. À un niveau basique, il s'agit d'utiliser le protocole DNS comme moyen d'infiltration/exfiltration de données ou comme canal de communication C2. Il existe de nombreux articles de blog que vous pouvez consulter pour plus d'informations sur ce sujet.
Parce qu'il s'agit d'une technique ancienne et bien connue, de nombreuses organisations mettent en place des méthodes de détection pour tenter de l'empêcher.
Le type d'enregistrement DNS privilégié pour le tunneling DNS a historiquement été TXT. Cela est dû au fait que les enregistrements TXT peuvent contenir plus de données que les autres enregistrements et qu'ils sont également sensibles à la casse, ce que les autres enregistrements ne sont pas, ce qui peut avoir un impact lorsqu'on aborde l'encodage.
Le mode langage contraint (CLM) est un mode de langage restrictif pour PowerShell qui réduit considérablement les capacités et les fonctionnalités autorisées de PowerShell. Pour faire court, .NET, les objets COM et les favoris des attaquants comme (new-object net.webclient).downloadstring... sont indisponibles. Ce lien fournit plus d'informations. Les organisations imposent cette politique aux utilisateurs normaux dans le cadre des règles de réduction de la surface d'attaque. En pratique, cela rend simplement notre vie plus difficile en tant qu'attaquants.
La plupart des gens devraient au moins avoir une connaissance superficielle du DNS grâce à l'utilisation d'outils comme Nslookup. Mais à un niveau basique, le client envoie une requête et le serveur DNS renvoie une réponse à cette requête. Il existe plusieurs types d'enregistrements DNS : CNAME, A, AAAA, TXT, MX et NS, pour n'en citer que quelques-uns. Chacun de ces enregistrements peut stocker et renvoyer des informations différentes. Ces enregistrements sont configurés dans un fichier de zone, qui est servi par un serveur DNS.
Un exemple de fichier de zone est montré ici :``` $ORIGIN example.com. @ 3600 SOA ns1.p30.dynect.net. ( zone-admin.dyndns.com. ; address of responsible party 2016072701 ; serial number 3600 ; refresh period 600 ; retry period 604800 ; expire time 1800 ) ; minimum ttl 86400 NS ns1.p30.dynect.net. 86400 NS ns2.p30.dynect.net. 86400 NS ns3.p30.dynect.net. 86400 NS ns4.p30.dynect.net. 3600 MX 10 mail.example.com. 3600 MX 20 vpn.example.com. 3600 MX 30 mail.example.com. 60 A 204.13.248.106 3600 TXT "v=spf1 includespf.dynect.net ~all" mail 14400 A 204.13.248.106 vpn 60 A 216.146.45.240 webapp 60 A 216.146.46.10 webapp 60 A 216.146.46.11 www 43200 CNAME example.com.
Si l'on interrogeait les enregistrements NS d'exemple.com, la requête renverrait ns1.p30.dynect.net, ns2.p30.dynect.net, ns3.p30.dynect.net et ns4.p30.dynect.net.
# Recherche
## Enregistrement de nom de domaine
Avant de commencer, nous devons brièvement parler de la configuration des enregistrements DNS pour pointer vers une IP que nous contrôlons et sur laquelle nous exécuterons un serveur DNS. Comme illustré ci-dessous, j'ai acheté un domaine et configuré des enregistrements DNS qui pointent le sous-domaine "dns" vers le sous-domaine "ns1", auquel est attribuée l'IP publique du serveur.
Cela signifie que toutes les requêtes effectuées pour "dns.edu....com" seront dirigées vers "ns1.edu....com" qui se voit attribuer l'IP 3..86. Sur cette IP, nous mettrons en place un serveur DNS pour servir nos enregistrements. Nous y reviendrons plus tard.
## Trouver un outil côté client
Ma quête a commencé par une simple recherche Google pour "powershell dns module" qui a renvoyé [ce lien](https://docs.microsoft.com/en-us/powershell/module/dnsclient/?view=windowsserver2022-ps). La commande Resolve-DnsName présentait un intérêt particulier. Elle semble être essentiellement une implémentation PowerShell du célèbre binaire Nslookup.exe. Notez que des types d'enregistrements spécifiques peuvent être demandés :
Ok, nous disposons donc d'un module PowerShell capable d'effectuer des requêtes DNS et d'en récupérer la réponse. Fonctionne-t-il en mode langage contraint (CLM) ? La réponse est en quelque sorte oui.
Comme vous pouvez le voir ici, si j'ouvre une nouvelle fenêtre PowerShell, exécute Resolve-DnsName, mets PowerShell en CLM (et teste avec l'appel simple ::WriteLine), puis exécute à nouveau Resolve-DnsName, cela fonctionne sans problème :
Cependant, si j'ouvre une nouvelle fenêtre PowerShell, que je la mets immédiatement en CLM et que j'essaie ensuite d'exécuter Resolve-DnsName, cela échoue :
Il semble que si un module a été chargé au préalable, il peut s'exécuter après l'application du CLM, mais le CLM empêchera son chargement s'il ne l'a pas déjà été. En pensant à un environnement cible où le CLM est appliqué par défaut pour les utilisateurs (et sans savoir si certains modules sont préchargés ou si DnsClient en fait partie), j'ai choisi à ce stade d'abandonner Resolve-DnsName et de revenir au bon vieux Nslookup.exe.
Nslookup.exe est un élément de base de la boîte à outils informatique et un binaire très connu utilisé à des fins légitimes. Il est fort probable qu'il soit autorisé à s'exécuter, même dans des environnements où la mise sur liste blanche des applications est une préoccupation.
Nslookup renverra à peu près les mêmes informations que notre requête Resolve-DnsName, il faudra simplement les manipuler un peu différemment au moment venu.
## Transformer un exécutable en enregistrements DNS ?
Bon, nous avons donc un moyen d'effectuer des requêtes DNS sur l'ordinateur victime. Comment pouvons-nous fournir notre charge utile dans un format que Nslookup peut récupérer ?