dnscat使用——整體感覺這個工具不完善，失敗率很高，傳檔案時候沒有完整性校驗，我自己測試時通過域名轉發失敗，可能是其特征過于明顯導緻

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

make

然後就可以按照下面的官方說明進行操作了。

我的感受：整體感覺這個工具不完善，失敗率很高，傳檔案時候沒有完整性校驗，我自己測試時通過域名轉發失敗，可能是其特征過于明顯導緻（子域名裡有dnscat關鍵字）。

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?"

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

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

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):

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.

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.

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.

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

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

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

For example:

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

For more options, use --help:

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

And run the shell on the client side:

Linux/BSD:

Windows:

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

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

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

A couple things to note:

No integrity checking is performed

There is currently no indication when a transfer is finished

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:

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:

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:

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:

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

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

本文轉自張昺華-sky部落格園部落格，原文連結：http://www.cnblogs.com/bonelee/p/8039034.html，如需轉載請自行聯系原作者