WEBVTT 00:14.720 --> 00:15.600 Outstanding. 00:15.780 --> 00:16.620 Apologies for that. 00:16.620 --> 00:17.980 So, my name is Aaron Seto. 00:17.980 --> 00:20.360 I am the Director of Learning at CoreLite. 00:20.360 --> 00:25.760 And today I'm going to be talking a little bit about the Zeek open source project in the light of OpenSoC. 00:25.760 --> 00:28.720 So, I've actually been part of the OpenSoC team for several years. 00:28.720 --> 00:32.540 Very excited to kind of talk about how these two projects are going to work together. 00:33.220 --> 00:38.400 Today's presentation was actually going to be a joint presentation with Amber, who is our Zeek Community Director. 00:38.400 --> 00:47.460 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. 00:47.640 --> 00:55.320 To kind of talk a little bit about... hold on, let me get my... I see that is going to be... 00:55.320 --> 00:57.680 I do not blame Discord right now. 00:57.680 --> 00:59.880 It just had the rug pulled out from under it. 00:59.880 --> 01:01.340 So, let me switch over to this. 01:01.740 --> 01:03.540 So, I'm going to talk a little bit about Zeek. 01:03.540 --> 01:04.460 What is Zeek? 01:04.460 --> 01:17.440 It's an open source framework that is used for network security monitoring, basically looking at network traffic. 01:17.440 --> 01:20.300 And you might have heard of Zeek as BRO. 01:20.300 --> 01:23.160 So, this was back in 1995. 01:23.160 --> 01:26.040 BRO started at Lawrence Berkeley National Labs. 01:26.040 --> 01:36.280 And there were a number of people who were looking into this problem space, and were thinking not even in a security context, but just looking at network traffic at large. 01:36.520 --> 01:51.080 And the name BRO 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. 01:51.080 --> 02:04.200 But if you've heard of BRO or if you've heard of Zeek, it was probably as part of a research center university government, even potentially for like network forensics and network operations. 02:04.200 --> 02:08.880 There's actually some vendors, though I mentioned I'm employed by Corlite. 02:08.880 --> 02:14.640 There are a number of vendors who actually have Zeek integrated in with their platform and use it. 02:14.660 --> 02:18.200 So, if you've heard of it before, that's probably why. 02:18.600 --> 02:22.120 Zeek itself is actually very customizable, very extensible. 02:22.120 --> 02:24.380 It's really kind of its own language. 02:24.380 --> 02:36.160 And there's a lot that you can do with Zeek in terms of just having scripts and plugins and protocol analyzers and kind of these components that work together to analyze your network traffic. 02:36.200 --> 02:38.840 So, there's the Zeek package manager. 02:38.840 --> 02:43.340 If you go to packages.zeek.org, you can see all of these packages that the community has contributed. 02:43.340 --> 02:46.480 But you also, because it's open source, you can write your own. 02:46.480 --> 02:50.180 And so, there's actually a try.zeek.org environment where you can play around with that. 02:50.180 --> 02:52.200 And I'm not going to dive into that too much right now. 02:52.200 --> 02:53.940 I just want you to know that it's out there. 02:55.440 --> 02:57.940 So, what is the data? 02:57.940 --> 03:00.120 Like, the Zeek data is really where the power is. 03:00.120 --> 03:02.240 And I want to talk about what that looks like. 03:02.240 --> 03:07.500 So, I'm going to use three examples here, three logs to kind of start that conversation. 03:07.500 --> 03:09.280 On the left is the con log. 03:09.280 --> 03:11.820 So, that's the connection log. 03:11.820 --> 03:19.820 If 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. 03:19.820 --> 03:22.200 Every single connection will appear in the con log. 03:22.200 --> 03:25.340 But then there's these other logs that are more protocol-specific. 03:25.340 --> 03:27.240 So, let's say I have HTTP data. 03:27.240 --> 03:30.440 Like, I have a web browser talking to a web server. 03:30.600 --> 03:33.980 I'm going to see all of the metadata associated with that connection. 03:33.980 --> 03:37.040 So, things like what was the user agent string that was sent? 03:37.040 --> 03:39.880 What's the URI that was requested if you're talking about the client side? 03:39.880 --> 03:42.720 From the server side, like what was the MIME type that was returned? 03:42.720 --> 03:43.460 How many bytes? 03:43.460 --> 03:44.880 What was the status code? 03:44.880 --> 03:47.640 All of those things we see in our HTTP log. 03:47.660 --> 03:54.760 Similarly, if we're talking about other protocols, let's say like DNS, I can see the DNS, like the client and the server. 03:54.760 --> 04:00.920 I can also see the queries and the answers, the responses, which is surprisingly difficult to dig into sometimes. 04:00.920 --> 04:02.620 We'll talk about that more in a second. 04:03.000 --> 04:13.800 Now, realistically, there are only a few logs that you're really focused on in a given environment, in a given exercise, and frankly, even in OpenSoft. 04:13.920 --> 04:20.520 But, there are probably pushing four dozen logs in total now in the ZEKE OpenSource project. 04:20.520 --> 04:30.960 So, there's a log for pretty much any protocol you can think of, and all that metadata, that rich metadata from that protocol, is stored in that log for whatever purpose that you might need. 04:30.960 --> 04:32.980 I've got a couple links down at the bottom, too. 04:33.280 --> 04:34.900 CoreLite has a little PDF cheat sheet. 04:34.900 --> 04:36.640 I'll have that link for you in a second, too. 04:37.220 --> 04:43.780 And the ZEKE OpenSource project has really good detailed documentation about logs and even some things that didn't make the cheat sheet. 04:43.840 --> 04:48.700 That's actually where I stole these graphics from, was from the CoreLite cheat sheet, because it's a little more colorful. 04:49.900 --> 04:56.660 So, to really talk about how we use ZEKE, let me start off by kind of comparing a little bit. 04:56.660 --> 05:03.660 So , we need to see if things are actually fine, or if maybe things are fine, or if things are actually not true, then we get something from tools like Wireshark and gpdump. 05:03.740 --> 05:09.000 Or, in the middle, we have intrusion detection systems, intrusion prevention systems. 05:09.000 --> 05:21.540 So, things like Snort and Suricata, things that we'll find as we kind of work our way through just kind of looking at this kind of signature-based detection. 05:21.700 --> 05:23.700 And then, on the far right, we have NetFlow. 05:23.700 --> 05:29.900 We have the IP addresses, ports, protocols, timestamps, that kind of high-level information. 05:29.900 --> 05:38.020 These are three very common tools, which we'll see as you're kind of getting familiar, as you're probably already familiar with. 05:38.020 --> 05:41.320 But, let's use those to kind of compare ZEKE. 05:41.320 --> 05:46.580 To start off with, ZEKE is really fundamentally different from something like NetFlow. 05:46.580 --> 05:49.680 Well, it's fundamentally different from all of these, but let's start with NetFlow. 05:49.880 --> 06:03.800 So, NetFlow is giving us just that IP address, port, protocol, timestamp, just that generic info, versus something like ZEKE is going to be able to understand protocols at a much deeper level. 06:03.800 --> 06:09.820 So, it understands how something like HTTP works, and it can pull out all that metadata. 06:09.820 --> 06:14.420 It can even see things like files being sent over HTTP and extract those files out. 06:14.420 --> 06:18.000 So, we're not saving everything, we're saving the most useful tidbits. 06:18.540 --> 06:23.120 And really, when you're thinking of ZEKE, I don't want to talk about how it compares to some of these tools. 06:23.120 --> 06:26.240 I want to say, like, throw away your IDS, throw away NetFlow. 06:26.240 --> 06:27.520 What should be useful? 06:27.840 --> 06:30.540 Deploy ZEKE in parallel with these tools. 06:30.540 --> 06:42.560 And especially if you have something like full packet capture, then you can go ahead and use ZEKE to help find where the most interesting pieces of that full packet capture, that data resides. 06:43.460 --> 06:47.460 Now, comparing ZEKE to an IDS is something that's very commonly done. 06:47.460 --> 06:53.140 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. 06:53.140 --> 06:55.920 It's here to say, this is what's happening in the network right now. 06:59.180 --> 07:07.720 So if something goes south, it's because I need to respond to that, or at least I need to investigate it to look at it. 07:07.740 --> 07:14.580 But ZEKE is here logging everything that's going on and giving us the control to say, is this good or is this bad? 07:15.280 --> 07:18.800 Now, as I mentioned before, ZEKE is very expandable, very extensible. 07:18.820 --> 07:21.740 And so there's a lot of things that we can add on to ZEKE. 07:21.740 --> 07:25.540 We can kind of do things like, hey, if you see these kinds of anomalies, let me know. 07:25.540 --> 07:32.700 Because ZEKE understands protocols at such a low level, it can do things like say, hey, this looks like protocol abuse. 07:32.700 --> 07:37.880 This looks like a situation because I totally understand how this protocol should work. 07:37.880 --> 07:41.200 And this is not conforming to that standard. 07:41.220 --> 07:44.100 I'm going to go ahead and write a notice log. 07:44.100 --> 07:45.940 I'm going to go ahead and write something to the weird log. 07:45.940 --> 07:48.200 And we'll talk about some of those logs a little bit more in a second. 07:48.200 --> 07:50.560 But there's a lot of things that we can do with this. 07:50.920 --> 08:03.540 So when I'm talking about ZEKE data, what I'm really talking about is the representation of network traffic, of what you're seeing on your network as it's represented in ZEKE data. 08:03.540 --> 08:06.040 Now, there's a couple ways you can get those logs out. 08:06.040 --> 08:08.000 You can look at the raw ZEKE logs. 08:08.000 --> 08:10.620 And we'll kind of see a little bit of that today. 08:10.700 --> 08:27.820 But as you normally use in an enterprise, and as you'll use in OpenSOC, that data is being forwarded to a SIEM where you can interact with that and get the context of all the other host-based data and everything else that's coming into that SIEM environment. 08:27.940 --> 08:36.000 So in case you haven't guessed already, our SIEM of choice for OpenSOC, if you were watching the workshop earlier, is Greylog. 08:36.000 --> 08:38.620 And so we'll talk about what this looks like in Greylog. 08:38.880 --> 08:47.700 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. 08:47.700 --> 08:51.020 So remember I said we have a CON log and an HTTP log. 08:51.300 --> 09:09.580 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. 09:09.580 --> 09:12.400 Now, the question becomes, how do I kind of pivot? 09:12.400 --> 09:16.180 I see something in my CON log, and I know there's HTTP in there. 09:16.180 --> 09:19.540 How do I go find the matching thing in my HTTP log? 09:19.920 --> 09:24.760 So the way you're going to do that is with what's called the UID, or the connection unique ID. 09:24.760 --> 09:30.640 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. 09:30.640 --> 09:36.880 So if I have a connection, let's say, that uses HTTP, and let's say it transfers a file. 09:36.880 --> 09:46.360 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. 09:46.360 --> 09:51.160 On the topic of file transfers, there's another type of unique ID called the file unique ID. 09:51.160 --> 10:05.880 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. 10:06.660 --> 10:10.860 So, all right, I've done a lot of the explanation. 10:10.860 --> 10:14.260 I want to dive into one pretty thorough use case. 10:14.260 --> 10:15.500 And I want to do this for two reasons. 10:15.500 --> 10:19.820 One, I want to get you in the mindset of how an incident responder thinks. 10:19.820 --> 10:21.720 And for some of us, that's not a stretch. 10:21.720 --> 10:23.480 And for some of us, that might be a little new. 10:23.560 --> 10:30.860 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. 10:30.860 --> 10:37.560 And so let's say I'm fresh out of college or fresh out of another career field I'm pivoting. 10:37.560 --> 10:40.680 And I just joined this team. 10:40.680 --> 10:42.400 I'm a SOC analyst. 10:42.400 --> 10:43.680 I'm entry level. 10:43.720 --> 10:49.880 And as is tradition, I am awarded the honor of the night shift. 10:49.880 --> 10:52.740 And I'm sitting here, and I'm watching alerts roll in. 10:52.740 --> 10:55.500 And it's my job to kind of triage these alerts. 10:55.500 --> 11:11.340 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, or I have something in my playbook that I know how to resolve this myself. 11:11.580 --> 11:15.340 Is it maybe instead something that I can dismiss? 11:15.340 --> 11:18.580 I can say, well, this is a false positive, or this is not actionable. 11:18.680 --> 11:20.000 Okay, somebody's port scanning. 11:20.000 --> 11:20.880 Doesn't matter. 11:20.880 --> 11:22.700 I can't really do anything about it. 11:22.700 --> 11:27.300 Or in the third case, do I need to escalate this? 11:27.300 --> 11:37.680 Do I need to bring this to someone, a senior member of our team, who can then spend a little bit more time looking at this, or maybe has the expertise to work through this? 11:38.060 --> 11:40.040 And so it's 2 a.m. 11:40.040 --> 11:40.780 I'm sitting here. 11:40.780 --> 11:42.000 I'm watching these alerts roll in. 11:42.000 --> 11:43.680 I'm trying to figure out, can I deal with this? 11:43.680 --> 11:45.820 Can I deal with this myself? 11:45.820 --> 11:46.860 Can I dismiss this? 11:46.860 --> 11:48.460 Do I need to escalate this? 11:48.460 --> 11:52.060 And an alert comes in from our Intrusion Detection System. 11:52.060 --> 11:58.980 And it says, hey, I saw a DNS request leaving the network, and the host name in that DNS request matched the signature. 11:58.980 --> 12:02.140 So the IDS raised an alert to say, I know that. 12:02.140 --> 12:07.000 I have a signature that says that's associated with a known command and control server, a C2 server. 12:07.000 --> 12:08.400 So what am I going to do? 12:08.400 --> 12:10.060 Can I deal with this myself? 12:10.060 --> 12:11.200 Can I dismiss this? 12:11.200 --> 12:12.420 Do I need to escalate this? 12:12.420 --> 12:17.640 And if I just have this data to look at this, I might start off in my DNS log. 12:17.640 --> 12:22.220 So I mentioned there's a log for DNS, and this is a DNS-related alert. 12:22.220 --> 12:30.520 Let me turn to my DNS log, and I'm going to see the workstation or stations, potentially, that have tried to reach out and look up that host name. 12:30.520 --> 12:34.280 The DNS servers that responded to that, which maybe is something internal. 12:34.280 --> 12:39.980 Maybe it's an external DNS server, depending on how I can block that from leaving my network. 12:39.980 --> 12:45.800 I see the query itself, which in theory my IDS already told me, so it's not really that big of a deal. 12:45.800 --> 12:48.740 But the big one here is the answer field. 12:48.740 --> 12:50.080 It's literally called answer. 12:50.080 --> 12:54.520 There's a field in your DNS log, and it is the response that was provided to the client. 12:54.520 --> 12:58.540 So in this case, I know the client queried for this host name. 12:58.540 --> 13:00.880 I want to know what IP address they got back. 13:00.880 --> 13:09.000 A lot of times, even with good DNS logging setup, if you have your DNS server set up to forward logs, a lot of times they won't give you that last piece. 13:09.000 --> 13:11.260 They won't give you the answer, the IP address. 13:11.260 --> 13:16.100 And I need that, because I need to pivot from my DNS log to my con log. 13:16.100 --> 13:28.500 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? 13:28.620 --> 13:34.080 Maybe I had an intrusion prevention system that stopped it. 13:34.080 --> 13:40.120 Maybe I got lucky and the attacker's infrastructure was down, and I just dodged that bullet. 13:40.120 --> 13:42.200 But I want to know if there was a connection. 13:42.200 --> 13:43.240 I want to know more about it. 13:43.240 --> 13:45.400 And let's say for the sake of this example, there was. 13:45.400 --> 13:46.680 There was a connection. 13:47.260 --> 13:54.860 And so I can pivot from my DNS log to my con log, look for connections to that IP address, say that there were connections. 13:54.860 --> 13:56.280 I want to see what ports they're on. 13:56.280 --> 13:57.040 When did they happen? 13:57.040 --> 13:58.280 Are they still happening? 13:58.280 --> 14:00.620 How many bytes were sent either way? 14:00.940 --> 14:05.600 And ports in particular is interesting, because I want to know a little bit more about this communication. 14:05.600 --> 14:11.860 Let's say for the sake of this example that the communication to that server was on port 80. 14:12.040 --> 14:15.000 Well, the more veterans of you might say, port 80 is obviously HTTP. 14:15.000 --> 14:15.900 I know that. 14:16.020 --> 14:19.960 But hang on, put your attacker hat on for a second and think about this. 14:20.020 --> 14:24.560 An attacker doesn't have to use the port for its intended purpose. 14:24.560 --> 14:28.120 So just because they're on port 80 doesn't mean they're using HTTP. 14:28.320 --> 14:34.120 But one of the cool things Zeke does is it has what's called dynamic protocol detection, DPD. 14:34.120 --> 14:41.380 So I'll see in my con log a field called service that tells me the protocols identified. 14:41.380 --> 14:45.700 Zeke knows, regardless of what port it's on, what's going on inside that connection. 14:45.700 --> 14:48.320 And so it'll say, yep, I know there's HTTP inside of here. 14:48.320 --> 14:49.860 I don't care that it's on port 80. 14:49.860 --> 14:54.100 I mean, obviously, that wouldn't be what we would expect. 14:54.260 --> 14:57.980 But Zeke tells me certainly this has HTTP traffic. 14:57.980 --> 15:03.020 So I'm going to pivot now from my con log to my HTTP log to get more information. 15:03.020 --> 15:06.040 And how do I pivot between those two logs? 15:06.480 --> 15:09.620 The connection unique identifier, that UID field. 15:09.620 --> 15:14.520 Remember, that appears in every single log that has information about this connection. 15:14.520 --> 15:21.880 So I'm going to look to that UID field and look to see if I have a matching entry in my HTTP log. 15:21.880 --> 15:25.980 And in there, I'm going to see things that relate to this connection. 15:25.980 --> 15:29.160 Things like user agent strings and cookie values, get push parameters. 15:29.160 --> 15:33.220 Things that the browser sends as part of that request. 15:33.220 --> 15:34.980 And also I get some response information. 15:34.980 --> 15:42.120 And these are things that you'll hear the term indicator, or an IOC, or an indicator of compromise. 15:42.120 --> 15:46.920 These are things that might help us figure out exactly what this is, what malware strain we're dealing with. 15:46.920 --> 15:54.960 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? 15:54.960 --> 15:57.720 Does anybody recognize this string that looks a little bit weird? 15:57.720 --> 16:00.720 Do I know what malware that's associated with? 16:01.840 --> 16:05.060 And so, if so, I might be able to handle this myself. 16:05.060 --> 16:06.840 I might say, all right, cool. 16:07.320 --> 16:09.900 This is an incident that I know how to resolve. 16:09.900 --> 16:13.020 I'm going to go ahead and quarantine, you know, kick that machine off the network. 16:13.260 --> 16:14.620 I'll contact the user. 16:14.620 --> 16:19.460 We'll start an IT ticket, get it re-imaged, and probably reset the user's password. 16:20.040 --> 16:22.120 But, okay, I can handle it, right? 16:22.860 --> 16:25.620 But, I like being the worst-case scenario person. 16:25.620 --> 16:28.920 What happens if I don't know how to deal with this? 16:28.920 --> 16:35.360 What happens if I don't have any indicators that I can pull up and say I know what malware strain this is? 16:35.380 --> 16:39.220 Let's say, for the sake of this example, that this is a downloader. 16:39.220 --> 16:48.580 This is a piece of malware that kind of establishes a foothold on this compromised workstation and then beacons out to a C2 server and starts downloading additional malware. 16:48.580 --> 16:59.420 It's going to bring back tools, things that might potentially let the attacker find a foothold on this workstation or within this network. 16:59.420 --> 17:13.820 So, in that case, I would see all these HTTP 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? 17:13.820 --> 17:20.500 Specifically, I'm looking for... so Zeke has the ability to extract MD5, SHA-1, and SHA-256 checksum. 17:20.580 --> 17:24.420 And so these checksums are things that, again, can be an indicator of compromise. 17:24.420 --> 17:27.080 Another IOC that I can use and go back and say, what is this? 17:27.460 --> 17:33.280 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. 17:33.280 --> 17:43.320 I can also look around my network and see what other machines have seen those hashes and maybe there's other machines that are part of this compromise that I'm just now discovering now. 17:45.660 --> 17:49.560 But let's say... I don't know, I like being the worst case scenario person. 17:49.560 --> 17:59.400 Let's say that the attacker gets a foothold on that machine and starts deleting evidence, which, you know, putting my open-sock hat on for a second, it's been known to happen. 17:59.400 --> 18:02.640 So let's say the attacker goes in and starts to clean up after themselves. 18:02.640 --> 18:08.280 And I'm like, well, great, all the information on that endpoint now that the evidence is getting erased. 18:08.280 --> 18:11.780 Well, remember I talked about Zeke having file extraction. 18:11.780 --> 18:23.180 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-wise, wiped, whatever, off that workstation, I still have those binaries. 18:23.180 --> 18:32.680 So putting my worst case scenario hat 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. 18:32.680 --> 18:41.580 If I have to escalate this and, you know, it's 2.15 in the morning now, and I have to call one of the senior members of my team to say, yo, this looks bad. 18:41.780 --> 18:44.020 You know, I'm pretty sure this is an actual incident. 18:44.340 --> 18:46.200 Here are the things that I know so far. 18:46.200 --> 18:47.800 I know the IP address that we're getting out to. 18:47.800 --> 18:51.700 I can tell you all the hosts that are talking to that host name or that IP address. 18:51.800 --> 18:56.940 I have some indicators that we can potentially write some IDS signatures for so we can catch this in the future. 18:57.020 --> 19:05.400 I have these SHA-1, MB5, and SHA-26 hashes that we can, you know, search the network, and I can tell you what machines have this malware associated with them. 19:05.400 --> 19:10.720 So I figured out the scope, and I mean both in time and in the hosts associated with this. 19:11.000 --> 19:20.640 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. 19:20.640 --> 19:27.960 So even in the worst case scenario, I've got a lot of evidence here, even without talking about anything on the endpoint at all. 19:28.180 --> 19:39.780 So I know I belabor this quite a bit, but I think it's powerful to talk through kind of the questions that you'll be asking yourself as you're going through something like an open-socket exercise or a real-world exercise. 19:39.780 --> 19:41.100 They're shockingly similar. 19:41.920 --> 19:47.960 And also to understand where you go in the ZEKE data to understand those questions a little bit better. 19:48.000 --> 19:52.000 So there's many ways, as I mentioned, that this ZEKE data can be represented. 19:52.000 --> 19:57.540 So here I have a screenshot of Splunk, which is, you know, you can get a free version and pipe the data into Splunk. 19:57.540 --> 20:01.200 And so, sure, that's a thing, you know, if you're a Splunk person. 20:01.200 --> 20:03.500 We had a talk earlier on Kibana. 20:03.500 --> 20:12.160 Instead of asking if you're using the Elastic, the Elk stack, you can feed this data into Kibana and look at it that way as well. 20:12.400 --> 20:16.200 But our tool of choice in open-socket is going to be Greylock. 20:16.320 --> 20:20.560 And so you should get comfortable with what this looks like in Greylock. 20:20.560 --> 20:28.400 So to start off with, when you get access to the open-socket environment and you go to Greylock, you might end up looking at a screen like this. 20:28.400 --> 20:32.100 When you click on the screens, you're just going to get the stream of data. 20:32.100 --> 20:34.340 This is everything that's going across the network right now. 20:34.340 --> 20:35.840 It's a ton of data, right? 20:36.260 --> 20:45.520 And so as you're looking through this, I want to talk to you a little bit about the Greylock interface, but also we'll use it to kind of talk about what the ZEKE data will look like. 20:45.520 --> 20:53.140 So to start off with, you'll notice that I've typed a query into my Greylock window here that I am looking for ZEKE data. 20:53.140 --> 21:02.160 Specifically, I am asking Greylock to search for a field called event type, and I want you to tell me when that event type equals ZEKE. 21:02.160 --> 21:10.380 And so this is going to limit down the events that are returned back to me as part of this UI. 21:10.580 --> 21:19.580 And so this is a gotcha that you'll find again and again, especially in open-socket, where you'll be looking for an artifact and you're like, I can't find it, it's not here, I don't know where it is. 21:19.580 --> 21:28.280 It's because you probably have your search set to 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. 21:28.280 --> 21:34.980 So I'm also going to go ahead and turn down, or turn up, I guess you could say, my search window to a larger window. 21:34.980 --> 21:41.440 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. 21:41.540 --> 21:48.000 So with those things, I'm going to scroll down a little bit, and on the right-hand side here, you see the Greylock events. 21:48.000 --> 22:01.420 And so these are Zeek events, specifically, and you'll notice there's a lot of them, but each one of these is a Zeek log, a line in a Zeek log that's giving me some information about communication that happened. 22:01.420 --> 22:05.760 And if I click on any given one of them, you'll notice the event type is Zeek, that's why this was returned. 22:05.760 --> 22:10.080 And there's a lot of information here inside this particular log entry. 22:10.080 --> 22:16.500 The first thing that you should look at, the first thing I want you to get familiar with, is this file field. 22:16.500 --> 22:19.620 And the file field tells me which type of log is this. 22:19.620 --> 22:23.700 In this particular case, I'm looking at a MySQL log or a MySQL log. 22:23.700 --> 22:27.780 So this is going to have information about a database transaction that occurred here. 22:27.780 --> 22:31.720 Now, if you look down a little bit further, you will see the message, which is the line. 22:31.860 --> 22:35.520 These are the individual fields of the MySQL log. 22:35.520 --> 22:43.860 Now, there's 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. 22:43.860 --> 22:50.100 So for something like this, I have to kind of turn back to some of those cheat feeds for that documentation to figure out, like, what does each field mean? 22:50.100 --> 22:57.460 Like, I can see the first field is a timestamp, and the second field that starts with a C, that's my connection unique ID, so that's something I can pivot off of. 22:57.460 --> 23:00.440 I see some IP addresses, some ports, I see a MySQL query. 23:00.440 --> 23:05.260 Sometimes it's a little self-explanatory, but refer to that documentation as needed. 23:05.260 --> 23:06.880 Let me give you another example here. 23:06.880 --> 23:08.820 So I'm scrolling down, looking at another entry. 23:08.820 --> 23:11.980 Again, event type is Zeke, that'll be consistent. 23:11.980 --> 23:16.280 But instead now, I'm looking at the con log, so this is that connection log. 23:16.280 --> 23:19.580 This is giving me information about a connection that occurred. 23:19.860 --> 23:25.440 And I see the message down here that those fields, which you'll also notice, all the fields have been broken out for me. 23:25.440 --> 23:28.280 So I can see the connection state, the destination IP. 23:28.320 --> 23:31.120 There's a Boolean that tells me, is that inside my network? 23:31.140 --> 23:33.400 And that's a Zeke variable that gets set. 23:33.400 --> 23:35.560 I get to see, you know, the destination port. 23:35.560 --> 23:38.200 The history field is actually a really interesting one. 23:38.200 --> 23:41.640 I don't have nearly enough time to dive into it, but it's really well documented. 23:41.640 --> 23:46.560 And it tells you kind of the order of things that happened inside the communication. 23:46.680 --> 23:48.000 So there's a lot of things here. 23:48.000 --> 23:53.740 And also, you'll notice, I could scroll down, but I can also see it here in the message field, that connection unique ID. 23:53.900 --> 23:55.980 So, sure, there's a connection here. 23:55.980 --> 23:57.860 All right, it's on port 80. 23:57.860 --> 23:59.180 Is it HTTP? 23:59.180 --> 24:01.180 Well, I see HTTP in my message there. 24:01.180 --> 24:04.260 And if I were to scroll down, I would see that as part of my service field. 24:04.260 --> 24:13.380 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. 24:13.700 --> 24:15.760 So as we scroll down a little bit further... 24:15.760 --> 24:18.300 Oh, look, here's an HTTP log entry. 24:18.360 --> 24:21.940 And so this file here tells me I'm looking at the HTTP log. 24:21.940 --> 24:24.240 I get a little information from the client side. 24:24.240 --> 24:28.700 So it looks like this was a GET request for the slash link on the root page. 24:28.720 --> 24:30.940 So I can see a little bit of information from the client. 24:30.940 --> 24:33.140 I can see a little bit of information from the server. 24:33.140 --> 24:36.840 I respond back with a 200 OK, which is perfectly normal. 24:36.840 --> 24:37.280 Right . 24:37.660 --> 24:40.380 At least that's what I would generally expect. 24:40.380 --> 24:43.900 And so all these fields, again, are broken out for me as I work my way through. 24:43.900 --> 24:47.680 One more log entry I want to talk about is the files log. 24:47.680 --> 24:52.200 So I mentioned that whenever we see a file transfer, the example I used was HTTP. 24:52.200 --> 24:57.640 But it actually works over SMB, SMTP, HTTP, FTP. 24:58.300 --> 25:00.380 I'm sure I'm forgetting many of them. 25:00.380 --> 25:05.180 But fundamentally, if we can see a file transfer that's happening, we can pull that off the wire. 25:05.320 --> 25:10.560 And so you'll see an entry in your files log that gives you things like the LIME type. 25:10.560 --> 25:13.520 So, oh, this looks like it was an MP4 video. 25:13.540 --> 25:17.600 I get those hashes, those checksum values, which in the case of a video... 25:17.600 --> 25:19.160 Maybe that's interesting or not. 25:19.300 --> 25:21.840 Or a document, that might be a lot more interesting. 25:21.840 --> 25:25.580 That might be something that would be a very interesting indicator to key off of. 25:25.980 --> 25:28.300 In some cases, you'll see the file name. 25:28.300 --> 25:32.460 In this particular case, this was part of an HTTP connection that just wasn't provided in a header. 25:32.460 --> 25:34.920 We just couldn't extract it for one reason or another. 25:35.060 --> 25:39.060 But if we do get the opportunity to pull a file name off the wire, we'll happily do that. 25:39.300 --> 25:41.760 There's one thing that I didn't have an arrow to on the slide. 25:41.760 --> 25:45.360 And that, as you'll notice just under the file name, is the file unique ID. 25:45.360 --> 25:50.820 And so similar to the connection unique ID that starts with a C, the file unique ID starts with an F. 25:50.820 --> 25:54.380 And that tells me that this is associated with a file transfer. 25:55.080 --> 25:56.700 So there's a lot of data. 25:56.700 --> 26:03.040 I'm just giving you the highlights, and I promise you're going to see some of those in some OpenSock scenarios later. 26:03.040 --> 26:05.820 Not that, you know, I don't want to spoil too much. 26:06.160 --> 26:09.480 I'll put these URLs in the Discord chat as well. 26:09.480 --> 26:12.640 I'll also post a PDF of these slides, so you'll have these. 26:12.720 --> 26:16.880 But these are the two resources I would suggest to get comfortable with Zik data. 26:16.880 --> 26:18.600 So the thing on the left is the PDF. 26:18.600 --> 26:19.960 I like it because it's searchable. 26:19.960 --> 26:29.560 The thing on the right is the Zik 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. 26:29.980 --> 26:35.600 So I only have a few minutes left, and I want to talk very briefly about the Zik community. 26:35.720 --> 26:42.260 And by all rights, this would be Amber here talking about, as a community director, she would talk authoritatively about this. 26:42.260 --> 26:47.120 And there's so much that's going on now and on the roadmap. 26:47.120 --> 26:52.100 Fundamentally, the things that you should know about is head to Zik.org slash connect. 26:52.100 --> 26:53.820 So Zik.org is the Zik website. 26:53.820 --> 26:54.700 They've got a YouTube channel. 26:54.700 --> 27:07.160 They've got a Twitter account that's constantly posting and retweeting new packages and things that are relevant to current vulnerabilities that are blowing up Twitter. 27:07.360 --> 27:13.660 Zik started a Slack organization, a Slack channel, which Discord... I'm working on it. 27:14.240 --> 27:24.820 Slack is the home of a lot of these really great conversations that you can have alongside the Zik developers, the package developers, and they're a really approachable community. 27:24.820 --> 27:33.020 That said, because it has such a long history to it, there are also some very good mailing lists that you should join as well. 27:33.200 --> 27:37.860 On the bottom left, you see there are a lot of in-person events, obviously not happening at the moment. 27:37.860 --> 27:40.760 But keep an eye out if you hear Zik Hour, Zik Days. 27:40.940 --> 27:48.460 These are kind of local organizations, so you can kind of come and hang out for a happy hour and meet people. 27:48.580 --> 27:53.320 In fact, you can kind of help Amber organize your own if this is something that you want to bring to your area. 27:53.380 --> 27:55.180 I'll give you her contact information. 27:55.180 --> 27:56.980 She'll be eager to talk to you. 27:57.100 --> 28:03.000 Zik Week is actually an annual event that we do, so it's all these conversations about Zik package development. 28:03.000 --> 28:15.200 Things from like, how are Blue Teamers using this to defend themselves, all the way down to like the lowest internals of the Zik ecosystem. 28:15.540 --> 28:19.380 There are also now a lot of virtual events that are happening. 28:19.380 --> 28:26.400 So if you check out the Zik.org site or the Zik Slack, you'll hear about a lot of online events that are happening. 28:27.560 --> 28:37.840 There's Zik from Home, there's Ask the Zik-sperts, which is where they bring in a lot of experts, and you can just be like, hey, I'm trying to install Zik at home, and I'm hitting this error, and they'll happily walk you through it. 28:38.180 --> 28:40.240 Super, super approachable community. 28:40.800 --> 28:44.300 And to that end, I would encourage you to contribute to that community. 28:44.300 --> 29:01.060 So a lot of folks, especially approaching open source, think, well, hey, I'm just getting started, or hey, you know, yeah, I'm working on this Blue Team thing, and I'm figuring this out, but I don't know anything about development or, well, anything about what seems like it would be needed here. 29:01.060 --> 29:07.620 And I want to dispel that, because there's so many skills that are required to make this work. 29:07.620 --> 29:10.220 So yes, you might be thinking in code. 29:10.220 --> 29:13.240 You might be saying, well, I'm not a good coder. 29:13.240 --> 29:23.740 Well, okay, what about looking into the user community and contributing to, as you're installing this, and you're saying, hey, this documentation, you know, is a little bit unclear. 29:23.740 --> 29:26.900 Or, hey, I tried to do this, and this documentation didn't work for me. 29:26.900 --> 29:31.580 Let me fire off something on the mailing list and say, hey, I have some suggestions. 29:31.800 --> 29:35.680 How do I, you know, make some proposals to the documentation? 29:35.920 --> 29:37.680 Maybe you want to try your hand at scripting. 29:37.680 --> 29:41.920 Scripting is actually pretty approachable, and there's so much that you can do in the Zika language. 29:42.080 --> 29:52.740 Things that are just very simple that are going to help you in your day-to-day, versus like, hey, there's a protocol I just want to tear into, whatever that might be. 29:52.920 --> 29:57.940 Maybe you're just saying, hey, you know, I don't know anything about Zika yet. 29:58.140 --> 29:59.460 Where could I start? 29:59.540 --> 30:00.360 Download it. 30:00.360 --> 30:04.720 Get some of the latest releases and give us an okay and say, yep, we tested it out. 30:04.720 --> 30:05.120 It worked. 30:05.120 --> 30:08.240 Help us test releases and get that feedback. 30:08.240 --> 30:17.240 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 don't have the skills that I need to climb it. 30:17.280 --> 30:21.200 And Amber has this awesome metaphor about, think of this as a lattice. 30:21.200 --> 30:23.660 Think about kind of moving diagonally. 30:23.660 --> 30:29.980 Think about kind of charting your own path and building your own skill set as you're contributing back to the community. 30:29.980 --> 30:34.280 This goes for so many communities, but I think for Zika, it's especially true. 30:34.620 --> 30:41.760 So there are a couple links that I threw down earlier, the link to the Zika documentation. 30:41.760 --> 30:48.220 So if you're interested in deploying Zika locally, probably something I would recommend putting on until after OpenStock, because you're going to have a busy weekend. 30:48.460 --> 30:50.040 But you've got the link there. 30:50.040 --> 30:51.700 Again, I'll post these in the Discord. 30:51.720 --> 31:00.180 Security Onion, a lot of you know, as kind of the Cali for blue team, it's a Linux distribution that has all of these tools built into them, including Zika. 31:00.180 --> 31:14.920 And so if you're interested in just having kind of a live environment, I wouldn't recommend it for like a full production environment, but for just getting your feet wet and understanding how this works together with these other tools, Security Onion is a fantastic starting point. 31:14.920 --> 31:18.660 I mentioned that PDF, so I've got the link to the PDF there. 31:18.660 --> 31:21.720 And oh, by the way, there's this event that's happening called OpenStock. 31:21.860 --> 31:26.420 If you haven't joined the OpenStock Discord yet, there's a lot that's happening there. 31:26.420 --> 31:30.840 It starts tomorrow, but you can swing on by, you can get registered and set up. 31:30.840 --> 31:37.540 Check out the DC28 OpenStock CTF in the Blue Team Village Discord for more information about that. 31:37.960 --> 31:42.180 So with that said, I think I am pretty darn close to time here. 31:42.180 --> 31:45.480 I want to leave you with my contact info, Aaron Soto at Corelite.com. 31:45.480 --> 31:57.760 Amber is our Zika Community Director, an incredible resource, and just constantly has these amazing plans for the Zika community and helping it grow. 31:57.760 --> 32:03.560 So if you are interested at all, there's also a Zikurity Twitter account that I mentioned. 32:03.640 --> 32:06.020 There's a Zik channel in that OpenStock Discord. 32:06.020 --> 32:12.800 So even if you're not going to play OpenStock, come join the Zik channel and kind of have the conversation there. 32:12.800 --> 32:14.400 Keep an eye out for a lot of these online events. 32:14.400 --> 32:16.340 As I mentioned, Zik From Home, Ask the Zik Experts. 32:16.340 --> 32:19.240 There's a lot more on the way that I'm sure Amber could write a lot. 32:19.340 --> 32:27.020 And we're also doing, not quite as cool as OpenStock, I'll admit, but some community CTFs to help you learn the Zik environment. 32:27.020 --> 32:31.980 So with that said, I know I am pretty darn close to time. 32:32.420 --> 32:36.760 Did we have any questions from the chat? 32:36.900 --> 32:43.920 I'm going to scroll and kind of take a quick look here, but if you have any... 32:44.680 --> 32:48.160 I'm actually happy to have a conversation with folks afterwards. 32:48.320 --> 32:51.200 As I know, we are pretty darn close. 32:51.320 --> 32:54.220 I'm hearing people ask about, you know, how hard is it to set up? 32:54.220 --> 32:55.460 I'd encourage you if you...