![]() ![]() Let’s dust off our favorite socket library and make it ourselves. Since we’ve seen that most DNS APIs don’t allow you to do much besides specify record type (but not the class) and the domain name, we will have to do this the hard way. Additional records and authority records will get dropped or not passed through to the next server, as they are thought to be errant. In addition to this, if you take a look at the source code of popular DNS server software like BIND, you’ll see that including more than one question will actually return a “format error” code back to the requester, as is described in this Stack Overflow post. Linux is similar, but does allow one to specify a class for a query. For example, the Windows DNS API only allows a developer to make a request with one question, under the IN class. Most DNS libraries don’t expose DNS operations at a low enough level to perform these types of manipulations. Like what’s the deal with Additional records? Why not throw a bunch of data in there? Why not send multiple Questions? Why not send a response packet as a request? Libraries Don’t Make It That Easy But why does everyone do it this way? The DNS protocol has a lot of other stuff going on in it that doesn’t seem to be used much. I saw how most DNS C2 was conducted, with tools like Iodine, DNSCat2, and Cobalt Strike and noticed that they mostly behave similarly to our example above. We can theoretically go outside of the standard format of DNS messages in order to construct our novel DNS C2 channel to evade this type of network monitoring. In fact, if there is monitoring, it is likely logging only the most pertinent fields of DNS while ignoring the rest. Okay, so why would anyone want to perform obtuse DNS manipulations in the first place? For evasion, of course! Lots of network controls let DNS out, or don’t monitor it very closely. Response to our malware’s DNS record request: a base32 encoded command for the malware to run.Īfter decoding the response, we get the command to run: offĭecoded data the command for our theoretical malware to run on the theoretical infected machine. ![]() Below, we show an example response containing a base32 encoded command. Upon receiving the message encoded in the lookup, the C2 server may respond with data for the compromised device and can pass commands. Lookup on the wire: a DNS record request for JBSWY3DPFQQFO33SNRSCCexamplecom. Below is how the DNS lookup appears on the wire: |21|JBSWY3DPFQQFO33SNRSCC|07|example|03|com|00 00 10 00 01| For this example, let’s say we own examplecom. Then, we prepend the fake subdomain to a real domain that we control and perform a DNS lookup. In this case, we used base32: JBSWY3DPFQQFO33SNRSCC Here’s a simplistic example of this data encoding in action: Hello, World!įirst, we encode the data so that it is a valid subdomain. Compromised devices send these DNS lookups to their DNS server, which will pass the lookups upstream, eventually hitting the malicious DNS server. Standard DNS C2Īdversaries often leverage DNS for C2 by putting commands into the domain name fields in DNS lookups, and encoding the commands such that they look like valid domains. The most common method will be described below, followed by a novel technique. While researching DNS C2, I noticed that threat actors almost always use this technique the same way. Finally, many organizations will prioritize HTTP(S) proxy logging, and will neglect collection/analysis of DNS logs as they deem it too costly for minimal reward. Second, DNS is able to bounce around the internet until it is routed to its final destination, which can frustrate analysis at the IP level. Since most (all?) devices need DNS to function properly, the protocol is almost never blocked and is rarely restricted. DNS is a useful channel for malware C2 for many reasons. Threat actors have been using the domain name system (DNS) for command and control (C2) for years.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |