Cet article est également disponible dans: 日本語 (Japonais)
Les acteurs malveillants ont utilisé la commande & contrôle (c2) les canaux de communication sur le Domain Name service (DNS) et, dans certains cas, ont même utilisé le protocole pour exfiltrer les données. C’est au-delà de ce qu’une connexion C2 « heartbeat” communiquerait., Des acteurs malveillants ont également infiltré des données/charges utiles malveillantes dans le système des victimes via DNS et, depuis quelques années, la recherche de L’Unité 42 décrit différents types d’abus découverts.
le DNS est un protocole essentiel et fondamental de l’internet – souvent décrit comme le « répertoire de l’internet” – mappant les noms de domaine aux adresses IP, et bien plus encore, comme décrit dans les RFC de base du protocole. L’omniprésence du DNS (et le manque fréquent de contrôle) peut permettre des méthodes très élégantes et subtiles pour communiquer et partager des données, au-delà des intentions initiales du protocole.,
en plus des exemples D’utilisation du DNS déjà mentionnés, un certain nombre d’outils existent qui peuvent permettre, entre autres, à leurs attaquants de créer des canaux secrets sur le DNS dans le but de cacher la communication ou de contourner les politiques mises en place par les administrateurs réseau. Un cas d’utilisation populaire consiste à contourner l’enregistrement de la connexion Wi-Fi à l’hôtel, au café, etc. en utilisant le DNS souvent ouvert et disponible. Plus particulièrement, ces outils sont disponibles gratuitement en ligne dans des endroits comme GitHub et peuvent être faciles à utiliser. Vous trouverez de plus amples renseignements sur ces outils dans la section Annexe à la fin du présent rapport.,
dans ce rapport, nous présentons les types, les méthodes et l’utilisation de L’infiltration et de l’exfiltration de données basées sur le DNS et fournissons des pointeurs vers les mécanismes de défense.
DNS
DNS utilise le Port 53 qui est presque toujours ouvert sur les systèmes, les pare-feu et les clients pour transmettre les requêtes DNS. Plutôt que le protocole TCP (Transmission Control Protocol) plus familier, ces requêtes utilisent le protocole UDP (User Datagram Protocol) en raison de sa faible latence, de sa bande passante et de son utilisation des ressources par rapport aux requêtes TCP équivalentes., UDP n’a aucune capacité d’erreur ou de contrôle de flux, ni aucune vérification d’intégrité pour s’assurer que les données sont arrivées intactes.
comment l’utilisation d’internet (Navigation, Applications, chat, etc.) est-elle si fiable? Si la requête DNS UDP échoue (c’est un protocole de meilleur effort après tout) dans un premier temps, la plupart des systèmes réessayeront un certain nombre de fois et seulement après plusieurs échecs, basculeront potentiellement vers TCP avant d’essayer à nouveau; TCP est également utilisé si la requête DNS dépasse les limites de la taille du datagramme UDP-typiquement 512 octets pour,
la Figure 1 ci-dessous illustre le processus de base du fonctionnement du DNS: le client envoie une chaîne de requête (par exemple, mail.googlecom dans ce cas) avec un certain type – typiquement A pour une adresse hôte. J’ai sauté la partie par laquelle les systèmes DNS intermédiaires peuvent avoir à établir où‘. com ‘ existe, avant de savoir où ‘googlecom’ peut être trouvé, et ainsi de suite.
Figure 1., Opération DNS simplifiée
Une fois qu’un nom est résolu en un cache IP, cela aide également: le nom-à-IP résolu est généralement mis en cache sur le système local (et éventuellement sur des serveurs DNS intermédiaires) pendant un certain temps. Les requêtes suivantes pour le même nom du même client ne quittent alors pas le système local jusqu’à ce que ledit cache expire. Bien sûr, une fois que l’adresse IP du service distant est connue, les applications peuvent utiliser ces informations pour permettre à d’autres protocoles basés sur TCP, tels que HTTP, de faire leur travail réel, par exemple en veillant à ce que les GIF Internet cat puissent être partagés de manière fiable avec vos collègues.,
donc, dans l’ensemble, quelques dizaines de requêtes DNS UDP supplémentaires provenant du réseau d’une organisation seraient assez discrètes et pourraient permettre à une charge utile malveillante de se signaler à un adversaire; des commandes pourraient également être reçues à l’application demandeuse pour traitement avec peu de difficulté.
Si vous voulez approfondir le fonctionnement du DNS – à partir de la saisie des touches pour épeler le nom de domaine que vous souhaitez parcourir – veuillez lire cet article.,
Data Trail
tout comme lorsque vous naviguez sur internet, que ce soit en pivotant à partir d’un résultat de moteur de recherche ou en accédant directement à une URL de site Web, vos requêtes DNS laissent également une trace. La quantité de trace dépend des systèmes et des processus impliqués en cours de route, de la requête quittant le système d’exploitation à la réception de l’adresse IP résultante.,
en se concentrant uniquement sur le côté serveur et, en utilisant quelques exemples de base, il est possible pour les serveurs DNS-en particulier ceux dont la journalisation étendue ou de débogage est activée – de rassembler un hôte entier (sans jeu de mots) d’informations sur la demande et le client qui la demande.,
Cet article donne une idée du type d’informations qui pourraient être glanées dans les journaux du serveur DNS; un adversaire exploitant un tel serveur obtient L’adresse IP distante envoyant la requête – bien que cela puisse être le dernier saut ou L’adresse IP du serveur DNS, pas l’adresse IP exacte du client demandeur – ainsi que la chaîne de requête elle-même, et quelle que soit la réponse du serveur.
Tunneling DNS
maintenant que nous avons une compréhension commune du DNS, de son fonctionnement dans un réseau et des capacités de traçage côté serveur, creusons un peu plus profondément dans les capacités de tunneling., Dans cette section, nous décrirons comment les balises de commande et de contrôle (C2) peuvent fonctionner sur DNS, et comment l’exfiltration et l’infiltration de données sont possibles.
C2
Un canal C2 souvent sert à deux fins pour l’adversaire. Tout d’abord, il peut agir comme une balise ou un battement de coeur indiquant que leur charge utile distante fonctionne toujours – a toujours un battement de coeur – car il est beaconing-out (communiquer) à leur serveur.
Vous pouvez considérer L’opération DNS de base, comme le montre la Figure 1 ci-dessus, comme un exemple de battement de coeur., Si l’implant malveillant sur le système client envoie à plusieurs reprises une requête au serveur de l’acteur via l’infrastructure DNS, l’acteur peut indiquer à partir des journaux qu’un implant est en cours d’exécution. Ce qui devient difficile, c’est de faire la distinction entre plusieurs victimes infectées par l’implant.
considérons un autre exemple décrit par la Figure 2 ci-dessous, où le système client est compromis par un logiciel malveillant qui construit des chaînes de requête d’apparence étrange à envoyer via DNS., Des requêtes comme celles-ci agissent toujours comme un battement de cœur indiquant à l’adversaire que sa charge utile est toujours active, mais elles fournissent également des méta-données de base sur la victime et, surtout, des moyens d’identifier de manière unique une victime d’une autre.
Figure 2., Exemple opération de requête DNS C2
Les noms d’Utilisateur et les noms d’hôte peuvent ne pas toujours être uniques, et certaines adresses IP peuvent être dupliquées sur plusieurs réseaux à l’aide de la traduction D’adresses réseau (NAT), mais les systèmes ont des identifiants uniques universels (UUID) ou d’autres propriétés, qui, une fois combinés, pourraient créer
certaines des méta-données de l’hôte compromis peuvent être envoyées en texte brut, mais peuvent sembler plus suspectes à première vue à quiconque voit de telles chaînes dans une requête DNS., Dans de nombreux cas, les données contiendront des caractères non pris en charge par DNS, auquel cas l’encodage sera requis. Dans la Figure 2, Vous pouvez voir l’équivalent encodé en base64 pour les méta-données, qui est construit en utilisant une notation délimitée » – » pour une analyse et un décodage simples côté serveur, comme indiqué dans la Figure 3 ci-dessous.
Figure 3., Journaux DNS côté serveur traquant la communication C2
la Figure 3 montre un exemple de ce à quoi un journal DNS brut d’une application Serveur DNS peut ressembler, avec des entrées de ligne pour la requête du malware et la réponse du serveur DNS, NXDOMAIN (ou domaine inexistant), dans ce cas.
à certains égards, un journal comme celui-ci, ou peut-être une petite base de données contenant les enregistrements décodés, pourrait être comparé aux panneaux de contrôle de botnet plus chic qui permettent au botnet herder de contrôler leurs systèmes de victimes Zombies.
l’Exfiltration
Alors, quoi d’autre pourrait être envoyé dans les requêtes DNS?, Eh bien, n’importe quoi en théorie, tant qu’il est encodé correctement et n’abuse pas des limites de taille UDP. Un moyen de contourner cette dernière contrainte pourrait être d’envoyer plusieurs messages d’enregistrement A et de les assembler d’une manière ou d’une autre côté serveur. Des Complications surviendraient cependant dans les datagrammes abandonnés ou manquants.
contrairement à TCP qui assure la retransmission des paquets défaillants, UDP n’a pas un tel mécanisme., Un algorithme serait nécessaire pour comprendre combien de messages seront envoyés et vérifier que le nombre correct arrive, mais plus compliqué que cela, demandez en quelque sorte au client de retransmettre certains segments des données jusqu’à ce que 100% arrive. Selon la quantité de données à transmettre – chaque PDF sur le système, par exemple – peut prendre un âge, et sembler extrêmement suspect pour les administrateurs réseau.,
Infiltration
en revanche, l’infiltration de données que ce soit du code, des commandes ou un fichier binaire à déposer sur le disque et à exécuter pourrait être beaucoup plus facile, en particulier en utilisant le type DNS de TXT (par opposition au type d’enregistrement hôte A). Les types TXT ont été conçus pour fournir un texte descriptif, tel que les détails du service, les noms de contacts, les numéros de téléphone, etc. en réponse aux requêtes DNS TXT pour les noms de domaine.
Devinez ce qui ressemble aime le texte? Données non textuelles codées en Base64!, La Figure 4 ci-dessous montre la requête identique envoyée au site malveillant comme dans la Figure 2, cependant, le type est maintenant TXT sur la demande et la réponse, et les données de réponse contiennent les 300 premiers caractères d’un fichier exécutable binaire codé qui pourrait être exécuté par le logiciel malveillant client. Encore une fois, en utilisant les journaux, l’adversaire serait en mesure de savoir quel client a demandé la charge utile, et que la charge utile a été envoyée (qui sait si elle est réellement arrivée…).
Figure 4., Exemple de requête DNS C2 avec Réponse de type TXT
Mais comment l’implant malveillant sait-il changer le type en TXT ou quand demander ce qui se trouve à l’intérieur des données « texte”? Il pourrait être intégré à la charge utile pour interroger à un certain moment de son exécution ou après un certain laps de temps, mais en réalité, il va être piloté par les acteurs en utilisant le deuxième objectif d’un contrôle de canal C2.
dans mes exemples précédents de communication DNS C2, la réponse du serveur DNS était NXDOMAIN., Ce message atteint évidemment le système client (et le logiciel malveillant) et pourrait être utilisé un message ou une instruction pour la charge utile, mais il limite sans paramètres ni détails. Entrez NOERROR.
NOERROR, comme le terme l’indique, signifie que tout a bien fonctionné – votre demande a été traitée et une réponse vous attend. Avec une NOERROR vient une réponse qui peut être traitée. Habituellement, il s’agit de L’IPv4 (pour les demandes de type A) ou de L’IPv6 (pour les demandes de type AAAA) ou il pourrait s’agir de TXT, comme indiqué dans la Figure 4 ci-dessus., En se concentrant sur un exemple simple – la réponse D’adresse IPv4-le malware n’a pas besoin d’une adresse IP réelle pour communiquer avec, contrairement à votre navigateur qui demandait » où se trouve googlecom?”. Le malware est déjà en communication avec sa destination en utilisant le C2 via DNS.
ce que le malware peut utiliser la réponse IP est l’une des 4,294,967,296 commandes ou instructions possibles. Encore une fois, en gardant cela très simple, il est possible qu’une valeur particulière dans le 4ème octet de L’IP, disons 100, indique au malware d’envoyer une requête DNS TXT au domaine de l’acteur pour collecter et exécuter une charge utile., La valeur 10 dans le premier octet pourrait signifier désinstaller et effacer les traces de la charge utile malveillante du système d’exploitation et des journaux d’événements. Littéralement, les options sont infinies, tout comme les niveaux de sophistication possible.
étant donné que l’adversaire a le contrôle sur le serveur DNS et que certaines applications de serveur DNS ou démons sont hautement configurables, il est possible d’envoyer des réponses conditionnelles au malware sur les systèmes de la victime en fonction des demandes envoyées par eux.,
par exemple, si la requête entrante contient un certain indicateur – un caractère – comme premier sous-domaine du nom de domaine, elle peut être lue par un programme s’exécutant dans le service DNS sur le serveur et fournir une réponse personnalisée au client. Cela pourrait être utilisé pour que le logiciel malveillant fonctionne automatiquement à travers un ensemble de tâches et fasse rapport en conséquence aux acteurs pour recevoir leur prochaine tâche.
Conclusion
DNS est un outil très puissant utilisé presque partout permettant aux applications et aux systèmes de rechercher des ressources et des services avec lesquels interagir., DNS fournit une base de communication permettant à des protocoles de plus haut niveau et plus puissants de fonctionner, mais peut signifier qu’il est négligé d’un point de vue de la sécurité, en particulier lorsque vous considérez la quantité de logiciels malveillants livrés via des protocoles de messagerie ou téléchargés à partir du web à l’aide de HTTP.
pour ces raisons, DNS est le choix parfait pour les adversaires qui recherchent un protocole toujours ouvert, souvent négligé et probablement sous-estimé pour tirer parti des communications depuis et vers les hôtes compromis., Unité 42 a vu plusieurs cas de logiciels malveillants, et les acteurs derrière eux, abuser DNS pour réussir dans leurs objectifs, comme discuté dans ce rapport.
les organisations peuvent se défendre contre le tunneling DNS de différentes manières, que ce soit en utilisant la plate-forme D’exploitation de sécurité de Palo Alto Networks ou la technologie Open Source.,lowing:
- blocage des noms de domaine (ou des adresses IP ou des régions de géolocalisation) en fonction de la réputation connue ou du danger perçu;
- règles autour des chaînes de requête DNS « étranges”;
- règles autour de la longueur, du type ou de la taille des requêtes DNS sortantes ou entrantes;
- durcissement général des systèmes d’exploitation de nouveaux domaines sont accessibles en particulier lorsque la méthode d’accès et la fréquence sont anormales.,
- Palo Alto Networks a récemment introduit un nouveau service de sécurité DNS axé sur le blocage de l’accès aux noms de domaine malveillants.
de plus amples informations peuvent également être trouvées dans la documentation ATT&CK framework sur le site Web de Mitre. Plus précisément, les techniques suivantes se rapportent aux concepts abordés dans le présent rapport.,>
Thanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their input on this report.,
Appendix: Toolkit List
| Tool Name | Description |
| dns2tcp | dns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs on Linux. The client can run on Windows. It supports KEY and TXT request types. |
| tcp-over-dns | tcp-over-dns (TCP-over-DNS) was released in 2008., Il a un serveur basé sur Java et un client basé sur Java. Il fonctionne sur Windows, Linux et Solaris. Il prend en charge la compression LZMA et le tunneling du trafic TCP et UDP. |
| OzymanDNS | OzymanDNS est écrit en Perl par Dan Kaminsky en 2004. Il est utilisé pour configurer un tunnel SSH sur DNS ou pour le transfert de fichiers. Les requêtes sont encodées en base32 et les réponses sont des enregistrements TXT encodés en base64., |
| iode | iode est un programme de tunneling DNS publié pour la première fois en 2006 avec des mises à jour aussi récemment que 2010. Il a été développé par Bjorn Andersson et Erik Ekman. Iode est écrit en C et il fonctionne sur Linux, Mac OS X, Windows et autres. Iode a été porté sur Android. Il utilise une interface TUN ou TAP sur le point de terminaison. |
| SplitBrain | SplitBrain est une variante de OzymanDNS., |
| DNScat-P / dnscat2 | DNScat (DNScat-P) a été initialement publié en 2004 et la version la plus récente a été publiée en 2005. Il a été écrit par Tadeusz Pietraszek. DNScat est présenté comme un outil « couteau Suisse » avec de nombreuses utilisations impliquant une communication bidirectionnelle via DNS. DNScat est basé sur Java et fonctionne sur des systèmes de type Unix. DNScat prend en charge un enregistrement et les demandes D’enregistrement CNAME (Pietraszek, 2004)., Comme il existe deux utilitaires nommés DNScat, celui-ci sera appelé DNScat-P dans cet article pour le distinguer de l’autre. |
| DNScapy | DNScapy a été développé par Pierre Bienaime. Il utilise Scapy pour la génération de paquets. DNScapy prend en charge le tunneling SSH sur DNS, y compris un proxy Socks. Il peut être configuré pour utiliser des enregistrements CNAME ou TXT ou les deux de manière aléatoire. |
| TUNS | TUNS, un tunnel IP sur DNS, a été développé par Lucas Nussbaum et écrit en Ruby., Il n’utilise aucun type d’enregistrement expérimental ou rarement utilisé. Il utilise uniquement des enregistrements CNAME. Il ajuste le MTU utilisé à 140 caractères pour faire correspondre les données dans une demande DNS. Les TUNS peuvent être plus difficiles à détecter, mais cela a un coût de performance. |
| PSUDP | PSUDP a été développé par Kenton Né. Il injecte des données dans les requêtes DNS existantes en modifiant les longueurs IP/UDP., Il exige que tous les hôtes participant au réseau secret envoient leurs demandes DNS à un service de courtier qui peut contenir des messages pour un hôte spécifique jusqu’à ce qu’une demande DNS provienne de cet hôte. Le message peut alors être envoyé dans la réponse. |
| votre liberté | HTTPS/UDP/FTP/DNS/ECHO VPN& solution de tunneling Pour Windows, Mac OSX, Linux et Android., Contourner les proxys et accéder à Internet de manière anonyme |
| Hexify | un outil est développé par Infoblox pour faire le test de pénétration pour le tunneling DNS., |
Appendix: Malware List
| Malware Name | Description |
| DNS_TXT_Pwnage | A backdoor capable of receiving commands and PowerShell scripts from DNS TXT queries., |
| DNSMessenger | DNSMessenger est un cheval de Troie D’accès à distance (RAT) qui ouvre une porte dérobée afin que les pirates puissent contrôler la machine compromise à distance |
| Oilrig – bondupdater | Le Cheval de Troie contre un gouvernement du Moyen-Orient peut utiliser un enregistrement et des enregistrements TXT dans son protocole de tunnel DNS pour ses communications C2 |
