D'oH The Simpsons Look at the Growth of DoH in Malware - Allan Liska

Cool. >> All right, guys. Next, we've got our next speaker. We've got Alan Lisker from Recorded Future. >> Thank you very much. >> Let me turn that off. >> I want to hear. >> Thanks, Alan. So, yeah, Alan's come over from the States for this event. So, he's going to give a really interesting talk and hope you guys will all enjoy it and give him a round of applause to get started. >> It's not that interesting. Wow. Wow. >> Just just you know what? I can't go on, man. Um uh so today we're going to talk about uh DNS over HTTPS. Um first of all, my name is Alan Lisa. Uh I am a ransomware

researcher at Recorded Future. I've been in cyber security for about it measures in decades now. So, I'm not going to give a number. Um, and uh, I'm really excited to be here. Uh, Will and his team have done an amazing job. So, everybody give them another round of applause because that's incredible. And Marcel, I would have happily given up the rest of my time to continue listening to your talk because I I think, you know, you're definitely one of the best. So, um, so, uh, first and foremost, in addition to being a ransomware researcher at Recorded Future, I own a comic book company. Um, in fact, some of our stickers are down there. So, I'd appreciate it if you all

buy some comics so I can get the hell out of this business. Um, but one of the advantages of owning a comic book company is I know a lot of amazing artists, including somebody who works for The Simpsons, who updated this meme for me. Um, so I'm going to post this on LinkedIn and uh you all are welcome to steal it and use it uh uh uh widely and uh available. That is a Simpsons authorized malware meme. So I'm pretty excited about that. Um so let's talk about DNS over HTTPS. Uh first of all, anybody familiar with the DO protocol? Few. Okay. Um that's good. Most people aren't. Um, so DNS over HTTPS is one of

those things that we like to do in tech, kind of like AI, which is a solution to a problem that nobody has, um, and something that nobody asked for. Uh, so um, it's introduced through RFC 8484. It's a protocol that allows for sending and receiving DNS responses over HTTPS. uh the idea was supposed to be that it increases privacy and security by preventing eavesdropping and manipulation of DNS traffic. So generally speaking DNS itself is a UDP protocol that is completely open so anybody can sit and listen in and intercept traffic. It's also relatively easy to redirect uh DNS. Uh if you have a Windows machine or a Mac machine or a Linux machine, somewhere on there, you

still have a host file which is a remnant to when we first started DNS and there are still bad guys that will manipulate where your DNS traffic is going just by editing that host file. Um and you know it's kind of this little thing that most people don't know about and most organizations don't protect against. So the idea was it would increase privacy and security by preventing eavesdropping and manipulating of traffic. The problem is bad guys also like to use these protocols and they can take advantage of all the things that are supposed to be good about DNS over HTTPS. So the way it works is do client um connects with the pre-programmed DO server sends a DNS

request but again over SSL to that server. it then that that proxy then forwards it over to a real DNS server gets the translation and sends it back. So all that you see on your local network traffic is an SSL request. So a typical HTTPS request looks just like every other HTTPS request which for most organizations is the bulk of their traffic. So, it blends in really nice with any other traffic that is on the network and it's really hard to figure out what's going on. Um, but and this is why we can't have nice things because bad guys start using this. In fact, starting in 2019, um, a little bit after the RFC was

approved, we started seeing the first malware using DNS over HPS and it's just kept up over time. But as you can see, starting last year, um, we saw this nice little bump in more and more malware using it. So, one of the things that we do at Recorded Future is we have a whole lot of malware collection and a lot of malware repository. Um, and so I went to our engineers and said, "Hey, I want to find a list of all the malware that's using DHD do as a CNC uh command and control protocol." And they're like, "Well, how do we do that?" I'm like, "I don't know, man. You're the malware engineers. I'm just a stupid

researcher." And so then we had to reconstruct how malware uses it and help I had to help them develop a query and so on. So kind of what uh Marcel was saying about how you kind of have to share your knowledge and information disseminated and nobody's an expert on everything. I don't know how to analyze malware. um uh but I know what the protocol looks like and how it's presented and so I could help the team that actually does do that figure that out and suddenly we had a surge in even though it was retroactive we really saw this surge here in the number of malware submissions uh with uh DO and of course it's not just malware but malware

adjacent tools cobalt strike um very much relies on uh do as an exfiltration protocol, as does um as does Brute, Retell, Silver, all of the tools the bad guys use to excfiltrate stuff out of your network also use uh DNS over HTTPS. So, I want to look at some of the uh some of the tools that are that are using or that have used uh uh DO in the past. Um the first is Godlua. um at first it's the first one that was reported and discovered and again almost immediately after the RFC was approved we started to see this uh it was first reported by Netl in uh 2019 I know it's really hard to see down at the bottom

but the URL for the report is there they had Windows and Linux versions and it was primarily used to launch DOS attacks and uh crypto mining did I do that I'm gonna not swing my hands around so much I guess because uh it makes it go. Um and then it was uh used do for C2 communication which is very common again because it's encrypted hard to see blends in very nicely with the traffic. Um and then we have power pepper which was used by um uh first reported by Kasperski in 2020 uh and that was used by the group Deathstalker and so it's a memory resident backdoor written in PowerShell. I know malware and PowerShell who knew. Um and uh you know

basically it was a way to run do act uh requests but running it in memory using the built-in capabilities for do that are in PowerShell. Then uh uh Chaml do um which is a nation state likely Chinese uh um and that is a Linux malware implant um developed by the Tamil gang first reported by Stairwell in 2023 a and it basically enables attackers to remotely access infected devices gather system information and execute very file various file operations. So, it was a b a remote back door way to get into the network to put the implant down and then you could call in. Again, everything done over HPS. So, blends in nice. Um, and then morphing mircat is the most

recent one. So, morphing mircat's been around since 2020, but it's only in the last year that they've started using DO as part of their uh fishing campaigns. Um and so again I it's we're seeing more of their activity but then they're also using uh DNA DNS over HPS to cloak their activity once they uh get on the box. And you know as Marcel pointed out one of the things that is used here uh is identity theft or or credential stealing etc or credential mining but again using DO as the C2 exfiltration. So you're sending all the data out over GO. So that's some of the malware families. There are dozens and dozens of others that are using this as either C2Xill or

or as Xfill or C2 or um any other methods, anything that basically you want to hide things in the traffic. So it's not enough just to report on this. Um, and again, you know, I'll go back and refer to Marcela's presentation again. I can tell you all this information, but it doesn't help you if you don't know how to protect your organization against that. So, how do you protect against do malware? That's one of the problems. It's really hard. Um, anybody know who Paul Vixie is? There you go. One DNS nerd, two DNS nerds. I love it. Um um and and what I said at the beginning, I love this quote from him about DOH. What we've done here

is create a new class of exfiltration risk that we can expect every intruder, whether hardware, software or meatware, is going to be using. And yes, that is correct as as we're seeing from the growth in that. Um and one of the big problems is most do malware uses these servers as uh you know as sort of what effectively acts as their C2 server. So again remember the process. You send an HTTPS request to a server. That server then translates it to DNS um gets the response back and then sends it back to you over as part of the uh HPS response. Well, um, how many people can block DNS.google in their organization? I'm I'm guessing probably

not many. Um, same thing with Cloudflare now. And please, if you work for Cloudflare, please please take this back to your your CEO. Um, while the rest of us are trying to fight malware, Cloud Cloudflare is ignore is is encouraging more malware. So, um, good job, guys. But I still realize you probably can't block them either. Same thing with Quad9. Some of the others obviously yes you probably can block down the road but because they use common infrastructure it's really hard. It's like malware that uses AWS as a C2 or or Azure. These are things that you can't block which makes it very difficult as a method to um uh a as a securing method but at least

they're things that you can monitor for. So maybe DNS.google Google requests over port 53 are fine, which is DNS port, but over 443, those you might be able to block. It depends on how um how uh what's the word I'm looking for? H how how you know uh specific you want to get with your firewall rules. Now, you can administratively disable DOA within your organization's web browser, and I highly encourage that if it's not something that you're using. So, a lot of them, Firefox, um, and others have DO enabled by default, and that's what they'll use. But if you disable that administratively, then that helps protect you. Um, however, um, that only works with browser implants. And don't

get me wrong, browser implants are a real problem. You know, it it's funny having been in the industry for a really long time. I went through Internet Explorer hell, right? And and how bad Internet Explorer was. And then we got this new breed of browsers and they were much more secure and much more protective and we didn't have to worry about the browser anymore. And then it turns out the bad guys figured out how to uh how to infect those new browsers as well. And we're back to the point where there are browser implants and browser vulnerabilities almost weekly being announced and and yes um again uh you know back to using ads and other things

as a way to to trick people. Um so if you can disable it within the browser that's great but that only impacts the um that only impacts the browser. You also have to look at other tools that may be using it. So again, a PowerShell based uh a PowerShell based malware is going to use the native PowerShell API calls to use DO. That's a lot harder to block. And in fact, Will and I were talking about this last night. So many of you all don't log PowerShell. So if somebody is using that, you won't know that uh that they are because it's there's no log request to do. And I and I get it for a lot of organizations

trying to log everything that's in PowerShell can be painful and searching through all of that can be painful. But PowerShell it, you know, I mean, as somebody who's studied ransomware for years, I don't know of any ransomware attack that doesn't use at least some PowerShell. So being able to monitor this stuff in um you know in PowerShell and being able to monitor for these kind of attacks in PowerShell is uh is really important. Um and and then some of them of course have it built in. So if they've written it in C C++ they're likely going to use their own libraries and so on. So that's harder to detect. So unfortunately, you go back to having to rely on um sort of

the old-fashioned DNS lists and stuff like that. Okay, we're going to block these servers. You know, we've got the common ones here, but start looking for others that are unusual and blocking those. uh and and that's really the only way that you can do it unless you've enabled uh SSL inspection on your network, which I know a lot of organizations would really love to do, but also that adds to your ability to actually monitor and look for things because you've got to find them out. Uh you you've basically now have, you know, 10 times the amount of traffic you have to search through and find things. So, it's a really hard challenge and it's a especially a hard challenge

because so many organizations already don't do a great job of monitoring DNS in the first place. DNS is one of those protocols that's often overlooked um or outsourced or not thought about or considered an IT problem, not a security problem. yet DNS is a critical critical component of so many um of so many malware attacks and it's just something that's kind of looked over and and I get it. You can't monitor everything. So, you have to kind of pick and choose your battles on that. Um as much as I'd love it if we all lived in a world where our socks were fully staffed and uh we could monitor all of the things that were

happening, I realize most of us don't live in that world. So, um, so DNS often falls by the wayside because it's hard and complicated to look for. Um, so all of that's really depressing. Um, and I'd like to end on a happy note, but uh, I don't have one. Um, cuz infosex sucks and we're fighting a losing battle and that's why I make comic books. Um, so I would I think I've got some time. Um, uh, so we can do one of two things. Marcel can come back up and finish her presentation. Um, or I'm happy to answer questions or y'all can go get a coffee or and I do apologize. I am very American. I realize I dropped a lot of

y'alls in my uh uh talk. Um, and I live like 30 miles from Marcel and yet she doesn't drop any y'all so I don't know what the difference is. I guess better upbringing. Um, >> British mother. >> Yeah, there you go. Um, but I'm happy to answer any questions y'all have or again whatever. So could an organization reduce its exposure by limiting where the DNS requests go. So from your organization you go to one one DNS source and that's it. Now okay it has to reach out but you know that your primary hop is going to a trusted one. >> No because it because it's using 443 um it's uh it doesn't look like a standard

DNS request. Um so you can if you know if you go back you can disable it in the browser. So you can disable uh the do in your browser and that helps limit it because then they can't use it or you can control it in a browser. If you're going to use DO, you have to go to our server. So in in that way, yes, but it doesn't help with fully compiled malware where it the the libraries are all built in and it's going to make a a an SSL request that's not going to look like it. But broadly speaking, you should definitely do that. you should make sure that all DNS requests are routed to and

nothing nothing um you know on port 53 or any of the other DNS ports are leaving your firewall. So that is a very good tactic for broadly protecting against DNS attacks because at least you have the logs of of of all the normal ones. It just doesn't always work with with this depending on how the malware is implemented. Good question though. Yes. Um, talk bringing that bringing that further down the chain. You just was brought into you talked about blocking DNS.google.com from a HTTPS point of view. Is that still a valid thing? I mean, we how many of us work full-time in the office nowadays? Not very many. >> Right. >> So, the device is is is the issue, not

particularly the network. >> That that's that's absolutely correct. um you know so uh so yes what I'm advocating is everybody return to office 100% of the time complete uh no no uh please don't record that um damn it um but uh but but or excuse me Joe uh there we go uh but but yes uh now now there are things that you can do if you've got uh if you've got uh uh you know uh like zscale or some sort of onrem firewall you can put or excuse me on uh laptop top uh your agent firewall, you can put those requirements so that even when people are home and using their work laptop, you can uh tamp down

some of those requests. But again, that's a lot to manage. And then you have to deal with all the uh uh you have to deal with all the help desk uh complaints. I can't get this plugin that I installed. Well, why are you installing a random plugin on your browser? Don't do that. Um >> uh um but so so >> highlighting a random problem highlight another problem that we've got then how do we put the mitigation for that >> right? Yeah. Exactly. And and I mean they they all build on each other >> down the track aren't we? >> Yeah. And and I mean and ultimately and so we're we are you know so recorded

future I I've seen that process because I've been there nine years where you know when I started nine years it's like go buy a laptop and then connect to our things and that was the extent of our security. don't do anything stupid was was effectively what it was. Um, now we've got a much tighter security control. A and we've seen over the years a as we've tightened up what we do and what we monitor and manage. Um, that generates a whole lot of complaints, but it's kind of what we've had to do to take control. It was one thing when we were 80 people, now we're 1500 people. Um, you know, so you know that those are

the kind of things we have to manage. So I but I but your point is is valid, right? That is you are you can protect within your workspace and you can even protect within um you if you're going to use uh agent firewalls and stuff like that. You can even protect the laptop, the work laptop connecting remotely. But what if you've got an employee that's asking access accessing Salesforce from a uh you you know from a home laptop because you know theirs isn't working or whatever. >> Bring your own disaster problem, >> right? It because it doesn't matter where the credentials are stolen from whatever machine it's stolen from. If they're there and they're out there,

they can be used to compromise your work. So So you know it it really is I mean broadly speaking it's a real challenging problem. There are definitely compensating controls you can put in place, but know the limitations of those compensating controls. That doesn't and and I I don't I know that sounded a little defeist. I don't want to say, well, don't do it cuz nothing matters. It's all going to fail anyway and you're going to get hacked. Um I mean, that is what's going to happen, but uh but but but we should do better to to try and improve the security as much as possible. You know, it's like they say with uh you know, if you at

least lock your car, then the you know, the casual thief is going to go to somebody whose car is unlocked. >> You're moving the problem away. You're making it harder for bad guys. >> Right. Right. Exactly. And that gives you more chances to uh that gives you more chances for detection. And that's, you know, I know it's almost cliche at this point to say, "Oh, defense and depth's important because everybody says that." But it really is true. And part of that is it gives you multiple te tiers of failure. Oh, we missed this, but because we were monitoring at these levels, we caught the second thing they were trying to do. So, we missed the

initial access, we got the first stage of the attack, etc. Um, so yes, do those things just know there are limitations to them. Any >> um so does usually follow the same sort of exploitation methods as normal DNS but with the like SSL on top? >> Right. Exactly. So it's, you know, used for the same things that you would use DNS for. So C2 communication is the number one thing that we see DOH attacks for. Um, and then number two is exfiltration. So they'll exfiltrate over that because again, right now there's so much SSL traffic. It used to be it'd be really weird if, you know, somebody was, you know, sending a lot of data over

SSL, but now everybody's sending a lot of data over SSL, so you don't always notice it. Um uh and so it it it blends in unfortunately a lot better. >> Any other question? Oh. [Applause]