 So without much ado, because I hear this speaker is very popular here, so it is without much ado, my pleasure to introduce to you Tri-Catch HCF, who's going to give a talk on Packet Whisperer. Thank you everybody for being here. If you can't hear in the back because it's loud, let me know. I'll speak louder and we'll run forward with this. Welcome to Defcon. Welcome to one of my favorite villages. We're going to spend the next 50 minutes. We're going to have 10 minutes for Q&A and transition, covering some of my favorite absolutist, bestest things. I love packets. I love networks. I love cryptography, especially text-based steganography, and I love red team stuff. So what we're going to cover here is real world stuff I've done for a while. I'm not going to talk about theory and what could be done. Everything we're discussing actually is a real thing. We'll talk about what it is, why it is, and a little bit of background. First, a little bit about me. Hey, I got a promotion yesterday. Yay! So now I'm technical director of red team ops, and I can focus more on strategic stuff. Prior roles. The most critical thing in the prior roles is I used to mop fish juice out of a cod locker at a fish and chip shop. Never forget where you're from, and wherever you are right now, wherever your kids are right now, be where you're going to be. We'll talk a little bit about DNS. It's not going to be a DNS class. It's more of a very high level overview, but I like everybody to be on the same sheet of music, so you know where I'm coming from, where you're coming from. A little bit about text-based steganography. Then we're going to talk about traditional text-based steganography, traditional standard DNS exfiltration, and then we're going to talk about some really fantastic things you can do when you marry those together. Of course, a little tool called packet whisper. Let's cover a scenario first. Anybody out there in a sock? Anybody out there in DFIR world? At some point, alarms trigger. There's something on a system. You dig a little deeper. There's a little lateral movement. Now you've found out there was somebody in your network and they were gathering data onto a staging server in your network space, so you start tracking them down, right? Well, good news. You hit that staging server. It doesn't look like anything left. You checked everything. The packet captures. No USB was connected. Great. Let's go have a beer. We'll leave the paperwork to the other guys to talk to the CSO and a C-suite because we're done. No data was lost. Yes. Or did they merely lose the scent? Let's dive into a little bit about the DNS here, right? DNS. Really simple, right? It turns system names into IP addresses. And reverse, it turns IP addresses into system names. The great thing about DNS, of course, is it's open just about everywhere because it's hard to operate a network that's going to connect to other networks if you're not using some form of DNS in most scenarios. So it's always there. It's UDP. So of course, standard UDP joke applies. You may get it. You may not. IPv4 and IPv6 are options as well. The real issue about DNS, of course, is not just UDP. It's high latency. Not only you're not guaranteed to get an answer back, but you're not exactly going to do a million requests in a space of a few seconds. That sounds like a broken DNS server. So really simple flow, right? I need to get to google.com. So my system says, hey, does anybody know how I find google.com? And my system hasn't seen it before. And it goes out to the local server DNS server. And it says, hey, do you guys know how to get there? It keeps asking and asking up. The DNS servers ask each other until somebody knows what the heck this thing is or does not know. Either way, you get an IP address back or you don't. If your local server doesn't have it, your local server has a list of buddies. DNS resolution servers either iterative or recursive. It'll either go through a list. Hey, do you know? Hey, do you know? Hey, do you know? Or it'll pass that trust up. Hey, if you don't know it, you can go ask other people on my behalf. If you've been following some of the headlines recently, well, if you've been following certain security topics in the larger industry recently, there's been more and more concern about the fact that DNS traffic goes everywhere. We'll talk about why that's gaining traction. The DNS hierarchies are built on levels of trust. At some point, somebody has to speak up and say, I am the person that knows the home address of that server. Absolutely. It is 40.12.111.60. And you as the requesting system sits back and goes, all right, that sounds pretty good. And then you make a request out to that IP address. Your system doesn't actually transfer data from a name. It's using that IP address. So two types, iterative, iterative and recursive. What really matters to us though is the DNS queries. The labels don't allow a whole lot of data. And as we'll see in existing DNS exfiltration techniques, they try to shove a lot in there. It's not a protocol you're ever going to use to exfiltrate gigabytes and terabytes of data unless you're really, really, really, really patient. But there's plenty of other sensitive data you can fit into a few K, a few hundred K. That'll work just fine. And it's done all the time. It's all based on fully qualified domain names. So angry.bobcats.surprisegifts.com. That is going to be a separate DNS reply than happy.puppies.surprisegifts.com. And even though it's all surprise gifts, it'll generate its own query. The labels are case insensitive. That matters for our purposes as well. So mixed case all you want. DNS doesn't care. DNS won't notice. There are a couple of protocols that are multicast. This is also going to be interesting for some of our use cases. MDNS, multicast DNS. It's DNS compatible. It's essentially a peer to peer self-organizing network. Think of those device self-discovery systems like Bonjour, you just plug in, hey guys, I'm here. Is anybody else here? And it goes out to the entire subnetwork, your slash 24, right? 1 through 254.255 is your broadcast address. So MDNS, multicast DNS, and local link multicast name resolution on its port as well. These are both multicast. Interesting thing on this particular set of protocols is a request goes to everybody on the subnetwork. You don't have to have fancy equipment. We'll talk about promiscuous mode in a second. But if you ever run Wireshark, let's see. If you run Wireshark, just go ahead and monitor port 53 or just type DNS in the filter. And you're sitting on a network. You're at a coffee shop or wherever. On most networks, you're going to see a lot of various types of DNS requests coming from other systems that have nothing to do with you. And they aren't asking you specifically. They're asking everybody, hey, does anybody know what this thing is? That's why DNS cash poisoning is a thing. You want to get into, of course, that flow that says, I totally speak for surprise gifts.com. That's the speed run on DNS. Text based steganography. This stuff I've been fascinated with since I was a little kid. It was super fun and it still is. There are a lot of different categories. The taxonomy of steganography is much larger than is typically covered in any particular article or journal or blog. These days when we talk about steganography, we're talking about hiding data in images. That's cool. It's fun. It's not bad. It's kind of limiting, though. It's like, wow, I want to send a bunch of messages. All right. I'm going to ex fill this entire 100 gigabytes worth of data I got off of that giant cloud. Let's embed it all in images. It's clunky. It's kind of terrible. Honestly, for most use case purposes, if you're going to see image based steganography in the wild and you deify our sock folks, know this better than I do, it's usually going to be along the lines of some sort of trade craft, a little bit of information. Headline last week, there was an engineer who was arrested. It appears he was using image based steganography to embed trade secrets of his aeronautics employer to bring them to another country. Image based steganography does get used. Absolutely. But it's sort of that fringe case. It's not how the typical bad guys are moving data around. Another problem with image based steganography is it's a well known vector. Google for it. Anytime you Google for steganography, you're going to find something about image based steganography. Back up to all of these options here. You'll have to specifically put in text based steganography to bring up most of these topics. Text based in that vast world. Some really approachable examples if you haven't heard a bit or used it before. The classic one is prisoners or soldiers deployed. They're trying to communicate with their friends and family. The first letter of every sentence. Just pull it off and you'll have the message I'm trying to send you. Or the seventh letter of every other word. It's just really, it's a cipher on top of the actual text. Code words for communication are technically text based steganography. You're hiding meaning. You're hiding data. So somebody you know, the standard code phrase is right. I found the bagels to be delicious this morning. Well, the agreement was that memes get the hell out of town. This whole operation just collapsed. Technically counts as text based steganography. Some of the more amusing ones, fonts, spacing and themes, now that we're in the era over the last 20 or 30 years of changing the appearance of text. So you can actually use the number of spaces between words as an encoding scheme. Think about binary. It's just zero and one. All right. What if it's one space or two spaces? Some fonts you can't tell the difference. You could transmit war and peace purely as ASCII text and have one or two spaces representing the ones or zeros of the entire set of data you're trying to exfiltrate. That's pretty cool too, I think. Our particular friend, however, transforming data into text. I really like this because it lets you hide the data truly in plain sight and it gives you a whole lot of flexibility. You tailor the ciphers to either look like nothing unusual or exactly what somebody is expecting to be okay. So you've seen some, there was a, anytime you feel like a privilege escalation attack, right? And the classic example is somebody takes a photo of their airline boarding pass and just puts pilot on top and then you walk in and you say, look, it says I'm a pilot and this is big, sharpie and it's hilariously bad. You do the same thing when we're encoding data into text strings. We're going to make it exactly what they want to see. It's fantastic for bypassing data whitelisting controls. So if you have that sensitive network and you have a locked down enclave and it's totally okay because the only thing that's ever going to leave outbound from this network, we've got everything locked down. Only IP addresses. Nothing will ever go wrong. Transform your data into a list of IP addresses and ship it out. Odds are, they're just like anybody here who does application development or has worked in AppSec knows that when you look at most filters and fields, you're lucky if they're doing a strip and clip approach and the IP address is going to be limited to only numbers and four dots in the right sequence. There's going to be a way to bypass that. And you can use the ciphers as a form of social engineering against the analysts who are going to review it too. Clocaflot, Clocafi exfiltration tool set. I presented it a couple years ago. It was an old technique of mine and it was time to share and it turns any file type into a list of strings. Very simple to do. That was my entire goal. Our kids are able to use it and it can be quite amusing. So you can turn an entire zip file into a list of Pokemon or a list of popular websites or a list of dessert ingredients. And then when you've transferred that wherever it needed to go, you declocify it and you have the original file back. Anybody who ever looks at anything along the way, they saw exactly what you wanted to see. So you have a spreadsheet. Here's a Clocafi workflow. Again, this is just a speed run. Check out the GitHub repository. It's free. You just select Clocafi file. You select from any number of the ciphers in the middle there. Sorry, it's tiny text. You decide if you want to add noise in the front. So in this particular shot, we have turned a zip file, bounty.zip, into a list of lat-long coordinates of Pokemon. And it looks absolutely nothing like the zip file it originally was. That's perfect. Some of the ciphers, you want to turn it into a bunch of emoji? Turn it into a bunch of emoji. You want to turn it into password hashes? Turn it into password hashes. It's why would you want to do that? I got good stories. So there it is. The slides, everything is going to be posted next week. So don't worry about having to take too many notes. You can just pull it down probably the end of next week. This is already out there. I'm just saying the slide deck will be out there. Clocafi has been out there for a few years. All right, we're getting closer to the good stuff. Traditional DNS exfiltration. If you've been doing any, again, sock work, response work, DFIR, if you've been building controls to defend your systems, DNS tunneling and exfiltration are probably not strangers to you. Frankly, if you've ever tried to bypass the in-flight Wi-Fi, DNS tunneling has probably been your friend. Because again, DNS is open everywhere, right? Yes, including airplanes. Before you get past that lock screen, that locked landing page, that forced portal where they make you pay for your in-flight Wi-Fi, some of the airlines have locked it down. But for a very long time, all the DNS requests were just going through. And there were tools that would let you tunnel HTTP, HTTPS over DNS. Rockstar, power to the people. DNS-based data exfiltration. That's been more of a adversarial operation. I don't want to go all spooky APTO, it's all APTs. But whatever the attacker group is, whoever it is, there are plenty of tools out there. Go check GitHub, Google forum, that will help you do DNS-based data exfiltration. There is some, let me say, do I have it on the next one? Yeah, problems coming up. We'll get to some problems. Typically, how it works is the attacker has to own the server that is the name server, the DNS name server for that domain. So typically, I can't do DNS-based data exfiltration to www.google.com. I don't own it. But I own Joe's Super Secret Awesome Bigel Shop.com and wham. All the DNS requests that look up my domain are going to go to my designated name server because part of my web server presence in the world is designating who my authoritative name server is. That's a pretty high bar for a lot of attacks. We'll get to that Y in just a moment. So here is typical DNS-based exfiltration. Sorry, DNS-based exfiltration. You've got some data you want to get out the door. Bad admin, bad Bob, way to go Alice, good password. She probably has a password manager. You simply encode or encrypt that data you're trying to get out. And then you make the payload a subdomain to subdomain.myevilserver.com. I have told the world that the name server for myevilserver.com is a certain box over there. And my designated box is going to get all of these subdomain DNS requests, which have the encrypted encoded payload right there as a subdomain. Now we're still limited to about 255-ish bytes per DNS request. So that's still one DNS request for every 250-plus bytes. It's a niche scenario, but it's a very real world scenario. This is happening a lot. And again, here we go. The query, the fully qualified domain name, which is a subdomain and the domain, goes to evil name server. It goes ahead and strips off the subdomain and then it decrypts it. And voila, there's the exfiltrated data. Win for the bad guys. Here are some problems with that. Giant red flags. If you've got a good SIN system, you and your SOC analysts are going to be triggering on this type of activity all the time because the attacker has to control the infrastructure. A lot of organizations... Oh, we'll get to that in just a moment. One of the first things a good response team is going to look at, as they're doing a formal analysis of what's been happening, let me look at the traffic that came off of that server. Anything that looks like a weird subdomain name? Bam, dogs on bacon. Attribution. So I've got to control the server, right? Uh-oh. Well, who are the bad guys? I don't know. Let's find out who owns the server. When you have a lot of available data, attribution is actually fairly straightforward. It's not easy, but when you have enough available data, attribution is pretty solid. You have the visibility on when that domain was registered, how it interacted with the DNS server, the name server, or any other request coming into that name server. It requires you have access to a lot of infrastructure, of course. Who has access to all the infrastructure? Basically, everybody that's not us, that is a government or a large giant company that handles network infrastructure and the parties that are entrusted with processing that data. So again, it's out there. That trail of breadcrumbs lead back. There's only so much you can do with the, hey, I'm not in your political boundaries. You'll never get me. At some point, you don't want people to know it was you, even if they can't touch you legally. Resiliency. Take that server down. Uh-oh. That was a problem. I worked really hard to get into that organization. Now I have no way of getting the data out. This is going to look bad on my report. Sock blacklisting, an active attack, a detected attack, is going to cut me off short. Also, more and more organizations are implementing DNS whitelisting. You can't connect to a DNS server that they don't specifically say is okay. And odds are, if you're working on the blue team side, you're already doing that, or you have a roadmap to do that. If you're on the blue team side and you're not doing that, oh, for the love of God, look into DNS whitelisting. The stuff it's going to break will annoy your employees, but it won't interrupt their workflow, if that makes sense. Now for the good stuff. We got through all the background. Thanks, folks. Combining DNS queries and text-based steganography. So what have we got here? Oh, sorry. DNS queries look up system names, right? Clochify turns any list of data into any file into a list of strings we want. So if we decide to use clochify to transform our data into a list of common system names, and then generate DNS queries using that list, we're getting closer, we can transfer data to any system that's able to see the DNS broadcast messages, MDNS, LLNNR, or to any system or appliance that handles DNS query traffic along the DNS path, whether it's iterative or recursive. DNS queries go all over the world, especially when you start looking at the cloud. We can do this, transfer it without using any DNS query fields that usually make an analyst go, ah, this is bad. We don't need an attacker-controlled DNS server anymore either, which is a really huge plus if you're trying to get the data out. So the sending and receiving systems never connect to each other directly. A great use case might be your favorite coffee shop, and you know your victim, where you stage the data, likes to show up before their work shift, you show up and wait for them to show up, and then you've had to trigger something, as soon as they connect, start exfiltrating that data out because the coffee shop configured their network, so you can see all the traffic, or it's a broadcast protocol, and you just pull it all out. There is no evidence, any data was ever transmitted to you. If you've got a perimeter router that you've compromised, you're seeing all the network traffic through, right? You're in the DMZ, or it's using a third-party server, now we're looking at third-party attacks. If I can get into your network service provider, your ISP, I can see all that data going back and forth. We've got some caveats coming up, we'll deal with them. And if the resolving DNS or DNS server or involved network appliance is external to the organization, yes, we'll see how to build a query so that data will get out of the organization's network. Want to reiterate something here? Any infrastructure outside of your organization that can see the requests, one more time, BGP hijacks have gotten sophisticated. It's no longer a nation state trying to siphon all your stuff. The criminal groups in the last several months within the year have been using BGP hijacks to say send all of the data through this path where I have controls for. The problem with that is especially these new attacks, they've started to poison the broader DNS cache. So you can do a BGP hijack of google.com, DNS 8888, we all know it and love it, right? That happened a couple weeks ago. 8888 had a BGP hijack attack associated with it. Didn't last very long. Didn't have to. The attackers are using DNS cache poisoning and the time to live values and the forged responses are going to persist in all of those downstream servers now and your attackers have persistent, relatively, persistent access to all of your DNS queries now. So it's not just can I get the date out in five minutes. You may have hours, you may have days. And the only thing that's going to be in the logs are DNS queries to google.com, to strange domains. We'll see some use cases as we walk through the tool, which brings us to packet whisper. All right, so it's sending data everywhere. It broadcasts to the broadcast address to your protocols on a local network. Why isn't this thing called packet shout? It didn't sound real good. I'm also not really good at marketing, but also go to a vendor party. I'm sure you've been to a few already and whisper to a friend, just talk to a friend. Nobody can hear you over all the noise. You were totally screened out. All you were doing was talking to somebody. Doesn't ring any bells, doesn't bring any alarms. Packet whisper is a nice little tool that does all these steps for you. I mean, sure, Cloakify is fun and there are a lot of things you can do with it. Try it out. Maybe you like it. But if all you want to do is exfiltrate data via DNS like this, packet whispers wraps up all these pieces for you. You just give it a payload name. It encodes the payload. You create, you choose the cipher. We'll get into the modes. It creates the DNS queries. You do the packet capture. However, you do your packet capture. Maybe you've got TCP dump. Maybe you've got T shark. Maybe you just own that network appliance that is going to be your point of capture. Once you've got that capture, that PCAP, just send the PCAP, load it up into packet whisper. It'll do all the stuff. It'll extract it from the PCAP. It'll de-clocify it for you and you'll have the file that you exfiltrated from the target organization. So our transmitter, again, Cloakify the payload into a list of DNS query targets. We create a single DNS request for each item on the Cloak list. Do not exfiltrate gigabytes of data. I mean, you can be the one that did it, but it will take a very, very long time. It takes minutes to get a few K out depending on how you're doing this. In certain cases, it's now time to transmit, to send it out, to make the DNS requests. It'll create a knock sequence. Standard crypto, standard stealthy, hey, here's a couple of things I'm going to do. Sometimes it's port scanning, if you're a bad guy, a specific series of ports. Sometimes, in this case, it's going to be a list of distinct queries. Why do I need that? Because everybody else is doing DNS queries on that same path. And when you're doing network address translation, all I can see is it's coming from the same base address of an organization. That IP address got sanitized. So in those cases, if the DNS query is not unique, you need that knock sequence. And it says, hey, now we need to look for this. There's a better way though, if it turns out you're going to be going outside of an organization, all that stuff is sanitized, we'll see some unique requests going forward. Again, generate that DNS request, and we have to pause between each DNS request. If you do 10,000 DNS requests all in a row, it's going to multi-thread, and it's going to show up all over the place, and we're totally out of luck. So that's definitely an issue. We'll talk more about that. The packet capture, again, whatever your favorite packet capture tool is, all we're looking for is a PCAP. We just need a standard PCAP with the DNS queries, and then the tool will take care of the rest for you. The extractor decoder takes the PCAP and just pulls out the DNS queries. And if a knock sequence was used, it's looking for the knock sequence, it's part of the workflow, we'll see it, and pulls out those queries from the PCAP once it's made that association, and declocifies the extracted payload. Doing a time check, we're doing good 20 minutes. Transmitting options. This is where you're actually going to be using this in the real world. Again, this is not theory. Common system names make great ciphers, but they also have some limitations. If your DNS requests are for www.google, if they're for YouTube, if they're for GitHub, if it's for common systems, well, you're going to defeat data blacklisting much of the time. Do a test run just to double check. But the important thing is you're not going to be generating any data that raises alarms, either in the alerts or when an analyst goes ahead and takes a look at it. This is really only a good use if you're connected on the same subnetwork. This method really needs the transmitter's IP address available so that you can deconflict. If you send common system names out over a netted perimeter, it's going to blend with everybody else's common names. You have no way to differentiate which is which. So back to that knock sequence. When I see a knock sequence in the packet traffic, it goes, oh, 10.1, 10.7.2 just gave me the knock sequence. Give me all DNS requests from 10.7.1.1.1.2, whatever I just said, and it'll go ahead and strip that out for you. Now, that's going to be a problem if that address had other people and other systems also generating similar traffic, right? I find this method works particularly well if it is a device that doesn't typically reach out to the internet. That could raise a little bit of concern, but it won't be generating all of this traffic. It's a device that's normally just connecting to internal infrastructure and it should never be going to Facebook.com. All right, that's one. And it just looks like this. Go down to GitHub. I provide some ciphers for you to use. They're operational, but go to GitHub and build your own list. The underlying Clocafi tool is really easy to create your own ciphers. I didn't want to create it if it wasn't easy to use and tailor and modify for your operational needs. And there you have it, a list. This is exactly what your traffic ends up looking like. Second transmitting option, distinct repeating fully qualified domain names. That is a mouthful. A lot of you are probably already like, yeah, I get it, fully qualified domain names. When you're going to be moving that data where those IP addresses cannot be determined, the only way you're going to be able to figure out that it's your exfiltrated data is give it a unique tag. However you choose to do that, the best route is through subdomains, unique subdomains. And we can repeat them. Because they're unique, nobody else is going to be generating traffic looking for that domain. Remember a key thing about packet whisper and this whole methodology, the DNS queries don't have to succeed. Failure is irrelevant. We just need the request to go out. That is our route of exfiltration. And so if you are a Bucca Rubanzai fan and you wanted to use the red lectroids cipher, the red lectroids cipher that comes with the tool is all of the Johns. And Bucca Rubanzai aliens invaded the planet about 80 years ago, 60 years ago. And they all picked the same name, John, because they didn't understand human culture. And they all work at yo-yo-dying propulsion systems. So if you do DNS queries using the red lectroids cipher, this will get outside of your organization. Because at some point it's going to try to resolve it unless it's seriously locked down. In most cases, that's going to get out. Because those subdomains do not exist. However, DNS caching will ruin that every time. Once I ask for john.warfin.yo-yo-dying.com, wherever that DNS response is cached, I'm stuck. If my collection point is above that DNS cache, I'm never going to see further requests. How do we bypass that? What if I can't get my collection point? If we cannot set up our collection point downstream from the DNS caching point, we've got a problem. The solution is to make sure we add random noise into each subdomain name, so that it will never cache. We're never going to repeat the same request. That's a problem because the way that Clocify encodes the data, it's a repeating series of base 64 encoded data. We need 66, 67 repeating values in order to transmit the Cloc, or we're never going to be able to decloak it. We can use a common list of root strings, and we can add a bunch of noise to it to make it look like blendy, weird traffic, and then start making those DNS requests. First thing that may pop into your mind, well, that sounds kind of stupid because we're back to the traditional DNS exfiltration model where somebody says, look, I encrypted a bunch of crap, and I'm making a DNS request. Well, we're right back to every single SOC and SIM infrastructure alerting all over the place and tracking it down. So we carefully select the domains that we're going to query when we're doing randomized noise. I love cloud front for this because all of your content domain servers, distributed network content servers, there's an acronym, I'm tired, sorry, they're all full of junk in the front, and they all go to cloud front, or they all go to any of the other CDN servers out there, right? So what we do is let's hijack, let's not use the word hijack, we're not attacking cloud front. We go ahead and generate some randomness, but we use those 66, 67 minimum strings that will let us encode our base 64 payload. And if you look at what we do at the bottom, the yellow piece is the root of our Cypher string. I'm sorry if that's low and you're sitting down and you can't see it, but the first six or so characters of all that weird looking stuff are the actual Cypher. Then there's about seven or eight random characters of crud that matches the format of cloudfrontrequests.cloudfront.net. Remember, we don't need it to successfully resolve, we need it to go out as a DNS request chain. So now we've got some options, because it will never repeat, that's up to the code to be random, and there's plenty of entropy in here, because we're counting it on never to repeat, we're never worried about DNS caching. All right, there are some issues here. There are any number of Cypher's for packet whisper that you can use. You may not want to create your own. What if I just want to use it out of a GitHub, trycatchhcf, out of the box? What if somebody else is doing expiltration too? I am not your problem at that point. The tool is not your problem. If you have that many people in your DNS chain that are running around going, yo, no, just shut it down and go home. Meet me on the beach. We'll have drinks. You know we all got stories to share, each and every one of us. Call me. DM me, they're open. So yeah, tailoring your Cypher, of course, making it your own list of whatever words you deem appropriate. Maybe it's all, you know, the fourth thing I love that is not part of this talk is tacos. What if I decide that I'm going to use that cloud front net method, random methodology, except I'm going to go to Roberto's.com. Sorry, Roberto's, I love your tacos. Nobody else is probably using that Cypher. The problem is the moment you tailor it, well, now it's the taco guy. And that's a little hard to hide out in the open. If you're using the same Cypher as everybody else is, oh, it's mystery hacker group everywhere. So again, check the GitHub repository for Cloakify. It'll show you all of the options on how to make your own unique Cypher. It's really straightforward. And if it's not, then blame me and contact me and I will make it better. Receiving, capture that data any way you want. Wireshark, T-Shark, TCP dump, capture tools on network appliances. If you're a network engineer out there, you know, you've got better stuff out there than Wireshark. Capture utilities on wall displays and kiosks. They are 100% a thing. I have done this before. This happy little wall kiosk lets you do packet captures. I don't know why. I've never known who has ever needed to debug a wall, a wall kiosk to see all the traffic on the network. And yet here we are. This is why we can't have nice things. So there we go. However, you're going to go ahead and pull the data. Don't worry about only filtering on the query names. Packet Whisper is going to take care of all that for you. Minimum hassle. But if you need to minimize your capture bandwidth, because you're pulling a collection, you were the threat team that did that BGP attack on 8888? Yeah, maybe only capture 53 so that you're not capturing terabytes of data to sift through. I have not tested this on terabytes of data. So I guess if you're a nation state, you can do your own research too and build your own code and then submit a pull request because it's about supporting the community. I have names in mind. I'm not going to talk. Must be positioned to capture that packet traffic. That's the only, only requirement people. So name servers along the way. We talked about multiple points already. I won't drill into that repeatedly. Be creative. I like network taps in my operations. Wherever I can get into network compliance somewhere and just click in a network tap. That implies some sort of physical access. But again, if you're a bad guy, and you know, bad guys are relative, pick your bad guy. And they've hijacked DNS. And now all that's going through their stuff anyway, they were able to do that without touching a thing. Oh, on the same Wi-Fi network, capturing device in promiscuous mode, that's pretty awesome. If that's not going to work because of whatever scenario reason, then go ahead and use one of the modes that does multicast. Wi-Fi networks, not all of them will let you see even other DNS requests. I've noticed in the last couple of years in my operations, more and more Wi-Fi networks are using client isolation. So I can't see network shares. I can't see DNS requests. I can't see anything. It's really ruining a lot of fun. And that's a good thing. Making sure you're collecting on the right network path. Standard wisdom applies. It's not a problem until it is. And then it's a real problem because you went through all that trouble to get it, right? And now you can't get it out. Well, if you're a defender, you're like, whoo, barely missed that bullet. But between multi-home systems and everything else, if you're going to be setting up a collection point, do a quick test. It'll be an indicator, but what the heck, YOLO. And just Google for something, search for something weird or something common with a weird domain. A test cloud front domain would be perfect. And to see if you can detect it. And then you're okay. So use dig and trace if you're Linux types, Unix types, or Windows equivalent. See where those paths are going. Extracting. Again, do all the magic for you. Read through the pcap. Knock sequence we talked about. And then it'll declokify for it. The only issues I have had, other than having to wait and be patient, is that occasionally a DNS query just goes off into the winds. I never see it. If it is operationally critical and you can't try again to exfiltrate, well, you're usually only missing one or two characters out of that base 64 payload. It's a Python challenge. Just brute force it and go have lunch. Just randomly add in A through F, zero through nine, and try to decode it and walk it down and have a script response to detect change in size. Walk away and you'll solve it. I've only had to do that once specifically. All right, we talked about selecting a query points. Avoiding duplication. Again, it's the same on a query path for all systems. It is slow. That is service. VPN connections. It makes sense, right? If your system is using a VPN connection, everything is encrypted all the way out through that VPN server's exit point. You won't see anything along the way. And I keep forgetting that sometimes. And it's really annoying. Frequency analysis, not as huge of an issue if you slow down what you're doing. We already talked about most of the countermeasures up front. But just remember, canary data and honey data, really, really, really, really good. Data is going to get out. If you have a way of your data trying to call home or call somewhere so you know data got out, that's a good thing to know. You can worry about how it got out. But if you don't detect it having left the barn, you're not even going to have a chance. You're good stock analysts, absolutely. DNS query whitelisting. Use it. Reduce my attack space. And then awareness, which is why we're here. And we got a couple minutes. Pack of whisper demonstration. So this is not my production box. And this morning, when I went to fire it up and checked everything, Wireshark was not working. Connection failed. My shell commands were not able to find directory structures. This machine is bought. I have backups of the slides. So the tool is going live next week. It's been a long week and I got a lot going on when I get home. It is going to go into the repository. But yes, near four hours ago, I apologize. I've been presenting a long time that has never happened to my system ever. And I want to be clear, I can make sure to connect to NSA secure Wi-Fi at the hotel last night. And I should have been totally safe. But no, my machine is screwed. However, because I've never had to use backup slides before, I'm happy I have backup slides that I can use now. It's menu driven. Broadcast a file, extract a file from a pcap. Take a look at the ciphers. When you go to broadcast a file, it asks you, what file do you want to load up? It will ask you, which cipher do you want to use? And then it'll ask you confirm send. How it goes. When you've got that pcap, load it up in extract file to pcap. It just asks for a file name. Bam. Does the magic we talked about. And if all goes well, you've got that file sitting right there. I tried to make the flow as realistic and repeatable as possible. Under the hood, you run packetwhisper.py, straight Python, cross platform. Yay. Sorry, 2.7. I'm going to work on 3.x soon. But right now it's 2.7 because those are my operational needs and I'm being selfish. Packetwhisper broadcast, packetwhisper capture are doing some of the under the hood magic. You can use those manually if you wanted to. I'll have a full tutorial when I get it up on github. I like tutorials. I like self-explaining stuff. And there's a clone, a clochify and declochify. That's it. There's no other crazy magic. Here's a workflow of actually working. And I use the two tools by hand. The upper right, that upper corner is transmitting. Wireshark is capturing the queries as they're being made. The bottom corner is loading the pcap and decoding it. In this case, I just ran md5 hash to validate that the payloads, the .xls file were the same through and through. Resources, again, you'll be able to pull those off when it goes up on the github next week. That is packetwhisper exfiltration toolset. I apologize for the computer hating my life. But check it out. Thanks for hanging in there. I know it was a long stretch.