WEBVTT 00:13.880 --> 00:15.080 Hello, everyone. 00:15.080 --> 00:16.100 Welcome back. 00:16.100 --> 00:26.300 My name is Rubix1138, and I welcome you to Serocata, an introduction into OpenSoC Capture the Flag tools. 00:26.300 --> 00:33.660 I'd like to welcome Josh to the stage here to talk about Serocata. 00:33.660 --> 00:48.460 A reminder, if you are not already in the Discord chat, please go to BlueTeamVillage.org, click on the links for DEF CON 28, and join our channel. 00:48.560 --> 00:51.100 So let's please give a warm welcome to Josh. 00:51.100 --> 00:52.020 Thank you. 00:53.740 --> 00:54.580 All right. 00:54.580 --> 01:07.100 Thank you very much for the introduction, and thank you to the Blue Team Village and all of DEF CON for all of the hard work that I know is going into this, and the opportunity here to talk to you all today a little bit about Serocata. 01:07.200 --> 01:14.680 So this will be really a brief introduction intended to give you some idea as to what Serocata is capable of. 01:14.680 --> 01:18.380 Hopefully there's a few things that you learn about that you didn't know it could do. 01:18.480 --> 01:21.320 I'm going to use a VM here to demonstrate that. 01:21.320 --> 01:25.180 So I have a lot of the text and all the UIs here fairly large. 01:25.180 --> 01:27.700 It should be legible, so you can see that. 01:27.760 --> 01:35.540 A little bit about Serocata then before we get too far into the technology is that Serocata is an open source project. 01:35.540 --> 01:39.580 Everything that you see here that I'll be talking about today is also open source. 01:39.580 --> 01:49.660 So there'll be a few tools I'll touch on beyond Serocata, but most of these are developed and supported by the OISF, the Open Information Security Foundation. 01:49.780 --> 01:56.220 So this is the 501c3 nonprofit that manages and maintains and supports Serocata and all the activity around that. 01:56.220 --> 02:09.500 So we have a very globally diverse team of executive development trainers and others that support and really make this project happen. 02:09.500 --> 02:17.040 There's also a very active community, and we have a number of different platforms that we have available to get engaged in the community. 02:17.040 --> 02:22.800 And so I would highly encourage you, if this is a new technology to you, to reach out to those communities and get involved. 02:22.860 --> 02:23.520 This is me. 02:23.520 --> 02:26.480 You can find me located just about anywhere on the internet. 02:26.580 --> 02:31.760 I am available at this email address as well as on Twitter. 02:31.760 --> 02:35.020 But if you search for my name, you'll probably be able to find me. 02:35.020 --> 02:44.440 And please feel free to direct any questions or anything I can help you with after this presentation in the future to any way you can get a hold of me. 02:44.880 --> 02:54.340 So to get started then, many know Serocata, or if you know Serocata, you recognize it as an IDS, an intrusion detection system. 02:54.340 --> 03:03.280 And likely in the OpenCTF scenario that you'll be engaging in, what Serocata will be doing then is generating IDS alerts, intrusion detection alerts. 03:03.280 --> 03:08.360 So that is, of course, one of Serocata's primary capabilities and primary roles. 03:08.360 --> 03:10.520 But it can do quite a bit more than that. 03:10.520 --> 03:12.740 It can do things like full packet capture. 03:12.740 --> 03:14.900 It can do protocol-specific logging. 03:14.900 --> 03:17.860 It can do file identification and extraction. 03:17.860 --> 03:20.320 It can do offline PCAP processing. 03:20.320 --> 03:27.720 So you can take a PCAP maybe from our sandbox and run that PCAP through Serocata to get IDS alerts and other protocol logs. 03:28.260 --> 03:30.940 I'm only going to talk for 15-20 minutes or so. 03:30.940 --> 03:35.220 So I want to touch on and give you a real brief demonstration about that capability. 03:35.800 --> 03:41.300 Realize, though, that we could probably spend days going through any one of those aspects. 03:41.300 --> 03:47.440 So again, there's a lot of resources that I can help point you to if that's something that would be of interest to you. 03:47.540 --> 03:54.360 Now, as an IDS, Serocata, again, primarily is generating those IDS alerts. 03:54.360 --> 03:59.440 And with those IDS alerts, then, they come in the form of rules. 03:59.440 --> 04:02.220 And rules, then, are simply put. 04:02.220 --> 04:09.000 They're a syntax, a pattern, or a series of patterns that are then applied to your network traffic. 04:09.000 --> 04:12.400 And if those patterns match, an alert is generated. 04:12.400 --> 04:17.380 Now, alerts can be for a large, wide variety of categories. 04:17.380 --> 04:26.140 You can have alerts around malicious behavior, but then you can also have alerts around policy violations or anomalies in your network. 04:26.140 --> 04:34.320 Let's say you have non-encrypted HTTP traffic going over a standard HTTPS, a TLS port, like 443. 04:34.540 --> 04:39.800 Not necessarily malicious, but certainly could be something that you'd want to know about in your environment. 04:39.800 --> 04:50.020 So the rules can be very broad, and they can provide different looks into the traffic in your environment beyond just the known malicious behaviors. 04:50.380 --> 05:01.980 Rules, if you are familiar with things like Yara, Yara signatures, you write a pattern and you use that Yara rule to match on different things, that's a lot how the rules work. 05:02.320 --> 05:14.300 From a practical perspective, most users are going to get their rules from a rule source, and they're going to feed them into the engine, and then they're going to monitor when those alerts are generated. 05:14.480 --> 05:23.820 You can, of course, create or construct your own rules, but that's something that is certainly a capability of the engine. 05:23.820 --> 05:28.040 You can define custom rule sets, but a lot of users are just going to consume those. 05:28.200 --> 05:40.320 It is important, of course, as alerts are generated, as you'll see here in just a moment, to also understand the rule syntax a bit, at least to the point where you can understand what that rule is telling you. 05:40.400 --> 05:44.140 So you have that ability to look at the rule itself as well. 05:44.200 --> 05:52.020 But again, rules are really a topic in and of themselves, so I want to stay a little bit more focused on the pragmatic side at this point. 05:52.560 --> 06:00.820 Now, I mentioned that rules, the way that we can look at rules is that rules come from sources. 06:00.960 --> 06:07.660 Those sources then can be combined to create rule sets, and those rule sets are what we feed into the engine, into Suricata. 06:07.880 --> 06:13.720 A very popular rule set, an open rule set, so an open source rule set, is the etopen. 06:13.760 --> 06:16.980 And Suricata, by default, will use that rule set. 06:16.980 --> 06:22.700 There are other open source rules that you can go and consume, that you can configure your engine to use. 06:22.700 --> 06:30.380 And then it really becomes up to you to determine the rules that you need or want, depending on the environment that you're using Suricata in. 06:30.380 --> 06:40.800 For example, I use it for a lot of malware analysis, so I grab pretty much any rule set I can find, because I'm okay with any individual analysis generating a lot of noise. 06:40.800 --> 06:44.900 In a production environment, I'd be a lot more cautious or careful. 06:45.280 --> 06:51.580 The VM that we're in, I maybe jumped ahead of myself just a tad, the VM that we're in is called CELTS. 06:51.640 --> 07:00.200 This is, believe it or not, my system crashed just before this presentation, so I had to restart. 07:01.300 --> 07:10.020 This is also an open source distribution, it's Debian-based, it's designed to really highlight all of the capabilities of Suricata. 07:10.020 --> 07:23.060 So you can, if you're not familiar with CELTS, or if you're not familiar with Suricata, you can go to Statements Networks, you can download CELTS Suricata ELK Stack, and you essentially have the VM that you see here in this demonstration. 07:23.060 --> 07:30.280 The only minor differences will be a script that I run, and then I have some PCAPs in here. 07:30.280 --> 07:33.440 You're not going to have any PCAPs when you download this. 07:33.440 --> 07:35.460 Otherwise, everything else should be the same. 07:35.480 --> 07:38.480 So that's what CELTS provides you. 07:38.480 --> 07:40.260 It's sort of like a security onion. 07:40.560 --> 07:43.880 It doesn't have some of the host-based stuff, and there's a number of differences in tools. 07:44.180 --> 07:48.780 With this, then, you have some interfaces, such as Sirius. 07:48.780 --> 07:55.080 And Sirius, then, is a graphical interface that allows us to manage rule sets. 07:56.460 --> 07:58.300 This comes in CELTS. 07:58.300 --> 08:06.760 Now, if you were to install Suricata, at least a more recent version of it, by default, Suricata comes with Suricata Update. 08:06.760 --> 08:14.140 So it's a command line utility that has been developed to manage the rule sets and the rule sources for your Suricata instance. 08:14.140 --> 08:22.500 I'm not going to run that here, because I already have CELTS set up and installed, or I'm sorry, Sirius, and I don't want to confuse the rule manager. 08:22.500 --> 08:23.880 I'm just going to use one or the other. 08:23.880 --> 08:33.160 But if you run the help, dash dash help, you'll see that it has all of the basic commands that we're going to cover here. 08:33.160 --> 08:42.580 We look at updating our sources, we look at listing sources, we look at enabling sources, and then applying those sources to build the rule set and deploy it to the engine. 08:42.680 --> 08:45.260 Again, so that's what we'll be seeing with Sirius. 08:45.480 --> 08:57.340 Now, I mentioned we have sources, and so we can, if we want to add any different type of public or custom source that is available, you can do that just by simply selecting these actions. 08:57.380 --> 09:03.800 And adding a source is usually as straightforward as adding the URL where that source is coming from. 09:03.800 --> 09:09.960 Now, there are some commercial rule sets, rule sources, and those then, of course, you have to pay for. 09:09.960 --> 09:14.540 Typically, you get an API key or some way to authenticate before you can use those. 09:14.640 --> 09:27.360 Some other examples of rule sets that are out there, if you go to abuse.ch, which is an awesome project and a lot of great resources, you can look at the blacklist project. 09:27.940 --> 09:31.520 And from there, we can look at the actual list. 09:31.700 --> 09:43.060 And you'll see that there are, for example, in this particular project, a number of rule sets that are available based off of things like blocking of C2 IPs or J3 fingerprints. 09:43.420 --> 09:57.240 Something to keep in mind, then, as you're looking at the different rule sets that are out there, you do need to, oftentimes, if you find there is a Suricata specific one, I would, typically, I would opt over that. 09:57.240 --> 10:10.540 A lot of rule sets are going to be compatible, not only with different versions of Suricata, and there's a fairly significant version change between 4 and 5, where 5 is the latest, but then a lot of them are compatible between Suricata and Snort. 10:10.800 --> 10:23.480 Some of the more recent rule sets, ETOpen or the Emerging Threats List rule sets, they are starting to also create Suricata 4 and Suricata 5 rule sets. 10:23.480 --> 10:27.500 And the changes in 5 are all based off of rule syntax. 10:27.500 --> 10:32.340 And so, you're getting, likely, more performance out of the 5.0 rule set. 10:32.460 --> 10:40.740 You also have to be careful, because, typically, the 5.0 rule set won't work with the 4.0 version or the 4.x version of Suricata. 10:40.740 --> 10:42.500 So, just some things to keep in mind. 10:42.500 --> 10:50.360 And, again, in general, you'll find a lot of compatibility, but I would always opt for, if I'm running Suricata, to take a set specifically designed for it. 10:51.460 --> 10:56.620 If we go back to Sirius, then, you can see that we have our sources listed here. 10:56.700 --> 11:03.220 Again, it's just a click away, or if you're using Suricata Update to add those sources. 11:03.380 --> 11:08.160 And then, once we have our sources, we can create and manage our rule set. 11:08.200 --> 11:12.180 The rule set, then, is just a combination of rule sources. 11:12.200 --> 11:17.460 The default here in this VM is to take the two sources that we have, add them to this rule set. 11:17.460 --> 11:22.880 And we can see that we have those two sources, and we have just under 21,000 rules. 11:23.580 --> 11:28.140 Once we have that configured, we have to deploy the rule set. 11:28.140 --> 11:33.300 We have to make sure that we've downloaded the most recent version, and then deploy those to the engine. 11:33.440 --> 11:40.440 And in this interface, you need to go to the Suricata tab, and then there's this rule set action. 11:40.480 --> 11:45.600 And what will happen here is that it will update, it will build, and it will push. 11:45.600 --> 12:00.140 And what you see with a lot of rule set managers is that they will combine all the rules that you've told it to use, and they will write it into a single file, and then deploy that into the location in the file system that Suricata looks for rule files. 12:00.900 --> 12:04.020 Suricata update also does something very similar. 12:04.140 --> 12:09.720 And in order to create the actual rule file, you just run Suricata update. 12:09.720 --> 12:16.620 So that will run based off of the current configuration, update the rule sets, and then write the file for Suricata to use. 12:16.700 --> 12:20.320 Now, I mentioned the rule location. 12:20.320 --> 12:27.900 So in order to understand where the rules are written to, maybe we want to confirm that they are in fact getting updated. 12:27.900 --> 12:31.660 So we want to look at the rule files or look at the timestamp on that rule file. 12:31.700 --> 12:37.220 The default location for the Suricata configuration is in etc Suricata. 12:37.220 --> 12:39.980 And then in particular, Suricata.yaml. 12:39.980 --> 12:44.000 So there is a yaml file that you can open and look at. 12:44.000 --> 12:45.980 And yes, I did just nano in public. 12:46.660 --> 12:48.960 Everything Suricata related is in here. 12:49.320 --> 12:52.840 You probably don't need to get too deep into the configuration file. 12:52.840 --> 12:54.160 That's something that will come with time. 12:54.160 --> 12:57.240 But definitely there are some things that you might want to check. 12:57.240 --> 13:05.520 Probably one of the most important, outside from we can look at the rule location here in just a moment, is this home net external net. 13:05.760 --> 13:11.380 If you dig into the rules, the syntax of the rules, they use home net and external net. 13:11.380 --> 13:20.600 And what they are using those variables for is to define the direction, the flow of traffic, and then when the engine should apply the rule. 13:20.600 --> 13:22.460 Should it be on the response? 13:22.460 --> 13:23.960 Should it be on the request? 13:24.160 --> 13:25.580 And so that's very important. 13:25.580 --> 13:28.300 It also, of course, defines the IP space. 13:28.300 --> 13:34.280 And so the default is to use standard RFC 1918 addresses, internal IP addresses. 13:34.340 --> 13:39.500 And again, the default then for your external network is to just negate your home network. 13:39.500 --> 13:41.620 But you want to make sure that these are correct. 13:41.620 --> 13:50.380 So if the environment that you're in or defending is using addresses that fall outside of this, that's just something that you want to definitely keep in mind. 13:50.380 --> 13:58.940 Now, one more quick thing about the configuration is that the engine supports sub-configuration. 13:59.100 --> 14:19.320 And with CELKS, we do have a sub-configuration, which means that in our primary configuration file, if we include sub-configurations, these sub-configurations, if they overwrite any configuration options in the primary, then including the sub-yaml, the sub-config will do that. 14:19.320 --> 14:20.720 It'll overwrite in the primary. 14:20.900 --> 14:31.660 So this can become helpful if you have a base configuration that you want to use, and then you deploy sensors into different areas of your network that have slightly different requirements based off of the type of traffic that they're seeing. 14:32.120 --> 14:38.800 In CELKS, we do have in the sub-yaml the change to the default rule file. 14:39.000 --> 14:41.840 So here you can see that's commented out. 14:41.840 --> 14:48.480 If we go a little bit further, the property default rule path and those rules will be located in etc-suricata-rules. 14:48.680 --> 14:53.440 And it's just going to be a single rules file, Sirius.rules, right? 14:53.440 --> 14:56.100 So that's just a real quick about the configuration. 14:56.100 --> 15:06.680 And again, unless you have reason, you probably don't need to get into it right off the bat, but definitely it's worth checking the whole net external net and tweaking that if you need to. 15:07.500 --> 15:15.100 Going back to the interfaces here, so we've now looked at different sources. 15:15.100 --> 15:18.480 You've got an understanding of where you can maybe grab some different rule sources. 15:18.500 --> 15:21.180 We know the process for updating and pushing those. 15:21.700 --> 15:26.420 Suricata can do a live rule set reload, so you don't necessarily have to restart the engine. 15:26.620 --> 15:33.920 The next thing that we'll do is we'll talk about just some of the protocol parsing and file identification capabilities. 15:34.280 --> 15:49.040 So as I mentioned here just a few minutes ago, one of the differences with this VM versus the one you would download from the GitHub is that we do have a couple of scripts that help us with the analysis and then the PCAPs. 15:49.040 --> 15:56.780 So that script is Siri.sh, although it's a relatively straightforward script in that it's running Suricata. 15:56.780 --> 16:00.340 Essentially, the main goal of it is to run Suricata in offline mode. 16:01.540 --> 16:08.160 Let me see... I forgot what PCAP I want to use. 16:26.200 --> 16:27.220 There we go. 16:28.820 --> 16:42.300 So one of the other... again, one of the capabilities I mentioned is that Suricata can run in offline mode, which means that you can feed it a PCAP and it'll process that PCAP as if it were, you know, analyzing the traffic live on the network. 16:42.340 --> 16:46.740 And then you get the same results from Suricata generating its output. 16:46.740 --> 16:51.280 Now, one thing I haven't mentioned yet is where Suricata generates all of its output. 16:51.300 --> 16:56.540 The default is to drop all of the data into a JSON file. 16:56.540 --> 16:58.020 It's the eve.json. 16:58.020 --> 17:06.180 And so the alerts, the protocol logs, file stats, anything that the engine generates, it will be in that eve.json. 17:06.180 --> 17:08.760 The JSON file then is very flexible. 17:08.760 --> 17:23.680 It's a very flexible file format because you can do things like submit it, just the JSON file itself to Elastic and other tools that allow you then to take that data and build, you know, visualizations and dashboards and then parse it in different ways. 17:23.840 --> 17:29.520 Now, the PCAP capability then is, again, this is offline mode. 17:29.520 --> 17:34.080 And when we run a PCAP, it's going to use the original timestamp from the PCAP. 17:34.080 --> 17:41.920 So we just need to keep that in mind because as we look at some of these interfaces, we need to oftentimes adjust the time and date. 17:41.920 --> 17:53.360 So if I look at a dashboard and it's looking at the last 24 hours, even though I just ran the PCAP, if the PCAP was from last week, I need to go back and adjust the timestamps, the filters, and that UI to go back to last week. 17:53.600 --> 17:55.420 We can run this script now. 17:55.420 --> 17:59.920 And again, main purpose is to get the PCAP running through Cercata in offline mode. 17:59.920 --> 18:09.980 So Cercata is going to load, the engine is going to load as it would normally, and it's going to load the rule set that it's configured to utilize, and then it's going to process the PCAP. 18:10.160 --> 18:22.940 Now, as that is loading, what we'll find is another open source project that is maintained and developed by one of the Cercata core developers is called Evebox. 18:22.940 --> 18:34.300 And Evebox provides you with a graphical ability then to look at basically alerts and some of the other data, the protocol data and the flow data that Cercata is generating. 18:34.300 --> 18:37.820 So we'll look at the end of the script. 18:37.820 --> 18:49.100 The script does one more thing before it finishes, and that it queries the eve.json file, looks for any alerts that were generated, and prints them here to our terminal. 18:49.280 --> 18:50.340 Now, that's great. 18:50.340 --> 18:51.900 It's helpful to see those alerts right away. 18:51.900 --> 18:56.980 But again, it's kind of hard to do all this work in a terminal, and it probably doesn't scale that well. 18:56.980 --> 18:59.960 So that's why we would switch to something like Evebox. 19:00.020 --> 19:07.040 Now, with Evebox, and it's going to be a little bit tight here in the UI, just because I have the zoom up high. 19:07.080 --> 19:10.880 But what we're seeing now are the alerts that were generated. 19:10.880 --> 19:17.780 So not only do we see specific alerts for events that happened, but we see other alerts. 19:17.780 --> 19:24.700 And in this case, we see other alerts around the same time that maybe this first alert was generated. 19:24.700 --> 19:30.580 So that helps us to possibly build a little bit better context around each individual alert. 19:30.580 --> 19:32.980 We can see here that we have several. 19:33.320 --> 19:40.480 In fact, these four right here are all based around an executable download. 19:40.580 --> 19:53.760 If we scroll up a little bit further, then we'll see that after that executable appears to be downloaded, we have alerts around Fyodo Tracker and Win32 Emotet command and control activity. 19:54.180 --> 20:01.060 As you start to understand what the alerts are telling you, you can start to read into them a bit more. 20:01.060 --> 20:05.940 We can see that this particular alert here, it's an info alert. 20:06.000 --> 20:10.300 There's color coding to help you visually gauge the severity of the alert. 20:10.300 --> 20:11.600 So this is an info one. 20:11.600 --> 20:14.840 It's a different category that the alerts are categorized in. 20:15.240 --> 20:18.920 An executable is retrieved with minimal HTTP headers, right? 20:18.920 --> 20:20.640 So this is an alert. 20:20.640 --> 20:25.360 And in one event, the download of an executable can actually generate several alerts. 20:25.360 --> 20:33.220 So this is telling you that something downloaded an executable file, and there were very minimal HTTP headers. 20:33.260 --> 20:46.840 And why this becomes significant is because oftentimes, our scripts like PowerShell, for example, which is regularly used from an office document to download executables, by default, they don't use very many HTTP headers. 20:46.840 --> 20:53.920 Typically, it's the get request header, the first header that's needed with the HTTP and the version, and then maybe the host. 20:53.920 --> 21:01.780 And so that is telling you that maybe where this originated from was something like a malicious office document, which actually is the case here. 21:01.780 --> 21:04.700 So those can definitely help to add additional context. 21:04.700 --> 21:08.000 And again, we can get many alerts around a singular event. 21:08.420 --> 21:14.640 We can select any of the alert and get a little bit deeper into the analysis. 21:14.640 --> 21:27.980 So if we select the ET policy, PE, or DLL download, this allows us then to get information about the traffic that matched from this alert. 21:28.020 --> 21:31.920 So we see, of course, the timestamp, we see the sensor that it came from. 21:31.920 --> 21:49.820 So if you're working in a multi-sensor environment, we have the protocol TCP, but this was HTTP, we have the source and the destination ports, the flow ID, we'll take a look at the flow ID here in just a moment, the signature, the category, as well as the signature ID. 21:49.820 --> 21:59.680 And what's helpful about having the signature ID available is that not only could we use this in this particular interface, we can filter off of that. 21:59.680 --> 22:07.720 So we could look back in time over however much data our environment is collecting on to maybe filter off of a specific signature. 22:07.720 --> 22:15.840 But then we can also take that signature ID and we can use... we'll actually use Sirius to do this. 22:15.840 --> 22:23.920 We can pull up that rule itself and select the rule and then look at the rule syntax. 22:24.220 --> 22:30.660 So we can now begin to understand exactly what it is in this rule that was matching on the traffic. 22:30.660 --> 22:34.980 So if we have to dig a little bit deeper to provide a little bit better context and understanding. 22:37.100 --> 22:38.920 Okay, so we'll go back. 22:39.500 --> 22:45.860 If you continue to scroll down in the interface, you'll have different values from the HTTP request. 22:45.860 --> 22:50.480 So that's some of the protocol parsing and logging capability that it has. 22:50.520 --> 22:52.640 You might have the response body. 22:52.640 --> 22:59.260 We can very clearly see if you're familiar with PE files anyway, and we can certainly see the PE file that was returned. 22:59.300 --> 23:03.920 And then, you know, scrolling down further, you'll eventually get to the raw JSON. 23:04.080 --> 23:12.960 So PE files are a bit large, but here you have them, just the raw JSON data that correlates to this alert. 23:13.380 --> 23:20.060 So if there's, for some reason, maybe some data that you know is in Suricata or it's being generated, it's in the EVE.JSON, it's not there. 23:20.060 --> 23:22.560 In the UI, you can come down here and check. 23:22.820 --> 23:28.260 It's also a good place to look just to get a better understanding of all of the data that Suricata is generating. 23:28.260 --> 23:31.840 And maybe there are some fields that it's not producing for you that you might need. 23:31.840 --> 23:35.840 And then there actually are ways to customize the engine to help correct that. 23:35.980 --> 23:38.700 Now, I mentioned the flow ID. 23:39.040 --> 23:41.200 So we can select the flow ID. 23:41.200 --> 23:51.260 And what that will do is essentially give us the ability to take a step back and to look at all of the other, you know, events that are around this particular flow. 23:51.320 --> 23:59.280 So not only now do we see the alerts, but we also see the different different type of events. 23:59.280 --> 24:05.460 We have the flow information, we have the HTTP information, we even have file information. 24:05.460 --> 24:09.720 So we can look at the HTTP request, for example. 24:09.720 --> 24:18.800 And now we can get the host, the URI, maybe the user agent, any of the data that is around the HTTP request itself. 24:19.080 --> 24:22.780 Very similarly with the file info. 24:22.940 --> 24:34.480 So Suricata has the ability then to not only identify files in the traffic, certain file types, it does have its limitations and everything is available under the read the docs. 24:34.660 --> 24:39.180 But then also, it has the ability to extract those files if you want it to. 24:39.180 --> 24:41.460 It doesn't do that by default, though. 24:41.620 --> 24:43.400 So here we have an executable. 24:43.400 --> 24:52.580 We know that it is pretty, you know, we know it's bad because we saw alerts related to EMETET traffic after it was requested and returned. 24:52.860 --> 24:56.140 And so now we can look at information about the file. 24:57.100 --> 25:00.080 The magic will determine the type of file. 25:00.080 --> 25:03.300 So your lib magic telling you the file type. 25:03.300 --> 25:06.460 We already knew it was a PE file, but here it confirms that. 25:06.540 --> 25:16.160 Of course, if we have PE files that we don't have alerts associated with, then this is another sort of piece of data point that then we know is data that's being generated that we could search on. 25:16.420 --> 25:29.340 We have the hash, which is also potentially very helpful because now we could take the hash of the file, and maybe we go and search for that on our favorite threat research platform, such as VirusTotal. 25:29.340 --> 25:31.620 So I'll paste the hash in. 25:31.700 --> 25:35.960 Now, you'll notice here, this is a PCAP from a week or so ago. 25:35.960 --> 25:41.000 And so likely, if it's EMETET, it would have been probably submitted to VirusTotal by now. 25:41.000 --> 25:42.720 We don't get any matches. 25:42.720 --> 25:47.140 And the reason that that is, is the state is truncated. 25:47.680 --> 25:54.800 And so what happens is, by default, Cercata only reads so far into the HTTP response. 25:54.800 --> 26:02.820 And because PE files tend to be large and larger than that response, it stops reading at its threshold and then hashes that content. 26:02.820 --> 26:11.520 So while it certainly read enough of the file to give us the signature, the magic, the PE file identification, it wasn't able to read all of it. 26:11.560 --> 26:21.640 This is done for performance reasons, and it's a very small change in the configuration in order to tell it to read further into the HTTP response. 26:21.640 --> 26:26.860 But again, those are determinations that you have to make based off of considerations for your own environment. 26:27.060 --> 26:31.040 But that is, again, something that you'll want to recognize and understand. 26:31.160 --> 26:38.680 Because if you didn't, and you thought this was in fact the hash of the file, results like this could maybe be a little bit misleading. 26:40.820 --> 26:42.440 Let's see here. 26:44.360 --> 27:04.360 Okay, in addition then to looking at alerts, again, you have the ability to comment, you have the ability to escalate or archive, you have under your events tab in the UI here, the ability to view any of the protocol logs that have been generated. 27:04.360 --> 27:08.620 So if you want to see all of the HTTP, you could select that. 27:08.620 --> 27:17.220 If you want to look at just DNS or TLS or SMB, it's all available here, and it allows you to see it again in the interface. 27:17.440 --> 27:22.140 This particular PCAP did not have any SMB, so we're certainly not going to see it there. 27:22.460 --> 27:30.040 And then there's also some basic alerting or reporting, some dashboards that help with that. 27:30.040 --> 27:42.960 And you can see that, again, you'll have a summary of the alerts, the top signatures, the top categories, your top source IPs and desk IPs. 27:42.960 --> 27:51.220 And so it can provide you, again, an ability to take a step back further and maybe monitor your environment from a bigger picture, broader perspective. 27:51.500 --> 28:00.000 Of course, because the output that Cercata is generating is JSON, you can put it into a pipeline. 28:00.000 --> 28:01.800 You can modify, enrich the data. 28:01.800 --> 28:04.360 You can submit it directly to Elastic. 28:04.360 --> 28:10.800 And from there, you have the ability then to create any number of dashboards or visualizations that you need. 28:10.920 --> 28:16.120 With CELKS, CELKS has a number of dashboards and visualizations already built. 28:16.120 --> 28:28.260 So if you download CELKS, you can use these dashboards and visualizations for inspiration and ideas to get an understanding or a sense of the type of visualizations that are quite helpful. 28:28.960 --> 28:33.540 Kibana is another open source tool that's something that you can utilize. 28:33.540 --> 28:39.540 But getting into all of the details of Elastic and Kibana are a bit beyond the scope of this particular workshop. 28:39.700 --> 28:42.940 The other tool that I always like to point out is Molok. 28:42.940 --> 28:47.000 Molok is another open source tool developed by AOL, supported by AOL. 28:47.380 --> 28:48.900 It's a great tool. 28:48.900 --> 28:51.360 It's like Wireshark on top of Elastic. 28:51.360 --> 28:58.160 And since Cercata can create full packet capture, it can generate and capture your network traffic. 28:58.160 --> 29:10.920 And then you could have Molok pick up the PCAP and ingest it so that now you can use this interface to search for aspects of your traffic over time, however you have your Molok configured to. 29:10.960 --> 29:15.980 Of course, if you're familiar with Molok, it also has its own capture capabilities. 29:16.000 --> 29:26.880 But again, I like to bring it up because if you already have Cercata deployed, these are capabilities that you might have a system that you've already set up and configured to utilize. 29:28.480 --> 29:48.840 Okay, so I think that was my about 25-minute crash course on Cercata and discussing some of the main primary features, what it's capable of, the kind of data that you can get, and how you can utilize that, as well as a VM that you can go and grab and start experimenting with it pretty quickly. 29:48.980 --> 29:51.620 At this point in time, though, that's all I wanted to discuss. 29:51.620 --> 29:59.520 So if anyone has any questions, I believe the Text Workshops Track 1 is available for questions. 29:59.520 --> 30:03.720 Of course, I have my contact information and I'll pull that up again. 30:03.720 --> 30:09.200 Please feel free to direct any questions to me, any way you can get a hold of me or prefer to get a hold of me. 30:09.900 --> 30:11.140 Thank you, Josh. 30:11.140 --> 30:15.260 Yeah, there's a lot of good discussion in the text chat. 30:15.260 --> 30:24.880 One question that popped up that I thought would be good to answer is, is Cercata based on the engine from Snort or is it developed completely different? 30:24.880 --> 30:26.740 It's completely different, yeah. 30:26.740 --> 30:34.900 There is a lineage that goes back to the Snort days, but it is not a fork, it is a rebuild. 30:34.900 --> 30:45.200 So there is a significant number of differences in the engines capabilities and then things like that, rules, syntax, so that they are different. 30:45.200 --> 30:51.900 The best thing I could probably tell you to do is under the Cercata Read the Docs. 30:52.040 --> 30:56.000 I'm not sure I'll be able to find it just by searching. 30:57.600 --> 31:00.300 I think there is a comparison page. 31:01.060 --> 31:07.700 There's certainly compatibility information, but I'm pretty sure somewhere in our Read the Docs there is a Snort versus Cercata. 31:07.700 --> 31:13.620 So if you're looking for the high-level big differences, this is a good place to go. 31:15.900 --> 31:22.900 Josh, thank you very much and thank you all for sticking through the Cercata workshop. 31:22.900 --> 31:28.840 In case anybody does have any follow-up questions, Josh will be around in the Discord channel. 31:28.840 --> 31:35.140 Like he said, it is the techs-workshops-track1 under the Flamingo Hotel group. 31:35.140 --> 31:38.020 Just scroll all the way down to the bottom to Flamingo Hotel. 31:38.220 --> 31:41.320 Check us out in that channel and he'll be answering questions. 31:41.720 --> 31:47.440 Now, Blue Team Village wants to say thank you to everyone that joined and this concludes the Cercata workshop. 31:47.440 --> 31:48.120 Thank you.