WEBVTT

0:00:04.000000 --> 0:00:07.660000
 And in this case, we're getting
 exactly what we want.

0:00:07.660000 --> 0:00:12.240000
 So welcome to instant response or detection
 as a threat detection as it

0:00:12.240000 --> 0:00:18.900000
 were, because we found a another a
 binary called SVC host dot exe that

0:00:18.900000 --> 0:00:22.840000
 is masquerading as the legitimate
 Windows SVC host dot exe.

0:00:22.840000 --> 0:00:27.640000
 But instead of being stored in its actual
 location, this one is sort of

0:00:27.640000 --> 0:00:31.800000
 a new one that is most
 obviously malicious.

0:00:31.800000 --> 0:00:35.860000
 And this one is stored in the temp folder
 under the root of the Windows

0:00:35.860000 --> 0:00:40.940000
 installation, the Windows drive
 or the C drive as it were.

0:00:40.940000 --> 0:00:46.380000
 And if we take a look at this here, you
 can see the we have a field called

0:00:46.380000 --> 0:00:49.720000
 attack TTPs. This is a custom field.

0:00:49.720000 --> 0:00:54.060000
 And it pretty much outlines what I've
 been calling this type of behavior,

0:00:54.060000 --> 0:00:55.880000
 which is masquerading, right?

0:00:55.880000 --> 0:01:00.140000
 So the technique or yeah, the technique
 by the way, the technique IDs

0:01:00.140000 --> 0:01:04.280000
 might be outdated, because this deployment
 of Elk is quite old, but it's

0:01:04.280000 --> 0:01:05.800000
 still masquerading.

0:01:05.800000 --> 0:01:11.700000
 So this is definitely malicious behavior
 because we can see the event

0:01:11.700000 --> 0:01:16.460000
 data images SVC temp C
 temp SVC host dot exe.

0:01:16.460000 --> 0:01:18.400000
 And what is being executed?

0:01:18.400000 --> 0:01:22.440000
 If we take a look at the field event
 data parent command line, we can

0:01:22.440000 --> 0:01:27.860000
 see that the attacker is using WMIC OS
 get format and they're essentially

0:01:27.860000 --> 0:01:32.660000
 reaching out to an external server and
 downloading a file called template

0:01:32.660000 --> 0:01:37.840000
 dot XSL. The parent image
 is, you know, WMIC.

0:01:37.840000 --> 0:01:40.920000
 So that's what is being
 used to facilitate this.

0:01:40.920000 --> 0:01:43.720000
 Parent of parent is CMD dot exe.

0:01:43.720000 --> 0:01:46.840000
 So they're typing out their commands
 using a CMD dot exe.

0:01:46.840000 --> 0:01:49.200000
 So that's their command and
 scripting interpreter.

0:01:49.200000 --> 0:01:54.140000
 And if we go to the image, sorry, to
 the message here, we can see that

0:01:54.140000 --> 0:01:58.020000
 command line C temp SVC is dot exe.

0:01:58.020000 --> 0:02:03.200000
 And we can see the, you know,
 parent command line.

0:02:03.200000 --> 0:02:04.180000
 Yeah, there we are.

0:02:04.180000 --> 0:02:06.400000
 You can see that reflected there as well.


0:02:06.400000 --> 0:02:12.700000
 So that's, you know, that's the power
 of knowing what to look for.

0:02:12.700000 --> 0:02:16.760000
 Now we can also extend this to be a bit
 more specific and refined by including

0:02:16.760000 --> 0:02:22.600000
 some additional binary names that are
 frequently masqueraded or used for

0:02:22.600000 --> 0:02:24.640000
 the purpose of masquerading.

0:02:24.640000 --> 0:02:26.700000
 So we can say by attackers, that is.

0:02:26.700000 --> 0:02:31.000000
 So we can say, or another one that's
 typically used is services dot exe.

0:02:31.000000 --> 0:02:33.560000
 And that's the one outlined
 in the lab documentation.

0:02:33.560000 --> 0:02:36.280000
 So if I had enter, let's see.

0:02:36.280000 --> 0:02:40.620000
 Ooh, this one is stored under Windows now,
 but pay attention to the directory

0:02:40.620000 --> 0:02:42.960000
 name for this particular log here.

0:02:42.960000 --> 0:02:48.640000
 Not only is there the common minikatz
 command here, command argument,

0:02:48.640000 --> 0:02:52.940000
 this Windows folder has an uppercase I.

0:02:52.940000 --> 0:02:57.100000
 Okay, so this is not the real Windows
 directory under the C drive.

0:02:57.100000 --> 0:03:00.520000
 This is something that the attacker
 has created again for the purpose

0:03:00.520000 --> 0:03:01.320000
 of masquerading.

0:03:01.320000 --> 0:03:06.780000
 And you can see in the field attack TTPs,
 the technique that's been highlighted

0:03:06.780000 --> 0:03:07.900000
 is more than one.

0:03:07.900000 --> 0:03:10.700000
 We have credential dumping
 and then masquerading.

0:03:10.700000 --> 0:03:15.880000
 So in this case, it's very clear that
 they've called mimikatz the mimikatz

0:03:15.880000 --> 0:03:20.040000
 executable services dot exe
 as a way of masquerading.

0:03:20.040000 --> 0:03:25.380000
 And we know that because secure LSA log
 on passwords is a mimikatz command

0:03:25.380000 --> 0:03:29.140000
 line argument that's used to
 dump credentials on Windows.

0:03:29.140000 --> 0:03:33.080000
 And in this case, log
 on passwords via LSA.

0:03:33.080000 --> 0:03:37.460000
 So if we take a look at the message here,
 you can see it pretty much reflects

0:03:37.460000 --> 0:03:42.840000
 that. And it tells us that this is
 being executed via the command line

0:03:42.840000 --> 0:03:44.320000
 or command prompt.

0:03:44.320000 --> 0:03:46.460000
 So hopefully this makes sense.

0:03:46.460000 --> 0:03:50.320000
 Now the lab documentation or the solution
 for this particular task outlines

0:03:50.320000 --> 0:03:55.980000
 way more Windows binary names or executable
 names that are frequently

0:03:55.980000 --> 0:03:59.020000
 used for the purposes of masquerading
 by attackers.

0:03:59.020000 --> 0:04:04.900000
 And you can leverage those to, you can
 essentially use the lab solution

0:04:04.900000 --> 0:04:07.000000
 if you want or those names.

0:04:07.000000 --> 0:04:10.460000
 But the key thing I wanted to point out
 is how to write your own searches

0:04:10.460000 --> 0:04:16.520000
 and the logical the logic behind
 creating your own searches.

0:04:16.520000 --> 0:04:20.120000
 And it's not, as I said, just copying
 and pasting searches because that

0:04:20.120000 --> 0:04:21.580000
 will not get you anywhere.

0:04:21.580000 --> 0:04:24.620000
 You need to understand, you
 know, what your task is.

0:04:24.620000 --> 0:04:28.460000
 And of course, in this case, the task
 is predefined, but you need to know

0:04:28.460000 --> 0:04:32.520000
 what the task is, what you're looking
 for, where it's typically found.

0:04:32.520000 --> 0:04:35.560000
 And of course, how to construct
 that query logically speaking.

0:04:35.560000 --> 0:04:39.820000
 So now that we've done one task, I
 probably need to restart my lab or

0:04:39.820000 --> 0:04:42.920000
 extend it because we've
 gone for quite a while.

0:04:42.920000 --> 0:04:46.140000
 And the time set is one hour or so.

0:04:46.140000 --> 0:04:49.560000
 I'll probably need to restart it so
 we can continue with the other task.

0:04:49.560000 --> 0:04:51.840000
 So just give me a second.

0:04:51.840000 --> 0:04:54.940000
 All right. So it looks like I have a couple
 more minutes so we can actually

0:04:54.940000 --> 0:05:00.000000
 proceed with the next task which in
 terms of what I wanted to cover was

0:05:00.000000 --> 0:05:04.320000
 that the next sequential task after task
 three, which was task four, which

0:05:04.320000 --> 0:05:09.620000
 is called or this is what the task is
 titled, detect suspicious services

0:05:09.620000 --> 0:05:16.240000
 that are, detect suspicious services
 interacting with Windows executables.

0:05:16.240000 --> 0:05:20.800000
 All right. So the description is as follows,
 the addition of a new service

0:05:20.800000 --> 0:05:23.040000
 is something worth analyzing.

0:05:23.040000 --> 0:05:27.960000
 Okay. Attackers oftentimes leverage Windows
 services for both exploitation

0:05:27.960000 --> 0:05:30.780000
 and persistence purposes, which is true.

0:05:30.780000 --> 0:05:37.140000
 And it is not uncommon to see attacker
 derived services interacting with

0:05:37.140000 --> 0:05:41.800000
 an executable from the Windows folder,
 the legitimate Windows folder.

0:05:41.800000 --> 0:05:46.600000
 So we need to create an elk search
 to identify this type of behavior.

0:05:46.600000 --> 0:05:51.720000
 And within the solution for task four,
 there's a hint provided where the

0:05:51.720000 --> 0:05:56.100000
 hint reads out as follows, identify
 Windows security log event IDs and

0:05:56.100000 --> 0:06:00.400000
 Windows event IDs related to service
 creation, which will take you to

0:06:00.400000 --> 0:06:04.500000
 a GitHub repository that essentially
 contains a cheat sheet that you can

0:06:04.500000 --> 0:06:09.580000
 use. So the objective is to detect cases
 or logs that essentially represent

0:06:09.580000 --> 0:06:15.300000
 instances where services are set to
 launch or interact with executables

0:06:15.300000 --> 0:06:22.020000
 that are located within the legitimate
 Windows directory under the C drive.

0:06:22.020000 --> 0:06:26.280000
 And more specifically, if that looks unusual
 or to look for unusual instances

0:06:26.280000 --> 0:06:28.300000
 of what I just mentioned.

0:06:28.300000 --> 0:06:33.820000
 So first things first, when we're dealing
 with service creation or looking

0:06:33.820000 --> 0:06:38.480000
 for, you know, events, in this case,
 very specific to Windows, when you're

0:06:38.480000 --> 0:06:43.540000
 looking for events or logs pertinent
 to service creation, the logs that

0:06:43.540000 --> 0:06:47.160000
 you're going to be or the Windows event
 IDs that are pertinent are going

0:06:47.160000 --> 0:06:53.520000
 to be typically 7 0 4 5 or 4 6 9 7.

0:06:53.520000 --> 0:06:59.520000
 Okay. So I can probably explain what
 each of these represents in it.

0:06:59.520000 --> 0:07:01.300000
 Probably a good idea.

0:07:01.300000 --> 0:07:06.080000
 So event, the event ID 4 6 9 7.

0:07:06.080000 --> 0:07:09.420000
 And remember, I mentioned when we're talking
 about the Windows event logging

0:07:09.420000 --> 0:07:13.540000
 early on in discourse that the best
 way to understand these event IDs

0:07:13.540000 --> 0:07:16.840000
 or to get familiar with them is through
 practical demonstrations.

0:07:16.840000 --> 0:07:18.380000
 And this is just one of them.

0:07:18.380000 --> 0:07:23.920000
 So event, the Windows event ID 4 6 9 7
 indicates that a service was installed

0:07:23.920000 --> 0:07:26.000000
 on the system. And it's typically stored.


0:07:26.000000 --> 0:07:30.600000
 The log path is security or that's
 its category, as it were.

0:07:30.600000 --> 0:07:33.920000
 And its use in detection
 can be as follows.

0:07:33.920000 --> 0:07:37.220000
 It can be used to detect unauthorized
 or unusual service installations,

0:07:37.220000 --> 0:07:41.660000
 which is generally speaking what we're
 looking for with regards to this

0:07:41.660000 --> 0:07:49.720000
 task task for the other use case is for
 for spotting persistence mechanisms,

0:07:49.720000 --> 0:07:53.200000
 especially or obviously
 in post exploitation.

0:07:53.200000 --> 0:07:58.020000
 So the key fields for this, you know,
 if for event logs with the event

0:07:58.020000 --> 0:08:04.180000
 ID 4 6 9 7 are the service name, the
 service file name, which is the path

0:08:04.180000 --> 0:08:07.860000
 to the executable and the account name,
 which is who installed it, especially

0:08:07.860000 --> 0:08:10.480000
 when you're dealing with
 persistence, right?

0:08:10.480000 --> 0:08:16.120000
 And then you have event ID 7 0 4 5,
 which essentially represents that

0:08:16.120000 --> 0:08:22.460000
 a service or essentially means that a
 service was installed on the system.

0:08:22.460000 --> 0:08:27.180000
 This is typically the log path
 is the system log path.

0:08:27.180000 --> 0:08:33.980000
 And what it tells us is that, you know,
 in addition to that, it also can

0:08:33.980000 --> 0:08:42.100000
 tell us that then the security log,
 which is something you need to keep

0:08:42.100000 --> 0:08:43.740000
 in mind, especially with the windows.

0:08:43.740000 --> 0:08:49.380000
 So in terms of why we would use 7 0
 4 5, the first is to complement a

0:08:49.380000 --> 0:08:52.480000
 windows event ID 4 6 9 7, right?

0:08:52.480000 --> 0:08:57.960000
 Which catches events when auditing
 is not configured or disabled.

0:08:57.960000 --> 0:09:01.660000
 The other use case is, you know, it captures
 slightly different metadata.

0:09:01.660000 --> 0:09:05.020000
 So things like the image
 path or the service type.

0:09:05.020000 --> 0:09:09.680000
 All right, so let's get to
 creating our search here.

0:09:09.680000 --> 0:09:13.020000
 And I believe my lab still
 has a bit more time to go.

0:09:13.020000 --> 0:09:18.160000
 So we can, the first thing as I've
 already covered this, we can just,

0:09:18.160000 --> 0:09:24.040000
 you know, filter for logs that have
 the event ID or the event ID.

0:09:24.040000 --> 0:09:27.300000
 Let's use 7 0 4 5.

0:09:27.300000 --> 0:09:32.080000
 Okay. So we'll use the field event
 ID and then just hit enter.

0:09:32.080000 --> 0:09:33.020000
 And here we are.

0:09:33.020000 --> 0:09:34.900000
 Okay. Interesting.

0:09:34.900000 --> 0:09:39.600000
 Looks like we already found something
 malicious here, like this executable,

0:09:39.600000 --> 0:09:44.740000
 which is stored under, you can see vent
 under the event data command line

0:09:44.740000 --> 0:09:47.820000
 column here or field as it were.

0:09:47.820000 --> 0:09:53.280000
 We can see for this particular event
 log or document on the path, the

0:09:53.280000 --> 0:09:57.800000
 path is saying system root, which is something
 that's only used when you're

0:09:57.800000 --> 0:10:04.060000
 trying to specify the path to
 a file in the command line.

0:10:04.060000 --> 0:10:09.060000
 So system root is referring to see
 the, the C drive as it were.

0:10:09.060000 --> 0:10:14.520000
 We can also see a lot more malicious activity
 because a C tools WCE, that's

0:10:14.520000 --> 0:10:16.660000
 the windows credential editor.

0:10:16.660000 --> 0:10:20.640000
 It's a malicious tool or not a malicious
 tool by nature, but it's a tool

0:10:20.640000 --> 0:10:24.240000
 used by attackers to again
 dump credentials.

0:10:24.240000 --> 0:10:28.560000
 We also have mimicats here, which again
 tells us there's a lot of credential

0:10:28.560000 --> 0:10:34.720000
 dumping going on, but we have some very
 funny executables that, you know,

0:10:34.720000 --> 0:10:39.560000
 or I should say very randomly named executables
 that are to an experienced,

0:10:39.560000 --> 0:10:45.640000
 I like seriously, you know, are very,
 very key or are key indicators that,

0:10:45.640000 --> 0:10:48.140000
 you know, something malicious
 is going on here.

0:10:48.140000 --> 0:10:49.840000
 So that's one way.

0:10:49.840000 --> 0:10:54.060000
 The other way, what if we wanted to
 combine event IDs that we're looking

0:10:54.060000 --> 0:10:57.520000
 for? So one or the other?

0:10:57.520000 --> 0:11:03.720000
 Well, in order to do this, we can, you
 know, for example, say, let's say,

0:11:03.720000 --> 0:11:10.100000
 yeah, we can say event ID 7 0 4 5, or
 we can use a logical operator and

0:11:10.100000 --> 0:11:16.840000
 say, actually, let's encapsulate this.

0:11:16.840000 --> 0:11:23.760000
 So we'll say, because I want to build
 on this event ID 7 0 4 5, and then

0:11:23.760000 --> 0:11:31.280000
 we'll say or event ID is going to be
 equal to the other one, which is

0:11:31.280000 --> 0:11:36.040000
 4 6 9 7. So service was
 installed 4 6 9 7.

0:11:36.040000 --> 0:11:39.820000
 And this just ensures that you're, you
 know, accurately, you're getting

0:11:39.820000 --> 0:11:44.600000
 an accurate picture of all the logs that
 are pertinent to a service installation

0:11:44.600000 --> 0:11:46.560000
 or instantiation.

0:11:46.560000 --> 0:11:50.840000
 So in this case, it looks like it works,
 but all, you know, all of our

0:11:50.840000 --> 0:11:55.680000
 matches are pointing or all
 have the event ID 7 0 4 5.

0:11:55.680000 --> 0:11:59.180000
 So we didn't need to add that
 per say in this case.

0:11:59.180000 --> 0:12:04.320000
 Now, remember what we're looking for
 is going back to the description

0:12:04.320000 --> 0:12:08.140000
 of the task. We are supposed to detect suspicious
 services that are interacting

0:12:08.140000 --> 0:12:10.000000
 with windows executable.

0:12:10.000000 --> 0:12:15.360000
 So our objective is to detect cases
 where services are set to launch to

0:12:15.360000 --> 0:12:18.920000
 interact with executables that are stored
 within the C windows directory,

0:12:18.920000 --> 0:12:20.680000
 especially if it's unusual.

0:12:20.680000 --> 0:12:24.640000
 So what that means is if we take a
 look at one of these ones here, we

0:12:24.640000 --> 0:12:32.020000
 can see what we're looking for here
 is, let's see, let me go back to.

0:12:32.020000 --> 0:12:35.600000
 So this one is one of them.

0:12:35.600000 --> 0:12:41.680000
 So system root. Let's see.

0:12:41.680000 --> 0:12:51.100000
 Okay, so. So if you actually take a
 look at this particular field, which

0:12:51.100000 --> 0:12:55.340000
 is called hunts, it actually performed
 correlation for us as to what this

0:12:55.340000 --> 0:13:00.320000
 means. And it says right of the suspicious
 service that that starts executable

0:13:00.320000 --> 0:13:02.180000
 from the windows folder.

0:13:02.180000 --> 0:13:09.920000
 Okay, so. So what this means if it
 isn't obvious already, whenever you

0:13:09.920000 --> 0:13:14.120000
 see system root, especially in this case,
 this is an environment variable,

0:13:14.120000 --> 0:13:18.040000
 right? And it's typical use case based
 on the fact that it's an environment

0:13:18.040000 --> 0:13:19.920000
 variable would be in the command line.

0:13:19.920000 --> 0:13:24.940000
 So an attack would say system root that
 what what that means is what system

0:13:24.940000 --> 0:13:29.920000
 root refers to is on windows is the root
 directory of the windows operating

0:13:29.920000 --> 0:13:31.820000
 system or where it's installed.

0:13:31.820000 --> 0:13:38.440000
 So more specifically what it means is
 the directory, the windows directory

0:13:38.440000 --> 0:13:41.980000
 or the folder called windows
 typically in the C drive.

0:13:41.980000 --> 0:13:47.660000
 Okay, so when we see this, this is exactly
 what we were looking for now.

0:13:47.660000 --> 0:13:52.620000
 We have pretty much created the search
 to look for what we were supposed

0:13:52.620000 --> 0:13:56.880000
 to look for or detect with
 regards to task for.

0:13:56.880000 --> 0:14:04.960000
 But what if we wanted to make our search
 a bit more refined here and,

0:14:04.960000 --> 0:14:08.580000
 you know, essentially also specify.

0:14:08.580000 --> 0:14:16.300000
 So we can say and so we also looking
 for so we say and event data, but

0:14:16.300000 --> 0:14:21.180000
 in this case. We have used event ID.

0:14:21.180000 --> 0:14:25.300000
 Let's use command line because that's
 this is the field, you know, that

0:14:25.300000 --> 0:14:27.580000
 contains the info we're looking for.

0:14:27.580000 --> 0:14:30.820000
 Also, we'll say event data.

0:14:30.820000 --> 0:14:37.320000
 Command line. Keyword.

0:14:37.320000 --> 0:14:42.640000
 And I would now need to
 use some rejects here.

0:14:42.640000 --> 0:14:47.340000
 So I'll just type it out and I'll get
 back when I've pasted it in and

0:14:47.340000 --> 0:14:49.780000
 I'll explain what it does.

0:14:49.780000 --> 0:14:55.140000
 All right, so I've just written out
 my rejects here to essentially.

0:14:55.140000 --> 0:15:01.500000
 To match that particular directory or
 environment variable, which is system

0:15:01.500000 --> 0:15:06.440000
 root. So I use lower case system root
 in the rejects with the flag as

0:15:06.440000 --> 0:15:10.440000
 you can see for to essentially specify
 that this is to be case sensitive

0:15:10.440000 --> 0:15:15.700000
 or, you know, case sensitive
 matching as it were.

0:15:15.700000 --> 0:15:21.100000
 And that should mean that if we hit enter,
 we'll pretty much get the same

0:15:21.100000 --> 0:15:25.660000
 logs as it were that we got previously,
 but a bit more specific.

0:15:25.660000 --> 0:15:30.360000
 So previously because we weren't filtering
 for any of these event IDs

0:15:30.360000 --> 0:15:33.000000
 or logs with the following event IDs.

0:15:33.000000 --> 0:15:37.620000
 We were filtering for them, but we are
 not specifying, you know, the the

0:15:37.620000 --> 0:15:39.040000
 actual path here.

0:15:39.040000 --> 0:15:42.580000
 We were getting pretty much.

0:15:42.580000 --> 0:15:48.480000
 All logs that represented service
 installation or instantiation.

0:15:48.480000 --> 0:15:52.620000
 Now we are able to get these suspicious
 or these logs that represent,

0:15:52.620000 --> 0:15:57.960000
 you know, execution of suspicious services
 that are stored within the

0:15:57.960000 --> 0:16:00.500000
 windows folder. So going back to the.

0:16:00.500000 --> 0:16:06.340000
 The actual task task for our job was to
 detect suspicious services interacting

0:16:06.340000 --> 0:16:09.800000
 with windows executable.

0:16:09.800000 --> 0:16:13.400000
 So the objective was to detect cases
 where services are set to launch

0:16:13.400000 --> 0:16:17.820000
 or interact with executables located
 in the windows directory, which in

0:16:17.820000 --> 0:16:19.060000
 this case we've done.

0:16:19.060000 --> 0:16:23.360000
 And the attack is in this case, or the
 logs in this case pretty much represent

0:16:23.360000 --> 0:16:26.380000
 the same. They've just used
 the environment variable.

0:16:26.380000 --> 0:16:30.760000
 Now, if we take a look at the message
 here, you can see it says correctly

0:16:30.760000 --> 0:16:33.040000
 that a service was installed
 on this system.

0:16:33.040000 --> 0:16:36.020000
 The service name is looks
 at, you know, random.

0:16:36.020000 --> 0:16:38.820000
 So it's just a string of alpha.

0:16:38.820000 --> 0:16:42.420000
 Sorry, application, lowercase letters.

0:16:42.420000 --> 0:16:47.300000
 And, you know, it's stored in C windows,
 and this is the name of the actual

0:16:47.300000 --> 0:16:52.520000
 service. So right over here or the actual
 binary or image as it were the

0:16:52.520000 --> 0:16:53.760000
 service name is.

0:16:53.760000 --> 0:16:56.840000
 Y W U N the binary.

0:16:56.840000 --> 0:17:03.320000
 Respective off that of the binary associated
 with that particular service

0:17:03.320000 --> 0:17:05.160000
 is right over here.

0:17:05.160000 --> 0:17:08.240000
 So we were able to complete that task.

0:17:08.240000 --> 0:17:09.620000
 Now there's just one more task.

0:17:09.620000 --> 0:17:13.800000
 I want to go through and I'll
 probably need to reset my lab.

0:17:13.800000 --> 0:17:18.220000
 But again, feel free to go through the
 other tasks they explain or they

0:17:18.220000 --> 0:17:19.520000
 provide you with solutions.

0:17:19.520000 --> 0:17:23.160000
 But hopefully my explanation of the
 solutions for the tasks that we've

0:17:23.160000 --> 0:17:26.960000
 gone through will make understanding
 those solutions a little bit easier.

0:17:26.960000 --> 0:17:30.940000
 So I'm just going to restart my lab
 and I will come back and complete

0:17:30.940000 --> 0:17:33.600000
 the last task, which was task eight.

0:17:33.600000 --> 0:17:37.720000
 And we can then conclude the
 practical demonstration.

0:17:37.720000 --> 0:17:40.780000
 So just give me a second.

0:17:40.780000 --> 0:17:43.780000
 All right, looks like
 I could extend my lab.

0:17:43.780000 --> 0:17:45.540000
 So we don't need to restart it.

0:17:45.540000 --> 0:17:50.600000
 So let's take a look at task eight,
 which is what I wanted to cover for

0:17:50.600000 --> 0:17:54.720000
 a very specific reason, because it
 allows us to explore, you know, the

0:17:54.720000 --> 0:17:58.700000
 pros of creating searches that use different
 fields other than the ones

0:17:58.700000 --> 0:18:10.160000
 we've used thus far.

0:18:10.160000 --> 0:18:14.260000
 But more specifically execution of the
 who am I command with system privileges

0:18:14.260000 --> 0:18:16.020000
 or elevated privileges.

0:18:16.020000 --> 0:18:20.100000
 So the description of that task is as
 follows when attackers gain access

0:18:20.100000 --> 0:18:23.760000
 to a system. They usually execute commands
 such as who am I for discovery,

0:18:23.760000 --> 0:18:26.840000
 you know, or local enumeration.

0:18:26.840000 --> 0:18:32.200000
 In this case, who am I is typically
 used to identify the level of access

0:18:32.200000 --> 0:18:36.040000
 or who they're accessing the system
 as as well as the privileges.

0:18:36.040000 --> 0:18:41.180000
 And what we need to do is to create a
 search to detect the who am I command

0:18:41.180000 --> 0:18:44.880000
 being executed with system
 level privileges.

0:18:44.880000 --> 0:18:48.960000
 So we already know that the field we're
 interested in or that's going

0:18:48.960000 --> 0:18:52.560000
 to be pertinent in this case is going
 to be the event data image field.

0:18:52.560000 --> 0:18:57.640000
 But there's another one that we haven't
 really touched on that is associated

0:18:57.640000 --> 0:19:05.900000
 with or pertinent to who the particular
 command or executable is being

0:19:05.900000 --> 0:19:11.520000
 executed by. And in this case, because
 we have been asked to again identify

0:19:11.520000 --> 0:19:17.380000
 or detect the who am I command being
 executed with system privileges,

0:19:17.380000 --> 0:19:18.900000
 it should be fairly simple.

0:19:18.900000 --> 0:19:23.040000
 So the field in this case that's going
 to be pertinent is going to be,

0:19:23.040000 --> 0:19:27.060000
 let's see if we can find it because
 we didn't add it yet is going to be

0:19:27.060000 --> 0:19:30.220000
 the field that contains that information.


0:19:30.220000 --> 0:19:34.220000
 So we've already added the host name
 here, but what we're looking for

0:19:34.220000 --> 0:19:37.680000
 is event data and something
 to do with the user.

0:19:37.680000 --> 0:19:41.440000
 So let's go ahead and
 see if we can find it.

0:19:41.440000 --> 0:19:44.580000
 So, yeah, there we are event data user.

0:19:44.580000 --> 0:19:49.100000
 So if I add it now, it tells us,
 you know, who executed what.

0:19:49.100000 --> 0:19:53.340000
 And because we haven't written a search,
 these are just all the logs,

0:19:53.340000 --> 0:19:54.720000
 we need to start doing that.

0:19:54.720000 --> 0:19:58.920000
 So first things first, we're looking
 for execution of who am I.

0:19:58.920000 --> 0:20:02.860000
 So we need to say event data and we
 can use the field event data command

0:20:02.860000 --> 0:20:06.760000
 line as well. But because this is an
 executable and not a command line

0:20:06.760000 --> 0:20:11.880000
 command as it were, we need to use event
 data image also event data dot

0:20:11.880000 --> 0:20:19.140000
 image. And that's going to be, and again,
 we'll just say, wildcard, don't

0:20:19.140000 --> 0:20:23.880000
 matter where it's coming from.

0:20:23.880000 --> 0:20:29.060000
 We can say, where my.exe.

0:20:29.060000 --> 0:20:35.220000
 And let's close that up there.

0:20:35.220000 --> 0:20:37.680000
 And then we'll say, and
 so logical operator.

0:20:37.680000 --> 0:20:41.320000
 And then we'll say, actually, let's
 start off with this before we sort

0:20:41.320000 --> 0:20:42.720000
 of add on. And then we'll say,
 okay, let's go on to that.

0:20:42.720000 --> 0:20:48.520000
 My bad. So forgot to use my quotes there.


0:20:48.520000 --> 0:20:49.420000
 Let's hit enter.

0:20:49.420000 --> 0:20:54.440000
 Okay. So here we can find all logs
 or documents pertinent to all that

0:20:54.440000 --> 0:20:59.160000
 are related to the execution
 of who am I.exe.

0:20:59.160000 --> 0:21:03.540000
 And we can see the, you know, under
 event data dot command line, what

0:21:03.540000 --> 0:21:05.520000
 context this is being executed under.

0:21:05.520000 --> 0:21:10.980000
 And we can see some very suspicious
 execution, some very suspicious logs

0:21:10.980000 --> 0:21:14.560000
 that essentially tell us that
 who am I is being executed.

0:21:14.560000 --> 0:21:18.640000
 You know, for this is indicative of
 malicious activity, because who am

0:21:18.640000 --> 0:21:32.880000
 I. And we can see that we can find this
 particular task, but we want to

0:21:32.880000 --> 0:21:37.240000
 be very specific, or we want to
 find the execution of who am I.

0:21:37.240000 --> 0:21:41.700000
 Or we want to find instances where who
 am I was executed by a user with

0:21:41.700000 --> 0:21:43.080000
 system privileges.

0:21:43.080000 --> 0:21:45.120000
 And this is what we're looking for here.

0:21:45.120000 --> 0:21:49.320000
 So, empty authority system,
 not just any user.

0:21:49.320000 --> 0:21:53.140000
 And you can see if we would have gone
 under the assumption that this was

0:21:53.140000 --> 0:21:57.240000
 malicious just on the basis that
 who am I previous executed.

0:21:57.240000 --> 0:22:00.560000
 And we didn't factor in who it was executed
 by, which in this case appears

0:22:00.560000 --> 0:22:05.800000
 to be a service account called Voun scan
 for, you know, as the name suggests

0:22:05.800000 --> 0:22:07.760000
 a vulnerability scanner.

0:22:07.760000 --> 0:22:09.780000
 Then we would have assumed
 that this is malicious.

0:22:09.780000 --> 0:22:14.900000
 And this is where the whole idea of,
 you know, false positives comes into

0:22:14.900000 --> 0:22:16.280000
 play, which we haven't got to yet.

0:22:16.280000 --> 0:22:21.100000
 In any case, we need to extend or expand
 our, or I should say refine our

0:22:21.100000 --> 0:22:26.880000
 search so we can say, and I'm
 now going to say event.

0:22:26.880000 --> 0:22:35.400000
 Data user, and we are going to
 say that is that should be.

0:22:35.400000 --> 0:22:37.480000
 Empty authority.

0:22:37.480000 --> 0:22:41.160000
 So we'll just say uppercase
 or empty authority.

0:22:41.160000 --> 0:22:45.220000
 And then, because we need to
 do a double backslash here.

0:22:45.220000 --> 0:22:49.860000
 This come and we can close
 that up so now it enter.

0:22:49.860000 --> 0:22:54.160000
 And now we're getting what we wanted
 to get or we've pretty much solved

0:22:54.160000 --> 0:22:58.080000
 the solution. So job was to detect
 execution of who am I by, you know,

0:22:58.080000 --> 0:23:03.160000
 user with privilege with elevated
 privileges or system privileges.

0:23:03.160000 --> 0:23:06.900000
 So if we take a look
 at one of these here.

0:23:06.900000 --> 0:23:10.160000
 And we see, yeah, that's who am I.

0:23:10.160000 --> 0:23:11.440000
 That's no issue.

0:23:11.440000 --> 0:23:16.340000
 Let's take a look at event data user
 that's empty authority system, but

0:23:16.340000 --> 0:23:20.920000
 we can see right over here.

0:23:20.920000 --> 0:23:25.320000
 You know, if we take a look at the message,
 we can learn more about this

0:23:25.320000 --> 0:23:30.080000
 particular log or that particular
 execution of who am I.

0:23:30.080000 --> 0:23:32.020000
 And we also have another one here.

0:23:32.020000 --> 0:23:35.860000
 And we can also take a look at the
 fields we explored previously.

0:23:35.860000 --> 0:23:39.660000
 Like, for example, there we are the TTP.

0:23:39.660000 --> 0:23:46.880000
 In this case, the only one displayed
 because it's relevant is the attack

0:23:46.880000 --> 0:23:48.940000
 stages or privilege escalation discovery.


0:23:48.940000 --> 0:23:51.580000
 That makes sense.

0:23:51.580000 --> 0:23:56.880000
 This one. Yeah, this is one that looks
 malicious because it's the parent

0:23:56.880000 --> 0:24:02.180000
 command line or parent images is CMD
.exe, which we know the attack has

0:24:02.180000 --> 0:24:05.860000
 been using based on our
 previous searches.

0:24:05.860000 --> 0:24:09.660000
 And the parent of parent is this funny
 executable that's stored where

0:24:09.660000 --> 0:24:15.040000
 it's stored in the system route directory,
 which again is an environment

0:24:15.040000 --> 0:24:18.240000
 variable that just means
 the windows folder.

0:24:18.240000 --> 0:24:19.920000
 And we can see that here.

0:24:19.920000 --> 0:24:24.160000
 So this looks quite malicious or this is,
 you know, an indication of something

0:24:24.160000 --> 0:24:27.240000
 fishy going on. So there we are.

0:24:27.240000 --> 0:24:29.480000
 That's pretty much it.

0:24:29.480000 --> 0:24:35.540000
 As I said, there's way more tasks than the
 ones I've covered in this demonstration.

0:24:35.540000 --> 0:24:38.320000
 And the reasons for that
 I already mentioned.

0:24:38.320000 --> 0:24:40.220000
 So go through the other tasks.

0:24:40.220000 --> 0:24:44.180000
 Hopefully now you're armed with an understanding
 of how to use elk, how

0:24:44.180000 --> 0:24:47.520000
 to, you know, write your own searches,
 what they mean, how to logically

0:24:47.520000 --> 0:24:52.980000
 or how to go through the logical phases
 of creating a search because I'll

0:24:52.980000 --> 0:24:57.360000
 reiterate again, it's not just about
 copying and pasting searches, even

0:24:57.360000 --> 0:25:01.260000
 though, you know, that may be something
 you as a beginner, you'd be tempted

0:25:01.260000 --> 0:25:06.060000
 to do. So now that you have a better
 understanding of, you know, what

0:25:06.060000 --> 0:25:10.100000
 to, or how to look for what you're looking
 for, or what you've been asked

0:25:10.100000 --> 0:25:15.360000
 to look for, you can go ahead and complete
 the other tasks and the solutions

0:25:15.360000 --> 0:25:22.860000
 there, you know, are quite well developed
 or outlined in that they require

0:25:22.860000 --> 0:25:26.360000
 you to understand exactly what I
 wanted you to understand here.

0:25:26.360000 --> 0:25:29.660000
 So anyway, with that being said, that
 brings us to the end of the practical

0:25:29.660000 --> 0:25:32.140000
 demonstration section of this video.

0:25:32.140000 --> 0:25:38.520000
 All right, so that was how to effectively
 use elk for a wide range of

0:25:38.520000 --> 0:25:43.580000
 things. But of course, in this case,
 the key objectives were to give you

0:25:43.580000 --> 0:25:48.240000
 if you haven't experienced using a seam,
 or all beat in this case, very

0:25:48.240000 --> 0:25:52.100000
 simple one to give you that first hand,
 or, you know, to give you the

0:25:52.100000 --> 0:25:54.520000
 opportunity to try it out
 for the first time.

0:25:54.520000 --> 0:25:59.340000
 Secondly, to show you how elk works with
 regards to, you know, the fields

0:25:59.340000 --> 0:26:05.060000
 looking for, you know, specific logs
 or activity, and consequently how

0:26:05.060000 --> 0:26:11.160000
 to create searches to find, you know, particular
 logs, or to detect particular

0:26:11.160000 --> 0:26:17.060000
 activity. And it's from these searches
 that you can then build, you know,

0:26:17.060000 --> 0:26:18.780000
 your rules for alerts.

0:26:18.780000 --> 0:26:26.060000
 So you, you know, a sock analyst or even
 an incident responder, when when

0:26:26.060000 --> 0:26:30.420000
 using a seam, you're not typically not
 going to be writing these searches,

0:26:30.420000 --> 0:26:36.400000
 you know, manually, you know, that's
 assuming that the alerts have already

0:26:36.400000 --> 0:26:42.120000
 been created. What this, what we explored
 here is sort of the precursor

0:26:42.120000 --> 0:26:46.780000
 to writing rules for alerts or rules
 that trigger alerts or what you would

0:26:46.780000 --> 0:26:52.080000
 be doing, or what the sock analyst would
 be doing, or what you'd consider

0:26:52.080000 --> 0:26:54.180000
 detection engineering.

0:26:54.180000 --> 0:26:59.820000
 What, what you'd be doing in that case
 is you'd be again writing these

0:26:59.820000 --> 0:27:04.240000
 searches for malicious activity or activity
 that you want to be alerted

0:27:04.240000 --> 0:27:09.500000
 about. And then once you've created them
 and refined them and you've confirmed

0:27:09.500000 --> 0:27:11.860000
 that they're giving you what you want.

0:27:11.860000 --> 0:27:17.080000
 At that point, you can then use those
 searches to create rules that will

0:27:17.080000 --> 0:27:21.660000
 then automatically trigger an alert
 if any of those parameters have been

0:27:21.660000 --> 0:27:24.260000
 met. So hopefully that makes sense.

0:27:24.260000 --> 0:27:30.500000
 That's going to be it for this particular
 video and I will be seeing you

0:27:30.500000 --> 0:27:31.960000
 in the next video.

