Finding Evil in DNS Traffic

Yeah, Bill. Thanks. Thanks. Only those of you at Security On yesterday, uh, who were there at the beginning would probably get that. So, um, all right. Good morning. Welcome to Beloved America Track. Obviously, we planned this very well. Standing room only. I think that's actually pretty awesome, uh, that it's standing room only in this talk. Um, we have now exceeded 700 check-ins this morning. So, let that digest for a second. uh little here little old Augusta, Georgia. Uh we had 711 check in as of about a minute ago. That's why I pulled the thing off cuz this what he was saying in the year. So uh I think that's pretty awesome. So thank you all for coming out and making

besides awesome again fourth year in a row. Our next speaker is uh uh just on let me that's easy for me to say works in the uh mission of national defense uh works right here on Fort Gordon on uh one of the cyber protection teams uh out there on Fort Gordon. He's got a lot of good things to say this morning. Uh I did forget one other note of administr uh lunch is actually going to start a little bit before 12, right? So right when when Keelin wraps up, you'll be able to go right out to lunch so there's not the big onslaught. And if you guys don't know where that is, down this hall

to the right, follow your nose to Chick-fil-A. Okay, so next speaker again from the CPT, I give you Kean Roberts.

Thanks, Phil. Um, and welcome to Finding Evil and DNS traffic. A little bit about myself. Um I have about 10 years of experience um in both cyber security and information system security. Um couple recent projects of mine that I've worked on is mercenary Linux um which is a hunt distribution a lot of dockerized applications that we use a lot and a lot of custom tools that we've written um which is PM by Daniel West and also the mercenary hunt framework um which again um created by myself and PM by Daniel West. Um, couple places you can find me. Um, real Slacker 007 on Twitter. Um, GitHub, Slacker7 repo. Um, all right. So, we'll go and

we'll talk about a little bit of my motivation for what prompted me to do this research. Um we'll talk about we'll talk a brief DNS overview and then we'll talk about some of the malware families that actually utilize um DNS for C2 and um that Xfield as well as as well as some other um exploits. We'll talk about some IFC's and a few detection methods. Um so why DNS? Um, I had to have like had that question asked to me probably 20 times because overall for the most part DNS is pretty boring. Um, that's one of the reasons that makes it really really vulnerable because it's one of those things that you just it just sits

there and runs seamlessly in the background, but it it has an enormous impact on all of our network communication um for a lot of different assets that we have on our networks. Um, and so that was pretty much um the technical motivation, but the my individual motivation was I was actually put on a to on an assignment to analyze DNS traffic on a training app and they were actually using DNS um for C2 and I couldn't detect it. So obviously I knew I needed to go back in the books and do more research and so decided to bring that here and share it with everybody here. So brief overview um obviously DNS user wants to access a resource on a

network um first checks with his local recursive server. Um from there um if the local recursive server doesn't have the the record that he's that he's looking for. it forwards it up to the authoritative server and from there to the the top level domain route and and then the route once the answer's found it's returned back to the user and then they're able to browse to to whatever asset they originally wanted to um gain access to. Um for the purpose of this brief um whenever I mention infrastructure I'm talking about everything from the operating system to any other services that are nested on the the system itself um to include the DNS application as well. Um and when I

mention protocol um I'm talking just the DNS protocol. Okay. Um so some of the operating systems we have both Windows and Nix. Um and on Windows you'll have Windows DNS on Nixon bind. Um these are some of the the most common ways that there are attack buffer overflows, race conditions, misconfigured permissions. Pretty much basically the the user or the administrator configures stuff. Um those are ways that the infrastructure itself can be targeted. Um other nested and the nested services on it as well. FTP um if they're nesting web on there as well um SMB SIFS things of that nature. The protocol protocol introduces um several different vulnerabilities um DNS cache poisoning DNS spoofing um distributed service attacks data X field

command and control and staging for further exploits. A lot of thread actors utilize this um all the time to conduct all these activities. So, we'll start with DNS cache poisoning. Um, pretty much um it's self-explanatory. Um, the cash on either the local system or the DNS server will be modified by an attacker. Um, the unsuspecting user goes to access a resource system checks local DNS cache is not there. It checks the recursive server. um it's been poisoned and it returns uh the IP or the address for the attacker's uh resource and the user unknowingly browses to the fake website and checks his email. Recursive servers and local DNS cache, those are the two primarily the the two

primary targets. U recursive servers actually aren't targeted for DNS cache poisoning attacks as much as they were in the past. Um this is largely due to a lot of security um features that's been built into a lot of the applications um such as bailwood grew and birthday paradox. Um primarily you'll see DNS cache poisoning take place on the local system. Um that's either within the local cache on the operating system itself or on the web browser. some of the malware families we have mentioned. Um I want to point out the DNS changer that's actually been around since 2011. Um DNS changer it originally target like local DNS cache on the system and now as of 2016 is

actually um morphed into targeting the default gateway and modifying the DNS records um and the the DNS configurations and the default gateway and controlling all our traffic for the network that way. Um so that one's really important. Three aspects that I want to point out for tracking DNS communication. Um source IP, source port and transaction ID. So by default DNS runs on UDP um which is um connectionless um traffic not like TCP where um it requires a three-way handshake and so each session is tracked by the protocol itself. DNS doesn't have that. So, it sort of inherits those vulnerabilities from UDP um and makes it susceptible to more to to further attacks. Um I want to

highlight source IP because with DNS amplification, it actually takes advantage of this vulnerability. Um DNS amplification tag um you have an attacker who will send you have an attacker who controlling the botnet. um all these bots they will send at the attacker's request they will send a very small DNS query to usually an open DNS server um requesting all of the resource records um for a given domain and then at this time they're spoofing their source address so that all the results are returned to a victim. some of the indicators are compromised. Um, spoof source addresses um monitoring your network traffic um to make sure that um all of to make sure that the um

source address spoofing isn't taking place. Um that should be um already being done. But if not, definitely want to implement that. Um the use of open DNS servers um you should only be using your internal recursive server anyway. So if there's any DNS traffic that's trying to resolve using an open DNS server or any DNS server other than your own, that should be another indicator of compromise. Modified TTLs. If you look in the image that we have um to hats.org, you you see a difference of 13 with the TTL. That could be the difference in like the US versus Afghanistan. Um so you definitely shouldn't see a TTL. um vary that much. So that would be another indicator of

compromise in itself. The use of the any record um the use of the any records it's not it doesn't mean that it's vulnerable by default. However, in conjunction with any of these others, then definitely it will be an indicator of compromise. Um especially the quantity. If you have any given number of nodes, we'll say a thousand nodes throughout your network, all making 100 requests um for any resource record for IETF.org um with a smooth source address um obviously that's an indicator of a compromise. Volume of queries. You have one node that's making 10,000 requests um over a short amount of time um to a given um domain. That's another indicator. Um, and lastly, queries versus responses. Make sure that you

have not necessarily the exact an exact match for the number of queries versus responses, but it should be relatively close. You shouldn't have a,000 or 10,000 more queries than you have responses for a given domain. So, that's another thing that you want to pay attention to whenever you're doing your traffic analysis. And this in this image, I want to highlight three things. um the use of the any record destination and lastly u the size. If you notice it's only 68 bytes. Doesn't take a really powerful machine to do that. Um, which makes this perfect for like botn nets and distributed denial of services because you're able to get several systems um, scattered geographically across the globe to all

participate in distributed denial of service to a victim without having any performance hit on their own system or their own network. So, if you're not monitoring for it, you're you could actually be participating in a distributed denial of service attack against another organization and not even know it. Um, so I want to definitely highlight that. This is an example of what that query might look like. Um, whenever you're looking at this traffic from a net from a command line based um, traffic analysis tool like TCB dump, net sniffg, something like that and take it pay close attention to how small it is. This plays right into what I mentioned before about how about how the um, how small

and how little resources it take to actually generate this query. and then take a look at the response. So this response generated from that exact same query. Now if you scale this and scale it across let's say 100 systems within your network all doing this 100 times a piece doesn't impact your network at all because of the size of the query. But remember they spoofed their source address. So all this traffic is being redirected from the from the open DNS server back to the victim. And you can see how that could quickly result in a denial of service because of resource resource exhaustion. Um, so definitely want to pay attention to those indicators of compromise to try to make

sure that not just because you're not being you're not the victim of distributed denial service attack, but you're also not participating in one um against another victim. DNS beacons. some of the key information um about DNS beacons. a couple of them very popular DNS beacon co-op strikes pretty sure everybody's familiar with that remote access track remote access Trojan that um allows you to do a number of things um via DNS both stage further attacks um C2 data X field control the number of call backs that you get like over over a given amount of time using throttle or jitter. Another one is DNS Trojan, which is another family of actual malware um that's used maliciously a lot. Um and and it does

some of the same things similar to Cobalt Strike. Some of the IoC's that it's important to pay attention to whenever you suspect DNS beacons is incremental changes. Pay pay attention to subdomains. Pay attention to the numbers. It might look like random characters, but everybody knows there's nothing random. So pay attention to those numbers. They have to be changing somewhat. Um size of the packets, UDP versus TCP. um in an attempt to remain stealthy. Um a lot of malware families they they limit the amount the amount of data that they try to pack into those UDP packets because once they go over a certain size then it will automatically switch over to TCP and then that's going to be that's going

to be an indicator of compromise and and could potentially cause them to be um be identified by the security team in the network. So they try to maintain within that 514 bytes of a UDP packet. Um that actually affects the number of packets because they have to keep the packets so small. Um it they have to generate a lot of them. So now you're going to see even though it's only one meg that they're trying to data Xill, but it generated like 10,000 packets. So you will see a large number of packets um just based on that fact alone. and and for that reason it's primarily used as C2 but can be used as data Xville as a last resort and

it's important to know that and then again queries versus responses um a lot of because of some of the security um features that are built into the application nowadays if the requests are coming in too fast a lot of times the server won't process them just because of that so it'll have to regenerate those queries so a lot of times you'll look over network and you might see three queries for every one response and that'll that'll also be a great way to um or a great indicator of compromise um and require further further like look from your security team attributes and why um there actually are legitimate uses um for DNS beacons and text records um particular um text

records applications like DKIM and um center policy framework actually use this um to communicate, exchange information between um different assets like email servers and um DNS servers about themselves. But one of the places you should not see it is from a host. You shouldn't have host on your network um or nodes like everyday user systems that are sending um DNS text records out. Um so that that would be another indicator of compromise in itself. Some examples of legitimate applications that also use DNS text records and A records are security applications. McAfee, Security Onion, um you name it. Um Semantic, they all use them. Um, a lot of one of the ways they do it is any

binaries, suspicious binaries that they identify, that your application identifies, they'll take it, hash it, prepend that hash to the domain, and then they'll send that out so that they could um check that hash against their their database and see if they've got any additional hits or if any other system or if any other network has reported that hash is being suspicious. This is an example of malicious. Obviously, you can see the s just based on the sheer size. Um, it should stick out. Um, which plays into like a little bit of what I mentioned about my own motivation um for doing this analysis. It kind of goes it DNS is one of those things that you you just kind of set it

and forget it. So, if you're not paying close attention, even though this jumps out at you because we're in this brief, um, if you're not even looking, you're not going to catch it because it's not breaking anything within the RFC. um it it's not it's the the right amount of the right size, the right amount of characters. Um there's nothing that's breaking any RFC. So, you could do this all day and if you're not checking, then you're not going to see it. You're not going to find it. Um another um indicator compromise is resolving to like a wild card. You'll see here with this domain, it's resolving to 0.0.0. Um, a lot of times this is this is used

because there's an there's an unlimited amount of domains that could come back. Especially if you're prepending data and you're encrypting it in B 64 in it before you attach it or prepend it to your domain. It's no way of really having every um every domain registered in the in the in the DNS server. So um you'd have to sort of resolve to anything. Um here's an screenshot of one of the applications DNS Hunter that that we use and as you see you have the same domain resolving to multiple countries IPs in multiple countries per Canada Germany China that should jump out at you definitely an indicator compromise there and at least requires um an additional look.

This is another screenshot. Same tool. Um just adding some more command line syntax just to refine the amount of output they were able to get um using GP. Um and now I have some actual videos of some of the tools I want to show. Um you have about three minutes to the top of the hour. Okay. that one. So, I a lot of the videos anyway, um if you if you want the videos, I can give you the videos or they'll be posted on YouTube so you can catch those. Um so, I'll just leave it open for questions um at this time. If anybody got any questions, they can ask or I'll stick around and you can ask me on the side.

Thank you.