WEBVTT 0:00:04.820000 --> 0:00:06.240000 Effectively using ELK. 0:00:06.240000 --> 0:00:10.040000 So now that you've got an introduction, at least a formal introduction 0:00:10.040000 --> 0:00:17.260000 to the ELK stack or Elastic Stack, we are now, it's sort of the perfect 0:00:17.260000 --> 0:00:23.140000 moment for you to get first -hand experience with ELK. 0:00:23.140000 --> 0:00:29.460000 But this is not just going to be random navigation and the tour of the 0:00:29.460000 --> 0:00:34.400000 interface, you're actually going to be learning how to use ELK or how 0:00:34.400000 --> 0:00:40.100000 to effectively use ELK to search for specific activity. 0:00:40.100000 --> 0:00:46.100000 That's very closely related to what you'll be doing in incident response. 0:00:46.100000 --> 0:00:50.660000 So in order to do this, we're going to be utilizing a lab. 0:00:50.660000 --> 0:00:54.480000 And this video has a lab associated with it. 0:00:54.480000 --> 0:00:57.340000 The lab is titled Effectively Using ELK. 0:00:57.340000 --> 0:01:00.740000 It's going to be just below this video. 0:01:00.740000 --> 0:01:04.240000 So first things first, let me give you a brief as to what the scenario 0:01:04.240000 --> 0:01:07.740000 is for the lab, because there needs to be one, especially when you're 0:01:07.740000 --> 0:01:12.460000 talking about an incident or detection as it were. 0:01:12.460000 --> 0:01:14.020000 So here's the scenario. 0:01:14.020000 --> 0:01:19.060000 The organization that you work for is evaluating a customized ELK stack 0:01:19.060000 --> 0:01:23.860000 as a SIEM solution to enhance its intrusion detection capabilities. 0:01:23.860000 --> 0:01:27.760000 And the SOC manager has tasked you with getting familiar with the ELK 0:01:27.760000 --> 0:01:30.460000 stack and its detection capabilities. 0:01:30.460000 --> 0:01:34.440000 And he has also tasked you with translating common attacker behavior into 0:01:34.440000 --> 0:01:40.220000 ELK searches. So essentially, this is what you'd consider generally speaking, 0:01:40.220000 --> 0:01:46.380000 I wouldn't call it threat hunting, but in the process of testing out a 0:01:46.380000 --> 0:01:53.980000 SIEM, what you typically do is you would perform threat emulation or adversary 0:01:53.980000 --> 0:01:59.360000 emulation, sort of use that to emulate or simulate attacks and see whether 0:01:59.360000 --> 0:02:01.160000 the SIEM is picking it up. 0:02:01.160000 --> 0:02:06.020000 But more importantly, we're sort of at the stage prior to that where we're 0:02:06.020000 --> 0:02:09.180000 essentially going to be performing the searches to see whether we can 0:02:09.180000 --> 0:02:13.900000 actually find specific adversary or attacker activity. 0:02:13.900000 --> 0:02:18.360000 In this case, we're not going to be simulating any attack activity, a 0:02:18.360000 --> 0:02:25.540000 dataset containing a dataset that's comprised of logs from various systems 0:02:25.540000 --> 0:02:32.020000 has already been ingested into the ELK stack or the ELK deployment that 0:02:32.020000 --> 0:02:34.640000 we're going to be using. 0:02:34.640000 --> 0:02:41.820000 And our job is to again, leverage ELK to find various bits of adversary 0:02:41.820000 --> 0:02:47.340000 or attacker activity as a way of learning how to use ELK. 0:02:47.340000 --> 0:02:54.760000 And more importantly, in addition to that, giving you an idea as to what 0:02:54.760000 --> 0:02:59.480000 detection looks like, of course, it is not directly related to response, 0:02:59.480000 --> 0:03:05.440000 but having the ability to look for specific activity based on a broad 0:03:05.440000 --> 0:03:09.340000 variety of criteria is very, very important. 0:03:09.340000 --> 0:03:14.300000 So you may be asking, well, what type of adversary activity are we searching 0:03:14.300000 --> 0:03:20.820000 for? Well, luckily for us, this lab has certain objectives or tasks, as 0:03:20.820000 --> 0:03:26.480000 it were, that whose job or whose responsibilities to do exactly that show 0:03:26.480000 --> 0:03:29.580000 you how to use ELK. 0:03:29.580000 --> 0:03:37.200000 And more importantly, I should say how to use ELK to search for specific 0:03:37.200000 --> 0:03:44.340000 adversary activity or attack activity or behaviors it were. 0:03:44.340000 --> 0:03:46.580000 So there's quite a few tasks here. 0:03:46.580000 --> 0:03:52.320000 The first two are specifically geared towards guiding you on how to, as 0:03:52.320000 --> 0:03:58.020000 it says here, add any fields, modify the fields that you see when using 0:03:58.020000 --> 0:04:04.440000 kibana to essentially enhance your the data, which is very important. 0:04:04.440000 --> 0:04:08.660000 Secondly, create an actionable visualization. 0:04:08.660000 --> 0:04:13.220000 And this is, you know, again, just using the data and creating visualizations. 0:04:13.220000 --> 0:04:17.360000 The ones I've highlighted, or the ones that are bold are the ones that 0:04:17.360000 --> 0:04:21.920000 I'm going to be focusing on, not for any specific reason, but just, you 0:04:21.920000 --> 0:04:24.840000 know, firstly, because there's quite a few, and I don't want this video 0:04:24.840000 --> 0:04:28.600000 to, you know, sort of go or be longer than it should be. 0:04:28.600000 --> 0:04:32.140000 Secondly, I also want to give you the opportunity to, you know, go through 0:04:32.140000 --> 0:04:37.720000 the other tasks yourself to better understand ELK, because again, handholding 0:04:37.720000 --> 0:04:42.220000 is fine. In so far as I'm showing you the fundamentals of writing a search 0:04:42.220000 --> 0:04:49.660000 query, but you need to be able to derive, you know, a lot more information 0:04:49.660000 --> 0:04:54.880000 or essentially deduce what the task is asking you to do in relation to 0:04:54.880000 --> 0:04:59.820000 the, you know, the logs or the operating system logs that you're dealing 0:04:59.820000 --> 0:05:03.520000 with. So in this case, it's going to be windows. 0:05:03.520000 --> 0:05:05.560000 So hopefully that makes it easier. 0:05:05.560000 --> 0:05:12.180000 So one final thing I'd like to point out is that this lab already has, 0:05:12.180000 --> 0:05:16.380000 you know, the tasks laid out in the lab tasks tab. 0:05:16.380000 --> 0:05:18.580000 You also have the solution. 0:05:18.580000 --> 0:05:21.800000 So you can go through that in written format if you want, but those can 0:05:21.800000 --> 0:05:29.280000 be a little bit difficult to So with that being said, as I mentioned, 0:05:29.280000 --> 0:05:33.540000 this lab or the lab in question is going to be just below this video and 0:05:33.540000 --> 0:05:39.200000 is again aptly titled the same as this video, which is effectively using 0:05:39.200000 --> 0:05:43.980000 ELK. So when you start up the lab and you open it up, you'll be, you know, 0:05:43.980000 --> 0:05:48.080000 directed or you will be provided with in browser access to a Kali Linux 0:05:48.080000 --> 0:05:54.660000 system, upon which you can access the ELK deployment on demo.ini.local 0:05:54.660000 --> 0:05:57.580000 via browser on port 5601. 0:05:57.580000 --> 0:06:00.560000 You don't need to authenticate and you'll be pretty much good to go. 0:06:00.560000 --> 0:06:04.480000 So I'm going to start my lab and I'll see you in there in a couple of 0:06:04.480000 --> 0:06:07.920000 seconds. All right. 0:06:07.920000 --> 0:06:09.720000 So I'm currently within the lab environment. 0:06:09.720000 --> 0:06:23.720000 And as I mentioned, you just need to open up to the ELK deployment, more 0:06:23.720000 --> 0:06:30.100000 specifically kibana, which as you know, as explained in the previous video, 0:06:30.100000 --> 0:06:34.340000 when we were introducing or getting an introduction to the ELK stack kibana 0:06:34.340000 --> 0:06:39.820000 is sort of the front end interface for the ELK stack and allows us to 0:06:39.820000 --> 0:06:41.320000 do quite a bit of stuff. 0:06:41.320000 --> 0:06:44.400000 So let's dive into the lab tasks. 0:06:44.400000 --> 0:06:47.800000 As I mentioned, I'm only going to be focusing on a couple of them. 0:06:47.800000 --> 0:06:51.600000 And there's a couple of important things that, you know, I need to point 0:06:51.600000 --> 0:06:56.060000 out that may not have been explained in the lab documentation. 0:06:56.060000 --> 0:07:00.060000 So first things first, you know, we'll get started with task one, which 0:07:00.060000 --> 0:07:06.260000 is, you know, adding, you know, or playing around with the fields, you 0:07:06.260000 --> 0:07:10.240000 know, that you see fit and I'll explain why that's important in order 0:07:10.240000 --> 0:07:12.560000 to enhance your understanding of the data. 0:07:12.560000 --> 0:07:15.920000 So first things first, we're going to go into discover that's where we 0:07:15.920000 --> 0:07:18.240000 can essentially access all the logs. 0:07:18.240000 --> 0:07:26.260000 And when you click on this here, you'll see that it's empty and or, you 0:07:26.260000 --> 0:07:30.220000 know, we're not getting any results or logs or anything like that. 0:07:30.220000 --> 0:07:34.040000 And that's because, as I mentioned, the data set that's been ingested 0:07:34.040000 --> 0:07:41.240000 was ingested manually, or, you know, was what we're dealing with here 0:07:41.240000 --> 0:07:46.260000 is a data set that and it was ingested manually. 0:07:46.260000 --> 0:07:50.660000 And you know, it wasn't necessarily from any particular hosts that were 0:07:50.660000 --> 0:07:52.760000 pushing the logs or anything like this. 0:07:52.760000 --> 0:07:54.820000 And this was ingested quite a while ago. 0:07:54.820000 --> 0:08:01.060000 So you want to go into the, we want to go into the time picker here on 0:08:01.060000 --> 0:08:05.420000 the top right and go to relative and set this to 15 years ago. 0:08:05.420000 --> 0:08:11.640000 And we should see the logs, they were ingested or the data was ingested 0:08:11.640000 --> 0:08:14.620000 in 2018. So there we are, we can now see the logs. 0:08:14.620000 --> 0:08:17.200000 And now we're sort of dealing with task one. 0:08:17.200000 --> 0:08:22.180000 So, you know, adding the fields on the left pane here, if you click on 0:08:22.180000 --> 0:08:25.200000 this dropdown, or you can see it saying log stash, right? 0:08:25.200000 --> 0:08:27.820000 So this is where you have your indexes. 0:08:27.820000 --> 0:08:31.300000 And in this case, we have a first index log stash, which we're currently 0:08:31.300000 --> 0:08:40.900000 operating with, or, you know, analyzing here or searching as the one we're 0:08:40.900000 --> 0:08:45.080000 interested in, in with regards to this particular lab is log stash. 0:08:45.080000 --> 0:08:47.800000 So you may be asking what an index is. 0:08:47.800000 --> 0:08:51.560000 And there's a good reason why I didn't explain it earlier. 0:08:51.560000 --> 0:08:57.720000 An index in, in elastic search specifically is like a database table, 0:08:57.720000 --> 0:09:01.400000 if you're familiar with what that is in relational databases, what that 0:09:01.400000 --> 0:09:04.040000 means is that it stores documents. 0:09:04.040000 --> 0:09:10.940000 And in the context of the, the elk stack document is essentially a JSON 0:09:10.940000 --> 0:09:12.960000 based record of data. 0:09:12.960000 --> 0:09:16.520000 So think of your logs, metrics or events, it's just another way of referring 0:09:16.520000 --> 0:09:21.320000 to logs, at least in the context of instant response. 0:09:21.320000 --> 0:09:25.980000 So typically, you know, if set up correctly, you're going to see, especially 0:09:25.980000 --> 0:09:29.540000 on a modern version of elk, you're going to see, you know, especially 0:09:29.540000 --> 0:09:34.900000 if you're using various beats to essentially ingest logs, or for, you 0:09:34.900000 --> 0:09:38.360000 know, log shipping as it were, or collection, I should say, you would 0:09:38.360000 --> 0:09:43.560000 see an index, you know, for windlog beat, file beat, so on and so forth. 0:09:43.560000 --> 0:09:45.940000 In this case, you know, we're just using log stash. 0:09:45.940000 --> 0:09:50.700000 It's not really important, but it's quite important for you to understand, 0:09:50.700000 --> 0:09:54.280000 or to have an idea of. 0:09:54.280000 --> 0:09:57.600000 And then of course, we have the fields, which I need to explain. 0:09:57.600000 --> 0:10:00.700000 So you'll see over here, there's the available fields. 0:10:00.700000 --> 0:10:04.420000 And you can, you know, scroll through them now fields are essentially 0:10:04.420000 --> 0:10:08.180000 key value pairs in each document or log as it were. 0:10:08.180000 --> 0:10:13.400000 So here you have your logs and here you have your, you essentially have 0:10:13.400000 --> 0:10:18.820000 a timeline where you can essentially view, you know, you know, the account 0:10:18.820000 --> 0:10:25.460000 of logs against the, you know, a particular timestamp in sort of a bar 0:10:25.460000 --> 0:10:29.540000 graph format, but going back to what I was saying, the fields are, you 0:10:29.540000 --> 0:10:33.100000 know, key value pairs, you know, in each document. 0:10:33.100000 --> 0:10:40.840000 So in each log, and in the context of, you know, kibana or this particular 0:10:40.840000 --> 0:10:46.700000 view, they're essentially represent columns of this particular table, 0:10:46.700000 --> 0:10:49.420000 you know, from in relational terms. 0:10:49.420000 --> 0:10:53.960000 So what that means is when you click on, when you're navigating through 0:10:53.960000 --> 0:10:57.520000 the fields here that they that are available, you have the ability to, 0:10:57.520000 --> 0:11:01.360000 you know, sort of improve your understanding of what you're seeing. 0:11:01.360000 --> 0:11:04.360000 So by default, this is a log here or a document. 0:11:04.360000 --> 0:11:09.060000 The only fields that we have are the timestamp, which, you know, is required. 0:11:09.060000 --> 0:11:11.760000 It's there by default and the source, right? 0:11:11.760000 --> 0:11:15.500000 So you can click on the arrow here to learn more about a particular log 0:11:15.500000 --> 0:11:20.700000 and or document in this case, you have the table view and the JSON view, 0:11:20.700000 --> 0:11:22.940000 which is sort of a raw format. 0:11:22.940000 --> 0:11:26.620000 And this contains all, you know, information pertinent to this particular 0:11:26.620000 --> 0:11:32.860000 log and it's sorted organized in the, in the form of fields, which as 0:11:32.860000 --> 0:11:36.620000 I mentioned, our key values, or, you know, key value pairs, which means 0:11:36.620000 --> 0:11:44.620000 you have the field and then the value, right? 0:11:44.620000 --> 0:11:49.800000 So the field name, computer name, and it's fairly obvious what the value 0:11:49.800000 --> 0:11:53.260000 or what this represents in it, you know, represents the computer name 0:11:53.260000 --> 0:11:54.040000 or the host name. 0:11:54.040000 --> 0:11:58.040000 In this case, we can see the value here for the computer name pertinent 0:11:58.040000 --> 0:12:03.380000 to this particular log or document is, you know, Windows 2012 DC 01, test 0:12:03.380000 --> 0:12:09.920000 domain, etc. And you have plenty of, you have plenty of fields here. 0:12:09.920000 --> 0:12:11.860000 Now there's different types of fields. 0:12:11.860000 --> 0:12:15.940000 You have your text fields, which are typically used or analyzed for, you 0:12:15.940000 --> 0:12:17.880000 know, full text search. 0:12:17.880000 --> 0:12:19.800000 You have keyword fields. 0:12:19.800000 --> 0:12:23.940000 These are, you know, typically used when you're doing exact match searches. 0:12:23.940000 --> 0:12:27.140000 And they're quite easy to identify. 0:12:27.140000 --> 0:12:31.760000 These are, if you highlight, if you go over this, or you take a look at 0:12:31.760000 --> 0:12:38.820000 the field names here, you'll see that next to them, you have this, this 0:12:38.820000 --> 0:12:41.320000 indicator. So you have T, right? 0:12:41.320000 --> 0:12:46.140000 So that's typically in the indicator of a text field. 0:12:46.140000 --> 0:12:50.020000 In this particular case, I'm not too sure. 0:12:50.020000 --> 0:12:54.700000 But the key point that I wanted to make is, so you have your text fields, 0:12:54.700000 --> 0:13:01.200000 keyword fields, examples would be things like, you know, for example, 0:13:01.200000 --> 0:13:04.200000 event, data, object server. 0:13:04.200000 --> 0:13:09.660000 And then you have numeric or date fields, which allow, you know, allow 0:13:09.660000 --> 0:13:15.760000 for you to, you know, run a range of searches or queries, and very useful 0:13:15.760000 --> 0:13:17.900000 for things like time based filtering. 0:13:17.900000 --> 0:13:21.600000 So for example, that would be the timestamp. 0:13:21.600000 --> 0:13:24.180000 And you can see that's accurately highlighted here. 0:13:24.180000 --> 0:13:26.320000 So that's a numerical date field. 0:13:26.320000 --> 0:13:29.820000 So this little icon sort of represents the types of fields that you're 0:13:29.820000 --> 0:13:33.260000 dealing with. Now, one key thing that I want to point out, and this is 0:13:33.260000 --> 0:13:39.460000 very important, because in one L collab, you'll see different field names. 0:13:39.460000 --> 0:13:42.340000 And in the other, you know, you'll see different field names. 0:13:42.340000 --> 0:13:46.100000 And you may be confused as to, you know, why the field names are different, 0:13:46.100000 --> 0:13:50.680000 because field names are, as you can tell, quite important in your analysis. 0:13:50.680000 --> 0:13:54.500000 The reason that you have, you know, different field names, or you'll find 0:13:54.500000 --> 0:14:01.040000 this variance is because in elk field names can be both predefined and 0:14:01.040000 --> 0:14:04.280000 custom, depending on the data source and how it is ingested. 0:14:04.280000 --> 0:14:07.780000 So in this case, as I mentioned, this is a custom data source that was 0:14:07.780000 --> 0:14:14.040000 ingested. And, you know, you have what I would call predefined custom 0:14:14.040000 --> 0:14:16.340000 fields in addition to predefined fields. 0:14:16.340000 --> 0:14:19.560000 So the predefined fields will remain the same. 0:14:19.560000 --> 0:14:22.600000 And how do you know, or how do you distinguish predefined fields from 0:14:22.600000 --> 0:14:27.260000 custom fields? Well, the predefined fields remain the same because they 0:14:27.260000 --> 0:14:30.960000 come from the standard data shippers like win log beat file beat audit 0:14:30.960000 --> 0:14:35.360000 bit, which means if you move from one elk deployment to the other, they, 0:14:35.360000 --> 0:14:37.520000 you know, they'll pretty much remain the same. 0:14:37.520000 --> 0:14:42.940000 And they're essentially based on the ECS or elastic common schema, which 0:14:42.940000 --> 0:14:46.060000 standardizes field names across different data types. 0:14:46.060000 --> 0:14:48.280000 And then you have your custom fields. 0:14:48.280000 --> 0:14:52.720000 This is typically the case when, again, you are passing logs with log 0:14:52.720000 --> 0:14:55.740000 stash or custom ingest pipelines. 0:14:55.740000 --> 0:14:59.480000 And you can index data from custom, you know, this allows for you to index 0:14:59.480000 --> 0:15:03.100000 data from custom applications or, you know, unstructured log sources. 0:15:03.100000 --> 0:15:07.880000 And in this case, that's exactly the case, because, you know, as I mentioned, 0:15:07.880000 --> 0:15:15.360000 in this particular case, the data set was in, we ingested a, you know, 0:15:15.360000 --> 0:15:20.040000 a custom data set or this lab has a custom dates ingested with log stack. 0:15:20.040000 --> 0:15:22.800000 So I just wanted to point that out now. 0:15:22.800000 --> 0:15:28.160000 In terms of what fields we should add or can add to make sense of what 0:15:28.160000 --> 0:15:31.260000 we're looking at in terms of the logs, it goes without saying that because 0:15:31.260000 --> 0:15:35.780000 we're dealing with a windows, we're dealing with logs from a windows system 0:15:35.780000 --> 0:15:38.900000 or a group of windows systems, we want the event ID. 0:15:38.900000 --> 0:15:42.740000 And in this case, this particular field, it looks custom to me. 0:15:42.740000 --> 0:15:48.340000 So we can add that and when you click on add, it's now going to add a 0:15:48.340000 --> 0:15:56.020000 new column that represents the event ID, the event ID that is specific 0:15:56.020000 --> 0:15:58.920000 to each log here or document, if you will. 0:15:58.920000 --> 0:16:05.840000 So you can see that this log here, this document has an event ID of 4656. 0:16:05.840000 --> 0:16:08.800000 And you can sort of use that on your knowledge and understanding of windows 0:16:08.800000 --> 0:16:12.140000 event IDs to understand what this log represents. 0:16:12.140000 --> 0:16:15.060000 Okay, so hopefully that makes sense. 0:16:15.060000 --> 0:16:22.180000 And then you have additional ones like, for example, let's go and take 0:16:22.180000 --> 0:16:28.300000 a look at some interesting ones here that is probably useful to add. 0:16:28.300000 --> 0:16:33.400000 One could be the, let's see, event data binary. 0:16:33.400000 --> 0:16:37.000000 Actually, no, we want the image and I'll explain what these are. 0:16:37.000000 --> 0:16:38.680000 So we have image. 0:16:38.680000 --> 0:16:46.240000 Let's go ahead and add the event data command line field right over here. 0:16:46.240000 --> 0:16:50.540000 So what these do, event data image, if you click on any one of these logs 0:16:50.540000 --> 0:16:56.060000 that has data, or, you know, that has information in the event data image 0:16:56.060000 --> 0:17:01.440000 column, you can actually go to where it's represented here. 0:17:01.440000 --> 0:17:08.280000 What this represents is, you know, as it says, the image associated with 0:17:08.280000 --> 0:17:11.620000 this log in windows, a parlance, the image is referring to the binary 0:17:11.620000 --> 0:17:16.880000 or executable, you know, pertinent, you know, the executable. 0:17:16.880000 --> 0:17:21.680000 So in this case, what's this, this is telling us is this, for this particular 0:17:21.680000 --> 0:17:26.380000 log, the, the image you're executable is, you know, file beat, which is 0:17:26.380000 --> 0:17:28.500000 C program files, file beat. 0:17:28.500000 --> 0:17:32.280000 And then you have the object name, which is something a little bit different. 0:17:32.280000 --> 0:17:35.660000 But if you go to the message here, this is where you can find more information 0:17:35.660000 --> 0:17:40.400000 about the actual log or in the, in the context of elk, they're called 0:17:40.400000 --> 0:17:44.280000 documents, not logs, but I'll, I'll alternate between the two. 0:17:44.280000 --> 0:17:48.740000 So you can see, based on the message here, you can see a handle to an 0:17:48.740000 --> 0:17:52.180000 object was requested, you can see the object in this case is C window 0:17:52.180000 --> 0:17:57.700000 system 32 DHCP, process information, this is where you have the image 0:17:57.700000 --> 0:18:02.000000 name, so file beat, so on and so forth. 0:18:02.000000 --> 0:18:05.140000 And then you have the process ID, all that good stuff. 0:18:05.140000 --> 0:18:07.240000 And the type is a Windows event log. 0:18:07.240000 --> 0:18:14.440000 So excellent. So you can see how the fields are essentially, or not essentially 0:18:14.440000 --> 0:18:19.980000 are very useful in helping you understand what you're looking at, right? 0:18:19.980000 --> 0:18:24.740000 So, not helping you understand the enhancing your understanding of the 0:18:24.740000 --> 0:18:29.380000 data or the logs, because previously, you know, you don't know what you're 0:18:29.380000 --> 0:18:33.040000 dealing with, you just have the time stand, but now we sort of getting 0:18:33.040000 --> 0:18:36.760000 a better idea of what we're dealing with, another good idea, or another 0:18:36.760000 --> 0:18:39.120000 good field to add is probably the host. 0:18:39.120000 --> 0:18:44.960000 Let's see if we have any info that's, that looks like a predefined field. 0:18:44.960000 --> 0:18:47.440000 So we'll probably not get, let's remove that column. 0:18:47.440000 --> 0:18:49.960000 By the way, if you want to move these around, you can use the arrow to 0:18:49.960000 --> 0:18:53.020000 move it to the left or to the right, depending on where the column you 0:18:53.020000 --> 0:18:54.740000 want to move is situated. 0:18:54.740000 --> 0:18:58.420000 You can also remove the field if you want, or in this case, in this view, 0:18:58.420000 --> 0:18:59.720000 it's a column now. 0:18:59.720000 --> 0:19:03.580000 But let's take a look at one of these logs as an example to understand 0:19:03.580000 --> 0:19:05.960000 what other field we can add. 0:19:05.960000 --> 0:19:09.000000 So computer name is probably a useful one to add. 0:19:09.000000 --> 0:19:11.840000 Let's see if we can find it here. 0:19:11.840000 --> 0:19:15.360000 So that's a predefined one. 0:19:15.360000 --> 0:19:20.480000 So one second, no, that would be just up here. 0:19:20.480000 --> 0:19:22.380000 There we are, computer name. 0:19:22.380000 --> 0:19:25.700000 So we can add that now, and we now know, you know, in this case, what 0:19:25.700000 --> 0:19:32.140000 each log or the system that the log is coming from or pertinent to. 0:19:32.140000 --> 0:19:38.000000 So in this case, we can see we have one log here that is coming from victim 0:19:38.000000 --> 0:19:47.400000 .testdomain.com. This data set contains logs or contain logs from an active 0:19:47.400000 --> 0:19:48.720000 directory environment. 0:19:48.720000 --> 0:19:51.480000 So multiple systems within the active directory environment. 0:19:51.480000 --> 0:19:55.880000 So now things are starting to get a lot more interesting. 0:19:55.880000 --> 0:19:59.800000 Okay, so that's task one that I've sort of handled. 0:19:59.800000 --> 0:20:03.360000 I'll not be dealing with visualization because that's really not important 0:20:03.360000 --> 0:20:08.620000 at this point. We're now going to get into task three, which is one that 0:20:08.620000 --> 0:20:11.980000 I think is really, really cool because it will teach you a lot about what's 0:20:11.980000 --> 0:20:16.240000 going on. So task three, if you take a look at the tasks in the lab documentation 0:20:16.240000 --> 0:20:23.320000 or the tasks tab is all about creating a search to identify files that 0:20:23.320000 --> 0:20:25.340000 are named like system processes. 0:20:25.340000 --> 0:20:29.660000 And more specifically, based on the description of the task, it says that, 0:20:29.660000 --> 0:20:33.480000 you know, it's a known fact that attackers try to blend in by naming their 0:20:33.480000 --> 0:20:38.700000 malware like legitimate windows processes, essentially masquerading to 0:20:38.700000 --> 0:20:40.440000 evade detection, right? 0:20:40.440000 --> 0:20:46.040000 And evade detection by whom, by the SOC analysts using a C and as well 0:20:46.040000 --> 0:20:48.720000 as incident responders to a certain extent. 0:20:48.720000 --> 0:20:51.820000 So how do we search for specific activity? 0:20:51.820000 --> 0:20:56.400000 Well, we use, we can create an elk search, right? 0:20:56.400000 --> 0:21:02.780000 And one hint that's been added in relation to this task is that it's fairly 0:21:02.780000 --> 0:21:08.960000 obvious that such files will not reside where the legitimate counterparts 0:21:08.960000 --> 0:21:14.200000 are located. So for example, if a an attacker is trying to, you know, 0:21:14.200000 --> 0:21:28.020000 masquerade and masquerade by naming their malware or their C host is located 0:21:28.020000 --> 0:21:34.240000 in reality. So now that we've sort of understood that we can get started 0:21:34.240000 --> 0:21:38.980000 with, you know, creating the search and it's not as simple as just copying 0:21:38.980000 --> 0:21:42.280000 and pasting, you actually need to understand what you're doing, what you're 0:21:42.280000 --> 0:21:46.760000 looking for, where this information is stored, what fields to use and 0:21:46.760000 --> 0:21:51.680000 remember, feel custom fields are going to be different across, you know, 0:21:51.680000 --> 0:21:53.460000 different seams. 0:21:53.460000 --> 0:21:58.380000 And so you need to be, you need to be aware of what fields to use based 0:21:58.380000 --> 0:22:01.100000 on the data that they represent. 0:22:01.100000 --> 0:22:05.180000 Okay, now before we do anything crazy, let me show you how to write a 0:22:05.180000 --> 0:22:09.940000 search. So what if you wanted to write a search to only list logs with 0:22:09.940000 --> 0:22:13.840000 that with the event ID of let's go with 5140? 0:22:13.840000 --> 0:22:15.460000 All right, so how would we do that? 0:22:15.460000 --> 0:22:18.700000 Well, we can do that by specifying the name of the field, remember key 0:22:18.700000 --> 0:22:22.980000 value pairs. So we say event underscore ID. 0:22:22.980000 --> 0:22:28.740000 And we say that is, in this case, let's go 5140, right? 0:22:28.740000 --> 0:22:31.720000 So 5140. And we hit enter. 0:22:31.720000 --> 0:22:33.340000 And we hit enter. 0:22:33.340000 --> 0:22:37.660000 And there we are now only the logs or documents as it's called would the 0:22:37.660000 --> 0:22:41.980000 only logs or documents displayed are ones that meet this particular criteria. 0:22:41.980000 --> 0:22:45.720000 Okay, so when you run a search, you hit enter, it then displays the results 0:22:45.720000 --> 0:22:50.560000 very nice. So let's delete that and just hit enter to go back to, you 0:22:50.560000 --> 0:22:52.040000 know, all the logs. 0:22:52.040000 --> 0:22:56.320000 And now let's, you know, get started with task three, which is creating 0:22:56.320000 --> 0:22:59.560000 a search to identify files that are named like system processes. 0:22:59.560000 --> 0:23:04.400000 So based on, you know, the description of the task, first thing we need 0:23:04.400000 --> 0:23:08.400000 to know or understand generally speaking is the list of commonly abused, 0:23:08.400000 --> 0:23:12.780000 the names of commonly abused windows binaries or programs, right? 0:23:12.780000 --> 0:23:18.520000 So this is where you have stuff like SVC host.exe LSAS.exe Explorer is 0:23:18.520000 --> 0:23:20.180000 another example. 0:23:20.180000 --> 0:23:25.140000 So that brings us to a very important question that we need to ask ourselves 0:23:25.140000 --> 0:23:32.640000 is how do we query logs to essentially find how do we create a search 0:23:32.640000 --> 0:23:44.200000 to find logs that essentially have or are related to processes that have 0:23:44.200000 --> 0:23:47.840000 the names of, you know, these commonly abused windows binaries? 0:23:47.840000 --> 0:23:52.000000 Well, firstly, we need to identify the field where that information is 0:23:52.000000 --> 0:23:55.860000 contained with regards to the theme you're using, right? 0:23:55.860000 --> 0:24:00.560000 So in this case, it looks like the event data image field here actually 0:24:00.560000 --> 0:24:02.780000 contains that information as we saw. 0:24:02.780000 --> 0:24:06.900000 So a good starting point would be to say, and again, this is, you know, 0:24:06.900000 --> 0:24:10.480000 trial and error, but we can say event, you specify the name of the field. 0:24:10.480000 --> 0:24:17.880000 So event data.image and now if you want to combine more than one logical 0:24:17.880000 --> 0:24:22.740000 expression is always a good idea to separate it or to include it in your 0:24:22.740000 --> 0:24:24.020000 parentheses here. 0:24:24.020000 --> 0:24:26.920000 So we can now say, what do we want it to include? 0:24:26.920000 --> 0:24:33.040000 Well, we just specify the processes that are the name of the image or 0:24:33.040000 --> 0:24:37.300000 binary name. So in this case, you know, we don't really need to specify 0:24:37.300000 --> 0:24:41.080000 the path per se, but just the name of the executable. 0:24:41.080000 --> 0:24:46.300000 So remember, our job is to find files that are named like system processes. 0:24:46.300000 --> 0:24:50.800000 So to begin with, we can see, you know, we can say, let's look for logs 0:24:50.800000 --> 0:24:59.420000 that, you know, logs that are associated with, you know, programs or processes, 0:24:59.420000 --> 0:25:05.140000 you know, like, you know, SVC host dot exe or something like this. 0:25:05.140000 --> 0:25:11.480000 Another one that's frequently abused by malware is l sass dot exe. 0:25:11.480000 --> 0:25:15.820000 So I'm using logical operators like or so we're not limiting it to just 0:25:15.820000 --> 0:25:17.900000 one executable name. 0:25:17.900000 --> 0:25:24.260000 And we can also say, or another one that's used is win log on dot exe, 0:25:24.260000 --> 0:25:26.900000 win log on dot exe. 0:25:26.900000 --> 0:25:30.140000 And then when you're done, you can just close the operandhesis here or 0:25:30.140000 --> 0:25:32.880000 your brackets as it were, and just hit enter. 0:25:32.880000 --> 0:25:37.800000 Okay. And what this will do is it'll find all processes or logs that are 0:25:37.800000 --> 0:25:42.120000 pertinent to processes that are matching these particular names. 0:25:42.120000 --> 0:25:45.040000 Right. So in this case, you can see it's going to be highlighted in yellow 0:25:45.040000 --> 0:25:46.980000 in that particular column. 0:25:46.980000 --> 0:25:49.440000 If you added that field as a column here. 0:25:49.440000 --> 0:25:54.540000 So now we're getting all the logs that are, you know, essentially contain 0:25:54.540000 --> 0:26:01.840000 or using, you know, or have any of these executable names in the event 0:26:01.840000 --> 0:26:03.360000 data image field. 0:26:03.360000 --> 0:26:08.680000 Okay. So we have, you know, all they all appear to be SVC host. 0:26:08.680000 --> 0:26:10.520000 So that's one aspect. 0:26:10.520000 --> 0:26:16.620000 But if you remember what the tasks asked us to do, not only are we supposed 0:26:16.620000 --> 0:26:20.860000 to identify, you know, the files or binaries that are named like system 0:26:20.860000 --> 0:26:23.860000 processes, in this case, we've done exactly that. 0:26:23.860000 --> 0:26:28.820000 But remember, attackers will not save the the amelicia if they called 0:26:28.820000 --> 0:26:33.200000 their malicious program or binary SVC host dot exe, they're not going 0:26:33.200000 --> 0:26:38.080000 to save it in the directory where SVC host actually exists on Windows, 0:26:38.080000 --> 0:26:42.300000 which is, you know, typically under Windows system 32 SVC host. 0:26:42.300000 --> 0:26:46.060000 So if I click on any of these logs, you can see that this looks fairly 0:26:46.060000 --> 0:26:48.720000 legitimate. There's nothing suspicious going on here. 0:26:48.720000 --> 0:26:57.600000 In fact, it's related to, in this case, let's see, it is, do we have any 0:26:57.600000 --> 0:26:59.040000 additional information? 0:26:59.040000 --> 0:27:03.780000 So we can see this is indexes log star sheave, we take a look at the message. 0:27:03.780000 --> 0:27:08.100000 Yeah, this looks, there's nothing suspicious going on here. 0:27:08.100000 --> 0:27:11.440000 And the reason it's not suspicious is because this is the legitimate SVC 0:27:11.440000 --> 0:27:13.440000 host dot exe binary. 0:27:13.440000 --> 0:27:18.820000 So we're trying to find binaries that have, you know, the that are masquerading 0:27:18.820000 --> 0:27:24.080000 as any of these legitimate Windows binaries or processes as it were. 0:27:24.080000 --> 0:27:29.280000 But the way to do that is to look for again, this the same process names 0:27:29.280000 --> 0:27:33.980000 or binary names, but not in the location where the original is saved. 0:27:33.980000 --> 0:27:35.340000 So how do we do this? 0:27:35.340000 --> 0:27:41.540000 Well, because we have the path to the image as it, you know, in specified 0:27:41.540000 --> 0:27:48.300000 in the event data image field, or as a value of that particular field, 0:27:48.300000 --> 0:27:53.980000 we can actually use some additional logic here in our search and say, 0:27:53.980000 --> 0:28:01.340000 let's say, okay, so we specify what we're looking for in terms of names, 0:28:01.340000 --> 0:28:03.820000 right, in terms of binary names. 0:28:03.820000 --> 0:28:10.000000 What we can then append onto this as a suffix is some additional logic 0:28:10.000000 --> 0:28:14.280000 by saying, so we've said what we're looking for, but we now need to add 0:28:14.280000 --> 0:28:16.660000 what we're not looking for. 0:28:16.660000 --> 0:28:19.200000 So we can say and not okay. 0:28:19.200000 --> 0:28:21.560000 So and not that's a logical operator. 0:28:21.560000 --> 0:28:27.180000 And we'll still use the field event data dot image. 0:28:27.180000 --> 0:28:30.140000 And we'll now need to specify. 0:28:30.140000 --> 0:28:43.220000 So we'll look for, you know, or exclude, we're now specifying what we 0:28:43.220000 --> 0:28:47.980000 want to exclude, because we want to exclude results that contain, let's 0:28:47.980000 --> 0:28:55.060000 say windows system 32 and stuff like this, we can do that by leveraging 0:28:55.060000 --> 0:29:00.240000 some leucine syntax, which is what we're using here, you can see it uses 0:29:00.240000 --> 0:29:14.920000 a leucine for specific strings, we would need to, you know, perform, because 0:29:14.920000 --> 0:29:20.420000 we're matching file paths or strings, we need to, we can use, let's say, 0:29:20.420000 --> 0:29:27.200000 the backslash for escape for special character escaping, and then because 0:29:27.200000 --> 0:29:30.440000 it's a path, we would need to include another backslash, and then we can 0:29:30.440000 --> 0:29:36.060000 also use a wildcard to match, you know, to essentially match any sequence 0:29:36.060000 --> 0:29:37.240000 of the characters. 0:29:37.240000 --> 0:29:42.400000 So if we can essentially say what that means is, because we're specifying 0:29:42.400000 --> 0:29:48.140000 a path, we would need to do, let's see, we'll use a wildcard there double 0:29:48.140000 --> 0:29:54.260000 backslash there, and then say, you know, system 32, so not case sensitive, 0:29:54.260000 --> 0:29:58.120000 that that's not really important per se, but you can be that specific 0:29:58.120000 --> 0:30:03.300000 if you want, and then we can also say we don't need to use a logic here, 0:30:03.300000 --> 0:30:09.120000 although you can, to specify another file path, we can say also exclude 0:30:09.120000 --> 0:30:14.440000 another common one is the sys wow 64, right, so we'll say on windows, 0:30:14.440000 --> 0:30:21.020000 so sys wow 64, that's another directory where the legitimate executables 0:30:21.020000 --> 0:30:27.400000 or binaries are stored, so sys wow 64, I don't think we need anything 0:30:27.400000 --> 0:30:31.040000 else, generally speaking, that's where it's stored, or you can go, you 0:30:31.040000 --> 0:30:35.140000 know, to the very, you can go old school and just say anything under see 0:30:35.140000 --> 0:30:40.160000 windows, but again, your attackers may be storing them under see windows, 0:30:40.160000 --> 0:30:43.980000 so that it looks even more legitimate than it actually is. 0:30:43.980000 --> 0:30:49.580000 So let's close this up and let's hit enter. 0:30:49.580000 --> 0:30:54.500000 Now remember, as is outlined in the lab documentation, there's a lot more 0:30:54.500000 --> 0:31:00.700000 legitimate, there's a lot more windows binary, there's a lot more window, 0:31:00.700000 --> 0:31:05.900000 windows binaries that attackers essentially masquerade as, and I'm referring 0:31:05.900000 --> 0:31:10.580000 to their names, I've only included SVC host or LSAS Win log on as an example, 0:31:10.580000 --> 0:31:15.460000 but that can be further defined, so I'll let enter, let's see, why am 0:31:15.460000 --> 0:31:24.420000 I having an issue here, so event data, so let's see what we want here, 0:31:24.420000 --> 0:31:30.780000 event data image, okay, that looks good to me, ah, I forgot to encapsulate 0:31:30.780000 --> 0:31:36.300000 this here, always something, so I'll let enter, and ah, interesting, so 0:31:36.300000 --> 0:31:41.420000 now we only get one log that matches our search query here.