Antisyphon Training Anticasts

🧦 SOC Summit 2026
https://www.antisyphontraining.com/event/soc-summit/

Are attackers hiding in your DNS traffic right now?

🔗 Register for FREE Infosec Webcasts, Anti-casts & Summits – 
https://poweredbybhis.com


Join instructor Faan Rossouw for a free one-hour training on hunting malware that uses DNS as a covert communication channel.

C2 frameworks, RATs, and backdoors frequently exploit DNS to stay hidden - sometimes for months. High-profile attacks like SolarWinds' Sunburst demonstrate just how devastating undetected DNS exfiltration can be.

This Antisyphon Anti-Cast focuses on behavior-based threat hunting techniques that go beyond signatures to uncover suspicious DNS activity attackers think they've hidden.

You'll learn how to:
* Recognize network artifacts that DNS tunneling produces
* Identify anomalies in DNS record types that signal malicious use
* Leverage open-source tools like Zeek, RITA, and Sysmon to detect malware abusing DNS
* Build detection strategies that make it very hard for DNS-based threats to remain hidden

If you're ready to stop trusting DNS and start verifying it, this session will give you the practical skills to hunt what's lurking in your network.

Chapters:
  • (00:00) - Intro - Threat Hunting Malware Communication over DNS
  • (01:00) - Introducing Faan
  • (02:35) - Threat Hunting C2 Over DNS
  • (04:07) - Threat Hunting - What is it and why is it awesome?
  • (05:49) - Assumed Compromise
  • (07:02) - David J. Bianco – Pyramid of Pain Guy
  • (13:35) - C2 Over DNS
  • (28:10) - TXT Record Abuse
  • (32:53) - Null Record
  • (35:14) - CNAME, MX, SRV… Oh my
  • (38:33) - DNS Sandwhich
  • (42:55) - ID Field Missuse
  • (49:05) - EDNS0
  • (52:40) - Encrypted DNS
  • (55:22) - Main Takeaway
  • (56:21) - The Workshop: Build a Reflective Shellcode Loader C2 in Golang
  • (57:58) - Q&A Start
  • (01:00:22) - DNS and Splunk?
  • (01:01:55) - Suggestions for Detecting DGA?
  • (01:03:32) - Offensive Security Tooling from a Threat Hunter Perspective
  • (01:07:34) - Restrict outbound DNS to protect against C2?
  • (01:09:13) - Communicating the value of Threat Hunting to Higher Ups.
  • (01:13:56) - Closing Remarks

Brought to you by:
Black Hills Information Security 
https://www.blackhillsinfosec.com

Antisyphon Training
https://www.antisyphontraining.com/

Active Countermeasures
https://www.activecountermeasures.com

Wild West Hackin Fest
https://wildwesthackinfest.com


Creators and Guests

Host
Zach Hill
Guest
Faan Rossouw
I’m a security researcher focused on the intersection of threat hunting and agentic AI. I do research at Active Countermeasures and instruct at AntiSyphon, teaching threat hunting and offensive security tooling. I’m also currently building aionsec.ai, an open-source platform to make elite threat hunting accessible to everyone.
MB
Producer
Meagan Bentley

What is Antisyphon Training Anticasts?

Podcast audio-only versions of weekly webcasts from Antisyphon Training

Zach Hill:

Hello everybody and welcome to today's Anticast with Phan. Super stoked today because he's going to be threat hunting some malware. I'm just gonna let you get started here and I will pop back in when there's about five, ten minutes or so left so we can do some q and a. And I will also announce our CTF. So, Ivan, go ahead and Perfect.

Zach Hill:

Get started. Good luck. Have fun. I'll see y'all soon.

Faan Rossouw:

Yeah. Thanks, Zach. Thanks a lot. So yeah. Okay.

Faan Rossouw:

Hello, everyone. So, yeah, welcome to my talk on threat hunting DNS. It's something that I'm actually very particularly very passionate about, specifically using DNS as a cover channel. So I'm super happy to share this with all of you guys today. So very quickly, who am I?

Faan Rossouw:

I actually forgot to add my name here, but my name is Fawn Rousseau. I work as a researcher at Active Countermeasures. That's the sister company of AntiSyphon and Black Hills. I also work as an instructor at AntiSyphon. I'll talk a little bit more about that towards the end of some things that are coming up.

Faan Rossouw:

I've also recently started my own little side project on ionsec.ai. It's really to do with the kind of overlap of agentic AI and threat hunting. So I'm gonna be teaching stuff there, and I also have an open source project I'm starting there. So if you're interested in that, please go check it out. If you wanna follow me, that's my home page.

Faan Rossouw:

I share a lot of free content there of all formats, so go check that out. And I also recently, last month, I joined LinkedIn in X. So my profiles I don't have a lot of friends there, guys. So you're all invited to be my friend over there. I appreciate it.

Faan Rossouw:

And GitHub, I publish a lot of free open source tools. I almost only work in Go. And mostly, it's different covert channels. And then I have a few kind of detection tools as well. And I've done a lot of effort now to document them properly.

Faan Rossouw:

So go check that out if you're interested in that. And in YouTube, I each time I'm here, I say I'm about to publish new videos. It never happens. But for real, guys, there's more content coming there related to ION's sake, related to Threat Hunting and Genetic AI coming in March. So, yeah, go join me there too.

Faan Rossouw:

So threat hunting c two over DNS. I always like kind of starting a talk by deconstructing the title because I think a title should ideally be pretty descriptive or indicative about what the talk's gonna be about. So that's the title. I have kind of a a subtitle or a tagline, which is beyond the obvious. So let's just break down the three major components here.

Faan Rossouw:

First, I'm gonna jump into threat hunting. I'm gonna tell you what threat hunting is and why it's awesome. This isn't really a super fundamental talk. It's gonna get way more com I I don't wanna say complex, but perhaps advanced towards the end. But I just wanna make sure that everybody at least knows what exactly we're talking about.

Faan Rossouw:

Right? And then we'll talk about c two over DNS. Just gonna really set the foundation so we understand what it is and how it works, kind of the the archetype almost. Right? So that that's a proper departure point for us to get then get into the third part, which is beyond the obvious.

Faan Rossouw:

Now why do I title beyond the obvious? It's because a lot of people, when you hear people speak about c two over DNS, they'll say kinda like, well, c two over DNS isn't really a problem because if you know exactly what to look for, it's very easy to find. And that's kind of one of those half truths. They're mostly right, but it's kind of a picture that's low resolution. If we add a few more pixels to that picture, we're gonna see there are exceptions, and it's not always as easy as it might initially seem.

Faan Rossouw:

Right? So threat hunting, what is it and why is it awesome? Well, if we typically think about a defensive security posture, kind of there are two components that come to mind. Right? The first is protection.

Faan Rossouw:

Right? It's the barrier. It's the wall. It's the moat. It's the drawbridge.

Faan Rossouw:

It's the archers. It's supposed to keep things out. Right? The other component is response. And our response is, okay.

Faan Rossouw:

Once we know there's a threat inside, either because we found them or they said, Your data's encrypted. Give me some Bitcoins, please. Then you have to deal with them. So those are kinda like the two comp the the two parts, you know, that we usually think when we think about defensive security posture. But what happens in the middle?

Faan Rossouw:

And what I mean by the middle is what happens what is this space where it some an adversary got past your defense but you're not yet aware of them? And this is typically referred to as the dwell time. Now it's hard to find the exact number because there are a lot of different numbers, and I think different people have different incentives for sharing different numbers. But it's always surprisingly longer than you expect it to be, and you could say the average time, which doesn't include when ransomware actors reveal themselves, might be something like six months. And so one way we can actually think about threat hunting in terms of its mission, you know, kinda like in a in a systems thinking kinda way is its job is to kinda collapse that gap.

Faan Rossouw:

So take it from six months, five, four, three, trying to minimize the time from when an adversary slipped through to when you know they're there. And it does that because it is kind of fundamentally based on this philosophy or school of thought that you can call assumed compromise. Now assumed compromise is a radical departure from idealism. Idealism is something like this. We'll keep a 100% of defenders out all the time because our defense is so good.

Faan Rossouw:

We signed up for the, like, the newest EDRs and all of that. Assume compromise says basically that it doesn't matter what you do. The there is so much complexity today. There's so much incentive to be attacked that it is basically impossible to keep a 100 of attackers out a 100% of the time. And so threat hunting said, well, okay.

Faan Rossouw:

We don't know for a fact there's someone inside, but if we assume someone's inside, if we hypothesize someone's inside, how are we gonna go about finding them? That's what a threat hunter does. And so the goal of threat hunting then is to find threats. Right? Pretty simple.

Faan Rossouw:

Right? Threat hunting, finding a threat. But it's actually not that simple. And to kind of understand what I mean here is let's turn to some guidance from one of our elders. And so some of you you might know David J.

Faan Rossouw:

Bianco. He's the Pyramid of Pain guy. He invented the Pyramid of Pain, which is in and of itself an incredible, I think, mental framework to help guide decisions and where to invest time and energy and stuff like that. But perhaps some of you didn't know, he's kind of like one of the, I would say, the founding fathers or I call him the high druid of threat hunting. Right?

Faan Rossouw:

He's he's OG. He he was there in the inception. He helped formalize it. And he's invented many other frameworks, the threat hunting maturity model. Initially, it was the SQUIRREL framework.

Faan Rossouw:

And then now most recently, he has, as part of his work at Splunk, contributed to the formalization of a framework called PEEK. And I wanna really just encourage anyone here that has an interest in threat hunting, whether you're starting out and you wanna learn more or you already started out and you wanna get better. You know, one of the major criticisms always leveled towards threat hunting is that it's this very kind of intuitive, nebulous, undefined act, and that sometimes has a hard time gelling with how businesses operate. Right? And one way in which you can become much better at understanding how to structure and formalize the process without sucking all the creativity and intuition out of it, right, which can become a danger too, is having some guiding framework or structure.

Faan Rossouw:

And that doesn't mean you need to be held captive to it. It means it helps create some order from chaos. So anyway, long sales pitch almost. I encourage all of you to go check out the Peak framework. But in the PEAK framework, David will also say that, you know, when you ask most people, obviously, that are on threat hunting, not the average man on the street, what is the goal of threat hunting, they'll say, like, finding threats or maybe more verbosely, finding threats that evaded existing detection.

Faan Rossouw:

Right? And when he formulated the SQUIRL framework ten plus years ago, that was also his original definition. But it has evolved since. And it's evolved mostly because if your goal is just finding threats, a, the value is transient. It's binary.

Faan Rossouw:

You succeeded if you found a threat, and if you failed, it was not a success. Right? And so now when he states that the goal of threat hunting actually is improving overall security posture through proactive searching. And so a threat hunter is almost like this person moving in your security posture, doing a permanent audit. They're looking for adversaries, but they're also they don't have tunnel vision.

Faan Rossouw:

Right? They're constantly scanning and being aware of everything there and seeing where gaps might exist. And so as he says there, you know, it's about making the organization fundamentally more secure through the hunting process itself. And so just to kinda wrap up my little section on threat hunting, I do wanna say because now it sounds kinda very lofty. Like, okay, Fon, what do you mean?

Faan Rossouw:

How how does threat hunting do this? And one way we can actually understand is, like, okay. If we say the goal is to improve overall security posture, and PEEK defines five core metrics. Another thing, hunting has always been very criticized for not being able to be measured. And so one of the goals that Peak set out to achieve is how do we create measurable metrics for threat hunting?

Faan Rossouw:

Because at the end of the day, guys, we need buy in from companies. Right? So it's important to have systems that can connect to one another. So what are the five core metrics? Well, first, it's incidents discovered, actual threats found.

Faan Rossouw:

So this is the original definition. Right? Threat hunting. This is the hunting threat. Okay.

Faan Rossouw:

You found a threat obvious. That's a good metric. Let's report that. The second one is new detection created. Now threat hunters have a specific hypothesis.

Faan Rossouw:

They're looking for specific, let's say, MITRE tactics or techniques or sub techniques, and then they might go in and see, oh, we're not actually even looking for bad techniques. We don't have the detections for them. And then there's a tight bond between the threat hunter and the detection engineer because the threat hunter's insight feeds back into the detection engineer, and it's almost like it becomes a memory. So that gets captured. Right?

Faan Rossouw:

So now the overall security posture has improved. The third one is visibility gaps identified, missing telemetry or blind spots. Now this one initially might seem a lot like the second one, then we just kind of say that. The second one means you have the data, you have the telemetry, you just don't have the detection. This one means you don't even have the data at all.

Faan Rossouw:

So again, the threat hunter has a hypothesis. They're looking around. They're like, oh, we don't even have data that would possibly say if somebody was using this technique. Another gap fold there. This one's pretty obvious.

Faan Rossouw:

Obviously, unpatched vulnerabilities or something that's misconfigured. Right? And then the last one is kind of weird, it seems like how is this improving. And I like it because in this way, even if even if you didn't find anything, every even if everything was perfect while you looked, just the fact that you can use, for example, the miter to see what you're covering, and now you can mark that I checked this tactic. So the next time we do another hunt, what we have to look at has now shrunk.

Faan Rossouw:

And even in that way, it has had progressive value. Right? It means the target has basically shrunk a little bit for the next hunt and we can be a little bit more accurate perhaps. So hunt output feedback into the system to strengthen it. And so really the core crux, why is threat hunting not just about hunting threats?

Faan Rossouw:

Because if you define it like that, then threat hunts that don't find threats are a failure, but they're not. Because if you identify the gap, if you produce new insights, new documentation, that is still a successful hunt. Your overall security posture has still improved. Obviously, I just touched on it. If any of you wanna know more, this is the excellent talk.

Faan Rossouw:

David's a great speaker. He has a bunch of videos on Peak. I think this is the best one. And then Splunk also has, like, a 40 page PDF on it. 40 pages, but a lot of beautiful graphs and stuff.

Faan Rossouw:

Extremely digestible. Again, encourage you guys to go check that out. I'm not a big frameworks guy guy necessarily, but Peak and MITRE are table stakes if you wanna get better at threat hunting, in my opinion. Moving on. So c two over DNS.

Faan Rossouw:

So guys, I can't spend time now defining what DNS is and how it works and the resolution process, you know, and either resolution or all that. There are tons of videos on YouTube to describe that already. Black Hills or Anti Syphon has a good one already on the subject, and and Troy already did one on that as well, c two over DNS. So go and look at that. I really wanna depart from it already being used now for c two.

Faan Rossouw:

That being said, I do have one quick slide just to quickly define what DNS is. And DNS, really, in its most simplest form is, hey. I have a domain. Please give me the IP for this domain. Okay.

Faan Rossouw:

Now I have the IP. Now I can actually go and connect to it. Right? Many of you that understand DNS will say, well, Fawn, that's not true. There's a lot of things involved.

Faan Rossouw:

It can be MX or a NS or a a service. There are a whole lot of different records, and that is, of course, true. But the genesis, the original impetus for creating DNS was this. It was to have IP for a domain. I don't know if you guys know this.

Faan Rossouw:

So DNS was created RFC one zero three five in 1987. Before that, many of you might know the host dot TXT file that you have on your system. Before DNS, everybody had a host dot TXT that just had every all IPs and domains on their computer. So that's how they that's how they knew where to make a connection to. Obviously, that became a little bit cumbersome around the eighties, so DNS was born from that.

Faan Rossouw:

So on the right is our agent. Right? It's the the victim host. It's on the target network. And now on the left is the c two server.

Faan Rossouw:

So I wanna I wanna show you how communication between these two happen. But I just wanna be clear now, the c two agent is basically LARPing. It's pretending it's pretending it's a a regular system on the network, and it's like, hey. I wanna resolve the domain. Right?

Faan Rossouw:

And on the left, the c two server, what's what it's LARPing as is the authoritative name server for that domain. K. Just very important for you to understand, I'm drawing things that it seems like there's a direct connection between them and that that can happen. There are circumstances in which that will happen. I'm gonna discuss that later on.

Faan Rossouw:

More often than not, the c two agent is gonna it's remember, again, as on a corporate enterprise network, it's communicating directly with a local DNS resolver, and that goes and does a whole little dance until it ultimately reaches the third data of name server, which is the c two server. Okay? So just keep that in mind. I just didn't wanna clutter this diagram. So we we place our emphasis and focus on a different concept, But that's happening here, right?

Faan Rossouw:

It's just invisible to us right now. So as with a lot of different communication, we have the request response cycle, just like with HTTP and HTTPS. That's at the heart of it, request response. So agent, agent's also a client. The client always initiates the communication, right?

Faan Rossouw:

Request. Or in DNS Parlance, you can say request, but technically the right word is query. So this first query is the check-in. The check-in is just, hello, I'm here. Do you have a job for me?

Faan Rossouw:

And then I wrote cache issue here to say that one of the big problems that the agent needs to overcome if it's not making a direct connection is it it doesn't want to get a cached response along the resolution chain because that means the communication didn't reach the c two server. Now there are a few different ways of overcoming that, and I'm going to mention them later. I just want you to be aware of it right now. The response from the c two server sorry. So the agent asked, hey.

Faan Rossouw:

Here's a domain. I want this type of record. And then the c two server goes, okay. Here's the response. Here's the type of record you asked for about what that really is is some information, and that information will say either I don't have a job for you, in which case go to sleep.

Faan Rossouw:

There's nothing else to do. Or I do have a job for you, and here's the job I want you to do. Alright? Now if there wasn't a job, that's it. If there is a job, then the next step now is another round.

Faan Rossouw:

This isn't step three. This is just another pair starting another round probably many of them because if it's going to send a substantial amount of data, then it's going to have to do a whole lot of queries. Right? And we'll see that soon as well. But anyway, now it's sending the data back, whatever.

Faan Rossouw:

Grant, who am I? It's got the host name. The username is sending that back. So there, how is it carrying the data? Usually in an encoded subdomain.

Faan Rossouw:

I want to point that out right after I finish this. We're going to zoom into that and explore it in great detail so you will understand that. And then the c two server responds. And why does it respond? Well, it doesn't really need to respond, but it just got a query.

Faan Rossouw:

And if it gets thousands of queries and it decides there's no real reason for me to respond, I won't bother responding, that's gonna look very weird. So just to keep up the pretext that they're legitimate, you know, DNS communication, it'll just send something back. Right? So let's now talk a little bit more about this encoded subdomain. Like, how does that work?

Faan Rossouw:

How? I don't understand. How is the encoded subdomain carrying data? How does that work? So like I just said, the agent, the client starts with sending a DNS query.

Faan Rossouw:

It has two main things. It has a bunch of things, two main things. It has a domain that it wants to have resolved, and it has a record type, a, quad a, text, whatever. So in the first section, the question section, there's something called the queue name. What is the queue name?

Faan Rossouw:

The queue name is this is the domain I want you to resolve. Alright? It's gonna send it over to the server. By the way, guys, obviously, simplified representation here. There are way more fields, and we're gonna cover some of them soon.

Faan Rossouw:

But now it asks, hey, I want this resolved and then our data, right, the record data, the c two server plunks that on, that's the answer. So we we can infer immediately this is obviously an a record. Why? Because it's giving an I p v four address, and it's sending it back. So right now, focus on that queue name field, the one the domain name that was originally sent from the agent to the server.

Faan Rossouw:

Let's zoom into it. Now there's a whole domain, but we're just interested in the subdomain. The attacker cannot use the whole domain. It cannot insert random data into the domain. Why not?

Faan Rossouw:

Because nobody's gonna ever have heard of a random domain that doesn't exist, and it'll never reach somewhere. In this case now, we're saying, well, the I the the attacker actually registered and owns the domain ionsec.ai. And then on the C 2 server, they're gonna have a they will have a record, a wildcard record, which means any subdomain associated with ironsec.ai, it comes to me. I am the authority for that. So we don't really care about www.

Faan Rossouw:

We just care about some domain, right, the idea of the pattern of a domain. So subdomain, if we look at the RFC ten thirty five, it's going to tell you you have 63 characters in total that you can have there. That's actually, use the term label and not a string or whatever, but that's what they say. And now the attacker is going to put encoded data as that's going be the characters. Right?

Faan Rossouw:

So to make this more tangible for you, I'm going to use an actual example. This is from DNS CAD two. Different software can do this differently. DNS CAD two is one of the most popular, well known. And so this is an actual subdomain that I got from running a DNS CAD two experiment.

Faan Rossouw:

And we can see even though it has 63 characters capacity, the creator decided to only use 34. I don't know why. I'm thinking they thought it's a little bit less noticeable, but honestly, 34 characters that look like that, I don't know how much more subtle that is than just using 63 or 60. But in any case, that's what they decided on. So if we even split it apart, those first three, they're not even used for data.

Faan Rossouw:

They're used for saying, is the type of command? Then they have to keep track of the session, and then they have to keep track of track of the exact packet sequence in the session. Why? Because DNS is UDP. You don't get reliability.

Faan Rossouw:

It's not like TCP. It's not baked into the protocol. So if you want reliability, if you don't want garbled data arriving on the other side, you have to invest some of your data at the application layer into keeping track of those things. So now that's the actual payload, guys. The actual payload is 24 x characters and 12 bytes.

Faan Rossouw:

And this is the part where in the beginning when I said it's a solved problem, it's very obvious. It's all related to this, 12 bytes for data. And why? Well, let's look at it a little bit closer. So 12 bytes.

Faan Rossouw:

Here's an example of a command that I ran. And this command is to give me some information about all the processes running on a Windows endpoint. Very, very normal for an attacker to first do some enumeration. And very, very normal, one of the first questions is, what are the processes running and what are their PIDs? If I want to be able to attack one of these processes, first, I got to know what's there, and you're going to need the PID.

Faan Rossouw:

That's how you refer to it in Windows language. You're not going to use the name. And there, we got 16,277 bytes. So if our capacity is 16,012 bytes and we want to send that amount of bytes, that's thirteen fifty six queries. And now I just want to put emphasis on this that gives you thirteen fifty six subdomains and unique FGDNs.

Faan Rossouw:

Why unique? Well, it's just encoded data. What what is the odds that you just randomly generate the exact same subdomain? Very low. Probabilistically, almost 100%, they're all unique.

Faan Rossouw:

And this is, again, guys, this is just for the pits. This is a ticket to potentially have a chance at doing something at some point in the future. This isn't ex filling data and learning all the secrets. This is like, you know, a very, very minor thing. And for that, we're going to need 1,356 unique FGDNs.

Faan Rossouw:

So if you still don't understand what the issue is, yeah, I'm going to spell it out now. Over time, if you actually if you actually are going to send a lot of data, you're gonna have tens of thousands, hundreds of thousands, even millions of unique FQDNs, unique subdomains. And the big problem is the domain, if you're an attacker and you just bought some domain, nobody's gonna have ever heard of that domain. Right? And so the biggest domain providers online, they have maybe a few 100 subdomains, unique FQDNs max.

Faan Rossouw:

Right? CDN is not worth counting, but that's a different deal. But if the biggest as well as household names, right, if they only have a few 100 and you have something random sounding, right, like xj40defderp.com, and it has 800,000 unique FQDNs, that is extremely high fidelity indicator that something, you know, something is rotten in the state of Denmark there. Right? And especially if you look at one of those subdomains and it doesn't say wwwormail.

Faan Rossouw:

Or devdot, it looks like that. Right? So then from the threat hunters point of view, we can say, well, we look for a high unique FQDN counts, and if we see as well as high entropy domains associated with an unknown domain, it's kind of like a perfect shot, right? Very, very little doubts. And that leads to this conclusion that c two over DNS is a solved problem.

Faan Rossouw:

Just look for that, what I just described, and basically, you're bulletproof against c two over DNS. And and and again, that's not wrong, but the thing is that assumes DNS is being used for high bandwidth data transfer. And me, I like to think most things. But in this case now, DNS can be used as a covert channel in two different ways, Big picture. Know, using the wrong as the wrong tool for a job or as the right tool for the job.

Faan Rossouw:

Right? What's the wrong tool for the job? Well, it's not a high bandwidth channel, so don't use it for transferring a lot of data. So when you're using encoded subdomains to transfer megabytes or gigabytes, you're using a spoon to try and hit in the nail. It's a terrible tool for that job.

Faan Rossouw:

And so what I want to really look at today is more, what what is DNS more appropriate for and how can we actually detect that? Before I get to that, some of you might think that, well, okay. But if I can't use DNS for data transfer, what's even the point? Sorry, guys. Sometimes I wear both, I think, both as a threat hunter and somebody doing offense.

Faan Rossouw:

So sometimes I speak I speak from both points of view. I just use them interchangeably, just so you're aware. But you might think that, okay, if DNS cannot be used for a lot of data transfer, why even bother? Why even use it at all? And that's a limited point of view because that assumes that a communication channel always has to only be one protocol.

Faan Rossouw:

Right? Start thinking multimodal. The best malware, something like Sunburst, they don't just use one protocol. They can communicate and transition between multiple different protocols. They can use DNS as a sleeper channel, a low bandwidth channel.

Faan Rossouw:

They can learn things and then on whatever trigger decide to transition to an HTTPS channel, which is much more suitable for high that was designed for high bandwidth, so much more suitable for that. Okay? So just a quick overview of what we're going be looking at. We're to look at TextRecord abuse, and Null record abuse, CNAME, and MailExchange, and Service. And we're going to look at something funky called DNSSandwich, and ID field abuse.

Faan Rossouw:

And we're going to look at EDNS zero. And then finally, we're going to look at encrypted channels. So text record abuse. So we just looked at this picture. Right?

Faan Rossouw:

So just forget the second round of query and response, and let's just focus on a single round of it. And on this one, I said it does the query. It has a domain it wants to have resolved, and it has a type of record. So let's say in this case, it actually asked, hey, I want a text record. And then the DNS is going to respond and provide the text record, right?

Faan Rossouw:

So what I'm talking about now specifically is the ability for the server to transfer data to the agent in the other direction using the RDATA field of the text record. So as we said, agents typically, just operative word there being typically, we're going to talk about exceptions, uses encoded subdomains for data transfer, and the server typically sends data in the record itself. So queue name, one direction, our data in the other direction. Right? And we all know there are a lot of different records.

Faan Rossouw:

And at the moment, I would say probably the most popular is the text record. And why is it the most popular? It's not perfect, but in a kind of Goldilocks principle, not too hot, not too cold. If you think of a combination of factors, it just kind of averages out that it's more or less has the best profile for data transfer. So why is it popular?

Faan Rossouw:

What are these properties? It's got two and a five characters per string. That's not a lot, but compare that to a record or quad a, right, way more. It's fairly common ish. It's not super it's definitely not a or a quad a, but it's not a null record either.

Faan Rossouw:

You know, you expect to see some text records in your traffic. It allows for multiple strings, and attackers can use that. But that also potentially introduces new problems from their point of view. So usually, it's not even used. But the real, I think, cherry on the cake from the attacker's point of view is one of the main uses for it is domain verification.

Faan Rossouw:

And when it's used for domain verification, a random encoded blob of data is inserted into it. So in other words, if an attacker decides to put a random blob well, not random, encoded data inside of it, superficially, it doesn't look wrong. It looks like that's what it's supposed to look like, unlike an encoded sub you know, high entropy, 50 character encoded subdomain. Clearly, like something's amiss there. This doesn't.

Faan Rossouw:

It blends in. So for detection, like I said, text records are not unusual. But what is unusual? Well, a sudden deluge from a single external host or domain to a single internal host, that is suspicious. And how are we gonna detect it?

Faan Rossouw:

Well, our good old friend Zeke, we can just query the DNS log and ask, show me all the domains where the text records were sent. Show me the amounts, and sort it by descending order. And so this is what that command would look like. Unfortunately, I won't have time to go through all the commands. There's quite a few of them today.

Faan Rossouw:

But please take the slides. They are available. Just use whatever resource you have at your disposal, something like Geppity or Gemini, and it'll quickly tell you exactly what that means. But here I ran it. This is from an actual data set that will be available to you guys as well.

Faan Rossouw:

And you can see inside of it, they're at 4,696 records. Not super exciting because it was the only thing there. So let's just kind of think of what would another data set look like that was on a busier network. It might look something like that, right? So you have records, different domains, but then you have this one that clearly sticks out, right, many times more.

Faan Rossouw:

And then obviously, next step is timeserversync.com. Sounds legit, but I've never heard of it. Let's do a domain reputation check on that, and then that's in combination with the amount of text records should definitely flag that something's going on here. So this was actually used a few times last year. This article is from July.

Faan Rossouw:

It was a specific type of malware called Joker Screammate that used this to upload the next stage, right, the payload to the the victim. And that kind of inspired me then to do my own simulation on it. So there's an article on Malware of the Day, which is a series I do where I simulate different malicious acts. I threat hunt them. And like I said, there, I always make the PCAP and the ZCLUGs available so you can perform the threat hunt yourself at home.

Faan Rossouw:

Next, have null record. So again, just to remind, the refreshed Jogger memories just established that from the agent to server, usually encoded subdomains. From the server to the agent, usually data's in the actual record, the R data field. And so here, we use text, but there are other options, right? And one of these other options is called the null record.

Faan Rossouw:

And so the null record defined in the original RFC for DNS and it's one of those weird things where they thought of all the things they'd need and created specific records for that. And then they said, what if one day we need something and we don't know what that something is? Let's just create a big old placeholder here. And so they gave it, like, full stats, like in a RPG game. They just maxed out all the stats bars and said, surely, one day, this will be useful.

Faan Rossouw:

So it has no imposed structure, and it's just the placeholder. And it turned out they were kind of pristine because it did turn out to be very useful for attackers. It was like the perfect record to use. A, you didn't need to encode it. It carried raw binary data.

Faan Rossouw:

No encoding overhead. Right? And 65 kilobytes per response. Right? You could upload your entire payload in a single request response cycle.

Faan Rossouw:

Incredible stuff. And it's so it must be clear to you that it started off really popular. I mean, it was wild when they started using it. But then the thing is it also literally has zero legitimate uses. And so what happened is victim of its own success.

Faan Rossouw:

How do you stop it? Well, just flag an alert on all instances of null rec null records should never be used on your network, So please flag it if it's happening. Once again, Zeke to the rescue. And there very easily remember, Zeke exposes per default, right, the domain name and the record type. So we can always find these things.

Faan Rossouw:

Very simple little query here. And you can see there we have a null. And it seems like they also didn't choose a very subtle domain name there. But there it is, right? Show me all null records.

Faan Rossouw:

Continuing, more and more records, CNAME, Mail Exchange, Service. Oh my. So if we look at the RFC, there are about 80 different records. But in reality, if you exclude DNSSEC, maybe on average corporate network, you'll see somewhere between ten and fifteen, right, on the low end and on the high end. So that's why I say the ideal versus the real.

Faan Rossouw:

Now almost any of them could theoretically, in principle, be used to carry data, and but that doesn't mean they're all equally suited. Some sure. You could do it, but there's no point in it. But of the ones that you can use, it's not always obvious which one to use. There are different trade offs that they have.

Faan Rossouw:

Right? And for whatever the attacker's goal is or their own personal preference, they might choose different records based on that. And there's almost always this trade off between capacity and stealth. So the higher the capacity, usually, the lower the stealth. And so then you'll use something with lower capacity like quad a that's much more, you know, common.

Faan Rossouw:

But then you're also because the capacity is so low, you have to use so much of it so that in of its way isn't stealthy too. There's no easy it's like a damned if you do, damned if you don't kind of consideration for the attacker. But that's what they have to work with. That's what they have to decide. So I'm just kind of mentioning these three because they're also they're also used, and they all return a host name.

Faan Rossouw:

And so hopefully, for some of you, you can immediately understand that that means, well, if they're returning a domain and we spoke about the subdomain being used from agent to server, this means that they can once again use the subdomain, but now from the server to the agents and not in the queue name field, but the R data field. Service record has an extra little capacity as well. So at the end of the day, it leads leads to the same high risk, high FQDN counts, high entropy. Right? So just to kinda summarize now, you know, speaking about these different records being used, like moving a lot of data has clear tells when you're doing it with DNS.

Faan Rossouw:

Again, it's not designed to do that. But you have to know what to look for and look for it. The reason I'm showing Noel and looking at the the R data field and stuff is because people, I think, become so obsessed and hyperfixated on only focusing on the queue name field agent to server. But there are worlds and there are design paradigms in which there are not encoded subdomains being used for XFO, but for info. Right?

Faan Rossouw:

So it's easy to detect, but you have to detect for it, obviously. And like I just showed, Zeke can almost detect everything because it exposes it doesn't even ex you don't even need scripting because Zeke literally has it in the default logs. And for some bonus points, if you wanted to create a script, there's an application called Ent, command line tool, and it will quantify entropy. So you can even then look at the average entropy of subdomains. Right?

Faan Rossouw:

So DNS sandwich, this is where things start getting a little bit funkier. So we just said queue name for agent to service, R data for server to agent. Right? But DNS actually has a lot of different fields. And now it doesn't mean you can use every single field for data transfer.

Faan Rossouw:

Some fields, it has to have specific values. And if you put random encoded data in it, they're gonna break. But some fields are ignored, and some inherently carry random data. That's expected, and an attacker can leverage this fact. So DNSSMage defines two fields that are specifically being ignored.

Faan Rossouw:

I first learned about this in this excellent article by Spencer Walden published in 2021, so you can go read more about it there. But, essentially, to understand what it is and how it works, we have to kinda zoom in and look at the DNS packet a little bit closer. So if we look at the top section oh, yeah. So for request or query, you typically have a header and a question section. And then the response section, it adds the answer section at the bottom.

Faan Rossouw:

There are exceptions to that. We're gonna cover that in EDNS zero, but that's the basic archetype, the basic makeup of a packet. Now if we zoom into header and these are the different fields, let's just focus on that one field that says z, and this is the z value of the z field. Once again, a placeholder has no use. Three bits that they decided in the RFC one zero three five will be used in the future.

Faan Rossouw:

It's in it's the future now, but they're still not really using it except with DNSSEC. Okay? But according to the RFC, this value has to always be zero. And I also wanna say three bits, so zero to seven. Not a lot of capacity, obviously, something.

Faan Rossouw:

And most middle boxes will ignore this. And I'm saying test because I've tested this. I've used bitwise operations, manipulated the value, sent it out. It always gets resolved. So you can change the value.

Faan Rossouw:

Now let's zoom out again a bit. And then we'll look at the question section this time. And now we see queue name. That's the domain name. Type, record type, a, quad a, text, and QClass here in the bottom.

Faan Rossouw:

Well, what is that? Well, QClass is kind of weird. It's 16 bits, so much more capacity, a lot of values. And it just always is one. It doesn't have to be one, but it always is one, and one means Internet.

Faan Rossouw:

And once again, you can change this value. And because it always is one and is always expected to be one, if you change the value, it doesn't matter. It'll still be resolved. So then DNS Sandwich by Spencer Walden, he basically said, well, you have this four bits and you have these 16 bits, and it's not a lot of data, but you can manipulate it because middle boxes ignore it and a lot of tools won't even look at it, security tools. So I wanna point out for me, this is such low bandwidth that, sure, you can transfer small amounts of data.

Faan Rossouw:

But what this is really useful for is semantic signaling, meaning imbuing certain values with predetermined, you know, meaning. Right? So in that sense, it it could be useful, like triggering a triggering a certain action from the server to the agent, etcetera. So how do we detect DNS sandwich? So like I said, z should always be zero.

Faan Rossouw:

Q class should always be one. Sometimes it is three four, two five four, two five five, but that is so rare that honestly, for me, even if that happens, I'm so just interested to understand why that happened that I'd wanna know about that too. So the bad news here is Zeke, your standard logs are not gonna point this out. If you go in dns.log, you won't see anything about this. The good news is the Zeke default parser does expose these values.

Faan Rossouw:

And what that means is you can create a custom Zeke script to alert on this. So very simple. If it's the z value is not zero, alert. It'll look something like that. And if Q class is not one, alert.

Faan Rossouw:

And it'll look something like that. Right? So easy to detect, but you have to take that extra step in implementing a Zeke script to do so. Now let's talk about ID field misuse. So, again, let's look at our blue packet.

Faan Rossouw:

Let's zoom into the top. Let's look at the parts. We just saw z. Now let's look at the top one, query ID, 16 bits. So what is it?

Faan Rossouw:

Well, it's every time the client or the agent is going to send a query, it's going to randomly generate this value. Why? It's just to keep track when it gets a response back to basically match the two, right, to resolve the two internally, to understand that's the response for this query. So this is actually only, if you think about it, useful for agent to server communication because the server has to echo the same one back. It's very limited, obviously.

Faan Rossouw:

It's definitely not bulk, but it is something. Right? So let's try to understand what does it look like normally, because I said it's random data. And then what does it look like when it's malicious? How can we detect it?

Faan Rossouw:

Well, it really depends. But first, let's to see this, let's just simulate a hunt. Okay? So I'm going to run the following command just to see resolutions, internal host, and the domain. And now what immediately catches my eye is this top one.

Faan Rossouw:

Right? For whatever reason, I don't know the domain. I don't like it. I did a reputation check. What's going on here?

Faan Rossouw:

And I go through, and I don't see encoded subdomains. I don't see any z. The z field looks normal. The Q class looks normal. Now as a threat, I hypothesize.

Faan Rossouw:

Right? My hypothesis is, well, what if ID field abuse is going on here? Let's have a look. So I'm going to run the following commands to get that value. And on the left, we see the value.

Faan Rossouw:

And just be aware that ZQL log it as decimal and not hex. But with some simple command line wrangling, we can immediately just convert that into hex here and into ASCII here. And maybe you can see pawned. So that's obviously not random looking at all. Right?

Faan Rossouw:

We can see there's data being transferred. And so if we expect ideophilic abuse, we can decode it and expect it, and we can detect it. Right? Yay. Problem solved.

Faan Rossouw:

Except that not really because we were very lucky here. Why were we lucky? The adversary didn't encrypt the data before encoding it. So either not a very good adversary or just very forgetful. Right?

Faan Rossouw:

So if they didn't, if they did encrypt it, which we would probably inspect any decent adversary to do, what would it look like then? Well, this exact same command would produce this. And on the right, we see nonprintable bytes. So what does that mean? Are they encrypted?

Faan Rossouw:

Or are they just random like we expect them to be? And the truth is there's no way for us to tell whether they're either of those two. So in this case now, it means if an adversary using this field ID for XFO and is encrypting prior to encoding, we actually cannot detect it directly. Okay? There's always hope.

Faan Rossouw:

So we can't detect it directly. I just showed you why, but we can use one among many of behavioral detections. Now I wanna tell you that the behavioral detections I'm gonna show you here now are applicable to almost everything we're talking about. This just that was just a natural way to segue it into this discussion here. But this isn't about IV field abuse now.

Faan Rossouw:

These are behavioral detections you can use everywhere. Okay? So, again, I've spoken about this a few times, but a big one always is okay. Is is it connecting directly to an IP that's suspicious? But if it isn't, if it's using a domain, we probably expect them to do that.

Faan Rossouw:

Do a reputation check. Is it known? Is it a known good? Is it a known bad? How old is it?

Faan Rossouw:

Right? The younger, the more suspicious. The newer, the more suspicious. It's a very young domain. The query frequency.

Faan Rossouw:

Right? If they are gonna be using one of these very low capacity fields because they're like, I don't wanna use encoded subdomains. That's too obvious. But they're still using it to transfer a lot of data. It's gonna be extremely noisy.

Faan Rossouw:

Right? And then timing patterns. DNS will still beacon. Right? So you can use something like RITA or AChunter, and you can still see the pattern.

Faan Rossouw:

The non stochastic communication patterns emerge over time. And then the other thing is direct resolver bypass. And so remember at the beginning I said there's a caching issue. Right? And the caching issue basically is I have to make sure that my query reaches the authoritative name server.

Faan Rossouw:

Right? One way to do that is by using a brand new encoded subdomain every time because then it's a brand new domain every time, and so a cache response won't come. But if you decide to not do that, then either you have to communicate very slow, right, longer than the TTL. That can be augmented in a way by actually just kinda rotating through, let's say, 30 or 50 different subdomains that are legit sounding, www.maildot. Right?

Faan Rossouw:

That's another way to do it. Or the third way is just make a direct connection outbound to the DNS server. Now it's also one of those things that totally shouldn't happen, but not everyone looks for this. So you have to see, especially if you have a policy of local resolution only, then you need to understand when this is not happening. And then a big one is no corresponding traffic.

Faan Rossouw:

Let's just zoom out here, guys. And remember, the entire point of asking for a domain to be resolved, right, is to be able to make a connection to that machine. Right? So if you have a domain that's being queried and you have thousands or tens of thousands of different responses but no direct connection ever to that destination, they're like, you never actually fulfilled the whole point of DNS. Right?

Faan Rossouw:

Now they can make dummy connections, and good malware once again will do that, but not all of them will. So you can use DNS. Log and you can use con. Log in Zeke, and you can very easily tell whether or not that's taking place. EDNS0, what is EDNS0?

Faan Rossouw:

It's the extension mechanism for DNS. So in, again, 1987, they designed the protocol. They couldn't have foreseen everything that they wanted eventually to use DNS for. And so around 9099, they had new functionality that was required. The first thing is they wanted to make bigger packets.

Faan Rossouw:

Later, DNS came along too. But how these things work, guys, you'll see this a lot, like, with the design of QUIC too. You can go in '99 like, oh, DNS, we designed it wrong. Hey, everyone. Stop using DNS tomorrow, and here's the new DNS two point zero.

Faan Rossouw:

Use this. There's too much inertia. Right? All the infrastructure is built around that. So what you gotta do is you gotta find a clever hack to use what you have to introduce new potential functionality.

Faan Rossouw:

And so they created a new called the pseudo op record in the additional section, and that basically created this extensible framework that made the packet itself more pliable and able to be used for other use cases. So remember when I said these are the only three section where I kind of lied. You sometimes also have the authority section for NS. And then you have this additional section that has a few different uses. But in this case, specifically, we are interested in adding there an opt pseudo record, which enables EDNS zero.

Faan Rossouw:

Or EDNS zero enabled produces an opt pseudo record in additional. Right? So why do adversaries love it? Well, in this case now, the client's gonna say it's gonna advertise, hey. I can handle 4,096 bytes considerably more data.

Faan Rossouw:

And then the server can send bigger packets back, so there's much more capacity. So it gives it gives a whole bunch of fields, not just three, but three of these fields can be abused in much the same way as we've seen other fields. And again, it's potentially popular or it is popular because it's one of those things that are very often ignored. So on the top left, that's the pseudo op record that goes into additional, and we see the client subnet, padding, and private. So on the right, on the bottom, I'm just showing you what it's used for in the capacity, and we can see client subnet, there's an IP.

Faan Rossouw:

Padding should just all be zeros, and private is experimental. It's another placeholder there for the future. So the good news is EDNS is common, so you can't block it, but the misuse of these three fields are very easy to spot. Why are they oh, sorry. Why are they easy to spot?

Faan Rossouw:

Because the client subnet should never be used from an internal workstation. It should be used by a CDN and a resolver. Right? Padding, often not used. And if it is used, should all be zeros.

Faan Rossouw:

And private codes should never be used at all. So if you have EDNS zero packets flowing out of an enterprise network and it has the client subnet field at all, it has private codes at all, or it has padding any other value than zero, that is incredibly suspicious. Super high fidelity. The bad news, unfortunately, is that Zeke's custom parser does not expose these values. That is not a train smash.

Faan Rossouw:

You can still get it. You need to learn how to use something called SPICE, which allows you to write your own custom protocol parser in Zeke. So if you do that, then you can easily detect on all these values. And finally, we're gonna talk about encrypted DNS. So encrypted DNS, we have three types, DNS over ToS, DNS over HTTPS, and DNS over QUIC.

Faan Rossouw:

Now it kind of evolved the first one because they wanted to hide the domains from ISPs. The problem of that was that it was it's very easy to block because it's predictable, unusual port, and you can see its DOT on the application layer. And then some smart people said, well, why don't we just take the DNS packet, encrypt it, put it in layer seven of a HTTPS package, and it'll just LARP as if it is HTTPS. Nobody will even know this is DNS at all, and so DOH was born. DOQ, I won't get into it, but the whole quick mission was to shave off the handshake, which is like fifty milliseconds.

Faan Rossouw:

So it's it's super cool. I love the design, but it doesn't really solve a problem. And in fact, in this malicious use case, we really have DOT and DOQ, which are both very easy to block because they stand out. You can tell it's DOT and DOQ. But DOH is much harder because it blends in.

Faan Rossouw:

You just think it's HTTPS. So DOT and DOQ should be blocked. In any case, they skip local resolvers. So block them and any application that will complain will just fall back on plain text DNS. In any case, they don't want you to switch to a different product.

Faan Rossouw:

Right? But you can block DOH. It looks just like HTTPS. But then from the adversary's point of view, if it appears like HTTPS, then why not just use c two over HTTPS? Why use HTTPS but then constrain yourself to DNS packets?

Faan Rossouw:

Right? Is there any even point of it at all? Is there any benefits? And the honest answer is there kind of is a benefit. And it's this thing called resolver as proxy.

Faan Rossouw:

And resolver as proxy basically means that, remember, they're gonna skip the local DNS resolver. They're gonna use a legitimate resolver. And only there will the actual domain of the attacker be visible. So once it exits your network, right? So resolver as proxy basically hides the malicious domain the whole time.

Faan Rossouw:

So how can we solve it? Again, we can't block HTTPS, but we can block those destinations, right? And the good news is there are only a finite amount of DOH resolvers. And for example, the COL project always keeps an up to date list of them. Zach, I got about two minutes left for that.

Faan Rossouw:

Yeah. So any internal DNS should block all of them. Okay. So the main takeaway here, guys, is that we now saw hopefully, I I I I I drilled the point home that there is many different ways that we can abuse DNS beyond just encoded subdomain XFO. And as we saw, they're almost always easy to detect.

Faan Rossouw:

But the point is you have to look for them. Right? And the specifics differed. But if you use Zeke and block lists, you'll stop about 80% of them. If you add custom Zeke scripts to the mix, you're gonna stop about 95% of them.

Faan Rossouw:

And then if you add spicy custom protocol parsers, 99 to a 100% of them. Right? So the the specifics differ. The solution is almost always the same. And the final thing I want you to keep in mind is adversaries operate under a law that there's an inverse relationship between stealth and operational efficiency.

Faan Rossouw:

Right? The more stealth, the less efficiency. The more efficiency, the more data transferred, the less stealth. Right? They're constrained by that.

Faan Rossouw:

So to just kinda wrap things up, I just wanna tell you guys very quickly about my workshop. So it's gonna be next Friday, and we're gonna build a reflective shellcode loader c two, or it's a c two framework. We're gonna I'm gonna give it to you. We're gonna learn what it is, how it works, and then we're gonna build the entire command handling system. And like the piece de resistance is gonna be a reflective shellcode loader, so we're gonna pop a calc EXE live.

Faan Rossouw:

It's gonna be super exciting. All my courses, I always place my emphasis not on the specifics and the source code and the exact syntax. It's on the the design thinking, the higher order. Design patterns and architectures. That's what I wanna share with you guys.

Faan Rossouw:

And so some of you might you know, there is obviously this major current right now about agentic development with the latest Claude going, you know, gangbusters on social media. I myself am sipping from that Kool Aid now. I wanna tell you guys, but you might think, well, is there even any point learning this? Because agents will do it. And I would, honest to god, say there's even more points in learning design and pattern and architecture because you can't just prod an agent with a stick and say, okay.

Faan Rossouw:

Do do do something cool now. You have to understand how to speak and communicate to it. So the things I put emphasis on is the perfect things to learn to then go and use with agentic developments. It's a sliding scale, $25 minimum. Please join.

Faan Rossouw:

And that's it, guys. Just a reminder, my websites, my projects, and thank you.

Zach Hill:

Awesome, man. Thank you so much for being here, sharing your knowledge with us as always. You are fantastic. It's always a pleasure, man. Thanks, brother.

Zach Hill:

I always say great things about you. So, again, thank you. And thank you to all of the students who who joined us today. If you have questions for Fawn, you can go ahead and put them into the chat, and we'll try to queue those up for you. But I am going to put the link for, the CTF today.

Zach Hill:

I can grab it and thought I had it, but I had a different link. I'll put the link for the CTF in the slide resources channel on Discord, and I'll link to that channel as well. From there, you'll be able to go ahead and head over to the Monday form, and they'll give you access to all questions and all the material that you'll need. Next Monday, we'll be choosing the winners for that. We'll be giving away a full, on demand access to the anti siphon training platform.

Zach Hill:

One of the other winners will also be able to pick any class of their choice from anti siphon training. And Fawn, Roswell UK is asking how common is this type of abuse?

Faan Rossouw:

Yeah. I mean, it's hard for me to give you an exact answer unless I had a lot of corporate data and did some analysis, and obviously, I don't. But what I would say is it's definitely not common, but it does exist. Right? So it's the difference between you being okay with, like, 98% coverage or very simply, like I showed, block list, Zeke, scripting, parsing, being able to do the full coverage.

Faan Rossouw:

You'll keep out most attackers. But once you really start heading towards sophisticated attackers, then these are the kind of things that you definitely want to be much more aware of.

Zach Hill:

The CTF channel in Discord was removed. We're just gonna be and putting it in the slide resources. But I do have so you guys I I have a go back for that, with our team to talk about that. So we are gonna try to do something a little bit different so that we can also include, like, the answers and things like that. So we will be working out some kinks and stuff with the CTF going forward.

Zach Hill:

So just keep that in mind. Thank you, Fanno, for the the answer there. And got a question here from Bethea on Zoom. They're participating in a three hour Sigma Splunk workshop today. It's focused on other areas than DNS.

Zach Hill:

But what would you recommend they keep in mind as they move through the workshop as it relates to DNS? Are there any follow ups to tie the anti chaos and the workshop together?

Faan Rossouw:

I don't know

Zach Hill:

what that

Faan Rossouw:

Well, I don't know necessarily exactly what you guys are gonna cover. Right? But Sigma is kind of every time I showed the detection, I showed a way to run a Z command to query existing Z logs to show whether something exists. Right? But the disconnect between what I showed and the reality is the reality you wanna have a sim and you wanna have it alerted.

Faan Rossouw:

Right? So that gap is can you know, Sigma has a role there. You can also just have Zeke produce something called notice.log. That's the default name, but you can call that anything you want. And you can basically tell your sim, how do I alert on please alert me every single time anything comes up in notice.log.

Faan Rossouw:

So think of way you could think of ways and what I showed here today. Once you have implemented the detection in Zeke, how to go from Zeke to you getting an alert in your SIM. Because the ultimate goal is for you not to run commands on outdated data, but sits in, you know, the the mythical single pane of glass and get alerts right there. Right?

Zach Hill:

Thank you, sir. And there's a question from Linux Geek. Any suggestions for detecting DGA?

Faan Rossouw:

I mean, I would say mostly everything in the realm of what I said related to behavioral. Right? So still frequency domain reputation for the direct connections. Was there ever was the resolver bypassed? And then also beaconing.

Faan Rossouw:

You know, guys, I I know I didn't place too much emphasis here today on Rita and AC Antlers because they really focus on the encoded subdomain part, and that's kinda like like I said, it's a solved problem. You need to look for it, though, and they look for it very well. But my point today you know, whenever I prepare a talk, I look at similar talks in the field on YouTube, and I don't ever wanna just share something into the collective that somebody else has spoken about probably better than me. Right? So nobody's really shared this information as best to my knowledge on YouTube.

Faan Rossouw:

So that's kinda why I wanted to get that out there. But, yes, for DJs, what I would say is focus more on the behavioral. And and again, like I said there, that is true for all of them. Right? Behavioral is almost more resilient than any specifics.

Faan Rossouw:

Specifics are always inherently more brittle. And now I'm using language from the Pyramid of Pain. Right? Remember David Jebianco?

Zach Hill:

Thank you, man. Alright. Yeah. Anybody has any other questions, you can throw them into the chat for us.

Faan Rossouw:

Maybe one thing is okay if I just say something real quick?

Zach Hill:

Yeah. Absolutely, man. Go ahead. Yeah.

Faan Rossouw:

So I I was just rushing in the end, guys, because, you know, I was aware of the time and that I was pushing it a bit. But I do wanna say that there might seem like there's this little bit of a disconnect between, hey, Fawn. You just spoke about threat hunting, but now you're teaching a workshop on offensive security tooling. Like, when what you know, that seems like a little bit of a disconnect. But honestly so my primary, like, ego security ego identification is as a threat hunter.

Faan Rossouw:

That's the label I'll put on myself. But I spend a lot of time developing new attack vectors because I see them as two sides of the same coin. And and I know that this isn't a unique idea. This is pretty banal at this point, but I just wanna tell every one of you that if you are if you identify with being a defender, learn to do offense and vice versa. Right?

Faan Rossouw:

So I would say a 100% that if you're not interested in offensive custom offensive security tooling at all, but you're like, man, I wanna threat hunt, and I don't wanna be limited by the tools that I can download from GitHub to simulate threats, I wanna be able to create my own threats, then the workshop is awesome for you because that's gonna open up a whole new way of thinking. And again, guys, you know, with the stuff going now on in the agentic space, these two, they've reached now power levels of being incredibly empowering. Once you have the ideas and agency, they are going to compress the time and effort required to produce things so you can learn much faster. Right? So that's all I wanted to say.

Faan Rossouw:

I just wanted to emphasize that, yes, it's a object tooling, but if you are into threat hunting like I am, again, that's kind of the the other side of the point, and they reinforce one another.

Zach Hill:

Thank you, sir. Sorry. Thanks for Typing. I can't I can't do the typing and talking thing at the same time. It's so difficult.

Zach Hill:

For everybody who's asking about the slides, the the link for the slides is available on Zoom under resources and on Discord on the slide resources channel.

Faan Rossouw:

And almost all the not almost all the things, but a whole bunch of things that I showed today that's unusual, the the text record abuse, the z fields, the not the Ivy field, but the Q class. I have tools for free. So if you go to my website and you go to projects, there's an overview of all my GitHub repos. All those tools are there, written in Golang, extensive documentation, user documentation. Go run your own some best way to learn, guys, literally.

Faan Rossouw:

Go set up a little lab environment. I also have a whole video on that on the c two webcast, episode four. Go check it out. Set up your own little thing. Dial up my tools.

Faan Rossouw:

Create your own tools. That's the fun, guys. Learning textbooks and just doing try hack me rooms the whole time, but it gets old. I mean I mean, it is cool too. Alright.

Faan Rossouw:

I also did a lot there. Don't wanna badmouth it. But things really become super exciting and, like, pulls you in once you start doing it yourself. So I really wanna encourage any of you that feel cold. If you feel like you're in a bit of a rut, you wanna level up, you feel like you're doing stuff the whole time, start doing it yourself.

Faan Rossouw:

Literally, the best way to learn is by doing it yourself. And, you know, we are so we've literally today never been so empowered with resources and the ability to use agentic tools to just figure shit out yourself, dude. Like, there is nothing stopping you anymore from doing something. Go and do it, please. It's it's it's awesome.

Zach Hill:

Thank you, sir. If you could include a link to your website in the Discord chat also.

Faan Rossouw:

Sure. Herman, would you mind dropping it there, please? I see Herman's around. And

Zach Hill:

Thank you, sir. Yeah. Thank you. And then could you restrict outbound DNS access to only a forwarder as protection against the c two?

Faan Rossouw:

Well, here's the thing. Sorry. To you wanna restrict it to only an outbound?

Zach Hill:

So the question is, could you restrict outbound DNS access to only a forwarder?

Faan Rossouw:

Because c two over DNS is mostly gonna use local DNS resolver. I actually didn't mention this, but actually one of the great benefits for the attacker about DNS I I I spent a lot of time today talking about all the limitations of DNS, and that might lead you to think like, why do they even use DNS? Just use straight HTTPS. The big, big value of DNS, right, is that most corporate networks will use a local DNS resolver, and it will throw its little mail in the same mail slot and will go to that same sorting station. What does that mean?

Faan Rossouw:

It means the malware, the the the the process, is never communicating directly outbound, nine like, 90% of the time. I I spoke about, you know, the exceptions there. And there is almost always, as a general rule, much more scrutiny to traffic that goes outbound, north south, than east west. Okay? So that won't stop them because they can just use the local DNS resolver, and they usually do.

Faan Rossouw:

The big benefit for for attackers, again, is they'll just leverage the DNS system that's already in place. And, you know, you can't block DNS. You've gotta use DNS. Right? So so that's one of the things.

Faan Rossouw:

Yeah.

Zach Hill:

Awesome. Here's a a really good question from anonymous attendee. It's a little bit longer, so I can paste this into the the chat also if you'd like. But they say, in many organizations, threat hunters are still viewed as glorified SOC analysts, which often results in limited investment and a lack of attention to our threat hunting reports. Too often, our findings and recommendations are only taken seriously after an incident occurs.

Zach Hill:

What strategies can help us demonstrate the value of threat hunting more effectively so that the business leaders and upper management prioritize our work and act on our reports proactively? That's a little bit of a longer one. I'll put it in the No.

Faan Rossouw:

It's I I love this question. I think a lot about it because to me, in principle, the concept and idea of threat hunting is awesome. But we can't be an island. Right? And at the end of the day, guys, a company's goal and the executives at the top, their goal isn't to stop threats.

Faan Rossouw:

Their goal is ROI, literally. Right? So as long as you're producing things that kind of feeds back into that, you are gonna have support and buy in. You can't just say like, oh my god. This is such interesting malware.

Faan Rossouw:

Look at the source code. They don't hear that. What they hear is, how does this serve my goals? So at the end of the day, I think I I don't know. The comment sounds like it came from somebody that is actually a threat hunter, which I love.

Faan Rossouw:

I I do know that this is you know, I don't work as the threat owner for company. I'm a threat hunting researcher. Right? So I get a lot of support, fortunately, to do what I do. But learning and reading and speaking about it, I would say, I don't know if you are you know, it depends on your company's maturity as well.

Faan Rossouw:

But I do definitely think that a good place to start at least is something like David Bianco's framework to more formalize what it is and what you're doing and what is the value you're bringing. Right? Because and and to, like, systematize it better. Right? There's this weird kind of paradox because on one hand, the power of the threat hunter is kinda like their intuition.

Faan Rossouw:

Right? Which is like something you can you wanna give them the freedom to roam. You don't wanna box them in and just kinda like operate as a SOC analyst. And but at the same time, if there's too much of that, then it's unclear like you communicated. What are you guys actually doing and what's the value here?

Faan Rossouw:

Right? You you guys are costing a lot of money. So I think two two things would do as best as you can ensure you can systematize and formalize the product, the process measure. Right? And then obviously, just sorry.

Faan Rossouw:

Super cliche answer, but, you know, this is the truth. It's just clear communication. You you have to make them understand what you're doing and how things work. Right? You can't just like, leave me alone.

Faan Rossouw:

Let me go do my cool hacker stuff, boss. Like, they have to really be clear on the value. And and I think, again, the cool thing about Peak is, you know, David is a threat hunter, but he's not necessarily like a dude that's designing tools and stuff. He's working on this stuff. Right?

Faan Rossouw:

The big picture stuff. It's like how to make threat hunting a thing. Right? And so a lot of that is framed and designed in a way where it's not just for security people. It is framed and designed in a way where you can start bridging the gap between you as the threat hunter and the heads of the organization, right, to support what you do, to understand what you're doing.

Faan Rossouw:

And I think, to me personally, a huge leap in that was just redefining what the goal of threat hunting is and defining the five metrics. You know? Like, when I because for me too, for the longest time, I just thought it's finding threats. But the thing is you're never gonna be as good as a machine at finding threats. Then 99% of the times or 95% of the times, you're not gonna find a threat.

Faan Rossouw:

And so it seems like, man, I'm paying this dude a salary, and, like, once a year, he found a threat versus I'm paying this dude a salary, and my system is getting so much better that it's finding more threats and more threats. Something that wasn't included in this metric that he says he believes should be included as well is what if in the future, your sock, right, has an alert and they find a threat, but that was an alert that came about from you being in the environment and recognizing that. Right? That is also something that can clearly show the effect you had even if you didn't catch a threat per se. I'm gonna stop myself from talking now because I could talk about this for a long time because I love this kind of stuff.

Faan Rossouw:

Right? This is is it's a very interesting thing to think about when you put humans in the equation as well.

Zach Hill:

No, dude. I love it. You know, you could I mean, I can tell that you're very passionate about what you're doing. And that that makes me very excited for I mean, not just you, but, like, all of the people that you get to speak to and all the students that you you'll you'll have an impact on. That excitement just bleeds through, man.

Zach Hill:

Like, it like it gets it it gets me so much in the feels. Awesome. I I I wanna say thank you on behalf of everybody joining us for honestly being here and sharing all of your knowledge, dude. Because you you are

Faan Rossouw:

Absolutely, man.

Zach Hill:

You you are fantastic.

Faan Rossouw:

Love it, dude. I love it. Absolutely. Yeah. Huge pleasure.

Zach Hill:

Yeah. We'll grab one more question.

Faan Rossouw:

Yeah. Let's do it.

Zach Hill:

For the slides, I apologize if you're on Zoom. I forgot to click the enable button for the slides, so you should be able to see them now and download them. My apologies for that. But if you guys loved what you saw today from Fon, you wanna learn more with him, please consider checking out his workshop. It's gonna be next week.

Zach Hill:

It is live, but it is also going to be recorded. So if you're not able to make it, to the live training, please consider just, you know, signing up for it anyway. You can, you know, get access to that recording, like I said. And then if you have questions for Fon, say you watch that that workshop, you know, a week later, and you might have questions based on that material. Can students still reach out to you, Fon?

Zach Hill:

Can they still ask you questions about the your workshop?

Faan Rossouw:

Absolutely, dude. Yeah. So I have my email is on my personal website, so you can find it there. Like I said, I'm on X and LinkedIn. I it it seems like I'm not that active there because I said because I just started, but I respond to messages there.

Faan Rossouw:

And I also have a Discord channel server. I do have intention of being more active there. To be honest, I am not that active there, but that's another option. And I I I genuinely honestly love when people reach out and ask things and to be helpful. And also, like, I I learn that way too, man.

Faan Rossouw:

You know, when you yeah. I won't give an example, but very, very often, there's things that are obvious that I overlook. And then when people ask me questions, it's incredibly enriching for me as a teacher. And then, hopefully, I can provide some value to the person who asked the question as well. You know?

Zach Hill:

What what was your example? I I mean, I I'm I I apologize, I'm only asking because I feel sometimes it's important. So I understand, like, where where you're coming from and all

Faan Rossouw:

On LinkedIn, like I said, I'm I'm kind of sipped on this agentic Kuwait now. I I've been a fan since LMs and stuff since the beginning of users. To me, it kinda went the last month from like, it's very cool to holy crap. This stuff is kind of insane because I've just been using Claude Code in Obsidian a lot in kind of the way I work. So I discovered that Claude actually keeps a log of all your conversations, and then I decided I wanna build this entire memory system with DuckDB and LaunchDB and an interface with SvelteKits and LayerCake on top of it so that I can get interesting insights from my data.

Faan Rossouw:

And so I've kind of posted, this is my project and this is my idea. And then it's kind of almost embarrassing because it's one of those things that's so obvious. And the dude just said, like, this is cool, dude, but, you know, this is obviously also, like, a huge security risk. Right? And, obviously, all your conversations with Claude is there look.

Faan Rossouw:

It's on your local machine. And from my point of view is, yes, you need to secure your local machine. Right? Right? But at the same time, I'm a security person.

Faan Rossouw:

I I I I sketched out a eight part road map of this cool project, and honestly, Fon, not one consideration was like, how can you make this system more secure? So I was like, thanks, dude. I will definitely add now a section in that. So so it was that. You know?

Faan Rossouw:

It was just a dude asking a a, like, simple question and it led to me being like, oh, kinda like blushing a little bit. Like, yeah. Totally right, dude. Let's do it.

Zach Hill:

So you put this out on LinkedIn, you said.

Faan Rossouw:

Yeah. I mostly I mean, I put stuff out on LinkedIn and and on X. Right now, I'm just I'm I'm building I'm working to towards building a whole kind of agentic threat hunting system. And so now I'm kind of assembling all the different core components. And sometimes it's like, I'm not working on that directly, but I'm it's almost like a kata.

Faan Rossouw:

Right? You're practicing some of the moves that you need to strengthen to do that. And for me, you know, what I, know, whatever your idea about vibe coding and all that is and, like and I don't identify as a vibe coder at all, but what that community is actually extremely positive. So if you go on, like, x and stuff like that, they're all about creating, expressing, no gatekeeping, seizing the future, seizing this moment. And a big part of that community to do is just, like, experiment, try new things, document it, and share it with everyone.

Faan Rossouw:

And I love that kind of shit, dude. So a big thing of what I'm spending time on now is kinda my own ideas and my own experiments that I'm creating, documenting, sharing it. So on farnross.com, I'm publishing now, at the moment, almost every day, some new article and write up of things that I'm doing. And then I'm releasing I I announced it on LinkedIn and on X, both. Yeah.

Zach Hill:

So I I asked that question for an entirely different purpose, honestly. Yeah. So one of the things we do a weekly AMA in this, you know, for everybody out there on Discord. Every single Tuesday, it's 11AM Central Standard Time, but everybody's welcome. And these AMAs, we have everybody from people who've, you know, never worked in security to been working in the security and IT for for many, many, many years.

Zach Hill:

But one of the things that we talk about all the time is how important it is to be putting yourself out there, sharing your knowledge, and, yeah, all you know, just sharing some of the things that you're working on. Because a lot of times or especially nowadays, you know, getting your next job is often through networking. And one of those things with networking is putting yourself out there. And what Fawn did, I think is like a perfect example of like him putting himself out there and having the community react from that. Where he was then able to learn even more about whatever project he was working on there just because he put himself out there and he got a response.

Zach Hill:

Right? He got he got somebody else to engage with that from the community. And that's really all that it took from you is just like, hey, I'm thinking about this project. Here's kind of what I'm working on. Here's my thoughts about it.

Zach Hill:

You put a little something together, shared that. It hit it hit somebody who was like, oh, I know something about this. And they they they messaged you. They left a comment. Have you thought about this?

Zach Hill:

And you didn't. And that gave you an opportunity to learn more. But you, one, created like a new connection with somebody out there on on the Internet there. You you net networked essentially. But then you you also created a a learning experience from that.

Zach Hill:

And that's a lot of what the cyber security community as a whole is. It's coming together. It's sharing your knowledge and just being a good person in the community. And I just I I wanted to highlight that aspect of it because I just want to encourage everybody Yeah. To put yourselves out there, share your knowledge, share the things that you're working on, ask for help, ask for ideas.

Zach Hill:

These are going to be the things that make a dramatic difference in your entire career journey. And you'll learn a lot about that from Jason Blanchard and his job hunt like a hacker workshop next week. That was not supposed to be a plug for his workshop, but it's a great opportunity to lean into it. Yeah. Right?

Zach Hill:

Put a link to that. But, you know, thank you again for for doing that. And yeah. Thank you. Is there anything you wanna add about that?

Zach Hill:

Because I think it's really important that that people do, you know.

Faan Rossouw:

Yeah. I mean, I don't wanna make this too long, but I actually have a big thing to add without going into too much of a backstory of my life and and and everything, guys. But that whole putting your thing self out there is literally how I got my job. Right? I got my job with active countermeasures, not because I have a degree or I was well known or I didn't even prepare a CV.

Faan Rossouw:

I had decided that I wanted to be in the cybersecurity. I had just started teaching myself cybersecurity, just spending time alone. And then less than a year in, I watched it was kind of a confluence of two videos. It was a threat hunting video by Chad Tilbury, and then there was a video by Eric Capuana. Eric Capuana created this free little course on Lima Charlie, and I remember there was a talk with Gerald Auger, and in the end, he said, yeah.

Faan Rossouw:

He wants to encourage anyone. Even if you're a beginner, whatever, make a little course and share it with the community. And then I kinda took that and the thing that Chad Tilbury was talking, I was like, I wanna make a little course on this. And so I made a little course on it. And then like a few months later, two months later, I took Chris Brenton's advanced threat hunting course through anti siphon.

Faan Rossouw:

And dude, I remembered so well. I wanted to share it the whole time, but then a part of me was like, oh, no, That's silly. It's so like, you know, this isn't worth sharing with other people. Like, you know, the kind of inner critic and and judge, like, thinking you're not good enough. So I didn't.

Faan Rossouw:

It was a four day course, and I remember so well, I kinda decided I wasn't gonna do it. And then on day four, I woke up, and there was just like something that compelled me. It said, dude, absolutely no fucking choices. Sorry. Share it.

Faan Rossouw:

And I shared it. And Chris, he looked at it. He's like, dude, this is awesome. I'm definitely gonna share it. I'm gonna share it on LinkedIn and stuff like that.

Faan Rossouw:

That was it. A few months later, I get an email from Chris being like, dude, still think that course you shared was so awesome, and just the fact that you made something and shared it with everyone, how about do you wanna start doing, like, little jobs here at Active Countermeasures? There's a little job for you there. I was like, absolutely. Know, in my mind, I was still gonna wait and become good enough to apply for a job eventually.

Faan Rossouw:

That led to me getting more work more work there, now now I'm here, guys, teaching you guys. And and that happened, like, two years ago for me too. Right? So I there's a part of me that's sometimes reluctant to share share the story because it makes it see I don't wanna be insensitive to people that are genuinely struggling to find a job. I don't wanna sound like I'm saying, just pull yourself up by your bootstraps, Sunny, and do something.

Faan Rossouw:

I know reality is part luck and part luck you create. You cannot control luck, but you can create the luck you you can control the luck you create. Right? If Chris wasn't such an awesome dude, if he didn't see something in me or whatever, that would have never happened. But if I didn't share the course, if I didn't make the course, if I didn't take that initiative, it wouldn't have happened either.

Faan Rossouw:

So for me, in an era now where I hear it's really hard to get a job, I hear there are automated CV scanners, and you can't even get a a follow-up interview. Dude, I'm on LinkedIn. Every day, there's a dude that's, you know, has all the off sick certifications, people who have PhDs. It's like, how are you gonna stand out when there are people with all these things? Make stuff and put yourself out there.

Faan Rossouw:

Really. I honestly think now is the best time to do that as your differentiator if you're looking to migrate upwardly in your career or if you're looking for your first job too. Like I said, I don't can't tell you it's gonna work for you too. It worked for me. But I don't know.

Faan Rossouw:

I can only give advice based on what I know worked firsthand, and that's what worked for me. So yeah.

Zach Hill:

Awesome, man. No. Thank you so much for for sharing all your knowledge and and your experience as well with everybody. Webcast was fantastic today. Make sure you all check out Fon's workshop coming up next week.

Zach Hill:

And if you all wanna check out what we have coming up at Black Hills and Anti Syphon, you can go to powered by bhs.com and that'll show all of our events that we have scheduled. I hope to see you guys tomorrow at our Black Hills webcast or see you next week at our anti syphon webcast. Hope you all have a great week, and thank you again, Fawn, and thank you everybody for being here.

Faan Rossouw:

Thanks to you, Zach. Thanks for everything, brother. You're such a great host, and thanks for the entire team for all the job you guys do behind the scenes. Really appreciate it, and thanks to all the viewers. Hope you guys have a beautiful day.

Faan Rossouw:

Thank you.

Zach Hill:

Kill it with fire, Megan.