 Outstanding. Apologies for that. So my name is Aaron Soto. I am the Director of Learning at CoreLite, and today I'm going to be talking a little bit about the Zeke Open Source project in the light of Open Sock. So I've actually been part of the Open Sock team for several years. Very excited to kind of talk about how these two projects are going to work together. Today's presentation was actually going to be a joint presentation with Amber, who is our Zeke Community Director. She had some unforeseen circumstances came up. So I'll be talking a little bit about the community piece, but I'll try and do it justice to her content. To kind of talk a little bit about... Let me get my... I see that is going to be... I do not blame Discord right now. It just had the rug pulled out from under it. So let me switch over to this. So I'm going to talk a little bit about Zeke. What is Zeke? It's an open source framework that is used for... What do you mean? Okay. It's an open source framework used for network security monitoring, basically looking at network traffic. And you might have heard of Zeke as Bro. So back in... This was back in 95. Bro started at Lawrence Berkeley National Labs. And there were a number of people who were looking into this problem space and were thinking... Not even as a security context, but just looking at network traffic at large. And the name Bro kind of was more... Really was kind of a nod to Big Brother being like, this has a lot of surveillance potential, but it also has a lot of network security potential, which is obviously what we'll be focusing on today. But if you've heard of Bro or if you've heard of Zeke, it was probably as part of like a research center and university government, like a big organization having it in a sock, using it for instant response, for threat hunting, even potentially for like network forensics and network operations. And there's actually some vendors, though I mentioned I'm employed by Corlite. There are a number of vendors who actually have Zeke integrated in with their platform and use it. So if you've heard of it before, that's probably why. Zeke itself is actually very customizable, very extensible. It's really kind of its own language. And there's a lot that you can do with Zeke in terms of just having scripts and plugins and protocol analyzers and kind of these components that work together to analyze your network traffic. So there's a Zeke package manager. If you go to packages.zeke.org, you can see all of these packages that the community has contributed, but you also, because it's open source, you can write your own. And so there's actually a tryout.zeke.org environment where you can play around with that. And I'm not going to dive into that too much right now. I just want you to know that it's out there. So what is the data? Like the Zeke data is really where the power is. I want to talk about what that looks like. So I'm going to use three examples here, three slides or three logs to kind of start that conversation. On the left is the con logs, the connection log. You've ever seen NetFlow and it's got like IP addresses, ports, protocols, timestamps, like all this really high level information. That's basically the con log. Every single connection will appear in the con log. But then there's these other logs that are more protocol specific. So let's say I have HTTP data, like I have, you know, a web browser talking to a web server. I'm going to see all of the metadata associated with that connection. So things like, what was the user agent string that was sent? What's the URI that was requested if you're talking about the client side from the server side? Like what was the mind type that was returned? How many bytes? What was the status code? All of those things we see in our HTTP log. Similarly, if we're talking about other protocols, let's say like DNS, I can see the DNS, like the client in the server. I can also see the queries and the answers, the responses, which is surprisingly difficult to dig into sometimes. We'll talk about that more in a second. Now realistically, there are only a few logs that you're really focused on in a given environment, in a given exercise, and then even frankly even an open site. But there are, I'm going to push forward those logs in total now, I mean within the Zeke open source project. So there's a log for pretty much any protocol you could think of and all that metadata, that rich metadata from that protocol is stored in that log for whatever purpose that you might need. I've got a couple of links down at the bottom to Corleag has a little PDF cheat sheet. I'll have that link for you in a second too. And the Zeke open source project has really good detailed documentation about logs and even some things that didn't make the cheat sheet. That's actually where I stole these graphics from was from the Corleag cheat sheet, because it's a little more colorful. So, how do we like to really talk about how we use the, let me start off by kind of trying to get a little bit so big to see things are on somebody or with somebody or with those like that we get some from those like wires dark and deep be done. Or in the middle we have it like intrusion detection system treatment prevention systems. So things like snort and suricata things that we'll find as we can work our way through just go looking at this this kind of signature based detection. And then on the far right we have that flow. We have, you know, the IP addresses, protocols, timestamps, that kind of high level information. These are three very common tools that we'll see as you, as you're kind of getting familiar, you know, as you're probably already familiar with. But let's use those to kind of compare Zeke. To start off with, Zeke is really fundamentally different from something like NetFlow. It's really well it's really different from all of these but let's start with NetFlow. So NetFlow is giving us just that, you know, protocol timestamp, just that generic info versus the something like Zeke is going to be able to understand protocols at a much deeper level so it understands how something like HTTP works and it can pull out all that metadata. It can even see things like files being sent over HTTP and extract those files out. So we we're not saving everything we're saving the most useful to this. And really, when you're thinking of Zeke, I want to talk about compares to some of these tools. I want to say like throw away your ideas, throw away NetFlow first be useful and deploy Zeke in parallel with these tools and especially if you have something like a full package capture, then you can go ahead and use Zeke to help find where the most interesting pieces of that full package capture that data reside. Now, comparing Zeke to an IDS is something that's very commonly done. And I want to take just a second to talk to that because Zeke isn't here to say what's good or bad or what's right or wrong. It's here to say this is what's happening with NetFlow. Because I need to respond to that. I know at least I need to investigate to look at. But Zeke is here logging everything that's going on and giving us the control to say, is this good or is this bad. Now, as I mentioned before, Zeke is very expandable, very sensible. And so there's a lot of things that we can add on to Zeke. We can kind of do things like, hey, if you see these kinds of anomalies, let me know. Because Zeke understands protocols at such a low level, it can do things like to say, hey, this looks like protocol abuse. This looks like a situation because I totally understand how this protocol should work. And this is not conforming to that standard. I'm going to go ahead and write a notice log. I'm going to go ahead and write something to the weird log. And we'll talk about some of those logs a little bit more in a second. But there's a lot of things that we can do with this. So when I'm talking about Zeke data, what I'm really talking about is the representation of network traffic and what you're seeing on your network as it's represented in Zeke data. Now, there's a couple of ways you can get those logs out. You can look at the raw Zeke logs. And we'll kind of see a little bit of that today. But as you normally use in an enterprise and as you'll use an open sock, that data is being forwarded to a seam where you can interact with that. And you get the context of all the other host-based data and everything else that's coming into that seam environment. So in case you haven't guessed already, our seam of choice for open stock, if you were watching the workshop earlier, is gray log. And so we'll talk about what this looks like in gray log. But one of the things that is, before we jump into that, I want to talk about how we kind of associate these logs with each other. So I remember I said we had like a con log and an HTTP log. And so every connection that comes in, I'll see in my con log, but every time there's some HTTP data, HTTP application layer protocol identified in this connection, there will be an HTTP log for that connection that has all that relevant metadata. Now the question becomes, how do I kind of pivot? How do I jump? I see something in my con log and I know there's HTTP in there. How do I go find the matching thing in my HTTP log? So the way you're going to do that is what's called the UID or the connection unique ID. And that's something that every time there's a mention of this connection, it's going to appear in any one of these logs. So if I have a connection, let's say, that uses HTTP and let's say it transfers a file, well, then I'm going to see that same UID in my con log, in my HTTP log, in my files log. And each one of those logs is going to give me the information about that file transfer. On the topic of file transfers, there's another type of unique ID called the file unique ID. And similarly, if I kind of want to pivot around and investigate a file that's happening or that I'm interested in, then I can use that file unique ID and search through logs and see what connections are associated with that unique ID. So, all right, I've done a lot of the explanation I want to guide into like one pretty thorough use case. And I want to do this for two reasons. One, I want to get you in the mindset of how an incident responder thinks. And for some of us, that's not a stretch. And for some of us that might be a little new. But the second thing I want to do is I want to show you how you would use just a Zeke data to work through a particular incident. And so let's say I'm, you know, fresh out of college or fresh, you know, out of another career field I'm pivoting. And I'm, you know, just joined this team. I'm a sock analyst entry level. And as is, you know, tradition, I am awarded the honor of the night shift and I'm sitting here and I'm watching alerts roll in. And it's my job to kind of triage these alerts. So I'm trying to figure out when something comes in, do I have like a playbook or procedure something that I can fall back to to say I know how to handle this. We've seen this before where I have something in my playbook that I know how to how to resolve this myself. Is it maybe instead something that I can I can dismiss I can say well this is a false positive or this is not actionable. Okay, somebody's poor scanning. Doesn't matter. I can't really do anything about it. Or in, you know, the third case, do I need to escalate this? Do I need to bring this to someone who can then, you know, spend a little bit more time looking at this or maybe has the piece to work through this. And so it's doing I'm sitting here, I'm watching these alerts roll and I'm trying to figure out can I deal with this. Can I deal with this myself can I dismiss this. Do I need to escalate this and alert and alert comes in from our internal detection system and it says hey, I saw a DNS request leaving the network, and the host name in a DNS request match the signature so the ideas raised are to say I know that I have a signature that says that's associated with a known command and control server a C to server. So what am I going to do to kind of a can I deal with this myself do I can I dismiss this do I need to escalate this. And if I just have as each data to look at this, I might start off in my DNS log so I mentioned there's a log for DNS and this is a DNS related alert. Let me turn to my DNS log and I'm going to see the workstation or stations that I've seen recently that have tried to reach out and look up that host name, the DNS servers that respond into that which maybe is something internal maybe it's you know an external DNS server depending on how if I can block that from leading my network. I see the query itself, which in theory my ideas already told me so it's not really that big of a deal. But the big one here is the answer field and it's literally called answer as a field in your DNS log and it is the response that was provided to the client. So in this case, I know the client queried for this, this host name, I want to know what IP address they got back. A lot of times, even with good DNS logging, you know, set up if you have your DNS server set up to forward logs. A lot of times they won't give you that last piece they won't give you the answer the IP address, and I need that because I need to pivot for my DNS log to my con log. So the question that I'm asking myself right now is okay. I know that there was a DNS request leaving the network, but was there a connection that followed that to the IP address that was resolved. Maybe the, I had like an intrusion prevention system that stopped it. Maybe I got lucky and the attackers infrastructure was down and I just, you know, dodge that bullet. So I want to know if there was a connection, I want to know more about it. And let's say for the sake of this example, there was there was a connection. And so I can pivot from my DNS log to my con log look for connections that IP address, say that there were connections I want to see what ports there on when did they happen are they still happening. How many bytes were sent either way. So in particular is interesting because I want to know a little bit more about this, this communication. Let's say for the sake of this example that the communication to that server was on poor 80. Well, the more veterans of you might say poor 80s obviously HTTP I know that. But hang on, put your attacker hat on for a second and think about this. The attacker doesn't have to use the port that for its intended purpose. So just because they're on port 80 doesn't mean they're using HTTP. But one of the cool things he does is it has what's called dynamic protocol detection DPD. So I'll see in my con log a field called service that tells me the protocols identified Zeke knows, regardless of what port it's on, what's going on inside that connection and so it'll say yep, I know there's HTTP inside of here. I don't care that it's on poor 80 I mean obviously that's that would go what that do what we would expect, but Zeke tells me certainly this is has HTTP traffic. So I'm going to pivot now from my con log to my HTTP log to get more information. And how do I pivot between those two logs. I'm going to look at the connection unique identifier that you ID field remember that appears in every single log that has information about this connection. So I'm going to look to that you ID field and look to see if I have a matching HTTP log. And in there, I'm going to see things that relate to this connection things like user agent strings and cookie values get close parameters things that the browsers sense as part of that request. And also I did some response information and these are things that you'll hear the term indicator when I assume it's for an indicator of compromise. These are things that might help us figure out exactly what this is what malware strain we're dealing with and that's something that again, I might be able to go back to previous incidents and playbooks and community resources and say, Hey, what is this thing does anybody does anybody recognize this string that looks a little bit weird do I know what malware that's associated with. And so, if so, I might be able to handle this myself I might say, All right, cool. This is an incident that I know how to resolve I'm going to go ahead and quarantine you know keep that machine off the network. I'll contact the user will start an it ticket get a re-imaged and probably reset the user's password. But okay, I can handle it right. But I like being the worst case scenario person what happens if I don't know how to deal with this what happens if if I don't have any indicators that I can pull up and say I know what malware strain this is. Let's say, for the sake of this example, that this is a downloader. This is a piece of malware that kind of establishes, you know, a foothold on this compromise workstation. So it begins out to see to server and starts downloading additional malware and it's going to bring back tools things that might potentially left to the attacker but it's a foothold on this on this workstation or within this network. So I would see all these HDD connections and I would see mentions in my files log so I could pivot from the HTTP log to the files log using that connection ID again and say hey what files are being transferred here specifically I'm looking for so Zeke has the ability to extract md5, And so these checks are things that again can be an indicator of compromise another IOC that I can use and go back and say what is this what you know maybe I don't know what the downloader is but I can kind of know what these other tools are and I can start to understand what the capabilities of this are. I can also look around my network and see what other machines have seen those those hashes and maybe there's other machines that are part of this compromise that I'm just now discovering now. But let's let's say I don't know I like being the worst case scenario person let's say that the attacker gets a foothold on that machine and starts deleting evidence which you know putting my open socket on for a second. It's been known to happen. So let's say the attacker goes in and starts to clean up after themselves and I'm like well great all the information on that endpoint now that the evidence is getting erased. Well remember I talked about Zeke having file extraction so I can pull out those files as they go across the wire save them to disk. And even if they get deleted you know zero eyes wiped whatever off that workstation I still have those binaries. So putting my worst case scenario head on again. If I say all right well the evidence has gone over there I still have these binaries that I can go back to and figure out exactly what they're capable of. If I have to escalate this and you know it's to 15 in the morning now and I have to call one of the senior members of my team to say yo this looks bad. You know I'm pretty sure this is an actual incident. Here are the things that I know so far I know the IP address that we're beginning out to I can tell you all the hosts that are talking to that host name of that IP address. I have some indicators that we can potentially write some IDS signatures for us we can catch this in the future. I have the show one and be five and shocked with six hatches that we can you know search the network and I can tell you what machines have this this malware associated with them so I figured out in the scope and I mean both in time and in the host associated with this. And if we have to bring in you know reverse engineers or you know malware analysis people they have those binaries they can start tearing through so even in the worst case scenario. I've got a lot of evidence here even without even without talking about anything on the end point at all. So I know I'd be labor this quite a bit but I think it's it's powerful to talk through kind of the question that you'll be asking yourself as you're going through something like an open sock exercise or a real world exercise. They're shockingly similar. And also to understand where you go in the Zeke data to add to understand those questions a little bit better. So there's many ways as I mentioned that the Zeke data can be represented. So here I have a screenshot of Plunk which is you know you can get a free version and type the data into Splunk and so sure that's a thing. You know, if there's one person we have a talk early run to run instead of the last several days using the elastic the Elk stack. You can feed this data into Kibana and look at it that way as well. But our tool of choice and open sock is going to be great log and so you should get comfortable with what this looks like in great log. So just start off with when you get access to the open sock environment and you go to great log you might look at end up looking at a screen like this that should you know we click on the screens. You're just going to get the stream of data. This is everything that's going across the network right now. It's a ton of data right. And so as you're looking through this. I want to talk to do a little bit about the great log interface but also will use it to kind of talk about what the Zeke data will look like. So to start off with you'll notice that I've typed a query into my great log window here that I am looking for Zeke data specifically I am asking great log to search for a field called event type. And I want you to tell me when that event type equals Zeke and so this is going to limit down the the events that are returned back to me as part of this. And so the other. Especially an open talk where like to be looking for an artifact. I can't find it. It's not here. I don't know where it is. It's because you probably have your search set to like the last five minutes. And if you're looking for something that happened several hours ago. Well yeah you're not going to see it. So I'm also going to turn down or turn up. I guess you could say my my search window to a larger window. Maybe I have a particular time span and I can input that. But right now I'm just kind of taking a casual stroll through the data. So with those things I'm just rolled down a little bit. And on the right hand side here you see the gray log events. And so these are Zeke events specifically. And you'll notice there's a lot of them. But each one of these is a Zeke log as a line in a Zeke log. It's giving me some information about communication that happened. And if I click on any given one of them you'll notice the event type is Zeke. That's why this was returned. And there's a lot of information here inside of this particular log entry. The first thing that you should look at the first thing I want to get familiar with is this file field. And so the file field tells me which type. In this particular case I'm looking at a MySQL log or my SQL log. So this is going to have information about a database transaction that occurred here. Now as you look down a little bit further you will see the message which is the line. This is that these are the individual fields of my SQL log. Now this one thing I'm going to come completely clean here. And some of the logs that you'll see, they're really parsed that cleanly. And so for something like this I have to kind of turn back to some of those cheat fees for that documentation to figure out like what does each field mean. Like I can see the first field of timestamp on the second field that starts with a C. That's my connection unique ID. So that's that's something I could pivot off of. I see some IP addresses and ports. I see my SQL query. Sometimes it's a little self explanatory, but refer to that documentation as needed. Let me give you another example here. So I'm scrolling down looking at another entry. Again, event type is Zeke that will be consistent. But instead now I'm looking at the con log. So this is that connection log. This is giving me information about a connection that occurred. I see the message down here that those fields, which will also notice all the fields have been broken out for me so I can see the connections date the destination IP. There's a building that tells me is that inside my network. And that's a Zeke variable that gets that I get to see, you know, the destination for the history field is actually a really interesting one. I don't have nearly enough time to dive into it, but it's really well documented and it tells you kind of the order of things that happened inside the communication. So there's a lot of things here and also you'll notice I could scroll down but I can also see it here in the message field that connection unique ID. So sure there's a connection here. All right. It's on port 80. Is it HTTP? Well, I see HTTP in my message there. And if I were to scroll down, I would see that as part of my service field. But I can look and search write a great log query to search for that connection unique ID and find all the information associated with this particular connection. So as we scroll down a little bit further. Oh, look, here's an HTTP log entry. And so this file here tells me I'm looking at the HTTP log. I get a little information from the client side. So it looks like this was a get request for the slash and kind of a group page. So I can see a little bit of information from the client. I can see a little bit of information from the server. So the server, if I assign it back to the 200, okay, which is perfectly normal. Right. But at least that's what I generally expect. And so all these fields again are broken out for me as I work my way through. One more log entry I want to talk about is the files log. So I mentioned that whenever we see a file transfer the example I use was HTTP but it actually works over SMB, SMTP, HTTP, FTP. I'm sure I'm forgetting many of them. But fundamentally if we can see a file transfer that's happening, we can pull that off the wire. And so you'll see an entry in your files log that gives you things like the mime type. So, oh, this looks like it was an mp4 video. I get those hashes, those checksum values, which in the case of a video, maybe that's interesting or not. If it wasn't a Word document, that might be a lot more interesting. That might be something that would be a very interesting indicator to key off of. In some cases you'll see the file name in this particular case. This was part of an HTTP connection that it just wasn't provided in a header. We just couldn't extract it for one reason or another. But if we do get the opportunity to pull a file name off the wire, we'll happily do that. And there's one thing that I didn't have an arrow to on the slide and that as you'll notice just under the file name is the file unique ID and so similar to the connection unique ID that starts with a C the file unique ID starts with an F and that tells me that this is associated with a file transfer. So, there's a lot of data, I'm just getting you the highlights and I promise you're going to see some of those in some open socks scenarios later, not that you know, I want to spoil too much. I'll put these URLs in the discord chat as well also posted a PDF of these slides so you'll have these, but these are the two resources I would seem just to get comfortable with the data so the thing on the left is the PDF I like it because it's searchable. The thing on the right is the documentation from read the docs that does a much better job of going into more depth and has more logs that didn't really make the cut on the cheat sheet. So, I only have a few minutes left and I want to talk very briefly about the seek community in by all rights this would be Amber here talking about as a community director she would talk authoritatively about this and there's so much this going on now and on the roadmap but fundamentally the things that you should know about is head to seek.org slash connect so seek.org is the seek website they've got a YouTube channel they've got a Twitter account that's constantly posting and retweeting new packages and things that are relevant to current vulnerabilities and that are being now blowing up Twitter. So seek started a slack organization slack channel which discord. I'm working on it but slack is is the home of a lot of these really great conversations that you can have alongside the seek developers, the package developers, and they're really approachable community. That said, because it is such that it has such a long history to it. There are also some very good mailing lists that you should join as well. On the bottom left you see there are a lot of in person events obviously not happening at the moment, but keep an eye out if you hear seek hours each days. These are kind of local organization so you can kind of come and hang out for a happy hour and meet people. In fact, you can you can kind of help Amber organize your own if this is something that you want to bring to your area. I'll give you your her contact information she'll be eager to talk to you. Zeke week is actually an annual event that we do so it's it's all these these conversations about seek package development, things from like how are, how are, you know, blue teamers using this to defend themselves, all the way down to like the lowest internals of the the Zeke ecosystem. There are also now a lot of virtual events that are happening so if you check out the seek that are excited the Zeke Slack, you'll hear about a lot of online events that are happening things that are. There's Zeke from home there's asked the Zeke spurts which is where they bring a lot of experts and you can just be like hey I'm trying to install Zeke at home and I'm getting this error and they'll happily walk you through it. Super super approachable community. And to that end, I would encourage you to contribute to that community so a lot of folks, especially approaching open source think well hey I'm getting started or hey, you know, yeah I'm working on this blue team thing and I'm figuring this out but like, I don't know anything about development or, you know, well, anything about you know what seems like it would be needed here, and I wanted to spell that because there's so much. There's a lot of deals that are required to make this work so yes, you might be thinking in code you might be saying well I you know I'm not a good coder. Well, okay, what about looking into the user community and contributing to as your and as you're installing this and you're saying hey this documentation, you know I was a little bit unclear or hey I tried to do this, and this documentation didn't work for me. Let me fire off something on the mailing list and and say hey I have some suggestions. Let me try, you know, make some proposals to the documentation. Maybe you want to try your hand at scripting scripting is actually pretty approachable and there's so much that you can do in the Zika language. Things that are just very simple that are going to help you in your day today versus like hey, there's a protocol I just want to tear into whatever that might be. Many years just saying hey, I, you know, I don't know anything about Zeke yet. Where could I start download it get the get some of the latest releases and and give us an okay and say yep we tested out it worked help us test releases and get that feedback so there's so much that you can do and it's so tempting to think of this as like, I'm at the bottom of this ladder and I and I don't have the skills that I need to climb it and amber has this awesome metaphor about think of this is a lattice think about kind of charting diagonally think about kind of charting your own path and building your own skill set as your as you're contributing back to the community this goes for so many communities but I think for Zeke is especially true. So, there are a couple links that I threw down earlier the the the link to the Zeke documentation so if you're interested in deploying the locally probably something I would recommend putting on till after open stock because you're going to have a busy weekend, but you've got the link there again I'll post these in the future. Security onion a lot of you know, as as kind of the Cali for blue team as it's a Linux distribution has all these tools built into them, including Zeke. And so if you're interested in just having kind of a live environment, I wouldn't recommend it for like, you know, a full production environment, but for just getting your, your, your, your feet wet and understanding how this works together with these other tools security union is a fantastic starting point. I mentioned the the PDF so I've got the link to the PDF there and oh by the way there's this event that's happening called open stock. If you haven't joined the open stock or the open stock discord yet there's a lot that's happening there it starts tomorrow, but you can you can swing on by you can get registered and set up. Check out the DC 28 open stock CTF in the blue team village discord for more information about that. So with that said, I think I am pretty darn close to time here. I want to leave you with my contact info, so to a core like calm ambers are a Zeke community director, an incredible resource and just just constantly has these amazing plans for the Z community and and and helping it grow. So, if you are interested at all there's also a security Twitter account that I mentioned, there's a Zeke channel in that open stock discord so if you're not going to play even if you're not going to play open stock come join the Zeke channel, and I have the conversation there. Keep an eye out for a lot of these online events as I mentioned Zeke from home asked the Zeke experts there's a lot more on the way that I'm sure Amber could rattle off. And we're also doing not quite as cool as open stock I'll admit, but some community CTFs to help you learn the the Zeke environment. So with that said, I know I am pretty darn close to time. Did we have any questions from the from the chat. I'm going to scroll and kind of take a quick look here but if you have any I'm actually happy to have a conversation with folks afterwards. As I know we are pretty darn close hearing people ask about you know how hard is it to set up. I encourage you if you if you