[00:13.880 --> 00:21.260]  Hello, everyone. Welcome back. My name is Rubix1138, and I welcome you to Serocata,
[00:21.260 --> 00:31.000]  an introduction into OpenSoC Capture the Flag tools. I'd like to welcome Josh to the stage
[00:31.000 --> 00:36.680]  here to talk about Serocata. A reminder, if you are not already in the Discord chat,
[00:36.680 --> 00:43.020]  please go to BlueTeamVillage.org, click on the links for
[00:44.740 --> 00:52.020]  DEF CON 28, and join our channel. So let's please give a warm welcome to Josh. Thank you.
[00:53.740 --> 00:58.320]  All right. Thank you very much for the introduction, and thank you to the Blue
[00:58.320 --> 01:01.960]  Team Village and all of DEF CON for all of the hard work that I know is going into this,
[01:01.960 --> 01:07.100]  and the opportunity here to talk to you all today a little bit about Serocata.
[01:07.200 --> 01:12.460]  So this will be really a brief introduction intended to give you some idea as to what
[01:12.460 --> 01:17.400]  Serocata is capable of. Hopefully there's a few things that you learn about that you didn't know
[01:17.400 --> 01:23.320]  it could do. I'm going to use a VM here to demonstrate that. So I have a lot of the text
[01:23.320 --> 01:28.780]  and all the UIs here fairly large. It should be legible, so you can see that. A little bit about
[01:28.780 --> 01:34.940]  Serocata then before we get too far into the technology is that Serocata is an open source
[01:34.940 --> 01:39.700]  project. Everything that you see here that I'll be talking about today is also open source. So
[01:39.700 --> 01:45.240]  there'll be a few tools I'll touch on beyond Serocata, but most of these are developed and
[01:45.240 --> 01:51.560]  supported by the OISF, the Open Information Security Foundation. So this is the 501c3
[01:51.560 --> 01:56.380]  nonprofit that manages and maintains and supports Serocata and all the activity around that. So
[01:56.380 --> 02:05.760]  we have a very globally diverse team of executive development trainers and others
[02:05.760 --> 02:11.620]  that support and really make this project happen. There's also a very active community,
[02:11.620 --> 02:17.040]  and we have a number of different platforms that we have available to get engaged in the community.
[02:17.040 --> 02:21.040]  And so I would highly encourage you, if this is a new technology to you, to reach out to those
[02:21.040 --> 02:25.800]  communities and get involved. This is me. You can find me located just about anywhere on the
[02:25.800 --> 02:33.200]  internet. I am available at this email address as well as on Twitter. But if you search for my
[02:33.200 --> 02:37.180]  name, you'll probably be able to find me. And please feel free to direct any questions or
[02:37.180 --> 02:43.260]  anything I can help you with after this presentation in the future to any way you
[02:43.260 --> 02:49.840]  can get a hold of me. So to get started then, many know Serocata, or if you know Serocata,
[02:49.840 --> 02:56.800]  you recognize it as an IDS, an intrusion detection system. And likely in the OpenCTF scenario that
[02:56.800 --> 03:01.820]  you'll be engaging in, what Serocata will be doing then is generating IDS alerts,
[03:01.820 --> 03:07.560]  intrusion detection alerts. So that is, of course, one of Serocata's primary capabilities and primary
[03:07.560 --> 03:13.060]  roles. But it can do quite a bit more than that. It can do things like full packet capture. It can
[03:13.060 --> 03:19.120]  do protocol-specific logging. It can do file identification and extraction. It can do offline
[03:19.120 --> 03:24.440]  PCAP processing. So you can take a PCAP maybe from our sandbox and run that PCAP through
[03:24.840 --> 03:30.440]  Serocata to get IDS alerts and other protocol logs. I'm only going to talk for 15-20 minutes
[03:30.440 --> 03:35.220]  or so. So I want to touch on and give you a real brief demonstration about that capability.
[03:35.800 --> 03:41.440]  Realize, though, that we could probably spend days going through any one of those aspects. So
[03:42.160 --> 03:46.100]  again, there's a lot of resources that I can help point you to if that's something that would be of
[03:46.100 --> 03:54.580]  interest to you. Now, as an IDS, Serocata, again, primarily is generating those IDS alerts. And
[03:54.580 --> 04:02.220]  with those IDS alerts, then, they come in the form of rules. And rules, then, are simply put.
[04:02.220 --> 04:08.320]  They're a syntax, a pattern, or a series of patterns that are then applied to your network
[04:08.320 --> 04:15.520]  traffic. And if those patterns match, an alert is generated. Now, alerts can be for a large,
[04:15.520 --> 04:21.460]  wide variety of categories. You can have alerts around malicious behavior, but then you can also
[04:21.460 --> 04:28.140]  have alerts around policy violations or anomalies in your network. Let's say you have non-encrypted
[04:28.140 --> 04:36.640]  HTTP traffic going over a standard HTTPS, a TLS port, like 443. Not necessarily malicious, but
[04:36.640 --> 04:40.800]  certainly could be something that you'd want to know about in your environment. So the rules can
[04:40.800 --> 04:45.820]  be very broad, and they can provide different looks into the traffic in your environment
[04:45.820 --> 04:54.660]  beyond just the known malicious behaviors. Rules, if you are familiar with things like Yara,
[04:54.660 --> 04:59.860]  Yara signatures, you write a pattern and you use that Yara rule to match on different things,
[04:59.860 --> 05:07.240]  that's a lot how the rules work. From a practical perspective, most users are going to get their
[05:07.240 --> 05:12.040]  rules from a rule source, and they're going to feed them into the engine, and then they're
[05:12.040 --> 05:18.420]  going to monitor when those alerts are generated. You can, of course, create or construct your own
[05:18.420 --> 05:24.660]  rules, but that's something that is certainly a capability of the engine. You can define custom
[05:24.660 --> 05:29.560]  rule sets, but a lot of users are just going to consume those. It is important, of course,
[05:29.560 --> 05:35.660]  as alerts are generated, as you'll see here in just a moment, to also understand the rule syntax a bit,
[05:35.660 --> 05:41.540]  at least to the point where you can understand what that rule is telling you. So you have that
[05:41.540 --> 05:46.880]  ability to look at the rule itself as well. But again, rules are really a topic in and of
[05:46.880 --> 05:52.020]  themselves, so I want to stay a little bit more focused on the pragmatic side at this point.
[05:52.560 --> 05:59.700]  Now, I mentioned that rules, the way that we can look at rules is that rules come from
[05:59.700 --> 06:04.480]  sources. Those sources then can be combined to create rule sets, and those rule sets are
[06:04.480 --> 06:11.240]  what we feed into the engine, into Suricata. A very popular rule set, an open rule set,
[06:11.240 --> 06:16.980]  so an open source rule set, is the etopen. And Suricata, by default, will use that rule set.
[06:16.980 --> 06:22.020]  There are other open source rules that you can go and consume, that you can configure your engine to
[06:22.020 --> 06:27.220]  use. And then it really becomes up to you to determine the rules that you need or want,
[06:27.220 --> 06:32.440]  depending on the environment that you're using Suricata in. For example, I use it for a lot of
[06:32.440 --> 06:37.980]  malware analysis, so I grab pretty much any rule set I can find, because I'm okay with any
[06:37.980 --> 06:43.260]  individual analysis generating a lot of noise. In a production environment, I'd be a lot more
[06:43.260 --> 06:49.280]  cautious or careful. The VM that we're in, I maybe jumped ahead of myself just a tad,
[06:49.280 --> 06:56.900]  the VM that we're in is called CELTS. This is, believe it or not, my system crashed just before
[06:56.900 --> 07:05.420]  this presentation, so I had to restart. This is also an open source distribution, it's Debian-based,
[07:05.420 --> 07:11.460]  it's designed to really highlight all of the capabilities of Suricata. So you can, if you're
[07:11.460 --> 07:16.000]  not familiar with CELTS, or if you're not familiar with Suricata, you can go to Statements Networks,
[07:16.000 --> 07:21.940]  you can download CELTS Suricata ELK Stack, and you essentially have the VM that you see here
[07:21.940 --> 07:29.540]  in this demonstration. The only minor differences will be a script that I run, and then I have some
[07:29.540 --> 07:33.920]  PCAPs in here. You're not going to have any PCAPs when you download this. Otherwise,
[07:33.920 --> 07:39.600]  everything else should be the same. So that's what CELTS provides you. It's sort of like a
[07:39.600 --> 07:43.200]  security onion. It doesn't have some of the host-based stuff, and there's a number of differences
[07:43.200 --> 07:51.080]  in tools. With this, then, you have some interfaces, such as Sirius. And Sirius, then, is a graphical
[07:51.080 --> 08:00.340]  interface that allows us to manage rule sets. This comes in CELTS. Now, if you were to install
[08:00.340 --> 08:06.760]  Suricata, at least a more recent version of it, by default, Suricata comes with Suricata Update.
[08:06.760 --> 08:11.980]  So it's a command line utility that has been developed to manage the rule sets and the rule
[08:11.980 --> 08:16.740]  sources for your Suricata instance. I'm not going to run that here, because I already have CELTS
[08:17.380 --> 08:22.680]  set up and installed, or I'm sorry, Sirius, and I don't want to confuse the rule manager. I'm just
[08:22.680 --> 08:30.620]  going to use one or the other. But if you run the help, dash dash help, you'll see that it has all
[08:30.620 --> 08:35.440]  of the basic commands that we're going to cover here. We look at updating our sources, we look at
[08:35.440 --> 08:40.920]  listing sources, we look at enabling sources, and then applying those sources to build the rule set
[08:40.920 --> 08:46.460]  and deploy it to the engine. Again, so that's what we'll be seeing with Sirius. Now, I mentioned we
[08:46.460 --> 08:53.080]  have sources, and so we can, if we want to add any different type of public or custom source that is
[08:53.080 --> 09:00.540]  available, you can do that just by simply selecting these actions. And adding a source is usually as
[09:00.540 --> 09:05.720]  straightforward as adding the URL where that source is coming from. Now, there are some commercial
[09:05.720 --> 09:11.440]  rule sets, rule sources, and those then, of course, you have to pay for. Typically, you get an API key
[09:11.440 --> 09:17.340]  or some way to authenticate before you can use those. Some other examples of rule sets that are
[09:17.340 --> 09:23.220]  out there, if you go to abuse.ch, which is an awesome project and a lot of great resources,
[09:23.620 --> 09:31.520]  you can look at the blacklist project. And from there, we can look at the actual list.
[09:31.700 --> 09:36.660]  And you'll see that there are, for example, in this particular project, a number of rule sets
[09:36.660 --> 09:43.940]  that are available based off of things like blocking of C2 IPs or J3 fingerprints. Something
[09:43.940 --> 09:49.260]  to keep in mind, then, as you're looking at the different rule sets that are out there,
[09:49.260 --> 09:55.000]  you do need to, oftentimes, if you find there is a Suricata specific one,
[09:55.000 --> 09:59.500]  I would, typically, I would opt over that. A lot of rule sets are going to be compatible,
[09:59.500 --> 10:04.180]  not only with different versions of Suricata, and there's a fairly significant version change
[10:04.180 --> 10:08.860]  between 4 and 5, where 5 is the latest, but then a lot of them are compatible between
[10:08.860 --> 10:15.940]  Suricata and Snort. Some of the more recent rule sets, ETOpen or the Emerging Threats List
[10:16.640 --> 10:24.200]  rule sets, they are starting to also create Suricata 4 and Suricata 5 rule sets. And the
[10:24.200 --> 10:30.320]  changes in 5 are all based off of rule syntax. And so, you're getting, likely, more performance out
[10:30.320 --> 10:36.920]  of the 5.0 rule set. You also have to be careful, because, typically, the 5.0 rule set won't work
[10:36.920 --> 10:42.500]  with the 4.0 version or the 4.x version of Suricata. So, just some things to keep in mind.
[10:42.500 --> 10:46.620]  And, again, in general, you'll find a lot of compatibility, but I would always opt for,
[10:46.620 --> 10:53.140]  if I'm running Suricata, to take a set specifically designed for it. If we go back to Sirius, then,
[10:53.140 --> 11:00.240]  you can see that we have our sources listed here. Again, it's just a click away, or if you're using
[11:00.320 --> 11:06.860]  Suricata Update to add those sources. And then, once we have our sources, we can create and manage
[11:06.860 --> 11:13.020]  our rule set. The rule set, then, is just a combination of rule sources. The default here
[11:13.020 --> 11:18.280]  in this VM is to take the two sources that we have, add them to this rule set. And we can see
[11:18.280 --> 11:26.000]  that we have those two sources, and we have just under 21,000 rules. Once we have that configured,
[11:26.000 --> 11:30.880]  we have to deploy the rule set. We have to make sure that we've downloaded the most recent version,
[11:30.880 --> 11:37.740]  and then deploy those to the engine. And in this interface, you need to go to the Suricata tab,
[11:37.740 --> 11:44.060]  and then there's this rule set action. And what will happen here is that it will update,
[11:44.060 --> 11:49.740]  it will build, and it will push. And what you see with a lot of rule set managers is that they will
[11:49.740 --> 11:54.560]  combine all the rules that you've told it to use, and they will write it into a single file,
[11:54.560 --> 12:00.140]  and then deploy that into the location in the file system that Suricata looks for rule files.
[12:00.900 --> 12:07.960]  Suricata update also does something very similar. And in order to create the actual rule file,
[12:07.960 --> 12:12.860]  you just run Suricata update. So that will run based off of the current configuration,
[12:12.860 --> 12:20.320]  update the rule sets, and then write the file for Suricata to use. Now, I mentioned the rule location.
[12:20.320 --> 12:26.760]  So in order to understand where the rules are written to, maybe we want to confirm that they
[12:26.760 --> 12:30.620]  are in fact getting updated. So we want to look at the rule files or look at the timestamp on that
[12:30.620 --> 12:37.940]  rule file. The default location for the Suricata configuration is in etc Suricata. And then in
[12:37.940 --> 12:44.360]  particular, Suricata.yaml. So there is a yaml file that you can open and look at. And yes,
[12:44.360 --> 12:51.060]  I did just nano in public. Everything Suricata related is in here. You probably don't need to
[12:51.060 --> 12:55.400]  get too deep into the configuration file. That's something that will come with time. But definitely
[12:55.400 --> 12:59.340]  there are some things that you might want to check. Probably one of the most important,
[12:59.340 --> 13:05.520]  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:17.660]  And what they are using those variables for is to define the direction, the flow of traffic,
[13:17.660 --> 13:22.920]  and then when the engine should apply the rule. Should it be on the response? Should it be on
[13:22.920 --> 13:28.780]  the request? And so that's very important. It also, of course, defines the IP space. And so
[13:28.780 --> 13:35.720]  the default is to use standard RFC 1918 addresses, internal IP addresses. And again, the default then
[13:35.720 --> 13:40.840]  for your external network is to just negate your home network. But you want to make sure that these
[13:40.840 --> 13:46.520]  are correct. So if the environment that you're in or defending is using addresses that fall outside
[13:46.520 --> 13:51.900]  of this, that's just something that you want to definitely keep in mind. Now, one more quick thing
[13:51.900 --> 14:00.260]  about the configuration is that the engine supports sub-configuration. And with CELKS,
[14:00.260 --> 14:06.460]  we do have a sub-configuration, which means that in our primary configuration file, if we include
[14:06.460 --> 14:13.960]  sub-configurations, these sub-configurations, if they overwrite any configuration options in
[14:13.960 --> 14:19.880]  the primary, then including the sub-yaml, the sub-config will do that. It'll overwrite in
[14:19.880 --> 14:24.820]  the primary. So this can become helpful if you have a base configuration that you want to use,
[14:24.820 --> 14:28.500]  and then you deploy sensors into different areas of your network that have slightly different
[14:28.500 --> 14:35.600]  requirements based off of the type of traffic that they're seeing. In CELKS, we do have in the
[14:35.600 --> 14:41.960]  sub-yaml the change to the default rule file. So here you can see that's commented out. If we
[14:41.960 --> 14:47.120]  go a little bit further, the property default rule path and those rules will be located in
[14:47.120 --> 14:53.800]  etc-suricata-rules. And it's just going to be a single rules file, Sirius.rules, right? So that's
[14:53.800 --> 14:59.180]  just a real quick about the configuration. And again, unless you have reason, you probably don't
[14:59.180 --> 15:03.940]  need to get into it right off the bat, but definitely it's worth checking the whole net
[15:03.940 --> 15:11.430]  external net and tweaking that if you need to. Going back to the interfaces here,
[15:11.900 --> 15:16.560]  so we've now looked at different sources. You've got an understanding of where you can
[15:16.560 --> 15:21.180]  maybe grab some different rule sources. 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:31.520]  The next thing that we'll do is we'll talk about just some of the protocol parsing and
[15:31.520 --> 15:37.480]  file identification capabilities. So as I mentioned here just a few minutes ago,
[15:37.480 --> 15:42.120]  one of the differences with this VM versus the one you would download from the GitHub
[15:42.640 --> 15:49.040]  is that we do have a couple of scripts that help us with the analysis and then the PCAPs.
[15:49.040 --> 15:55.380]  So that script is Siri.sh, although it's a relatively straightforward script in that it's
[15:55.380 --> 16:00.340]  running Suricata. Essentially, the main goal of it is to run Suricata in offline mode.
[16:01.540 --> 16:27.220]  Let me see... I forgot what PCAP I want to use. There we go.
[16:28.820 --> 16:32.580]  So one of the other... again, one of the capabilities I mentioned is that Suricata
[16:32.580 --> 16:38.200]  can run in offline mode, which means that you can feed it a PCAP and it'll process that PCAP
[16:38.200 --> 16:43.640]  as if it were, you know, analyzing the traffic live on the network. And then you get the same
[16:43.640 --> 16:49.300]  results from Suricata generating its output. Now, one thing I haven't mentioned yet is where
[16:49.300 --> 16:56.620]  Suricata generates all of its output. The default is to drop all of the data into a JSON file. It's
[16:56.620 --> 17:03.680]  the eve.json. And so the alerts, the protocol logs, file stats, anything that the engine generates,
[17:03.680 --> 17:09.980]  it will be in that eve.json. The JSON file then is very flexible. It's a very flexible file format
[17:09.980 --> 17:16.900]  because you can do things like submit it, just the JSON file itself to Elastic and other tools
[17:16.900 --> 17:22.060]  that allow you then to take that data and build, you know, visualizations and dashboards and then
[17:22.060 --> 17:29.520]  parse it in different ways. Now, the PCAP capability then is, again, this is offline mode.
[17:29.520 --> 17:34.640]  And when we run a PCAP, it's going to use the original timestamp from the PCAP. So we just need
[17:34.640 --> 17:40.320]  to keep that in mind because as we look at some of these interfaces, we need to oftentimes adjust
[17:40.320 --> 17:45.920]  the time and date. So if I look at a dashboard and it's looking at the last 24 hours, even though I
[17:45.920 --> 17:51.000]  just ran the PCAP, if the PCAP was from last week, I need to go back and adjust the timestamps,
[17:51.000 --> 17:56.500]  the filters, and that UI to go back to last week. We can run this script now. And again, main purpose
[17:56.500 --> 18:01.280]  is to get the PCAP running through Cercata in offline mode. So Cercata is going to load,
[18:01.280 --> 18:05.260]  the engine is going to load as it would normally, and it's going to load the rule set that it's
[18:05.260 --> 18:11.920]  configured to utilize, and then it's going to process the PCAP. Now, as that is loading,
[18:11.920 --> 18:19.180]  what we'll find is another open source project that is maintained and developed by one of the
[18:20.080 --> 18:26.420]  Cercata core developers is called Evebox. And Evebox provides you with a graphical ability
[18:26.420 --> 18:32.000]  then to look at basically alerts and some of the other data, the protocol data and the flow data
[18:32.000 --> 18:38.800]  that Cercata is generating. So we'll look at the end of the script. The script does
[18:38.800 --> 18:45.760]  one more thing before it finishes, and that it queries the eve.json file, looks for any alerts
[18:45.760 --> 18:50.960]  that were generated, and prints them here to our terminal. Now, that's great. It's helpful to see
[18:50.960 --> 18:55.140]  those alerts right away. But again, it's kind of hard to do all this work in a terminal, and it
[18:55.140 --> 19:00.560]  probably doesn't scale that well. So that's why we would switch to something like Evebox. Now,
[19:00.560 --> 19:05.760]  with Evebox, and it's going to be a little bit tight here in the UI, just because I have the
[19:05.760 --> 19:12.560]  zoom up high. But what we're seeing now are the alerts that were generated. So not only do we see
[19:12.560 --> 19:18.700]  specific alerts for events that happened, but we see other alerts. And in this case,
[19:18.700 --> 19:24.700]  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:37.840]  We can see here that we have several. In fact, these four right here are all based around
[19:37.840 --> 19:44.400]  an executable download. If we scroll up a little bit further, then we'll see that after that
[19:44.400 --> 19:51.620]  executable appears to be downloaded, we have alerts around Fyodo Tracker and Win32 Emotet
[19:51.620 --> 19:58.860]  command and control activity. As you start to understand what the alerts are telling you,
[19:58.860 --> 20:04.800]  you can start to read into them a bit more. We can see that this particular alert here, it's an
[20:04.800 --> 20:10.660]  info alert. There's color coding to help you visually gauge the severity of the alert. So this
[20:10.660 --> 20:16.020]  is an info one. It's a different category that the alerts are categorized in. An executable is
[20:16.020 --> 20:22.360]  retrieved with minimal HTTP headers, right? So this is an alert. And in one event, the download
[20:22.360 --> 20:28.320]  of an executable can actually generate several alerts. So this is telling you that something
[20:28.320 --> 20:34.140]  downloaded an executable file, and there were very minimal HTTP headers. And why this becomes
[20:34.140 --> 20:39.640]  significant is because oftentimes, our scripts like PowerShell, for example, which is regularly
[20:39.640 --> 20:45.500]  used from an office document to download executables, by default, they don't use very
[20:45.500 --> 20:50.520]  many HTTP headers. Typically, it's the get request header, the first header that's needed with the
[20:50.520 --> 20:56.720]  HTTP and the version, and then maybe the host. And so that is telling you that maybe where this
[20:56.720 --> 21:01.780]  originated from was something like a malicious office document, which actually is the case here.
[21:01.780 --> 21:06.400]  So those can definitely help to add additional context. And again, we can get many alerts around
[21:06.620 --> 21:14.640]  a singular event. We can select any of the alert and get a little bit deeper into the analysis.
[21:14.640 --> 21:24.320]  So if we select the ET policy, PE, or DLL download, this allows us then to get information
[21:24.320 --> 21:30.680]  about the traffic that matched from this alert. So we see, of course, the timestamp, we see the
[21:30.680 --> 21:35.100]  sensor that it came from. So if you're working in a multi-sensor environment, we have the protocol
[21:35.100 --> 21:43.560]  TCP, but this was HTTP, we have the source and the destination ports, the flow ID, we'll take a look
[21:43.560 --> 21:50.040]  at the flow ID here in just a moment, the signature, the category, as well as the signature ID. And
[21:50.040 --> 21:55.320]  what's helpful about having the signature ID available is that not only could we use this
[21:55.320 --> 22:01.500]  in this particular interface, we can filter off of that. So we could look back in time over
[22:01.500 --> 22:07.720]  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:41.540]  Okay, so we'll go back. If you continue to scroll down in the interface,
[22:41.540 --> 22:47.440]  you'll have different values from the HTTP request. So that's some of the protocol parsing
[22:47.440 --> 22:53.920]  and logging capability that it has. You might have the response body. We can very clearly see
[22:53.920 --> 22:59.260]  if you're familiar with PE files anyway, and we can certainly see the PE file that was returned.
[22:59.300 --> 23:05.980]  And then, you know, scrolling down further, you'll eventually get to the raw JSON. So PE files are a
[23:05.980 --> 23:12.960]  bit large, but here you have them, just the raw JSON data that correlates to this alert.
[23:13.380 --> 23:17.660]  So if there's, for some reason, maybe some data that you know is in Suricata or it's being
[23:17.660 --> 23:22.560]  generated, it's in the EVE.JSON, it's not there. In the UI, you can come down here and check.
[23:22.820 --> 23:26.960]  It's also a good place to look just to get a better understanding of all of the data that
[23:26.960 --> 23:31.140]  Suricata is generating. And maybe there are some fields that it's not producing for you
[23:31.140 --> 23:35.840]  that you might need. And then there actually are ways to customize the engine to help correct that.
[23:35.980 --> 23:43.700]  Now, I mentioned the flow ID. So we can select the flow ID. And what that will do is essentially
[23:43.700 --> 23:49.200]  give us the ability to take a step back and to look at all of the other, you know, events that
[23:49.200 --> 23:57.560]  are around this particular flow. So not only now do we see the alerts, but we also see the different
[23:58.140 --> 24:03.140]  different type of events. We have the flow information, we have the HTTP information,
[24:03.140 --> 24:10.700]  we even have file information. So we can look at the HTTP request, for example. And now we can get
[24:10.700 --> 24:18.800]  the host, the URI, maybe the user agent, any of the data that is around the HTTP request itself.
[24:19.080 --> 24:26.200]  Very similarly with the file info. So Suricata has the ability then to not only identify
[24:26.200 --> 24:31.820]  files in the traffic, certain file types, it does have its limitations and everything is
[24:31.820 --> 24:38.520]  available under the read the docs. But then also, it has the ability to extract those files if you
[24:38.520 --> 24:44.460]  want it to. It doesn't do that by default, though. So here we have an executable. We know that it is
[24:44.460 --> 24:49.160]  pretty, you know, we know it's bad because we saw alerts related to EMETET traffic after
[24:49.160 --> 24:56.140]  it was requested and returned. And so now we can look at information about the file.
[24:57.100 --> 25:03.300]  The magic will determine the type of file. So your lib magic telling you the file type.
[25:03.300 --> 25:07.960]  We already knew it was a PE file, but here it confirms that. Of course, if we have PE files
[25:07.960 --> 25:12.640]  that we don't have alerts associated with, then this is another sort of piece of data point that
[25:12.640 --> 25:17.860]  then we know is data that's being generated that we could search on. We have the hash,
[25:17.860 --> 25:22.380]  which is also potentially very helpful because now we could take the hash of the file,
[25:22.380 --> 25:29.340]  and maybe we go and search for that on our favorite threat research platform, such as VirusTotal.
[25:29.340 --> 25:35.960]  So I'll paste the hash in. 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:47.140]  We don't get any matches. 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:00.460]  And because PE files tend to be large and larger than that response, it stops reading at its
[26:00.460 --> 26:05.600]  threshold and then hashes that content. So while it certainly read enough of the file to give us
[26:05.600 --> 26:11.520]  the signature, the magic, the PE file identification, it wasn't able to read all of it.
[26:11.560 --> 26:16.300]  This is done for performance reasons, and it's a very small change in the configuration
[26:16.300 --> 26:23.360]  in order to tell it to read further into the HTTP response. But again, those are determinations that
[26:23.360 --> 26:28.360]  you have to make based off of considerations for your own environment. But that is, again,
[26:28.360 --> 26:32.780]  something that you'll want to recognize and understand. Because if you didn't, and you
[26:32.780 --> 26:37.840]  thought this was in fact the hash of the file, results like this could maybe be a little bit
[26:37.840 --> 26:52.260]  misleading. Let's see here. Okay, in addition then to looking at alerts, again, you have the
[26:52.260 --> 26:57.840]  ability to comment, you have the ability to escalate or archive, you have under your events
[26:57.840 --> 27:04.560]  tab in the UI here, the ability to view any of the protocol logs that have been generated. So
[27:04.560 --> 27:10.080]  if you want to see all of the HTTP, you could select that. If you want to look at just DNS or
[27:10.080 --> 27:17.220]  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:28.440]  And then there's also some basic alerting or reporting, some dashboards that help with
[27:29.300 --> 27:38.120]  that. And you can see that, again, you'll have a summary of the alerts, the top signatures,
[27:38.120 --> 27:45.040]  the top categories, your top source IPs and desk IPs. And so it can provide you, again, an ability
[27:45.040 --> 27:50.000]  to take a step back further and maybe monitor your environment from a bigger picture, broader
[27:50.000 --> 27:59.160]  perspective. Of course, because the output that Cercata is generating is JSON, you can put it
[27:59.160 --> 28:05.240]  into a pipeline. You can modify, enrich the data. You can submit it directly to Elastic. And from
[28:05.240 --> 28:09.820]  there, you have the ability then to create any number of dashboards or visualizations that you
[28:09.820 --> 28:16.860]  need. With CELKS, CELKS has a number of dashboards and visualizations already built. So if you
[28:16.860 --> 28:23.080]  download CELKS, you can use these dashboards and visualizations for inspiration and ideas to
[28:23.080 --> 28:28.260]  get an understanding or a sense of the type of visualizations that are quite helpful.
[28:28.960 --> 28:34.000]  Kibana is another open source tool that's something that you can utilize. But getting
[28:34.000 --> 28:38.600]  into all of the details of Elastic and Kibana are a bit beyond the scope of this particular
[28:38.600 --> 28:44.320]  workshop. The other tool that I always like to point out is Molok. Molok is another open source
[28:44.320 --> 28:51.360]  tool developed by AOL, supported by AOL. It's a great tool. It's like Wireshark on top of Elastic.
[28:51.360 --> 28:57.440]  And since Cercata can create full packet capture, it can generate and capture your network
[28:57.440 --> 29:02.020]  traffic. And then you could have Molok pick up the PCAP and ingest it so that now you can
[29:02.020 --> 29:08.720]  use this interface to search for aspects of your traffic over time, however
[29:08.720 --> 29:13.960]  you have your Molok configured to. Of course, if you're familiar with Molok, it also has its
[29:13.960 --> 29:19.420]  own capture capabilities. But again, I like to bring it up because if you already have Cercata
[29:19.420 --> 29:24.460]  deployed, these are capabilities that you might have a system that you've already set up
[29:24.460 --> 29:34.760]  and configured to utilize. Okay, so I think that was my about 25-minute crash course on Cercata
[29:34.760 --> 29:40.720]  and discussing some of the main primary features, what it's capable of, the kind of data that you can
[29:40.720 --> 29:46.940]  get, and how you can utilize that, as well as a VM that you can go and grab and start experimenting
[29:46.940 --> 29:51.920]  with it pretty quickly. At this point in time, though, that's all I wanted to discuss. So if
[29:51.920 --> 29:59.520]  anyone has any questions, I believe the Text Workshops Track 1 is available for questions.
[29:59.520 --> 30:04.640]  Of course, I have my contact information and I'll pull that up again. Please feel free to
[30:04.640 --> 30:09.200]  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:16.060]  Thank you, Josh. Yeah, there's a lot of good discussion in the text chat. One question
[30:16.060 --> 30:21.440]  that popped up that I thought would be good to answer is, is Cercata based on the engine
[30:21.440 --> 30:26.740]  from Snort or is it developed completely different? It's completely different, yeah.
[30:26.740 --> 30:33.120]  There is a lineage that goes back to the Snort days, but it is
[30:33.120 --> 30:38.620]  not a fork, it is a rebuild. So there is a significant number of differences in the engines
[30:39.460 --> 30:45.700]  capabilities and then things like that, rules, syntax, so that they are different. The best
[30:45.700 --> 30:53.000]  thing I could probably tell you to do is under the Cercata Read the Docs. I'm not sure I'll be
[30:53.000 --> 31:02.320]  able to find it just by searching. I think there is a comparison page. There's certainly compatibility
[31:02.320 --> 31:07.700]  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.980]  In case anybody does have any follow-up questions, Josh will be around in the Discord channel. Like
[31:28.980 --> 31:35.780]  he said, it is the techs-workshops-track1 under the Flamingo Hotel group. Just scroll all the
[31:35.780 --> 31:40.300]  way down to the bottom to Flamingo Hotel. Check us out in that channel and he'll be answering
[31:40.300 --> 31:43.960]  questions. Now, Blue Team Village wants to say thank you to everyone that joined
[31:43.960 --> 31:48.120]  and this concludes the Cercata workshop. Thank you.