[00:14.720 --> 00:20.360]  Outstanding. Apologies for that. So, my name is Aaron Seto. 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:43.140]  She had some unforeseen circumstances came up, so I'll be talking a little bit about the community piece,
[00:43.140 --> 00:47.460]  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:59.880]  I do not blame Discord right now. 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:04.460]  So, I'm going to talk a little bit about Zeek. 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:26.040]  So, this was back in 1995. BRO started at Lawrence Berkeley National Labs.
[01:26.040 --> 01:29.980]  And there were a number of people who were looking into this problem space,
[01:29.980 --> 01:36.280]  and were thinking not even in a security context, but just looking at network traffic at large.
[01:36.520 --> 01:46.260]  And the name BRO really was kind of a nod to Big Brother, being like, this has a lot of surveillance potential,
[01:46.260 --> 01:51.080]  but it also has a lot of network security potential, which is obviously what we'll be focusing on today.
[01:51.080 --> 01:59.960]  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,
[02:00.800 --> 02:04.200]  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:31.260]  And there's a lot that you can do with Zeek in terms of just having scripts and plugins and protocol analyzers
[02:31.260 --> 02:36.160]  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:15.380]  If you've ever seen NetFlow and it's got like IP addresses, ports, protocols, timestamps,
[03:15.380 --> 03:19.820]  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:44.880]  How many bytes? 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:51.080]  Similarly, if we're talking about other protocols, let's say like DNS,
[03:51.080 --> 03:54.760]  I can see the DNS, like the client and the server.
[03:54.760 --> 03:57.860]  I can also see the queries and the answers, the responses,
[03:57.860 --> 04:00.920]  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:07.900]  Now, realistically, there are only a few logs that you're really focused on
[04:07.900 --> 04:13.800]  in a given environment, in a given exercise, and frankly, even in OpenSoft.
[04:13.920 --> 04:18.540]  But, there are probably pushing four dozen logs in total now
[04:18.540 --> 04:20.520]  in the ZEKE OpenSource project.
[04:20.520 --> 04:24.020]  So, there's a log for pretty much any protocol you can think of,
[04:24.020 --> 04:27.560]  and all that metadata, that rich metadata from that protocol,
[04:27.560 --> 04:30.960]  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:36.640]  CoreLite has a little PDF cheat sheet. I'll have that link for you in a second, too.
[04:37.220 --> 04:40.680]  And the ZEKE OpenSource project has really good detailed documentation
[04:41.180 --> 04:43.780]  about logs and even some things that didn't make the cheat sheet.
[04:43.840 --> 04:46.940]  That's actually where I stole these graphics from, was from the CoreLite cheat sheet,
[04:46.940 --> 04:48.700]  because it's a little more colorful.
[04:49.900 --> 04:54.220]  So, to really talk about how we use ZEKE,
[04:54.220 --> 04:56.660]  let me start off by kind of comparing a little bit.
[04:56.660 --> 04:59.080]  So, we need to see if things are actually fine, or if maybe things are fine,
[04:59.080 --> 05:00.980]  or if things are actually not true,
[05:00.980 --> 05:03.660]  then we get something from tools like Wireshark and gpdump.
[05:03.740 --> 05:07.480]  Or, in the middle, we have intrusion detection systems,
[05:07.480 --> 05:09.000]  intrusion prevention systems.
[05:09.000 --> 05:11.420]  So, things like Snort and Suricata,
[05:11.420 --> 05:13.960]  things that we'll find as we kind of work our way through
[05:14.460 --> 05:21.540]  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:28.560]  We have the IP addresses, ports, protocols, timestamps,
[05:28.560 --> 05:29.900]  that kind of high-level information.
[05:29.900 --> 05:31.420]  These are three very common tools,
[05:31.420 --> 05:36.120]  which we'll see as you're kind of getting familiar,
[05:36.120 --> 05:38.020]  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 --> 05:53.900]  So, NetFlow is giving us just that IP address, port, protocol, timestamp,
[05:53.900 --> 05:55.720]  just that generic info,
[05:55.720 --> 06:03.800]  versus something like ZEKE is going to be able to understand protocols at a much deeper level.
[06:03.800 --> 06:08.000]  So, it understands how something like HTTP works,
[06:08.000 --> 06:09.820]  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:20.320]  And really, when you're thinking of ZEKE,
[06:20.320 --> 06:23.120]  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:33.740]  And especially if you have something like full packet capture,
[06:33.740 --> 06:37.200]  then you can go ahead and use ZEKE to help find
[06:37.200 --> 06:42.560]  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:49.300]  And I want to take just a second to talk to that,
[06:49.300 --> 06:53.140]  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:04.880]  So if something goes south, it's because I need to respond to that,
[07:04.880 --> 07:07.720]  or at least I need to investigate it to look at it.
[07:07.740 --> 07:10.860]  But ZEKE is here logging everything that's going on
[07:10.860 --> 07:14.580]  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:28.800]  Because ZEKE understands protocols at such a low level,
[07:28.800 --> 07:32.700]  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 --> 07:52.920]  So when I'm talking about ZEKE data,
[07:52.920 --> 07:57.780]  what I'm really talking about is the representation of network traffic,
[07:57.780 --> 08:03.540]  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:15.680]  But as you normally use in an enterprise, and as you'll use in OpenSOC,
[08:15.680 --> 08:20.600]  that data is being forwarded to a SIEM where you can interact with that
[08:20.600 --> 08:24.680]  and get the context of all the other host-based data
[08:24.680 --> 08:27.820]  and everything else that's coming into that SIEM environment.
[08:27.940 --> 08:33.340]  So in case you haven't guessed already, our SIEM of choice for OpenSOC,
[08:33.340 --> 08:36.000]  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:42.720]  But one of the things that is... before we jump into that,
[08:42.720 --> 08:47.700]  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 --> 08:55.060]  And so every connection that comes in, I'll see in my CON log,
[08:55.060 --> 08:58.800]  but every time there's some HTTP data,
[08:58.800 --> 09:04.260]  HTTP application layer protocol identified in this connection,
[09:04.260 --> 09:09.580]  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:23.140]  So the way you're going to do that is with what's called the UID,
[09:23.140 --> 09:24.760]  or the connection unique ID.
[09:24.760 --> 09:27.800]  And that's something that every time there's a mention of this connection,
[09:27.800 --> 09:30.640]  it's going to appear in any one of these logs.
[09:30.640 --> 09:34.780]  So if I have a connection, let's say, that uses HTTP,
[09:34.780 --> 09:36.880]  and let's say it transfers a file.
[09:36.880 --> 09:40.780]  Well, then I'm going to see that same UID in my CON log, in my HTTP log,
[09:40.780 --> 09:46.360]  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 --> 09:56.320]  And similarly, if I kind of want to pivot around and investigate a file that's happening,
[09:56.320 --> 10:01.440]  or that I'm interested in, then I can use that file unique ID and search through logs
[10:01.440 --> 10:05.880]  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:28.240]  But the second thing I want to do is I want to show you how you would use just a ZEKE data
[10:28.240 --> 10:30.860]  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:43.680]  I'm a SOC analyst. 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:01.660]  So I'm trying to figure out when something comes in, do I have like a playbook or procedure,
[11:01.660 --> 11:06.620]  something that I can fall back to, to say I know how to handle this, we've seen this before,
[11:06.620 --> 11:11.340]  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:22.700]  Okay, somebody's port scanning. Doesn't matter. 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:30.960]  Do I need to bring this to someone, a senior member of our team,
[11:30.960 --> 11:37.680]  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:42.000]  And so it's 2 a.m. I'm sitting here. I'm watching these alerts roll in.
[11:42.000 --> 11:45.820]  I'm trying to figure out, can I deal with this? Can I deal with this myself?
[11:45.820 --> 11:48.460]  Can I dismiss this? 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:55.460]  And it says, hey, I saw a DNS request leaving the network,
[11:55.460 --> 11:58.980]  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:10.060]  So what am I going to do? Can I deal with this myself?
[12:10.060 --> 12:12.420]  Can I dismiss this? 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:27.700]  Let me turn to my DNS log, and I'm going to see the workstation or stations, potentially,
[12:27.700 --> 12:30.520]  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:50.080]  But the big one here is the answer field. 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 --> 13:00.880]  So in this case, I know the client queried for this host name. I want to know what IP address they got back.
[13:00.880 --> 13:07.020]  A lot of times, even with good DNS logging setup, if you have your DNS server set up to forward logs,
[13:07.160 --> 13:11.260]  a lot of times they won't give you that last piece. 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:22.700]  The question that I'm asking myself right now is, okay, I know that there was a DNS request leaving the network,
[13:22.700 --> 13:28.500]  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:43.240]  But I want to know if there was a connection. I want to know more about it.
[13:43.240 --> 13:46.680]  And let's say for the sake of this example, there was. There was a connection.
[13:47.260 --> 13:52.840]  And so I can pivot from my DNS log to my con log, look for connections to that IP address,
[13:52.840 --> 13:56.280]  say that there were connections. I want to see what ports they're on.
[13:56.280 --> 14:00.620]  When did they happen? Are they still happening? 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.900]  Well, the more veterans of you might say, port 80 is obviously HTTP. 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:49.860]  And so it'll say, yep, I know there's HTTP inside of here. 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:53.440]  And that's something that, again, I might be able to go back to previous incidents and playbooks and community resources and say,
[15:53.440 --> 15:57.720]  Hey, what is this thing? 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:09.900]  I might say, all right, cool. 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:19.460]  I'll contact the user. 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:44.480]  This is a piece of malware that kind of establishes a foothold on this compromised workstation
[16:44.480 --> 16:48.580]  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:06.020]  So, in that case, I would see all these HTTP connections and I would see mentions in my files log
[17:06.020 --> 17:11.060]  so I could pivot from the HTTP log to the files log using that connection ID again
[17:11.060 --> 17:13.820]  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:30.680]  Maybe I don't know what the downloader is, but I can kind of know what these other tools are
[17:30.680 --> 17:33.280]  and I can start to understand what the capabilities of this are.
[17:33.280 --> 17:37.840]  I can also look around my network and see what other machines have seen those hashes
[17:37.840 --> 17:43.320]  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:54.720]  Let's say that the attacker gets a foothold on that machine and starts deleting evidence,
[17:54.720 --> 17:59.400]  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:15.780]  So I can pull out those files as they go across the wire, save them to disk,
[18:15.780 --> 18:21.220]  and even if they get deleted, you know, zero-wise, wiped, whatever, off that workstation,
[18:21.220 --> 18:23.180]  I still have those binaries.
[18:23.180 --> 18:28.460]  So putting my worst case scenario hat on again, if I say, all right, well, the evidence has gone over there,
[18:28.460 --> 18:32.680]  I still have these binaries that I can go back to and figure out exactly what they're capable of.
[18:32.680 --> 18:36.660]  If I have to escalate this and, you know, it's 2.15 in the morning now,
[18:36.660 --> 18:41.580]  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:01.720]  I have these SHA-1, MB5, and SHA-26 hashes that we can, you know, search the network,
[19:01.720 --> 19:05.400]  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:18.100]  And if we have to bring in, you know, reverse engineers or, you know, malware analysis people,
[19:18.100 --> 19:20.640]  they have those binaries they can start tearing through.
[19:20.640 --> 19:24.800]  So even in the worst case scenario, I've got a lot of evidence here,
[19:24.800 --> 19:27.960]  even without talking about anything on the endpoint at all.
[19:28.180 --> 19:31.220]  So I know I belabor this quite a bit,
[19:31.220 --> 19:35.640]  but I think it's powerful to talk through kind of the questions that you'll be asking yourself
[19:35.640 --> 19:39.780]  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:07.420]  Instead of asking if you're using the Elastic, the Elk stack,
[20:07.420 --> 20:12.160]  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:25.600]  So to start off with, when you get access to the open-socket environment and you go to Greylock,
[20:25.600 --> 20:28.400]  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:35.840]  This is everything that's going across the network right now. It's a ton of data, right?
[20:36.260 --> 20:41.500]  And so as you're looking through this, I want to talk to you a little bit about the Greylock interface,
[20:41.500 --> 20:45.520]  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 --> 20:59.140]  Specifically, I am asking Greylock to search for a field called event type,
[20:59.140 --> 21:02.160]  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:15.980]  And so this is a gotcha that you'll find again and again, especially in open-socket,
[21:15.980 --> 21:19.580]  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:23.140]  It's because you probably have your search set to the last five minutes,
[21:23.140 --> 21:28.280]  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 --> 21:57.300]  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,
[21:57.560 --> 22:01.420]  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:19.960]  So the thing on the left is the PDF. I like it because it's searchable.
[26:19.960 --> 26:26.280]  The thing on the right is the Zik documentation from Read the Docs that does a much better job of going into more depth
[26:26.280 --> 26:29.560]  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:54.700]  So Zik.org is the Zik website. They've got a YouTube channel.
[26:54.700 --> 27:00.040]  They've got a Twitter account that's constantly posting and retweeting new packages
[27:00.040 --> 27:07.160]  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:21.440]  Slack is the home of a lot of these really great conversations that you can have alongside the Zik developers,
[27:21.440 --> 27:24.820]  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:43.860]  But keep an eye out if you hear Zik Hour, Zik Days. These are kind of local organizations,
[27:43.860 --> 27:48.460]  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:56.980]  I'll give you her contact information. 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:08.300]  Things from like, how are Blue Teamers using this to defend themselves,
[28:08.300 --> 28:15.200]  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:33.180]  There's Zik from Home, there's Ask the Zik-sperts, which is where they bring in a lot of experts,
[28:33.180 --> 28:36.140]  and you can just be like, hey, I'm trying to install Zik at home, and I'm hitting this error,
[28:36.140 --> 28:40.240]  and they'll happily walk you through it. 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 --> 28:48.620]  So a lot of folks, especially approaching open source, think, well, hey, I'm just getting started,
[28:48.620 --> 28:52.760]  or hey, you know, yeah, I'm working on this Blue Team thing, and I'm figuring this out,
[28:52.760 --> 29:01.060]  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:13.240]  So yes, you might be thinking in code. You might be saying, well, I'm not a good coder.
[29:13.240 --> 29:20.640]  Well, okay, what about looking into the user community and contributing to, as you're installing this,
[29:20.640 --> 29:23.740]  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:39.040]  Maybe you want to try your hand at scripting. Scripting is actually pretty approachable,
[29:39.040 --> 29:41.920]  and there's so much that you can do in the Zika language.
[29:42.080 --> 29:46.780]  Things that are just very simple that are going to help you in your day-to-day,
[29:46.780 --> 29:52.740]  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 --> 30:04.720]  Where could I start? Download it. Get some of the latest releases and give us an okay and say, yep, we tested it out.
[30:04.720 --> 30:08.240]  It worked. Help us test releases and get that feedback.
[30:08.240 --> 30:12.740]  So there's so much that you can do, and it's so tempting to think of this as like,
[30:12.740 --> 30:17.240]  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:26.120]  Think about kind of moving diagonally. Think about kind of charting your own path
[30:26.120 --> 30:29.980]  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:45.840]  So if you're interested in deploying Zika locally, probably something I would recommend putting on
[30:45.840 --> 30:48.220]  until after OpenStock, because you're going to have a busy weekend.
[30:48.460 --> 30:51.700]  But you've got the link there. Again, I'll post these in the Discord.
[30:51.720 --> 30:56.040]  Security Onion, a lot of you know, as kind of the Cali for blue team,
[30:56.040 --> 31:00.180]  it's a Linux distribution that has all of these tools built into them, including Zika.
[31:00.180 --> 31:02.880]  And so if you're interested in just having kind of a live environment,
[31:02.880 --> 31:06.520]  I wouldn't recommend it for like a full production environment,
[31:06.520 --> 31:12.180]  but for just getting your feet wet and understanding how this works together with these other tools,
[31:12.180 --> 31:14.920]  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:50.340]  Amber is our Zika Community Director, an incredible resource,
[31:50.340 --> 31:57.760]  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:16.340]  Keep an eye out for a lot of these online events. 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:22.900]  And we're also doing, not quite as cool as OpenStock, I'll admit,
[32:22.900 --> 32:27.020]  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...