Hello, everybody. Welcome to today's Black Hills information security webcast. We got Troy Wojewoda. Also, that is how you say it. Wojewoda is one of my favorite last names in the whole world to pronounce.

It's Troy Wojewoda. And today, Troy is gonna talk about networks and thinks about that. He's gonna talk about Zero to Zeke. I remember when you sent the description in, I was like, yeah. This is something that I could definitely use.

Like, it's introductory. It's how to get started. And then Troy has a workshop next week if you wanna join us for that. And then he's got a training class going up. He'll talk about that at the end.

But today is about learning about the topics that Troy's passionate about, that Troy's really good at, and that Troy wants to share with you. And so, thank you, Troy, for sharing your knowledge today. If you have questions at any time, feel free to ask them. Most likely, we'll answer them at the end of the webcast. And then join us on Discord if you wanna participate with your, fellow attendees, post GIFs, memes, emojis, all those things, because it's fun.

Troy, it's all yours. I'll see you in about fifty minutes or so, to answer questions. Alright, everybody.

Sounds good, Jason. Thanks. Thanks for the introduction, Jason. Welcome. Welcome, everybody.

Thanks for coming and hanging out with us. As as Jason mentioned, my name is Troy Woodrow in case you missed it in preshow or you're just come tuning in. And what I'm gonna talk about today is, this concept of basically standing up a Zeke sensor. I called this title I I titled this presentation zero to Zeke and and really with the idea of, you know, kinda if you're just getting started, maybe you're not, you know, too savvy on on the Linux operating system. If you if you didn't know this by now, Zeke is on on Linux.

So it's primarily installs on on Linux operating systems. And one of the barriers to entries that I've experienced talking to other folks in the industry is is is the having the lack of experience in in Linux to kind of, you know, do do various things, and this would be one of them. So I wanted to put this presentation together and show, know, some examples of how we can, if you're if you're new to this or just getting started or curious to kind of, you know, looking at, how how to get better better experience with network traffic analysis and capturing that traffic. It's very, very, you know, simple to get a sensor stood up and start, you know, monitoring traffic. And and that's really what the the idea and the take home with this presentation is is all about.

Just a little bit about myself. I've been in the InfoSec cybersecurity realm of things for about two decades now. Actually, coming up on two decades, 2006 is where I kinda, you know, started getting in in in involved into IT cyber. InfoSec, we called it at the time. And and I started off intrusion detection, and that kind of inevitably led to did, incident response and then forensics and all all the different experiences that I had over the years.

So, so it it gave me the, that that experience in which I've kinda built upon and and, you know, am where I am today. I'm very thankful for all those things. I've just wanna share back with you on some of the things and that that I've learned along the way to kinda help, you know, other folks getting started because I know I definitely needed that when I was, you know, coming along. So I'm gonna jump right into this. Network security monitoring, why why does it matter?

Right? Well, hopefully, if you're here and you're interested in this topic, I shouldn't have to, you know, give you give you too much of a a a sales pitch on this. But but really from from a network security monitoring or for network monitoring perspective versus endpoint telemetry and detection and and things dealing with with endpoint telemetry, they're complementary of each other. Right? So network sensors give you that bird's eye view, the 30,000 foot, breath wise of of a of a given computer network where your endpoint is, your opportunity to get deep into the the the weeds of things.

So depth versus breadth. And they're and to me, they're complementary of each other. We have opportunities to do things with network security monitoring that we can't do if we're just solely dependent on endpoint and vice versa. And and and kinda looking at it from, you know, doing incident response for for a long time in my career. And even though EDR technology has come a long way a a long way, there's still this concept of I'm looking at things.

I'm I'm evaluating stuff that's going on on a given endpoint or multiple endpoints. With network security monitoring, you have the opportunity to see things from a from that bird's eye view, but really most importantly, from an adversarial perspective, it gives you that higher ground perspective. Right? I'm seeing things coming out or going into a specific endpoint or endpoints, and I'm not reliant totally on the technology that's running on maybe what is assumed to be compromised or or or compromised asset. So, again, hopefully, I don't have to give a sales pitch of of how important our security monitoring is, but here we are.

And and this is really, you know, again, getting started, increasing your knowledge about network security monitoring. And one of the things that I found one of the technologies that I found over the years is this this the Zeke, what's formerly known as Bro. And if you didn't know this, it's actually 30 years old now. Vern Paxton, who developed the technology, what was formerly known as Bro, now Zeke, started in 1995. It's typically labeled as a intrusion detection system.

You can do intrusion detection with Zeke. It's definitely possible. It has frameworks for that. And and and I've definitely and I've written detections off of Zeke telemetry for sure. But its real power is the is is the collection and the metadata collection of all the things.

Right? Network protocol analyzers that that the technology is capable of is just in in what I call deep packet inspection. Right? So versus when you're just looking at, you you know, say, NetFlows or TCP connections or or or network traffic via whether it's a firewall or some some other type of network telemetry that's being produced, generally, those solutions only give you, like, a connection state or duration. You know, you get the the two pool connections that we typically see with NetFlow and stuff like that.

With with Zeke, we have the opportunity to kinda peer in to do that deep packet inspection. And it what it does is that metadata collection of all those different things and all those different protocols. And, yes, there is a lot of encryption and more and more prevalent these days of of of encrypted protocols, and and that is true. But that doesn't limit us from our ability to get information out of even those encrypted connections, we can still get information prior to the encryption being set up, and and there's there's there's a slew of things. We're not gonna go into the details of what's getting produced by Zeke.

We have other information tutorials that we put together. There's class opportunities, also webcasts that we put out there. And I have some links at the end of this presentation that shows you the getting started with the log analysis of of what Zeek produces. This this presentation is gonna be focused on getting that actual sensor up and running, which, kinda is important if you wanna get get started with, using, this type of technology. I really like this, this quote from, Richard Biclich, and that is, like, it's it's not just like an intrusion detection.

Right? And now he was quoting Bro at the time. Again, same technology. But, you know, that network network security monitoring data, the session data, the transaction data, all this this rich contextual data that's put together in nice form and protocol base will gives us the opportunity to kinda look back at data that's been collected. And I'll share a quick quick story about this before I actually go into the actual sensor, you know, standing up and stuff is, you know, when we hear about, like, vulnerabilities dropping, like o days and things like that, typically, when those things are occurring and we're learning about them, the activity has it's it's possible that the activity has been been occurring prior to it's been public dissemination.

So so heart bleed isn't it? Heart bleed we'll take shell shock, for example. That's that's something that's probably ten or eleven years old now, but it was a twenty year old plus vulnerability with with bash. And when that Ode popped or or became public information, I remember, like, looking back at like, I had a Zeke sensor deployed at a a public facing Internet point of presence. And the the day that that information went went live, you could literally see all the inbound traffic hitting the DMZ trying to like, user agent fields and host header fields and all these other h t p o fields that are that we could see in clear text with the that the Zeke was ripping out and and and logging and indexing.

We could see all these different shell, like, exploit exploit attempt string patterns and stuff like that in those fields, which was great. You know, obviously, it becomes public dissemination. Everybody's scanning everybody on the Internet, and we're you know, that there's no surprise there. But what was more important is I had, you know, weeks or months worth of historical ZCLOG so that I can go back and say, okay. Were we seeing any of this activity prior to its public dissemination?

Right? That would be more indicative of someone or some some entities having knowledge of that exploit and being utilizing that prior to it becoming public information. And and that is exactly where we get, like, that power with with with Zeke itself. Like, what the the the importance parts of it. Looking at Zeke itself and the Zeke technology, there's really two modes of operation.

And I and I talk about this when I when I teach the class, and we don't really get into, like, standing up the sensor itself. We look more at, like, how to use Zeke and and how to customize Zeke and and and how to, you know, analyzing the logs that it produces and stuff. But I just wanted to take a moment and share, like, there are two different ways we can use this technology. One is and and and on the left here is what we're gonna talk about today is how to get the sensor up, how to get it monitoring traffic in in a in a very simple, like, kinda, you know, easy way that where the barriers of entry are are lowered for kinda getting started in this in this field. And that's and that's typically how most people deploy their Zeek sensors and they use them in the continuous monitoring mode.

But one thing you could also do with Zeke, if you have it in a lab environment or a VM or just wanna stand up and play with it and you don't really wanna you don't really care too much about the the continuous monitoring aspect, but you just wanna kinda understand, you can replay you could you could take Zeke and and run it against just saved PCAP files. And in fact, I would actually encourage people that get more and more into this technology that use Zeke and start writing, say, stuff like custom Zeke scripts to actually have packet captures saved as as test files or or, you know, test data for when you're you're deploying those custom Zeke scripts. So you know that your script your Zeke script, for example, is going to, do x y z. That's a a special thing that the Zeke script does. And the and the p cap file that you have to test against it, has the components in it that you know are gonna be extracted.

Then you can run it on there, you get your expected results. And what's important about that is when you upgrade to a newer version of Zeke, you know, just like anything else that we upgrade in our environments, we wanna make sure that whatever we're doing specifically from a customization perspective passes. Right? Because this has actually happened to me with this technology before where I had custom scripts. We upgraded to a newer version, and those custom scripts actually broke.

They didn't break where they failed. They just produced and outputted the data in the wrong fields and and and and really the wrong data in the wrong fields. So it's really important to kinda have the the the the ability to test your your customization. Just wanted to kinda show that those two those two options are available to us. So so step zero.

By the way, we always, you know, start counting at zero. Right? So what step zero for for me here is that we wanna get started. You wanna you wanna understand and and and deploy a Zeek sensor or build a Zeek sensor or get one up and running. Really, it comes down to, you know, some of the components like the the the the pre steps.

Right? So you gotta you know, whether you have the hardware and do you have the right spans or or how you're gonna get the traffic. So that all may take time. But the point of this presentation is essentially the inverse of, like, that may take a lot of time, like weeks or whatever to kind of come up with a plan, figure out where you're gonna monitor. Maybe you have to acquire software.

Maybe you have to buy some more RAM or what whatever that ends up being. But the install time should be very, very quick. When we're thinking about installing or deploying a Zeek sensor in that live continuous monitoring mode, we really gotta ask ourselves where do we wanna deploy the sensor? We could deploy in various different, you know, areas, choke points if you will in a in a network environment. We gotta be aware, like, the the the the benefits and the trade offs of where those positional points are.

And I'm just for very simplicity purposes, I'm just showing a, you know, a traditional network, you know, drawing here where we have a DMZ. You have a perimeter firewall that's facing the Internet. Below your DMZ, you have a, you know, maybe another firewall zone or or or or at least like a core choke point or something like that, your router choke point, various subnets and and whatnot. Now deploying Zeke throughout everywhere in your environment obviously doesn't scale. We talked about, like, breadth versus depth.

That's where your endpoint technology will come into play. You're going going across all of your different, you know, endpoints in your in your assets or your systems, but strategically finding areas in which your network would deploy these sensors. And they kind of it kinda it definitely matters. When we wanna understand beaconing and we wanna understand and we wanna correlate internal address space to traffic that's maybe going out to the Internet. If we're deployed on the on the outside and there's netting going on, we're not gonna see the internal source IP address or the internal host that's actually originating the traffic.

So if we wanted to get beaconing, we wanna understand which particular endpoints are actually communicating, we would have to be inside that netted zone. And and and, you know, the other thing that you have the opportunity to do there, and this is something that Zeek is very well does and helps you. Even if you you you can't think of or or or maybe you you you're deploying Zeke in a way in which you wanna catch threat activity, that's great. That's what that that that's that's what, you know, I use it for primarily and and and and other folks that that I, you know, talk to use it primarily to to identify threats or at least, you know, have that catalog of information. You can go back and help, you know, in IRs and stuff like that.

But one other thing that it can do is help you just audit your environment. You're seeing systems that are communicating on your network, but then when you go look at your endpoint telemetry, right, then you don't have any, you know, endpoint monitoring on, you know, a handful of systems. Right? Maybe the whole entire subnet you see communicating that you have no endpoint knowledge asset inventory on. Maybe the EDRs are not configured correctly.

Maybe maybe they're misconfigured or not there at all. Maybe you have rogue systems in the environment. There could be a whole, you know, slew of different things. Maybe you thought you disabled certain weak protocols, like certain weak ciphers with, like, TLS one point o or 1.1, but you're seeing negotiated TLS negotiations at those weaker cipher suites or at those weaker protocol levels. You can use this as like an audit to to from that perspective when you have it kinda deployed internally where you can see the source IP.

Conversely, like, on the outside of the network, if you're not positioned on the outside of network rather, and you're getting inbound threat activity or attacks at your DMZs and we've seen this. Right? We've seen, you know, VPN concentrators gateways getting popped. You know, Palo Alto had a had a pretty significant o day in early twenty twenty four where the perimeter firewalls were there was a a vulnerability that was actually being exploited there. When you see these perimeter devices being attacked and exploited, there's nothing there.

If you if you don't have a sensor, there's no EDR. There's nothing to tell you that that that's actually going on. So, you know, you have different opportunities depending on your placement. I'm actually a proponent for doing both, but they come with caveats. Right?

Like, again, just like I mentioned. And and the other thing is, you know, when you're on the outside, you're gonna see a lot of garbage. You're gonna see a lot of noise. But, again, I like these complimentary solutions. We can use these.

We can use this as a audit factor. Like, for example, if you're on the outside of the network and your perimeter firewall is is is configured or supposed to be anyways configured to only allow, say, these three or four ports inbound, well, then you should never see successful connections to any other ports. Right? Zeek will tell you that. It's a, you know, it's a passive technology, and it's gonna it's gonna just see observe and and and log.

So, you know, identifying where you wanna be is definitely gonna be key to that. Right? And then, you know, I I you know, acquiring your hardware, installing the all OS, which I'll talk a little bit about that, identifying which ports you wanna, you know, monitor, where those spans or that span or tap topic is is coming into the the sensor itself. And if you're if you're unsure, like, say, you get a sensor up and you're like, okay. I got the sensor up.

I maybe I know my management, you know, interface because I could see that's the IP address assigned to it and I'm connected to it. But I don't, like, know what other interface I have to span connected to it. There's some helpful commands you can run. Like, the IP space, a, will show you all your in network interfaces. Again, these are Linux commands.

Another IP command that you can use to show, like, the the link statistics. And then the eth tool as well will give you some more statistics on those various different interfaces that you wanna target. And then you should be able to see, like, you know, you you identify your management interface that you're connected up to, but then you could see the other interfaces and what they're transmitting and receiving as far as for for data coming and going to those those interface those network interfaces. And then when it comes down to it at the end of the day, you wanna decide, like, how am I gonna install Zeke? And this is really if if you read the the the the elevator pitch of this talk, you would see that, okay, very little Linux experience, you know, a few commands.

I think it's something like, you know, I I mentioned something between two or three or four commands. And and and and that's serious. We we can do that. We're gonna we're gonna when we do that, we're gonna we can take the docker approach using that containerized technology. But the Zeke project itself has come a long way over the years.

When I first started using the technology, and it's been well over I think 2013 is when I started using and looking at Bro, you had to essentially compile the source code. And there was a lot of complications with the the network interface cards, whether that they supported ring or AF packet. AF packet actually has come a long way to supporting commodity, you know, network cards where we could essentially going up to speeds of anywhere from five to 10 gigs using that, you know, open source method of of having the capability to capture high rate traffic with just things like the the AF Packet technology has come a long way. And the Zeke project themselves, if you if you didn't know this, there's a commercialized version of Zeke called Corelight. And, the the folks that actually work over there, are the same folks that design and develop the technology of Zeke, and they left Zeke as open source, which is a which is a great thing.

But that that Zeke open source project does support, various different, Linux operating systems, where we now have the ability to just do, you know, app get install type type approaches too, to get Zeke up and running. However, the Docker approach we're gonna look at today is something, that, was adopted via a different project, but our active countermeasures team, which is a sister company of Black Hills Information Security, had kinda set up this GitHub project that, that that utilizes basically Docker Zeke to get that sensor up and running with with very few commands and and actually have a guide, a quick start guide to walk you through setting up your monitor interfaces. And I'll show you the live what that looks like, you know, going through that in in a little bit here. Like I mentioned, you you wanna you you're gonna wanna take one or two paths. Right?

You can you can go the docker approach and and get it up and running via with Zika's actually running in a docker container with some some various data coming out of the container to the host OS, and I'll show you what that looks like. But then the other option is is to go with one of the, you know, the different Linux binaries. There is source code too since it's open source. You could still go the source code route and compile it that way. But again, this this talk is really for people just maybe you're familiar with Linux, maybe somewhat familiar with Linux, but but that that system administrator level experience is just not there.

But you really wanna get your your feet wet with with with this technology. So for the talk, we're gonna we're gonna focus more on the the the Docker Zeke instance of getting a sensor up. But there are other options, and and and and and definitely check those out if you wanna get more and more involved into into this this technology. As I mentioned, our active countermeasures team, our sister org for BHIS has this GitHub project where we can go, and we'll be looking at it. And and, literally, these are the four commands you gotta that you that you run.

If you already have Docker on the system, then that first command, that curl command to fetch Docker and run it and get Docker installed doesn't even apply. Right? So it's it's it's as little as grabbing that Zeke script, which we'll talk about making it executable and then starting that up. And it basically, that script does everything and gets you going and walks you through a little lizard. And and so that's what we're gonna focus on for this talk.

But again, here's the the link to to where the those Linux binaries are, and you could see that there's some popular Linux OSs that are supported. But if you're using Docker, you know, the good news is that it'll it'll support it'll typically be supported on a much more than just the ones that are listed here. So pick your poison, but we're gonna kinda walk through, like, the the the quick start method. And as I mentioned, it's it's really if you go to that GitHub repo, there's this option that says quick start, and you just follow those commands, and you're up and running within, I wouldn't even say, minutes, probably less than a minute. And there's that there's those set of commands again, just to kinda show you how it how easy it is to to to get this running.

When you go and you start this process for the first time, you're gonna run once once you follow those commands and you get the the last one was Zeke start, which we're showing here, What it'll do is it'll look to see if you have a a node config already already in existent in this op Zeke Etsy directory. If that doesn't exist, then it'll prompt you to essentially select the interfaces that you wanna monitor. So like we can see in this example here, we have the docker the the network interface that's associated with docker the docker container. We have our e n p eighty eight s zero, which is the one that we're selecting to monitor in this case. And then we have the eighty nine s zero, which is our management interface that has an IP address assigned to it.

Then we have our our our loopback address as well. I I do wanna make a comment real quick if for those that are not familiar with Docker or maybe forgot about this. Docker, that one seven two seventeen IP there is standard for Docker. And if you're using that IP space for anywhere close to where you wanna deploy the sensor, you'll either have to not do it in that environment or you'll have to configure Docker to use a different IP. So that by default, it uses that one seven two seventeen subnet range.

And so if you're using that somewhere in your environment and you don't take, you know, heat of that, you're gonna end up with some IP potentially IP conflict issues and may even blow yourself away when it comes to, you know, accessing the sensor itself. So so just be careful of that. I wanna make note of that because I've seen that happen before where where that kind of became a conflict, and we just you had you just have to tweak the one of the two things you have to change the subnet you're operating in, which is probably a little bit harder to do, or just change the default configuration for Docker to use a different range. And you can see we can we if there was multiple interfaces here, the script will identify all the interfaces and you could select multiple interfaces. You're not limited to just one.

If the device that you're using has multiple interfaces, you have multiple spans going to it, you can have Zeke attached to all those those different interfaces. And and I wanted to spend a little bit of time talking about the actual script itself, Zeke. So if you if you've used Zeke before and you haven't used it in the docker instance that we're talking about, but you use Zeke, you either compiled it or installed it from one of those links binaries, you'll you you probably are aware that the when you run Zeq, you're actually running a Linux binary. You're running an ELF executable, right, when you're when you're running Zeq on an installed system. When we run Zeq on this method for the Docker Zeq instance, you're you're not running Zeke.

It's you're not running an executable a Linux, you know, binary executable. You can see in this command, we can type the which command with Zeke. It tells us that it's at user local bid in Zeke, and then we can run the file command against that, and we could see that it's actual shell script. And so I wanted to kinda highlight that out just to make sure that people that that we were using Zeke and you're running this Zeke command. When you start running these commands, these various commands that orchestrate the docker Zeke, it's not like running traditional Zeke.

So so that docker Zeke's instance is orchestrated by the Zeke script, which has its own set of commands that are actually just orchestrating in the standing up or updating or or dealing with the actual Docker container where Zeke is running inside of. And this is just a quick little snippet of the script. If you go look at GitHub repo, you can see that that this is what what it looks like. There's a concept at the very top where you can define a different top level directory for Zeke. By default, it's gonna choose slash ops slash Zeke, and that's going to be the default directory for the Docker Zeke instance that you you get get running up.

And so so that's that's one of the one of the the key piece pieces there. Otherwise, if you don't if you just leave everything as default and run it, it'll set the it'll set the default to opseq for for Zeke's home directory. And then also keep in mind the image name too. So there's different various Docker Zeke instances that exist being referenced by this GitHub repo. The latest one, which we'll see what that actually what actually instance of Zeke is actually running in that, but you could see there that that variable is also set to to use the latest Zeke the Zeke release there, which is not the latest and greatest that the developers have in the Zeke project.

But just just to throw that out there that that that that's how the different versions controlled are being done and handled by this by this script. And then in a little bit, I'm gonna actually show you and then jump on to a a system that I have staged and ready to go and kinda walk through some of this stuff. But I but I wanna take some time to highlight some of the components of dealing with this deployment scenario. So once you get it up and running, Zeke's gonna go do its thing. But you may be like, well, how do I so it's so Zeke's running in a Docker container.

If you didn't know this or maybe you did, Docker when you run things in a Docker container and you restart the container, you lose persistence. Right? So so the the question might be, well well, if Zeke is running in the Docker container, how am I getting access to the Zeke logs? And, you know, maybe just as important, how do I customize it? How do I customize Zeke in which it would survive?

Like, what if the server reboots or the Docker container restarts? Like, we wanna make sure that things survive persistent wise because the the traditional nature of Docker is not persistent. And so one of the mechanisms to do that is by referencing this directory path, this app Zeke share Zeke site autoload. In that directory, by default, you'll see these four scripts, zero zero one unload scripts, 200. If you look at the two that I have highlighted with arrows pointing to them, they actually say in the comments of the scripts, do not modify these scripts.

They're gonna be rewritten when you restart the the Docker container. So they're kinda like high level. This is how the project was built. If you if you kinda get going with this and you're like, I don't really like that, we'll go you know, obviously, you can you can fork the project and and change it. But just to let you know, like, these two scripts are going to be, these two files will be overwritten, and you'll lose whatever type of persistence you put in there.

The other ones and and any other ones you drop in this directory, by by the way, will be loaded up when Zeke starts up. And so if you wanna add some customization to Zeke, it doesn't have to be added to the one hundred dash default dot Zeke or the nine hundred dash z k g dot Zeke. It could be a whole another file. It doesn't even have to have that same naming convention. What the container will do is it'll look into this app Zeke shared site auto load directory, and it'll pull all these scripts in.

And it's kinda like if you think about it, if you're if you're familiar with Zeke under the, under the site directory, there's this concept of a local dot zeek file, and that's where you customize Zeke. And that exists inside the Docker container, but, again, the persistence, you know, piece that that that we're concerned about. But what happens when Zeke starts back up, it'll reference this auto loads directory and pull all these scripts in. So you could you could just create a new file in here and put all of your customization in that new file. You could separate it out, if you will.

Just be careful not to modify the two that are highlighted because they will be overwritten when when the Docker container restarts. Another concept or another way in which Zeke can be customized is via Zeke's package manager. And so there's this package manager store, which is net URL there, packages.zeke.org, and you can go and there's very there there's some popular zeek packages that have been developed by various folks, you know, contributing to this open source project. And, like, one of them, if you follow this if you follow this path and you get Docker Zeek going based off of this presentation and that active countermeasures, get up repo, you'll you'll you'll find out that there one of the packages that are installed is the JW three package. So JW three hashing, JW three s, which is the server side hashing of the TLS negotiated cipher suites.

So if you're not familiar with JW three, that's basically what it does is it looks at the the TLS connection being an encrypted tunnel before that connection gets established as a a handshake between a client and a server wishing to do TLS encryption a tunnel. I mean, they gotta negotiate they have to negotiate cipher suites. Both sides have to negotiate the highest Cypher suite that both sides actually support. But in this negotiation process, both the client and the server send their respective algorithms that that they support. And what Jot three does is it looks at those algorithms and it looks at the order in which they're presented, in in a in a unique ordered array, and it hashes that.

And it gives the that hash a fingerprint of, like, this is the client. And and oddly enough, you can use, like, three or four different, browsers on the same system going to the same server, and and most likely, you'll have three or four different JW three hashes because each browser kinda presents its data, in its version, presents its data a little bit differently to the server. And vice versa, the server does the same thing. So that's what Jaw three does. And, you know, out of the box, Zeke doesn't to to get this capability, you wouldn't go to the Zeke package manager and pull this down, and that's what's being done here.

I say all that because there are a couple mount points that this Docker Zeke instance uses, which could be located if you if you type for Docker volume l s and you have Docker installed, it'll show you all the different mount the the Docker volumes that exist on the system. So if you're using Docker for other things besides this, you'll see more than these volumes. But if you're just doing the Docker zeek instance and you run this Docker volume l s command, you'll see that these three different volumes that are referenced. And this is where the package manager gets saved. The the logic for the package manager gets saved, and therefore, again, for for survivability of the of of, like, the docker container being restarted and and things like that.

So just be aware that there's those two different places where we have persistence mechanisms set up so we don't lose that customized capability that we've put in place, you know, on initiation after after that when when a when a Docker container or the server reboots. And so here's a couple examples of just very, very small examples of how you would go about tweaking. If we go back to this this directory here, appzeek shares zeek site autoload, we can create a file or we can add to one of these other 100 dash default or the 900 dash Zeke. We can create another file or we can add to one of those two. These two different statements here.

One of them is the first one is we're gonna load the policy to tell Zeke to log its logs in JSON format. By default, Zeke will log its logs in tab separated values, which I actually prefer to utilize if I'm act looking at the Zeke logs on the local host. Tap separate is much easier from a a human readable, you know, perspective. It's also JSON is actually more disk space utilization. So JSON adds more data to to to the the output.

Because if you think about it, every value that's being produced comes with its the actual field name of the value with inside the JSON blob. So although JSON adds more data to to the logging versus tab separated, it's much easier from, like, a machine ingestible perspective. And what I mean by that is if you're offloading this data to a SIM to some kind of, you know, Splunk or Elastic or something like that, it's much easier to for for those processing engines to pick up a JSON blob and run with it because you don't have to tell it much of anything. Everything's already instructed in the JSON blob. It's like, this is the field names.

The better it doesn't matter what order they're in. These are the names of those fields, and these are the field values respectively. So that's nice from that perspective. But if you're actually, like, just playing around and and and and use looking at the data locally on the system, I find tab separated is is much easier to do. But, again, it's it's to reach their own.

This is just the way this first statement, if you if you load it up when Zeke runs, we'll output the logs in JSON. The the second one is one that I bring up because I I see this a lot when we deploy sensors internally, is Zeke, for for for starters, has knowledge of lots tons and tons of network protocols. You know, we we talk about, like, the heavy hitters like HTTP and DNS and and and and SSH and and TLS and and all those other ones. And and there's tons that Zeke does. One of them it does is actually identifies and log Syslog traffic.

And if you think about that for a second, like, Syslog is the way in which to transport logs from one system to another. And so if we have if we if we have if if if Zika is seeing that syslog traffic, if it's UDP five fourteen is by default what it uses, but it could be other it could be over TCP as well. But if it's not encrypted, Zeke is gonna see that traffic, and it's gonna log the syslog. Meaning, if you have a firewall or some other kind of appliance or or system that's sending syslog to a SIM, and it's sending all its logs to a SIM, and Zeke is positioned a way where its span or tap point of presence is seeing that syslog traffic going, it's gonna also log the syslog traffic. So you're gonna have that syslog traffic going to your SIM, and your Zeke log your your Zeke system is gonna be logging syslog traffic.

And in my experience, when this happens, your majority of all your logs, like, 80 to 90% of all your logs are Syslog logs, which may be beneficial if you're in a situation where you're trying to understand something and you don't have the data. Like, you don't have access to that SIM or or or for for whatever purpose, like, for whatever reason that Syslog traffic didn't get to something that that you knew about, that you can look at, the the the data will be in there. But but in a practical sense, that's not what you really wanna your your Zeek sensor to be busy doing. Right? If you're sending Syslog traffic to a SIM and and maybe even you're sending the Zeek logs to to a SIM, it doesn't make sense to also have that Syslog traffic.

If you if you think about that from from that perspective, if your Syslog data is going to the same SIM that the Zeek blade is going to, you're gonna have duplicate data, for all your syslog data. So it's gonna it's gonna take up all all that, and it's gonna take up the the disk space, on on the, the sensor itself that is logging. So one easy way to disable that and there's there's various other ways, and we're not gonna go into the the the bowels of Zeke and how we can, you know, manipulate that. But one easy way to do it, is that second piece here, and it just disable the syslog stream. And so what that will do is just tell Zeke not to log the syslog traffic to a syslog log locally for Zeke.

It'll still log the connection, and that's okay. Because, what what typically happens is, we'll just say, like, a syslog traffic goes for for for a good period amount of time. It's sending again, example, firewall logs going to a SIM. It may be UDP over five fourteen or something like that. But even UDP traffic, even though it's stateless, when Zeke follows UDP traffic, it tries to add a sense of state to the connection.

It might be hard to to to kinda grasp with that idea if you're if you're kinda somewhat familiar with TCP versus UDP. But think of it from a DNS perspective. DNS traditional DNS over UDP. A client sends a DNS request. It's a UDP packet to its next, you know, resolver.

It's configured resolver. And that resolver either has the answer or it goes on to the chain, you know, the the chain of DNS. And then what comes back if an answer comes back, that that client that initiated the connection will get a UDP connection back from the resolver that it asked the question to with an answer, hopefully. And and when all that happens, you look at it like, well, those are two separate connections. Like, was a UDP connection going out, and then, ultimately, a UDP connection came back, which is true.

Those are two separate connections. UDP is stateless protocol. However, Zeke sees that it's tracking the connection the the DNS request, and and it's particularly the DNS request ID, and it's waiting for a response to come back. And it actually logs that whole that whole session, if you will, as one connection. So it's a little bit misleading if you're if you if if if you're just thinking TCP and UDP.

Zeke kind of tries to present the traffic in a way in which, yeah, it is UDP and it's stateless, but it's all one communication communication stream. Stream. It's It's all all one one session. And so think of syslog as the same way. The syslog, you know, traffic is UDP and it's sending stuff.

It's tracking that entire session. So what would if you were logging the syslog traffic, you may have 10,000 events in syslog log. But from a connection perspective, it's only maybe one or two connections that Zeke summarizes that UDP, like, stream of data in. So you could still you still have the activity that syslog traffic was being sent. You'll have, like, the amount of data that was ultimately sent from one side and amount of data that was sent from the other side as, like, a summary, kind of like a NetFlow kinda capture or a flow perspective capture.

But but you'll just have it in one or two connection logs events versus thousands and thousands to tens of thousands of individual syslog events. When we when we turn this off, you'll just have the so so the the the takeaway there is you don't lose true visible like, all visibility. You still see the originating and responding hosts. You just don't see all the different individual syslog events. And then finally, there's this cleanup script.

So active countermeasures different project than the active countermeasures repo. And I and I really do wanna give a shout out to to Ethan Robich. He's one of the analysts on the BHIS side. He and and the actor countermeasure team all altogether for putting all this stuff together. But I I know particularly some of these components that Ethan had kinda customized and worked to make that quick start method as well as this this cleanup script, process.

So what this does right here is, and I'll show you this in a little bit. When Zika's capturing data, it captures data for the for the the current hour of of of traffic. So the top of the hour, it starts capturing, logs. At the at the new next top of the hour, it takes all those logs, archives them to a directory location, which I'll show you in a little bit, and then it starts capturing new logs. It'll do this continuously until the disk fills up.

We don't want the disk to fill up, obviously, because then our server will stop working. And so what this script does is it makes sure that the disk never gets utilized above 90%. And once it hits that 90% threshold, it starts removing the oldest Zeke logs on that sensor. So if that sensor is, like, one terabyte or two terabyte, like, total disk capacity, and you've been running the sensor for for a while, you may have, you know, months or even years worth of historical ZCLOGs all the way up to that 90% threshold utilizing this script to kinda keep that. Because the last thing we wanna do is fill up our disk space and, you know, and tip that server over.

So a quick recap before I actually go into showing, you know, one of the systems that I've set up. And this is really just for your reference. So, hopefully, you get the slides and you can look at this or come back and look at this presentation and see, okay. These are, like, kind of the TLDR, you know, components that that we need to be aware of if we're utilizing this Docker Zeke kind of instance. Right?

So local user local bin Zeek, that's the script. That's actually Zeek script that orchestrates the the everything how the Docker container works. We're gonna there's some Zeek commands, and I have another slide that's gonna show some of those. App Zeke ETC, that's where our sensor configurations are. That's where when we select our interface as the monitor, those things all get saved there.

App Zeke logs, that's the directory in which the historical Zeke logs are gonna be saved to in in a in a structure in which you could see the example. For example, 20251031, if you go to that directory, that will be all the Zeke logs for that day archived and and g zip compressed. And then app zeek spool manager, that's a directory in which if you if you're if you're somewhat familiar with zeek and you installed zeek bare bones wise, then the current logs gets get stored in app zeek logs current. This is a little bit of a of a change to that. So it's it's not current.

It's just opseq spool manager, and that's where the current hours logs are until the top of the hour, and then they'll roll to that opseq log in respective day directory. App seek share site auto load, that's where those custom scripts that we want to, you know, customize our Docker Zeek instance reside in order for us the container for for persistence purposes. There's our zeke log clean script that runs every sixty seconds via cron and and make sure you know, looks at that 90% threshold on disk for disk utilization. If you're if you're not familiar with Docker or kind of, like, a little bit familiar but didn't know, if you wanted to kinda peer in or kinda hop into the container itself and look around, there's the exec command that we'd give Docker. So we'd run docker exec dash I t.

We reference the name of the container itself, is named Zeke, and then we give it a command bin bash, which is basically, like, let's start an interactive bash shell inside the container. So that allows us to kinda basically hop in the container, look around. But keep in mind, persistence is gonna get there's no persistence once so if you make any changes in that container and that container restarts, it's it's it's gonna lose all that. And then here's some common commands that that Zeke script could be used doing that orchestration thing. So Zeke restart to restart the container, start and stop the container.

And then there's even if you're running an older version of the Docker Zeke, you can update the container to the latest version by running zeek update. There are more switches that are that are that are possible, and I and I don't really have the time to kinda within this session to kinda jump into all those, but these are kind of like the the TLDR ones that that you'll most commonly use. In fact, I don't really use any of the other ones besides these these here. And before I go into that, I'm gonna hop actually over to my test sensor here. I already have the the Zeke script installed.

So Docker's installed and the Zeke script is pulled down and for to to be executable. So we typed the which command, which is telling me, like, okay. If I was gonna run this command Zeke, like, where am I actually running it from? And it tells us this user local bin z. So if I run that file command on on this path, if it was a true Linux alpha or Linux, you know, binary, it would come back as such.

Right? It'll say alpha or or or something something like that. And we could see it says born again JavaScript. So it's it's it's actually text. Right?

And, you know, even if we wanted to kinda, like, peer into it, we could look. This is the same script that's available in the docker in in that GitHub repo there that I already referenced. So so so there's that. So basically, at this point, you just Zeke and then start. And then it's gonna say, okay.

Like, I've recognized some interfaces here. We can see this this this is actually a sensor that's on WiFi. We're just gonna enable that just for just for giggles for this to see if we could generate some traffic. Unfortunately, I don't have any, like, span or tap traffic going to either 88 or 89 s o zeros interfaces. If I did, then that once we start that up, Zeke would be, you know, processing the data.

So I'm gonna enable the wireless interface just for giggles to see how that goes. And you could see how quick that was. Like, the the Zeke the Docker container should be running now. So if we if we type docker p s, we can see that this this is active countermeasures zeek colon latest. It doesn't tell us which version of zeek is running, and I'll just show you a quick tip of how to how to how to get that information out.

Remember that exec command for Docker, we can use that and we tap Docker exec Zeke because we're we're referencing the actual it's it's a little bit cut off here. But here's the name of the actual Docker container, Zeke. But then the the next command is the next argument is actually the command we wanna issue inside the container. So we can just type Zeke dash v to tell us what version of Zeke you're running. Right?

And so inside the container, it runs Zeke dash v and reports back out to standard out to our host that it's running version six dot two dot one. So there's that. If we wanna look at that directory where the log should be being written to now that we started it back up, we could see as we started up, there's not a lot of data in here. Hopefully, something will pop up here shortly. But you could see some logs are starting to show up.

And as we wait for that for a minute, we can just hop into AppZeek logs, and we could see, historically, this is what it would look like if you had all that historical traffic being being saved. So if we we looked at, say, for example, today, we could see that those are those z z gip gzip compressed logs that are being stored in that respective directory. So let's check out there. See, now we have a con log that actually showed up. We can we can oops.

Sorry about that. I'm gonna cat that log out. We can see it's actually in JSON format. You might might ask why well, how is it in JSON format if the default is tab separated? Well, that's because that's because I modified in the auto load directory this JSON output dot zeek.

So if we look at oops. If you look at that real quick, we could see that that's that one liner that's added to that that basically enables our our zeek logs to write in JSON format. So that's that's really it. Now we have an up and running Zeke sensor just like that. It was that it was that quick and easy.

One one couple of things that I wanted to to share real quick, and I know we're getting quite close to the top of the hour, is when I first started using this technology, I was so used to analyzing traffic in Wireshark or or t or or or tshark or t c b dump. And then this idea of source and destination traffic flip flopping as these communications go. Right? Because the source address is what's actually sending the packet. Because we're looking in Wireshark.

We're looking at a per packet perspective, right, at least in this in this top frame. But when Zeke presents this data, it presents it differently. It actually presents it and it looks like this. Right? This is actually what it looks like when you look at a tab separated version of Zeke.

You have the originating host, which originating the traffic, the responding host, which is responding to traffic, but you don't have this flip flop, like, scenario that you actually see when you open up Wireshark like this. And that's because in here, we're looking at a per packet perspective, whereas what Zeke is doing is it's consolidating it in a per connection. So this is the this the host the originating host is what originated the traffic. The responding host is what actually the server side or what responded initially responded to the traffic, and they'll stay in that state for that entire connection's history. Right?

And and, again, this this session, we don't have time to kinda dig into the logs itself. We do have other material that we can look at and learn from. But I just wanna share when I first started looking at Zeke, I I remembered, like, this scenario that happened to me a long time ago when we were looking at network traffic at our at one of our custom sensors before Zeke, before I started using the technology, and the span was actually misconfigured where it was only sending traffic. It was only spanning traffic in one direction. It wasn't spanning the opposite, the return traffic.

So this is what it looked like when you open up Wireshark. So when I first looked at Zeke, I was like, oh, crap. Our our our you know, this this traffic is actually you know, it's borked again. Right? Some some something's going on.

But, really, what it was is the way it was being presented. It's not being presented at a per packet perspective. It's being presented at a per connection perspective. So, and kinda in in closing here, we we have some resources, some of the stuff that I talked about, the the the various repos that I discussed, some of all the resources that we put together over over over the years, getting started with Zeke log analysis and some YouTube videos and and and other things to to to check out as well as the Corelight documentation. This one right here is the cheat sheet.

So I I I mentioned the the the plethora of network protocols and what it actually is aware of and can log and and referencing that cheat sheet is is definitely paramount because there's so much and it's constantly evolving and changing. So I will be teaching coming up at the end of next week. We have a pay forward what you can class, $25 minimum, but it's basically four hours. But we go probably, it'll be more like five hours. I try to keep it around four hours, but you'll get more material than that.

There's a few labs in there, but it's really just getting, yeah, kinda your feet wet in network traffic analysis. We'll talk about Zeke, but we'll talk about some other core concepts as well and kinda introductory to the various tooling. And and and that's really for folks that, like, really wanna, you know, kinda, you know, either a refresher or we'll get started in this type of field of study. I have a two day course, that's coming up next month at wild wild hack fest Denver. That's February.

There's an option to come live, which we would love you to come out and hang out and take and and and but if you can't make it, there's also a virtual option to take that course. And if those days don't don't work out for you, I'll be teaching that same class again at our sock summit in March. With that said, I guess we can open up the questions. We have, like, five minutes left, and Jason is back. Not to be confused with Jason.

Jason. Jason.

Good job, Troy.

Is here.

Yep. Whenever someone says Jason, I'm just think it's a I mean, every time.

Yeah. Hello,

everybody. Yeah. No. I did that at the beginning.

Alright. Anyway beginning.

So if you haven't checked in yet for Hackit, make sure you do so. You can do that on Discord. If you're not on Discord, I'm gonna put the link in the Zoom chat. It's gonna take you a few minutes if you're brand new to Discord before you can actually comment. But if you engage live during a webcast of ours, we give you credit for it.

And then once you hit 10 webcasts, we send you a reward anywhere in the world. So join our Discord server. And the other reason why is because this webcast was only an hour, but Discord is kind of for forever. And so you can ask your questions at any time. And and the community of 53,000 people, 4,000 active at any given time, will be around to help answer your question.

Like, it is pretty quick you get an answer to your question. Yeah. Alright. And then Zach Zach's here. Zach's here to tell you about the free CTF that we have, for today, and there's prizes.

There's a prize for a free CTF. We're gonna give you an opportunity to learn, and then we're gonna give you a prize if you learned.

Isn't that so cool? Like, the coolest thing. Just hang out and participate and just that's all you have to do. I'm a put the link into the Discord chat right now, and I'll also head over to Zoom and get that over there as well. Every single week though, going forward for every one of our webcast here at Black Hills Information Security and our anti cast and anti safe and training and even our webcast that we'll be doing once a month for active countermeasure.

I cannot talk today.

Countermeasure.

Anyway, all of our webcasts are going to have CTFs associated with them moving forward. And what we're looking to do is tie one of our backdoors and breaches cards and the topic of the webcast together to make sure that the challenge is kind of a you know, associated with that that card and the webcast topic of what you learned today. So, yeah, this week, we're doing DNS as c two for the challenge. So head over to the page that we put into the chat and we'll be giving away we'll be picking two winners, I should say. So the first winner will be getting a full year of subscription to anti safe and training, our on demand platform, so you get access to all of our classes.

And then the second winner will get access to one training of their choice from anti safe and training. So good luck. Have fun. Thank you.

Free CTF, then they get training? Like Yeah. That's all. So thank you, first of all, for joining us today. We're gonna get to your your questions, but I wanna make sure that Troy gets the chance to land this plane well.

And I've been using that term lately, land the plane well. I think it's because I I fly on a lot of planes, and I I want them all to land well. Anyway, Troy Yeah. If you could sum up everything you talked about in one final thought, what would it be?

That if you're afraid to kinda get started with this technology because you don't really understand Linux or command line, that it's really as simple as just getting a base, Linux operating system up and running, those three or four commands, and you're rolling.

K. You're rolling.

Alright, everybody. That is the official end of our time today, but we're gonna do q and a, for an extended period of time. Also, Tom Smith is here. If you wanna know what it's like to do business with Black Hills information and security and you wanna know about this new breach assessment, thing that we have that Troy is gonna be able to tell you about, then stick around for that. As a reminder, we try to keep the hour long webcast to actual educational material, and then we talk about, you know, things that we do before and after.

Alright. That is the end of the webcast. We're now on show banter. Troy, good job. Well done.

Good job, Troy. I got some questions for you, sir.

Yeah. Sure.

My question?

Go ahead, Jeff.

Can Zeke monitor a bridge between two interfaces? So your first question.

I mean, it depends on how you get it and present it to the, to the system, but it should be possible. Yeah.

That was easy.

Did you just hit the easy button on that?

I did.

Will Zeke update will Zeke update erase any previously configured settings in our current container?

No. But there's there is there there is a there actually is a pull request to that repo when you're going if you if you install Zeke for the first time now, you're you're fine. But if you've installed Zeke before, there's actually it's actually possible to I'm still showing my screen. Right?

Yeah. You're showing your contact slide.

So if you type docker images, and it this is me on my test system. You could see actually I have all the different versions of the docker zeek from ACM over the years. If you if you do four dot two or below and then you go to the latest, there is a bug in which the Docker container just hangs and hangs and hangs. And that's because if you if you remember, if you recall the from the presentation if not, I'll just type in here. If we type docker volume l s, you could see that these are the the mounted volumes.

Well, that Jaw three package manager, actually, if you even saw the earlier versions, it'll be there. Well, when you do the update, it doesn't blow away. To to short answer to your question, it doesn't blow away your configurations. No. And one of the problem with that is is that that JW three package is actually not backwards or not compatible from the older version, previous Zeke five to to greater than Zeke five.

So because the latest version is Zeke six dot two dot one, if you have a version four below, it'll actually break. So the quick fix is you just blow away those volumes and then and then re and then redo the update, and it and it'll actually update to the latest and greatest. And if the volumes aren't there, we'll replace them, and it'll replace them with the actual compliant code. So that's actually a pull request that I've done, towards the end of the year last year. It just hasn't been approved or hasn't been committed on that in that project.

But, but, yeah, short answer is it doesn't blow away your customizations. It just upgrades the actual container stuff. So you gotta be careful if you're if you have scripts that are not backwards compatible to previous versions.

Right. Also, I wanted to thank the 50 people that already, requested the new InfoSec Survival Guide Orange Book Incident Response Edition. Troy, I think you had an article in there, or you have an article in the SOC one coming up or the ThreatHunter one coming up.

Yeah. I've done I've done a couple. I've done the ThreatHunting one. There's also trying to think with the other one I did. Yeah.

Oh, network network traffic analysis. Yeah.

So for anyone to go to a link called the Spearfish general store for you to trust that link and then to put in your your address and your contact information, like, thank you. That takes a a level of trust that you most likely struggled with during the the process.

Yeah. And you can share with everyone else that it is a legit website, and we you did not get scammed.

Yeah. You know, looking back on it, calling our online store the Spearfish General Store may not have been the wisest

decision about that. There's a lot of abandoned carts, in there, so we

we did it. That's a funny story. When I first started working and I actually got the, like, package, like, from like, to start doing things officially as an employee for BHIS, I actually was, like, like, Spearfish. Like, that a real place? Like, did John buy

I know.

Like, a little section of South Dakota just call it Spearfish? And I looked it up, and, no, I mean, Spearfish has been a long I think around longer than John.

But,

I just thought that was really, really funny.

Yeah. It's a Shopify story.

Yeah. Originally, Black Hills was from Spearfish, South Dakota. And so we called it Spearfish General Store because it just made sense. But, you know, we changed the f to the p h. But, anyway, when would I use Zeke Docker versus Zeke locally, and how does storage work with the Docker version?

So either one will work fine. The the storage will work on the when I was talking about the cleanup scripts and all that stuff, and then all the other logs that get rid, they get rid out of the Docker container to the host operating system. And so, so whether you use Docker or not, is is pretty much irrelevant. The logs get stored on the host itself or the host operating system. And, and then, you know, if you don't implement that log cleanup script, then your disk will eventually fill up.

If you do, then then you're good there. But the good part about that is if, say, you don't do the Docker instance, but you have Zeke up and running, feel free. Use that use that script. You might have to tweak it a little to make sure the logs are in the right place to where it's identifying those logs. But that script alone, you can utilize without Docker and just run it every sixty seconds to make sure that your disk or your disk, you know, utilization never exceed 90%.

Troy, would it makes I mean, I I don't want this to be too self serving, but if someone came to your four hour workshop, do you feel like you would address a lot of this and answer all these questions live, like, interactively?

Abs yeah. Absolutely. I one of the reasons why I put this presentation together is well, Jason, you asked me to Mhmm. Sure. Yeah.

But you actually asked me to, hey. Is there something that's in your class that you don't really talk about, but you or or you don't have time or maybe you just don't exact like, elaborate on it in the class? And and one of the things I don't really get into is how to get the sensor up and running. So that's what this, like, session was for. But the other sessions and and, yes, as soon as I have questions about those things, I'm I I will spend an infinite amount of time, you know, talking about it.

But we spend time in those sessions actually understanding how to use that Zeke data, how to analyze that Zeke data. But but, yeah, fair any any of those questions would would definitely be, addressed in any the workshop or the class.

Yeah. One of the, like, one of the reasons why we're doing the webcast leading up to the workshops is because, like, sometimes you just need a an introduction to something before you feel comfortable even, like, making an attempt to going like, it's gonna be a hands on workshop. Do I even know this? So we do these to, like, just help Yeah. Get you acclimated to what

And in the workshop and the class, we actually use Zeke, but we don't use it. We use it just basically we feed it in PCAPs and stuff like that. So we kinda, like, help the students understand how the technology is processing that network data and then how to analyze that data and and kinda, you know, take it, you know, to to you know, however they wanna customize it and make it their own.

Yeah. And, Stuart, I just saw your comment. You're you're very welcome. Thank you so much for being here, and thanks for learning. Thanks for choosing, to show up here and, get this education.

Alright. So what we're gonna do now is, we're gonna give all the rest of these questions to Troy. Troy will take a look at them, see if there's some that he can turn in a blog post or a future webcast, to come back for or to add to his workshops or training classes. If you are interested in doing business with Black Hills or wanna know what it's like to do business with Black Hills, we got Tom here. And I wanna talk about the new breach assessments that Troy's doing.

So this is your opportunity. If you, don't wanna do business with Black Hills, thank you so much for joining us today. Thank you so much for your time. We we incredibly appreciate it. But, Troy, what is a breach assessment?

So the the concept of the breach assessment is essentially taking the lessons learned in the threat intelligence for for for that matter from our experience either in the SOC or on IR engagements, and and kinda looking at it for, like, how, you know, how we do pen testing. Our pen test engagements are looking at an environment and trying to identify those those vulnerabilities, those weaknesses before they actually get exploited, before the proverbial stuff hits the fan. Right? Like, that's what they're looking for. They're trying to find and identify those weaknesses so organizations can shore those up.

The breach assessment, you know, from a risk perspective, you know, we we know, you know, threat times vulnerability. Right? And that's what the pen testers are doing and trying to identify vulnerabilities, weaknesses. The the breach assessment is looking at trying to identify threats, active threats, or known previous threats in the environment. So we're using the love the threat intelligence, again, from our what we observe in IR engagements, what we observed in in the in the various different channels that we collect threat intelligence, produce it, or consume it.

But but more importantly, the TTPs, like the tactics, techniques, and procedures, and processes that threat actors do, we look for that activity on these breach on these breach assessments. So the other concept of it is we we try to leverage as much as possible as the economies of scale that we've already built in the SOC. We're not trying to invent the wheel or reinvent the wheel. You know, we use network sensors. We use endpoint telemetry.

We also have, you know, capabilities within the cloud environments and and those different, like, pillars of points of telemetry. So we kinda break it down to cloud, traditional networks, traditional endpoint, attack surface, you know, attack surface, and and that kind of includes OSINT or dark web stuff, but also your perimeter, and then identity services. Right? User accounts and identity services. We look at those five different pillars and kinda look for evidence of threat activity, that has occurred in the environment.

Yeah. And one one thing that's important to mention, I think, about breach assessments is that it really tends to be ideal when there's a merger situation or one company is acquiring another. And big questions have to be answered about, you know, are we ready to bring these two environments together? Are we ready to merge our networks? Are we ready to sort of, like, open the kimono to one another?

And it becomes the it becomes the the case really that a lot of times, like, in an in an acquisition, the acquiring company really needs to have a level of surety that they're not simply opening up their environment to to another environment that that's been breached. So if breach system can be super useful in a scenario like that, we can come in and use the threat hunting techniques that Troy mentioned that we have from a long a long history of doing threat hunting to try to identify and and deliver that level of of confidence to the acquiring organization that they're not just going to be open themselves up to, you know, huge amounts of trouble.

Yeah. And and, Tom, if somebody wants to take the first step towards this new service, this thing that we offer, what's the first step?

I mean, it's just like it's just like any other BHIS service, which is it's pretty simple. Reach out to us. You can go on to our website. We've got our phone number there. We've got a contact form.

We show an email address on there. Reach out via any of those methods. We'll let you back with the link to schedule a call with us. And, usually, we'll just get on the call. In in in the beginning, it'll be either me or it'll be Logan Bender, whom you might see.

If you're on enough webcast, you've seen Logan or Brian Strand. And Brian, you've seen on a billion webcast. So it'd be one of the three of us to take your call. We'll get on the phone trying to understand what it is that you're looking for and ensure that, you know, BHI services are things that make sense for what you're looking for. Like, can we deliver what you want?

And if that's and if and if we can, you know, we'll go through a process of essentially writing up a proposal of, like, how we would go ahead and meet your needs, showing you what that would cost, and then we'll get we'll get through the process of, you know, nailing down exactly what you want us to do, etcetera. Might be a couple of phone calls depending on what exactly it is that you need to do. We might pull in an expert like Troy in that process. If you want a brief assessment, Troy will get involved before before we before there's any ink on paper anywhere, and we'll make sure that it works. So we try to be fairly laid back about how the whole thing works.

And then, Tom, do you just hound people and hound people until they sign? What what's your normal process?

You know what? Honestly, I you know what? Honestly, I I think the the really I mean, really, the golden rule obtains, like, if, you know, if you don't wanna be hounded by someone selling you things, then why would you hound other people to sell things? So Yeah. I mean, no.

I mean, if we don't hear anything from you after you send you something, like, we might follow-up once or twice, but that would be it. And we're not we don't call you unless you wanna be called. But, no, we don't we don't we don't you know, we're not we don't have, like, quarterly earnings calls to show things on or commissions to chase, so

we're very

familiar with it that way.

So I haven't I haven't asked this question to you before, but I've heard this in the past is I think the term like, the saying is you don't want a dentist that's available today.

Yeah. You know what? That's yep. I'll I'll tell you what, I can riff on that. So, I mean, here's the thing.

I mean, you know, a dentist that's available today is sitting around twiddling his thumbs and wondering how he's gonna pay the rent at the nice dental office he's got. Right? You tend to want a dentist who has a long list of clients and it takes a little while to book with them. So the thing is for us, it tends to be the same thing, like we don't necessarily have availability today or tomorrow or next week. A lot of times you gotta wait like six weeks for us if you wanna get it.

For example, a pen test. There are some types of engagements that we have to be more available for like an incident response that Troy mentioned a minute ago. Like, can't say, oh, yeah. You're having an incident? Well, see you in six weeks.

That doesn't fly. Mhmm. So we do have a few types of service that we can deliver quickly and those are the ones where the necessity is that either you deliver the service quickly or you don't deliver it at all, like IR. Sometimes breach assessments too. So in those scenarios, we can deliver quicker, but but in general, with the the bulk of our services, advisory, penetration testing, general cybersecurity work, it's usually there's gonna be some time because, again, we're not a dentist who's really struggling to pay his rent.

We're a dentist with a list of happy clients.

Yeah. Okay. But we have a little bit of right? We have space where you broke a crown. That's an incident.

You gotta get that fixed right now.

I I like I like continuing this one. Yeah. You busted a crown. You got a bad toothache. You know?

You need someone to look at it. Yeah. That kind of stuff we can

The raging infection between the gums. Yeah. Alright, Troy. So, you know, one of the questions I always like to ask is why do you love the work that you get to do, Troy?

Oh, man. Solving problems, puzzles. But I think that's that I think that really comes down to it. You obviously, helping helping people out. Right?

Whether that's training because we're helping, you know, people kinda understand the concept and and and and I actually learn. Every time I teach, that's why I love I love like, I don't hold anything back, because I I learn better myself, and it's like a win win. So so that part of it, we're the opportunity to help customers, obviously, help themselves better. That that's that's that's huge. And and and and and solving problems, like, those challenges.

Right? It's always something that pops up, and that's kinda like, I guess, maybe why I specialize in IR even though I never really liked to admit it Because it's like, you don't know. It's like, we we talk about IRs being like snowflakes. Right? Like, they're all different.

They might be the same a little bit, but they're all a little bit different. And, you know, as much as we wanna be prepared and we talk about preparation and preparation and preparation, it's just inevitably, it's like you're responding. Right? So and then you gotta figure stuff out. And, oh, by the way, it's kind of a high pressure situation sometimes.

Right? It's like, you know, people are yelling at you. What's going on? Did you find it yet? Did you find it yet?

Those kind of things. I don't really enjoy all of that, but I enjoy the bigger picture of, you know, helping and and and helping people learn and helping people secure their environments.

So thank you so much for joining. Deb, if you were going to tell people why we would encourage them to come to Wild West Hackenfest in person or virtually, what would you say?

What would I say? Mhmm. It's like this, but in person. Like, we get to talk at you a lot, and we get to, you know, hear your response in Discord, but actually, like, speaking and having a conversation with you is so much better in person when you're right in front of us in a very non creepy way. And you'll get to hang out with 500 to a thousand of other friends who have this in common with you as well.

And Denver, it's Colorado. I love Colorado. It's awesome. Yeah. We're excited about it.

So if you wanna do business with Black Hills, just reach out to Tom. Tom's gonna take care of you. Tom does work on commission. Tom's not gonna get a new boat because he sold you something you don't need. Like No.

It's just Tom.

It's Tom. Yeah.

Thank you, Travis.

And then Troy gets to do the work, and he loves this work. And so give him an opportunity to solve one of the puzzles that you got. That'd be a lot of fun. Yeah. So thank you so much for joining us today.

Deb, final thoughts?

Final thoughts. Always just thanks for showing up and spending your time with us. We know there's so many different options. I know I've called it noise in the past. I don't think we're noise, but there is a lot of noise out there.

So we'd love you guys. Just thanks for thanks for being here. We'll see you guys next week.

Yeah. Thank you. Thanks for all the gifts. Thanks for the meme. Thanks for the photos.

Like Yeah.

You guys

I don't

know about you all, but it's a little distracting. Every once in while,

get it.

But it's also like Yeah.

It's so fun.

See what you did there.

Yeah. So we before I wrap up, like, the first time I got a chance to give a talk after the pandemic was over and I saw people nod their heads in the audience, like, I teared up. I I forgot how much I missed that non verbal, like, feedback of, you know, what you were saying. And so as soon as I saw that, I realized that the GIFs and the memes and everything that people post, that is our nonverbal feedback for the for the virtual digital era that we live in. So thank you so much for your your engagement because it keeps us entertained and keeps your fellow attendees entertained.

So thank you. Yeah. Alright. Ryan. Ryan, who we love more than anything in this whole world, and we respect, and we care about, and we know that you're not a real serial killer.

If you could just end the webcast gently, so ever gently

Gently?

Without any issues whatsoever. Just If you could just calmly and and gently end the webcast, that would be great. If you could just calmly and gently end the just kill it with fire, Ryan.

Kill it with fire.