start	end	text
13880	21260	Hello, everyone. Welcome back. My name is Rubix1138, and I welcome you to Serocata,
21260	31000	an introduction into OpenSoC Capture the Flag tools. I'd like to welcome Josh to the stage
31000	36680	here to talk about Serocata. A reminder, if you are not already in the Discord chat,
36680	43020	please go to BlueTeamVillage.org, click on the links for
44740	52020	DEF CON 28, and join our channel. So let's please give a warm welcome to Josh. Thank you.
53740	58320	All right. Thank you very much for the introduction, and thank you to the Blue
58320	61960	Team Village and all of DEF CON for all of the hard work that I know is going into this,
61960	67100	and the opportunity here to talk to you all today a little bit about Serocata.
67200	72460	So this will be really a brief introduction intended to give you some idea as to what
72460	77400	Serocata is capable of. Hopefully there's a few things that you learn about that you didn't know
77400	83320	it could do. I'm going to use a VM here to demonstrate that. So I have a lot of the text
83320	88780	and all the UIs here fairly large. It should be legible, so you can see that. A little bit about
88780	94940	Serocata then before we get too far into the technology is that Serocata is an open source
94940	99700	project. Everything that you see here that I'll be talking about today is also open source. So
99700	105240	there'll be a few tools I'll touch on beyond Serocata, but most of these are developed and
105240	111560	supported by the OISF, the Open Information Security Foundation. So this is the 501c3
111560	116380	nonprofit that manages and maintains and supports Serocata and all the activity around that. So
116380	125760	we have a very globally diverse team of executive development trainers and others
125760	131620	that support and really make this project happen. There's also a very active community,
131620	137040	and we have a number of different platforms that we have available to get engaged in the community.
137040	141040	And so I would highly encourage you, if this is a new technology to you, to reach out to those
141040	145800	communities and get involved. This is me. You can find me located just about anywhere on the
145800	153200	internet. I am available at this email address as well as on Twitter. But if you search for my
153200	157180	name, you'll probably be able to find me. And please feel free to direct any questions or
157180	163260	anything I can help you with after this presentation in the future to any way you
163260	169840	can get a hold of me. So to get started then, many know Serocata, or if you know Serocata,
169840	176800	you recognize it as an IDS, an intrusion detection system. And likely in the OpenCTF scenario that
176800	181820	you'll be engaging in, what Serocata will be doing then is generating IDS alerts,
181820	187560	intrusion detection alerts. So that is, of course, one of Serocata's primary capabilities and primary
187560	193060	roles. But it can do quite a bit more than that. It can do things like full packet capture. It can
193060	199120	do protocol-specific logging. It can do file identification and extraction. It can do offline
199120	204440	PCAP processing. So you can take a PCAP maybe from our sandbox and run that PCAP through
204840	210440	Serocata to get IDS alerts and other protocol logs. I'm only going to talk for 15-20 minutes
210440	215220	or so. So I want to touch on and give you a real brief demonstration about that capability.
215800	221440	Realize, though, that we could probably spend days going through any one of those aspects. So
222160	226100	again, there's a lot of resources that I can help point you to if that's something that would be of
226100	234580	interest to you. Now, as an IDS, Serocata, again, primarily is generating those IDS alerts. And
234580	242220	with those IDS alerts, then, they come in the form of rules. And rules, then, are simply put.
242220	248320	They're a syntax, a pattern, or a series of patterns that are then applied to your network
248320	255520	traffic. And if those patterns match, an alert is generated. Now, alerts can be for a large,
255520	261460	wide variety of categories. You can have alerts around malicious behavior, but then you can also
261460	268140	have alerts around policy violations or anomalies in your network. Let's say you have non-encrypted
268140	276640	HTTP traffic going over a standard HTTPS, a TLS port, like 443. Not necessarily malicious, but
276640	280800	certainly could be something that you'd want to know about in your environment. So the rules can
280800	285820	be very broad, and they can provide different looks into the traffic in your environment
285820	294660	beyond just the known malicious behaviors. Rules, if you are familiar with things like Yara,
294660	299860	Yara signatures, you write a pattern and you use that Yara rule to match on different things,
299860	307240	that's a lot how the rules work. From a practical perspective, most users are going to get their
307240	312040	rules from a rule source, and they're going to feed them into the engine, and then they're
312040	318420	going to monitor when those alerts are generated. You can, of course, create or construct your own
318420	324660	rules, but that's something that is certainly a capability of the engine. You can define custom
324660	329560	rule sets, but a lot of users are just going to consume those. It is important, of course,
329560	335660	as alerts are generated, as you'll see here in just a moment, to also understand the rule syntax a bit,
335660	341540	at least to the point where you can understand what that rule is telling you. So you have that
341540	346880	ability to look at the rule itself as well. But again, rules are really a topic in and of
346880	352020	themselves, so I want to stay a little bit more focused on the pragmatic side at this point.
352560	359700	Now, I mentioned that rules, the way that we can look at rules is that rules come from
359700	364480	sources. Those sources then can be combined to create rule sets, and those rule sets are
364480	371240	what we feed into the engine, into Suricata. A very popular rule set, an open rule set,
371240	376980	so an open source rule set, is the etopen. And Suricata, by default, will use that rule set.
376980	382020	There are other open source rules that you can go and consume, that you can configure your engine to
382020	387220	use. And then it really becomes up to you to determine the rules that you need or want,
387220	392440	depending on the environment that you're using Suricata in. For example, I use it for a lot of
392440	397980	malware analysis, so I grab pretty much any rule set I can find, because I'm okay with any
397980	403260	individual analysis generating a lot of noise. In a production environment, I'd be a lot more
403260	409280	cautious or careful. The VM that we're in, I maybe jumped ahead of myself just a tad,
409280	416900	the VM that we're in is called CELTS. This is, believe it or not, my system crashed just before
416900	425420	this presentation, so I had to restart. This is also an open source distribution, it's Debian-based,
425420	431460	it's designed to really highlight all of the capabilities of Suricata. So you can, if you're
431460	436000	not familiar with CELTS, or if you're not familiar with Suricata, you can go to Statements Networks,
436000	441940	you can download CELTS Suricata ELK Stack, and you essentially have the VM that you see here
441940	449540	in this demonstration. The only minor differences will be a script that I run, and then I have some
449540	453920	PCAPs in here. You're not going to have any PCAPs when you download this. Otherwise,
453920	459600	everything else should be the same. So that's what CELTS provides you. It's sort of like a
459600	463200	security onion. It doesn't have some of the host-based stuff, and there's a number of differences
463200	471080	in tools. With this, then, you have some interfaces, such as Sirius. And Sirius, then, is a graphical
471080	480340	interface that allows us to manage rule sets. This comes in CELTS. Now, if you were to install
480340	486760	Suricata, at least a more recent version of it, by default, Suricata comes with Suricata Update.
486760	491980	So it's a command line utility that has been developed to manage the rule sets and the rule
491980	496740	sources for your Suricata instance. I'm not going to run that here, because I already have CELTS
497380	502680	set up and installed, or I'm sorry, Sirius, and I don't want to confuse the rule manager. I'm just
502680	510620	going to use one or the other. But if you run the help, dash dash help, you'll see that it has all
510620	515440	of the basic commands that we're going to cover here. We look at updating our sources, we look at
515440	520920	listing sources, we look at enabling sources, and then applying those sources to build the rule set
520920	526460	and deploy it to the engine. Again, so that's what we'll be seeing with Sirius. Now, I mentioned we
526460	533080	have sources, and so we can, if we want to add any different type of public or custom source that is
533080	540540	available, you can do that just by simply selecting these actions. And adding a source is usually as
540540	545720	straightforward as adding the URL where that source is coming from. Now, there are some commercial
545720	551440	rule sets, rule sources, and those then, of course, you have to pay for. Typically, you get an API key
551440	557340	or some way to authenticate before you can use those. Some other examples of rule sets that are
557340	563220	out there, if you go to abuse.ch, which is an awesome project and a lot of great resources,
563620	571520	you can look at the blacklist project. And from there, we can look at the actual list.
571700	576660	And you'll see that there are, for example, in this particular project, a number of rule sets
576660	583940	that are available based off of things like blocking of C2 IPs or J3 fingerprints. Something
583940	589260	to keep in mind, then, as you're looking at the different rule sets that are out there,
589260	595000	you do need to, oftentimes, if you find there is a Suricata specific one,
595000	599500	I would, typically, I would opt over that. A lot of rule sets are going to be compatible,
599500	604180	not only with different versions of Suricata, and there's a fairly significant version change
604180	608860	between 4 and 5, where 5 is the latest, but then a lot of them are compatible between
608860	615940	Suricata and Snort. Some of the more recent rule sets, ETOpen or the Emerging Threats List
616640	624200	rule sets, they are starting to also create Suricata 4 and Suricata 5 rule sets. And the
624200	630320	changes in 5 are all based off of rule syntax. And so, you're getting, likely, more performance out
630320	636920	of the 5.0 rule set. You also have to be careful, because, typically, the 5.0 rule set won't work
636920	642500	with the 4.0 version or the 4.x version of Suricata. So, just some things to keep in mind.
642500	646620	And, again, in general, you'll find a lot of compatibility, but I would always opt for,
646620	653140	if I'm running Suricata, to take a set specifically designed for it. If we go back to Sirius, then,
653140	660240	you can see that we have our sources listed here. Again, it's just a click away, or if you're using
660320	666860	Suricata Update to add those sources. And then, once we have our sources, we can create and manage
666860	673020	our rule set. The rule set, then, is just a combination of rule sources. The default here
673020	678280	in this VM is to take the two sources that we have, add them to this rule set. And we can see
678280	686000	that we have those two sources, and we have just under 21,000 rules. Once we have that configured,
686000	690880	we have to deploy the rule set. We have to make sure that we've downloaded the most recent version,
690880	697740	and then deploy those to the engine. And in this interface, you need to go to the Suricata tab,
697740	704060	and then there's this rule set action. And what will happen here is that it will update,
704060	709740	it will build, and it will push. And what you see with a lot of rule set managers is that they will
709740	714560	combine all the rules that you've told it to use, and they will write it into a single file,
714560	720140	and then deploy that into the location in the file system that Suricata looks for rule files.
720900	727960	Suricata update also does something very similar. And in order to create the actual rule file,
727960	732860	you just run Suricata update. So that will run based off of the current configuration,
732860	740320	update the rule sets, and then write the file for Suricata to use. Now, I mentioned the rule location.
740320	746760	So in order to understand where the rules are written to, maybe we want to confirm that they
746760	750620	are in fact getting updated. So we want to look at the rule files or look at the timestamp on that
750620	757940	rule file. The default location for the Suricata configuration is in etc Suricata. And then in
757940	764360	particular, Suricata.yaml. So there is a yaml file that you can open and look at. And yes,
764360	771060	I did just nano in public. Everything Suricata related is in here. You probably don't need to
771060	775400	get too deep into the configuration file. That's something that will come with time. But definitely
775400	779340	there are some things that you might want to check. Probably one of the most important,
779340	785520	outside from we can look at the rule location here in just a moment, is this home net external net.
785760	791380	If you dig into the rules, the syntax of the rules, they use home net and external net.
791380	797660	And what they are using those variables for is to define the direction, the flow of traffic,
797660	802920	and then when the engine should apply the rule. Should it be on the response? Should it be on
802920	808780	the request? And so that's very important. It also, of course, defines the IP space. And so
808780	815720	the default is to use standard RFC 1918 addresses, internal IP addresses. And again, the default then
815720	820840	for your external network is to just negate your home network. But you want to make sure that these
820840	826520	are correct. So if the environment that you're in or defending is using addresses that fall outside
826520	831900	of this, that's just something that you want to definitely keep in mind. Now, one more quick thing
831900	840260	about the configuration is that the engine supports sub-configuration. And with CELKS,
840260	846460	we do have a sub-configuration, which means that in our primary configuration file, if we include
846460	853960	sub-configurations, these sub-configurations, if they overwrite any configuration options in
853960	859880	the primary, then including the sub-yaml, the sub-config will do that. It'll overwrite in
859880	864820	the primary. So this can become helpful if you have a base configuration that you want to use,
864820	868500	and then you deploy sensors into different areas of your network that have slightly different
868500	875600	requirements based off of the type of traffic that they're seeing. In CELKS, we do have in the
875600	881960	sub-yaml the change to the default rule file. So here you can see that's commented out. If we
881960	887120	go a little bit further, the property default rule path and those rules will be located in
887120	893800	etc-suricata-rules. And it's just going to be a single rules file, Sirius.rules, right? So that's
893800	899180	just a real quick about the configuration. And again, unless you have reason, you probably don't
899180	903940	need to get into it right off the bat, but definitely it's worth checking the whole net
903940	911430	external net and tweaking that if you need to. Going back to the interfaces here,
911900	916560	so we've now looked at different sources. You've got an understanding of where you can
916560	921180	maybe grab some different rule sources. We know the process for updating and pushing those.
921700	926420	Suricata can do a live rule set reload, so you don't necessarily have to restart the engine.
926620	931520	The next thing that we'll do is we'll talk about just some of the protocol parsing and
931520	937480	file identification capabilities. So as I mentioned here just a few minutes ago,
937480	942120	one of the differences with this VM versus the one you would download from the GitHub
942640	949040	is that we do have a couple of scripts that help us with the analysis and then the PCAPs.
949040	955380	So that script is Siri.sh, although it's a relatively straightforward script in that it's
955380	960340	running Suricata. Essentially, the main goal of it is to run Suricata in offline mode.
961540	987220	Let me see... I forgot what PCAP I want to use. There we go.
988820	992580	So one of the other... again, one of the capabilities I mentioned is that Suricata
992580	998200	can run in offline mode, which means that you can feed it a PCAP and it'll process that PCAP
998200	1003640	as if it were, you know, analyzing the traffic live on the network. And then you get the same
1003640	1009300	results from Suricata generating its output. Now, one thing I haven't mentioned yet is where
1009300	1016620	Suricata generates all of its output. The default is to drop all of the data into a JSON file. It's
1016620	1023680	the eve.json. And so the alerts, the protocol logs, file stats, anything that the engine generates,
1023680	1029980	it will be in that eve.json. The JSON file then is very flexible. It's a very flexible file format
1029980	1036900	because you can do things like submit it, just the JSON file itself to Elastic and other tools
1036900	1042060	that allow you then to take that data and build, you know, visualizations and dashboards and then
1042060	1049520	parse it in different ways. Now, the PCAP capability then is, again, this is offline mode.
1049520	1054640	And when we run a PCAP, it's going to use the original timestamp from the PCAP. So we just need
1054640	1060320	to keep that in mind because as we look at some of these interfaces, we need to oftentimes adjust
1060320	1065920	the time and date. So if I look at a dashboard and it's looking at the last 24 hours, even though I
1065920	1071000	just ran the PCAP, if the PCAP was from last week, I need to go back and adjust the timestamps,
1071000	1076500	the filters, and that UI to go back to last week. We can run this script now. And again, main purpose
1076500	1081280	is to get the PCAP running through Cercata in offline mode. So Cercata is going to load,
1081280	1085260	the engine is going to load as it would normally, and it's going to load the rule set that it's
1085260	1091920	configured to utilize, and then it's going to process the PCAP. Now, as that is loading,
1091920	1099180	what we'll find is another open source project that is maintained and developed by one of the
1100080	1106420	Cercata core developers is called Evebox. And Evebox provides you with a graphical ability
1106420	1112000	then to look at basically alerts and some of the other data, the protocol data and the flow data
1112000	1118800	that Cercata is generating. So we'll look at the end of the script. The script does
1118800	1125760	one more thing before it finishes, and that it queries the eve.json file, looks for any alerts
1125760	1130960	that were generated, and prints them here to our terminal. Now, that's great. It's helpful to see
1130960	1135140	those alerts right away. But again, it's kind of hard to do all this work in a terminal, and it
1135140	1140560	probably doesn't scale that well. So that's why we would switch to something like Evebox. Now,
1140560	1145760	with Evebox, and it's going to be a little bit tight here in the UI, just because I have the
1145760	1152560	zoom up high. But what we're seeing now are the alerts that were generated. So not only do we see
1152560	1158700	specific alerts for events that happened, but we see other alerts. And in this case,
1158700	1164700	we see other alerts around the same time that maybe this first alert was generated.
1164700	1170580	So that helps us to possibly build a little bit better context around each individual alert.
1170580	1177840	We can see here that we have several. In fact, these four right here are all based around
1177840	1184400	an executable download. If we scroll up a little bit further, then we'll see that after that
1184400	1191620	executable appears to be downloaded, we have alerts around Fyodo Tracker and Win32 Emotet
1191620	1198860	command and control activity. As you start to understand what the alerts are telling you,
1198860	1204800	you can start to read into them a bit more. We can see that this particular alert here, it's an
1204800	1210660	info alert. There's color coding to help you visually gauge the severity of the alert. So this
1210660	1216020	is an info one. It's a different category that the alerts are categorized in. An executable is
1216020	1222360	retrieved with minimal HTTP headers, right? So this is an alert. And in one event, the download
1222360	1228320	of an executable can actually generate several alerts. So this is telling you that something
1228320	1234140	downloaded an executable file, and there were very minimal HTTP headers. And why this becomes
1234140	1239640	significant is because oftentimes, our scripts like PowerShell, for example, which is regularly
1239640	1245500	used from an office document to download executables, by default, they don't use very
1245500	1250520	many HTTP headers. Typically, it's the get request header, the first header that's needed with the
1250520	1256720	HTTP and the version, and then maybe the host. And so that is telling you that maybe where this
1256720	1261780	originated from was something like a malicious office document, which actually is the case here.
1261780	1266400	So those can definitely help to add additional context. And again, we can get many alerts around
1266620	1274640	a singular event. We can select any of the alert and get a little bit deeper into the analysis.
1274640	1284320	So if we select the ET policy, PE, or DLL download, this allows us then to get information
1284320	1290680	about the traffic that matched from this alert. So we see, of course, the timestamp, we see the
1290680	1295100	sensor that it came from. So if you're working in a multi-sensor environment, we have the protocol
1295100	1303560	TCP, but this was HTTP, we have the source and the destination ports, the flow ID, we'll take a look
1303560	1310040	at the flow ID here in just a moment, the signature, the category, as well as the signature ID. And
1310040	1315320	what's helpful about having the signature ID available is that not only could we use this
1315320	1321500	in this particular interface, we can filter off of that. So we could look back in time over
1321500	1327720	however much data our environment is collecting on to maybe filter off of a specific signature.
1327720	1335840	But then we can also take that signature ID and we can use... we'll actually use Sirius to do this.
1335840	1343920	We can pull up that rule itself and select the rule and then look at the rule syntax.
1344220	1350660	So we can now begin to understand exactly what it is in this rule that was matching on the traffic.
1350660	1354980	So if we have to dig a little bit deeper to provide a little bit better context and understanding.
1357100	1361540	Okay, so we'll go back. If you continue to scroll down in the interface,
1361540	1367440	you'll have different values from the HTTP request. So that's some of the protocol parsing
1367440	1373920	and logging capability that it has. You might have the response body. We can very clearly see
1373920	1379260	if you're familiar with PE files anyway, and we can certainly see the PE file that was returned.
1379300	1385980	And then, you know, scrolling down further, you'll eventually get to the raw JSON. So PE files are a
1385980	1392960	bit large, but here you have them, just the raw JSON data that correlates to this alert.
1393380	1397660	So if there's, for some reason, maybe some data that you know is in Suricata or it's being
1397660	1402560	generated, it's in the EVE.JSON, it's not there. In the UI, you can come down here and check.
1402820	1406960	It's also a good place to look just to get a better understanding of all of the data that
1406960	1411140	Suricata is generating. And maybe there are some fields that it's not producing for you
1411140	1415840	that you might need. And then there actually are ways to customize the engine to help correct that.
1415980	1423700	Now, I mentioned the flow ID. So we can select the flow ID. And what that will do is essentially
1423700	1429200	give us the ability to take a step back and to look at all of the other, you know, events that
1429200	1437560	are around this particular flow. So not only now do we see the alerts, but we also see the different
1438140	1443140	different type of events. We have the flow information, we have the HTTP information,
1443140	1450700	we even have file information. So we can look at the HTTP request, for example. And now we can get
1450700	1458800	the host, the URI, maybe the user agent, any of the data that is around the HTTP request itself.
1459080	1466200	Very similarly with the file info. So Suricata has the ability then to not only identify
1466200	1471820	files in the traffic, certain file types, it does have its limitations and everything is
1471820	1478520	available under the read the docs. But then also, it has the ability to extract those files if you
1478520	1484460	want it to. It doesn't do that by default, though. So here we have an executable. We know that it is
1484460	1489160	pretty, you know, we know it's bad because we saw alerts related to EMETET traffic after
1489160	1496140	it was requested and returned. And so now we can look at information about the file.
1497100	1503300	The magic will determine the type of file. So your lib magic telling you the file type.
1503300	1507960	We already knew it was a PE file, but here it confirms that. Of course, if we have PE files
1507960	1512640	that we don't have alerts associated with, then this is another sort of piece of data point that
1512640	1517860	then we know is data that's being generated that we could search on. We have the hash,
1517860	1522380	which is also potentially very helpful because now we could take the hash of the file,
1522380	1529340	and maybe we go and search for that on our favorite threat research platform, such as VirusTotal.
1529340	1535960	So I'll paste the hash in. Now, you'll notice here, this is a PCAP from a week or so ago.
1535960	1541000	And so likely, if it's EMETET, it would have been probably submitted to VirusTotal by now.
1541000	1547140	We don't get any matches. And the reason that that is, is the state is truncated.
1547680	1554800	And so what happens is, by default, Cercata only reads so far into the HTTP response.
1554800	1560460	And because PE files tend to be large and larger than that response, it stops reading at its
1560460	1565600	threshold and then hashes that content. So while it certainly read enough of the file to give us
1565600	1571520	the signature, the magic, the PE file identification, it wasn't able to read all of it.
1571560	1576300	This is done for performance reasons, and it's a very small change in the configuration
1576300	1583360	in order to tell it to read further into the HTTP response. But again, those are determinations that
1583360	1588360	you have to make based off of considerations for your own environment. But that is, again,
1588360	1592780	something that you'll want to recognize and understand. Because if you didn't, and you
1592780	1597840	thought this was in fact the hash of the file, results like this could maybe be a little bit
1597840	1612260	misleading. Let's see here. Okay, in addition then to looking at alerts, again, you have the
1612260	1617840	ability to comment, you have the ability to escalate or archive, you have under your events
1617840	1624560	tab in the UI here, the ability to view any of the protocol logs that have been generated. So
1624560	1630080	if you want to see all of the HTTP, you could select that. If you want to look at just DNS or
1630080	1637220	TLS or SMB, it's all available here, and it allows you to see it again in the interface.
1637440	1642140	This particular PCAP did not have any SMB, so we're certainly not going to see it there.
1642460	1648440	And then there's also some basic alerting or reporting, some dashboards that help with
1649300	1658120	that. And you can see that, again, you'll have a summary of the alerts, the top signatures,
1658120	1665040	the top categories, your top source IPs and desk IPs. And so it can provide you, again, an ability
1665040	1670000	to take a step back further and maybe monitor your environment from a bigger picture, broader
1670000	1679160	perspective. Of course, because the output that Cercata is generating is JSON, you can put it
1679160	1685240	into a pipeline. You can modify, enrich the data. You can submit it directly to Elastic. And from
1685240	1689820	there, you have the ability then to create any number of dashboards or visualizations that you
1689820	1696860	need. With CELKS, CELKS has a number of dashboards and visualizations already built. So if you
1696860	1703080	download CELKS, you can use these dashboards and visualizations for inspiration and ideas to
1703080	1708260	get an understanding or a sense of the type of visualizations that are quite helpful.
1708960	1714000	Kibana is another open source tool that's something that you can utilize. But getting
1714000	1718600	into all of the details of Elastic and Kibana are a bit beyond the scope of this particular
1718600	1724320	workshop. The other tool that I always like to point out is Molok. Molok is another open source
1724320	1731360	tool developed by AOL, supported by AOL. It's a great tool. It's like Wireshark on top of Elastic.
1731360	1737440	And since Cercata can create full packet capture, it can generate and capture your network
1737440	1742020	traffic. And then you could have Molok pick up the PCAP and ingest it so that now you can
1742020	1748720	use this interface to search for aspects of your traffic over time, however
1748720	1753960	you have your Molok configured to. Of course, if you're familiar with Molok, it also has its
1753960	1759420	own capture capabilities. But again, I like to bring it up because if you already have Cercata
1759420	1764460	deployed, these are capabilities that you might have a system that you've already set up
1764460	1774760	and configured to utilize. Okay, so I think that was my about 25-minute crash course on Cercata
1774760	1780720	and discussing some of the main primary features, what it's capable of, the kind of data that you can
1780720	1786940	get, and how you can utilize that, as well as a VM that you can go and grab and start experimenting
1786940	1791920	with it pretty quickly. At this point in time, though, that's all I wanted to discuss. So if
1791920	1799520	anyone has any questions, I believe the Text Workshops Track 1 is available for questions.
1799520	1804640	Of course, I have my contact information and I'll pull that up again. Please feel free to
1804640	1809200	direct any questions to me, any way you can get a hold of me or prefer to get a hold of me.
1809900	1816060	Thank you, Josh. Yeah, there's a lot of good discussion in the text chat. One question
1816060	1821440	that popped up that I thought would be good to answer is, is Cercata based on the engine
1821440	1826740	from Snort or is it developed completely different? It's completely different, yeah.
1826740	1833120	There is a lineage that goes back to the Snort days, but it is
1833120	1838620	not a fork, it is a rebuild. So there is a significant number of differences in the engines
1839460	1845700	capabilities and then things like that, rules, syntax, so that they are different. The best
1845700	1853000	thing I could probably tell you to do is under the Cercata Read the Docs. I'm not sure I'll be
1853000	1862320	able to find it just by searching. I think there is a comparison page. There's certainly compatibility
1862320	1867700	information, but I'm pretty sure somewhere in our Read the Docs there is a Snort versus Cercata.
1867700	1873620	So if you're looking for the high-level big differences, this is a good place to go.
1875900	1882900	Josh, thank you very much and thank you all for sticking through the Cercata workshop.
1882900	1888980	In case anybody does have any follow-up questions, Josh will be around in the Discord channel. Like
1888980	1895780	he said, it is the techs-workshops-track1 under the Flamingo Hotel group. Just scroll all the
1895780	1900300	way down to the bottom to Flamingo Hotel. Check us out in that channel and he'll be answering
1900300	1903960	questions. Now, Blue Team Village wants to say thank you to everyone that joined
1903960	1908120	and this concludes the Cercata workshop. Thank you.