Summary
Beyond the Firewall: How Attackers Weaponize Your DNS
For many IT professionals, DNS is the internet’s invisible plumbing, historically managed by a “guy with a Unix beard in the basement,” as Infoblox educator Josh Kuo recalled on the Defenders Log podcast. But this foundational, often overlooked, protocol has become a primary vector for sophisticated cyberattacks.
In the interview, Kuo shared a jaw-dropping story of a software company that was unknowingly leaking intellectual property. Attackers weren’t breaching firewalls; they were using DNS tunneling. By encoding stolen data into a stream of seemingly normal DNS queries, they exfiltrated sensitive files right past traditional defenses. The malicious queries themselves carried the data out of the network.
This technique is effective because security teams universally trust and permit DNS traffic (port 53), creating a massive blind spot. Attackers exploit this trust not only to steal data but also to establish command-and-control (C2) channels, using DNS responses to send instructions to malware already inside a network.
The solution is to stop seeing DNS as a simple utility and start treating it as a critical security layer. By implementing Protective DNS services that use threat intelligence to inspect and block malicious queries, organizations can stop these attacks before a harmful connection is ever made. As Kuo emphasizes, understanding how DNS can be abused is the first step to defending it.
Full episode of The Defender’s Log here:
TL;DR
- DNS is an Overlooked Attack Vector: Because DNS traffic (port 53) must be allowed through firewalls for the internet to work, it has become a major security blind spot that attackers actively exploit.
- Attackers Use DNS to Steal Data: A key technique is DNS tunneling, where stolen data is encoded into a series of DNS queries. The queries themselves exfiltrate the sensitive information, bypassing traditional security measures.
- DNS is Used for Command & Control (C2): Malware uses DNS queries to “call home” for instructions. Attackers send commands back, often hidden in DNS records (like TXT records), to control compromised systems within a network.
- Phishing & Malware Start with DNS: Every malicious link a user clicks begins with a DNS query to find the server’s IP address. Blocking this initial query is the earliest and most effective way to prevent an attack.
- Protective DNS is the Solution: By using threat intelligence, a Protective DNS service can identify and block requests to malicious domains, preventing data exfiltration, C2 communication, and malware delivery before a connection is ever established.
- Education is Key: The speaker, Josh Kuo, transitioned from fieldwork to education to help the next generation of IT professionals understand these complex threats and recognize DNS not just as “plumbing” but as a critical security layer.
Links
View it on YouTube: https://www.youtube.com/watch?v=b_4BBF3qQgU
Listen to the episode on your favourite podcast platform:
Spotify
https://open.spotify.com/episode/3HFber3GgtqKXfdZKZovd1
Amazon Music
https://a.co/d/dllrGs5
ADAMnetworks
https://adamnet.works
Defenders Log Episode 6: Transcript
A Conversation with Josh Kuo of Infoblox
Intro: Deep in the digital shadows, where threats hide behind any random bite, a fearless crew of cyber security warriors guards the line between chaos and order. Their epic battles rarely spoken of until today. Welcome to the Defenders Log, where we crack open the secrets of top security chiefs, CISOs, and architects who faced the abyss and won. Here’s your host, David Redekop.
David Redekop: Well, hello everybody. Welcome back to the Defenders Log. This is episode number six and I’m very excited to have Josh Kuo with me today. He is the educator at Infolocks and uh Josh, welcome. Glad to have you.
Josh Kuo: Yes, thank you David. I’m very happy to be on a show.
David Redekop: I encounter a lot of people in the DNS space and uh just when years ago I thought it was a very small space. I see that it’s still growing over the years but then uh I think the actual DNS space itself is growing faster than the people. I’m constantly amazed at how broad the reach is of the work that we do in DNS. But uh before we get into some of the shop talk and technical things, tell us a little bit about Josh. Who is Josh?
Josh Kuo: So where should I start? Let me think. Um, I’ll start with why I got into computer stuff, which is interesting because growing up, my dad’s a dentist. I assumed that’s what I’m going to be. Everybody in the family assumed that’s the path I’m going to follow, but I felt it was kind of boring. I was attending school at uh, University of Hawaii, and I’m just like, organic chemistry, come on. I know how to tackle this problem. I just memorize all of this and I’ll be fine. But then I took computer science 101. I’m like, this is new. And I’ll be honest, I flunked the class. I sucked. But that was interesting. I’m like, this is not something I can memorize and conquer. So, it really piqued my interest. Like, this is something brand new. Um, so weirdly, I got into computer science because I sucked at it because it really piqued my interest. I don’t know how to solve it. And then over the years uh I would I worked as a small event ISP which is full of many colorful stories um that we we deliver uh uh like if you go to a trade show or a conference and speakers on stage well I would be responsible in delivering making sure the internet connectivity to that stage or to the podium is is is is good. So I learned a lot. I learned building networks really differently than other people because I I I I built uh I I I went to net world in Iraq which is a huge huge portable network. We used the address space 8458. That’s the address space and we use that to build a huge network in say Atlanta, pack it up, ship everything, go to Las Vegas, unpack it, let’s start over again. So I learned network building very differently than other people. Like to me , networks had to be built in a matter of hours or days, not weeks. Right? So from there I went to work for a uh security consulting company for a few years. Uh and then I encountered infoblocks and DNS and that was super interesting because DNS um in itself has a weird history depending on your organization or your team. A lot of people DNS at their company is the Unixy stuff, right? It’s the ponytail guy in the basement that’s running Unix server and DNS and that probably inherited down to like a bunch of systems folks today running DNS. Some other places it resides with the Windows team and some other places it’s run by the network team, right? Some places it’s all three and they fight over who owns which piece. So I happened to kind of know all these different uh uh sections and you know and and so I kind of got sucked into DNS and been doing that ever since. So quite a while now.
David Redekop: Well, I can identify with your uh description of the kinds of folks that are responsible for it at different companies. My first exposure was when I knew we had to collocate a server with our internet service provider’s data center in order for us to have some kind of a reliable presence instead of relying on our ISDN to be able to serve up enough bandwidth. And so uh I showed up with a box under my arm that was going to be racked. And uh this guy that I was introduced to, his name was Doug. Doug, I don’t know when we’re going to connect again, but I’ll never forget he was not your ponytail guy, but he had the Unix beard, right? And then went all the way down. And I’ll never forget that first interaction we have. So one of his first questions that’s technical, he says, “So do you have a zone file?” I’m like, “What’s a zone file?”
Josh Kuo: Zone file, right? Right.
David Redekop: And then after what’s a zone file response, then it’s like three more strokes of the beard. Oh, this is where we’re starting, are we? And so he was very patient. We became uh friends and interacted with each other for a long time and until he got out of the business. But uh anyway, so yes, there are certain character types because all that stuff under the hood so to speak or the internet plumbing as others refer to it has to be done and has to work and nobody notices when it’s working but everybody notices when it’s not working, right?
Josh Kuo: Yes. Yes. Exactly. Anybody who’s run a network can identify with that. um when I used to run many one of the many past jobs with our team ran the networks uh for the the convention center and then they didn’t understand like why do we need this whole team of people we never have problem with networks so they started laying people off and go well guess what the network has problems like we worked hard to you know to to upkeep the network we were talking about layers just before we called right because I had a layer one problem right and One of the coolest things about DNS and the discovery of DNS is I remember when it clicked for me if DNS works it means everything is working because it’s a layer 7 application and that means all the stuff below it okay you know with an asterisk most of the stuff below it probably is working as well if if your DNS is working and to this day I see you know entry- level technicians can I do an NS lookup of https://www.google.com/url?sa=E\&source=gmail\&q=google.com and if that works okay then I’m good to go Right.
David Redekop: Right. It’s actually what I run so I do customer facing education at infoblocks. Uh actually so what I see is almost the flip side there’s a lot of people who are focused on web applications. So what they’ll do is go to the web address https://www.google.com/url?sa=E\&source=gmail\&q=app.comp.com whatever it doesn’t show up and then they don’t have enough knowledge to troubleshoot correctly. And a lot of times you know you know how the hierarchy goes right the app people blame the system people system people blame the network people network people blame DNS.
Josh Kuo: So my job a lot of times is walk through well what does it do and what steps can you take using NS lookup uh or dig uh or other tools to figure out what’s working what’s not working and why and where do you go from there?
David Redekop: No, it’s uh that’s very interesting that uh that’s the role that you end up ended up as uh being the edgeator. Did you eventually get to a point I mean given some of the publications you’ve written like for example DNS sec deployment guide like that gets about as technically nerdy as you can get at what point did you switch to the uh education side of things?
Josh Kuo: So, I think I’ve always had a tender spot for education. Um um I had thought about going to pursue my master’s degree and maybe teach at the university, but my grades were so bad. They didn’t want me. So, I’m like, “All right, well, I guess I need to go to find a real job.” But I still love, you know, just sharing my knowledge because I always think it’s important throughout my career, my own career path. A lot of people kind of like you mentioned Doug with the beer. All right. Took the time, sat down with you and go, “All right, dummy. Let me explain to you how this stuff works, right? But not so condescending like I just did, but they did in a very very nice way. And I want to be sort of that person for the next generation of people to come that’s going to build and expand the internet that you and I have inherited from the generation before us.” Um, so I did a lot of consulting work. I did a lot of field work installing configuring uh troubleshooting um not just DNS but many many systems and over time the sort of opening line for my classes I kind of joke about hey guys I got tired of doing that so I’m going to teach you so you can do it on your own. So that’s partially why I decided I’m going to switch from I used to do more 5050 of field work and training. Now I do exclusively just training.
David Redekop: I see. So instead of giving a man a fish, you wanted to teach him how to fish.
Josh Kuo: Right. And hopefully I get to the part where I’m even behind. I’m teaching the teacher who’s teaching you how to fish.
David Redekop: That’s excellent. That’s excellent. I still found myself last week asking one of our guys, guys, I don’t want to be taught how to fish. Today, I just need to fish. So, there are times when one is needed and there are times when the other one is needed. Yeah. So DNS is a very broad topic and one of the reasons I was glad to um ask you to come on this podcast uh Josh is that infolocks has been a really important leader in the industry in doing threat intelligence uh for um large enterprise for government to the point where I see SISA documents coming out of the United States um CISA group where the only vendor that’s mentioned is infoblocks Like first of all good on you guys uh congrats on obviously doing good work in that space for creating um in a way I don’t know it was you who created the protective resolver uh nomenclature that now gets used as a standard uh uh no I wish take credit for that sorry it’s yeah that that now protective DNS was created by NSA and CISA okay gotcha gotcha um but you are definitely dominant um in that space and uh there’s lots of opportunity for others now to come into that space and we are excited to um potentially be doing uh some things together in one way or another because we have um complimentary uh technologies let’s just say but tell me uh because what what our audience is interested in hearing is actual stories um and I know you have uh lots of them so some that you can share where mal malware took a very interesting approach that was novel at its time and once one malware author does something then another group might adopt the same techniques but tell me the first time when you’re like had a jaw-dropping moment of uh DNS being the vehicle for malware.
Josh Kuo: Sure. Okay. So um without just sharing the names of the parties involved we found a case where the customer is a software vendor. So they have a lot of sensitive uh intellectual property copyright material and these are leaked and they couldn’t really find out why. I don’t, we don’t see any leakage and after quite a bit of investigation uh and with some of the Infoblancs appliances in line we were able to see well guess what they’re leaking out through DNS. Uh this is quite a few years ago when DNS tunneling was not as common or well known. So we explain to educate the C customer that most people think oh DNS you just look up a name you get an IP address and that’s it. How can you possibly leak or steal data over that? Like, well, oh, there’s record types and blah blah blah blah blah. We could do this. I could I could set up evil https://www.google.com/url?sa=E\&source=gmail\&q=josh.com and if I get the malware on your computer, it could look up, hey, what’s the name for https://www.google.com/url?sa=E\&source=gmail\&q=xyz.josh.com. Okay. And and and get a response. That’s a normal DNS exchange. But in this case we can see in instead of asking for https://www.google.com/url?sa=E\&source=gmail\&q=XYZ.vilosh.com it takes a stolen data and and do something to it you know in different encoding and it becomes chunk of https://www.google.com/url?sa=E\&source=gmail\&q=data.jsh.com and goes to the DNS server. Now whether or not the DNS server responds is irrelevant at this point. the data already got out and then the evil persons running this website or domain just collects all this DNS information and then reassemble it in the far end to get back the exfiltrated data. So that was I think yeah this is several years ago and when I first learned about it I’m like wow that’s cool. Well that’s the first thing and secondly whoa this is terrible because a lot of people wouldn’t think that they need to watch DNS as it’s leaving their front door.
David Redekop: Right. So most people think of a firewall as something that you just block certain ports. All right. So if I want to block FTP, block port 21. Okay. And that’s all I need to know about that. Okay. I don’t want to allow web traffic out so I block ports 80 and 443. Good. And nobody bothers with port 53. Port 53 is used for DNS. It always has to be open. Otherwise, I can’t look up https://www.google.com/url?sa=E\&source=gmail\&q=google.com or I can’t look up microsoft.com or whatever. So most people don’t really pay attention to that. And and and that’s why it was so effective back then. Because people don’t think about it, don’t know to look there, and that’s how people were leaking data out. Now, since then, there’s been other iterations of using DNS for uh uh nefarious purposes. For instance, command and control. That’s another interesting thing where the attacker will set up an infrastructure to respond to DNS queries but the queries and responses actually mean something. Right? So it’s not actually, “Hey, what’s the IP for so and so?” The response is not an IP. Response could be a TXT record. Okay. And the malware could say, “Okay, give me the TXT record for Google Search” Okay. And I send back in the TXT record some kind of encrypted message or something that says, “Okay, computer, I want you to go look for all the social security numbers on this computer and encrypt it and send it back to me.” Right? And then the next query would say, “Okay, here’s some encrypted data.” And that sends it back. So we found many cases of these kind of exchanges over the years. So DNS tunneling can be used for data exfiltration as well as for command and control. And nowadays, uh, we also see DNS used for phishing and malware delivery. Okay. It’s the, you know, the most simple cases you get an email. “Hey, you won the lottery!” Oh, that’s great. I won the lottery. Click on this link. Okay. I click on the link and that link is a DNS name, right? It’s not an IP address. So, I click on the link. Okay, what’s the IP address for Google Search? Okay. It comes back as so-and-so IP and then my computer goes there. And that’s where the malware is hosted. Right? But if you can catch it early enough in the chain… If your DNS server says, “Oh, Google Search, I know about this place. That’s a bad place.” and block it right there, then the malware delivery doesn’t even happen.
Josh Kuo: That’s right. That’s right. And it’s not even a case of a bad website. Sometimes a good website gets taken over.
David Redekop: Oh, yes. Yes, many times. What we call a domain hijacking where the bad actor, the evil actor will go to your domain registrar where you register your domain, okay, and they will try to social engineer and try to hijack your domain. So now, you may have a domain called Google Search. Okay. And that points to a web server. But if I hijack Google Search, I can point it to a different IP and now that’s my malicious server. So people think they’re going to your website, but they’re not. They’re going to mine, and that’s how I can do all kinds of malicious stuff.
Josh Kuo: Right. Or they can poison the records on your authoritative name server if they can get access to it. It’s really insidious. And so the average consumer doesn’t know. All they know is that they went to a website that they trust. And then all of a sudden, they started getting ransomware attacks or something like that. They started noticing symptoms of, “Wow, I have a problem on my computer.” And so this is a really insidious way that malware gets delivered to consumers these days. And so, um, I think one of the most important things that a chief information security officer or a business owner needs to do is to consider the end points on their network, which can mean all the laptops that they’ve handed out to their employees, what are they clicking on? Right? And the only way you can really know is to do a packet capture or in some other way, look at the logs of your DNS queries.
David Redekop: Yes. Yes. Correct. Uh, but that’s hard to scale up. If you have a small company of 10, 20 people, you can probably manage it. You know what? Just to look at the logs. But if you have 10,000, 20,000 people, how do you sift through that much noise? And that’s where, you know, some of the Infoblox product line is, that’s what we focus on. We build a threat intel platform where we can consume threat intel data from many different sources, our own research team, from the government, from other third parties, and then we’ll build a gigantic list of bad domains or bad IP addresses and and we put some logic to it so that if your users tries to go to a bad place, we’ll we’ll we’ll sync hold them or we’ll stop them before they can get there.
Josh Kuo: Yeah, that’s beautiful. That is a great gift to the internet community, and I’m glad that you guys have taken that on. It’s an enormous task. So, Josh, we’re out of time. This has been a fascinating conversation. I hope it’s not the last time we’ll speak. I want to thank you for coming on to the Defender’s Log.
David Redekop: Thank you so much. It was a pleasure.