WEBVTT

0:00:03.660000 --> 0:00:05.920000
 Introduction to Log Analysis.

0:00:05.920000 --> 0:00:12.780000
 So welcome everyone to the Log Analysis
 subsection of this course.

0:00:12.780000 --> 0:00:17.680000
 In the previous section we wanted, or
 we got an introduction to Endpoint

0:00:17.680000 --> 0:00:20.620000
 Analysis, theoretically what it entails.

0:00:20.620000 --> 0:00:26.900000
 And one of the types of Endpoint Analysis
 that I sort of outlined there,

0:00:26.900000 --> 0:00:30.700000
 among many others was a log analysis.

0:00:30.700000 --> 0:00:34.740000
 So in this video I'm going to be setting
 this stage for what we'll be

0:00:34.740000 --> 0:00:41.820000
 covering in a practical sense from the
 next video with regard to log analysis.

0:00:41.820000 --> 0:00:47.100000
 But I thought before we do anything
 practical it's always important to

0:00:47.100000 --> 0:00:54.100000
 introduce these concepts theoretically,
 you know, to give you an idea

0:00:54.100000 --> 0:01:00.020000
 as to what it's all about, what it entails
 as it were, what the objectives

0:01:00.020000 --> 0:01:05.340000
 are, and what the expected deliverables
 or outputs are, or usually are.

0:01:05.340000 --> 0:01:07.900000
 So what is a log analysis?

0:01:07.900000 --> 0:01:13.520000
 Well, on a host or end point logs,
 as you probably know by this point,

0:01:13.520000 --> 0:01:15.640000
 are the operating systems diary.

0:01:15.640000 --> 0:01:18.020000
 So they're like the diary
 of your computer.

0:01:18.020000 --> 0:01:21.900000
 You know, you can actually try this
 out for yourself on Windows or even

0:01:21.900000 --> 0:01:27.160000
 Linux. So what exactly does an operating
 system write about in this diary?

0:01:27.160000 --> 0:01:33.160000
 Well, you can think of things like, you
 know, every process start or process

0:01:33.160000 --> 0:01:38.220000
 execution, you know, user logins, in
 general authentication attempts,

0:01:38.220000 --> 0:01:43.040000
 registry changes, kernel errors,
 and network sockets.

0:01:43.040000 --> 0:01:47.340000
 Information about network socket connections
 can be recorded or are recorded

0:01:47.340000 --> 0:01:49.640000
 as a timestamp entry.

0:01:49.640000 --> 0:01:54.660000
 And that's a very important aspect of
 operating system logs or the operating

0:01:54.660000 --> 0:01:57.960000
 system's diary, just like a normal diary.


0:01:57.960000 --> 0:02:03.500000
 Although with human beings, our diaries
 usually have the date in terms

0:02:03.500000 --> 0:02:06.600000
 of day, month, year, maybe
 there's timestamps.

0:02:06.600000 --> 0:02:11.540000
 But with logs, all of the aforementioned
 activity that an operating system

0:02:11.540000 --> 0:02:15.780000
 would log into their diary would
 be timestamped accordingly.

0:02:15.780000 --> 0:02:20.640000
 Right? So that brings us to the
 question, what is log analysis?

0:02:20.640000 --> 0:02:24.220000
 Specifically, in this case, because
 we're talking about endpoints, we

0:02:24.220000 --> 0:02:25.780000
 need to be a bit more specific.

0:02:25.780000 --> 0:02:31.880000
 So endpoint log analysis is the practice,
 right, of searching, filtering,

0:02:31.880000 --> 0:02:36.520000
 correlating, and interpreting those
 entries, those entries being, you

0:02:36.520000 --> 0:02:40.920000
 know, the operating systems diary,
 as it were, in order to answer five

0:02:40.920000 --> 0:02:44.300000
 typical incident response questions.

0:02:44.300000 --> 0:02:47.880000
 So did anything malicious
 happen on this host?

0:02:47.880000 --> 0:02:51.100000
 And then more specifically,
 when did it start?

0:02:51.100000 --> 0:02:53.140000
 And how far did it go?

0:02:53.140000 --> 0:02:55.940000
 How did the attacker get in and stay in?

0:02:55.940000 --> 0:02:59.540000
 So initial access and persistence are
 not saying that when performing

0:02:59.540000 --> 0:03:01.940000
 log analysis, you're always
 going to be doing this.

0:03:01.940000 --> 0:03:05.500000
 Or these are the questions you're always
 going to be answering, you know,

0:03:05.500000 --> 0:03:08.620000
 because it's going to be tied to the
 incident that you're investigating,

0:03:08.620000 --> 0:03:17.020000
 but proceeding on, which identities or,
 you know, user accounts, for example,

0:03:17.020000 --> 0:03:20.500000
 files or data were touched or accessed.

0:03:20.500000 --> 0:03:26.380000
 And what concrete indicators or IOCs like
 hashes, IPs, domains, or registry

0:03:26.380000 --> 0:03:32.240000
 keys in the case of Windows, can we
 use to protect the rest of our other

0:03:32.240000 --> 0:03:38.380000
 endpoint? So which, you know, what IOCs
 can we use to, you know, perform

0:03:38.380000 --> 0:03:45.660000
 an enterprise wide sweep to identify
 other systems affected firstly, but

0:03:45.660000 --> 0:03:49.340000
 more importantly, which, you know,
 usually comes post incident or post

0:03:49.340000 --> 0:03:55.440000
 incident analysis is using, you know,
 what we found, you know, using what

0:03:55.440000 --> 0:04:00.860000
 the incident responder found to improve
 detection, you know, and that's

0:04:00.860000 --> 0:04:04.480000
 where we get into detection, engineering
 and stuff like this.

0:04:04.480000 --> 0:04:07.160000
 So that's what log analysis is all about.


0:04:07.160000 --> 0:04:12.160000
 Now, what we need to take a look at the
 role logs play in an investigation

0:04:12.160000 --> 0:04:15.440000
 or, you know, analysis as it were.

0:04:15.440000 --> 0:04:21.480000
 So firstly, we've gone through, you know,
 what types of the typical steps

0:04:21.480000 --> 0:04:26.660000
 involved in, you know, the responders first
 five minutes or in first response.

0:04:26.660000 --> 0:04:31.520000
 And we already know what the, you know,
 the analysis phase entails with

0:04:31.520000 --> 0:04:34.500000
 regards to the incident
 response lifecycle.

0:04:34.500000 --> 0:04:39.740000
 But now we're sort of seeing how roles
 we're trying to see the role that

0:04:39.740000 --> 0:04:45.940000
 logs play with regard to incident response,
 more specifically detection

0:04:45.940000 --> 0:04:48.900000
 and analysis, but more
 specifically analysis.

0:04:48.900000 --> 0:04:51.420000
 So we have alert validation.

0:04:51.420000 --> 0:04:56.900000
 So how do host or endpoint
 logs fulfill this need?

0:04:56.900000 --> 0:05:00.100000
 Well, you know, triggers on, you know,
 let's say suspicious PowerShell

0:05:00.100000 --> 0:05:06.460000
 that from that point, we can
 utilize logs, log analysis.

0:05:06.460000 --> 0:05:10.800000
 In this case, the example leverages security
 or system on logs on windows

0:05:10.800000 --> 0:05:14.080000
 to either confirm or refute
 the execution chain.

0:05:14.080000 --> 0:05:19.160000
 So this is one way we can use logs or
 the role logs play in an instant,

0:05:19.160000 --> 0:05:24.900000
 you know, in an investigation or the
 role they play in supporting the

0:05:24.900000 --> 0:05:27.780000
 activities and incident responder
 would be doing.

0:05:27.780000 --> 0:05:30.300000
 You then have scoping
 and timeline, right?

0:05:30.300000 --> 0:05:34.420000
 So how, how do endpoint or host
 logs fulfill this need?

0:05:34.420000 --> 0:05:40.020000
 Well, ordered log time stamps, let
 responders rebuild every step from

0:05:40.020000 --> 0:05:44.020000
 initial exploit to initial access
 to persistence and C2.

0:05:44.020000 --> 0:05:48.340000
 So you can essentially leverage the
 fact that logs are timestamp, you

0:05:48.340000 --> 0:05:52.320000
 know, really on any or, I should say
 all operating systems, but they are

0:05:52.320000 --> 0:05:59.420000
 outliers there. We can use that fact
 or the fact that logs are timestamp

0:05:59.420000 --> 0:06:06.100000
 to rebuild firstly to for scoping,
 but secondly, to rebuild every step

0:06:06.100000 --> 0:06:10.680000
 from initial access to persistence
 and anything else that the attacker

0:06:10.680000 --> 0:06:14.340000
 may have done, which is very useful
 in timeline development, right, or

0:06:14.340000 --> 0:06:17.500000
 building a timeline of events.

0:06:17.500000 --> 0:06:19.380000
 And then root cause discovery.

0:06:19.380000 --> 0:06:23.620000
 So how do host or endpoint logs
 fulfill this particular need?

0:06:23.620000 --> 0:06:27.220000
 Well, let's use, you know, an example
 here where, you know, first evidence

0:06:27.220000 --> 0:06:31.220000
 of lateral movement or privilege escalation
 often appears only in local

0:06:31.220000 --> 0:06:34.420000
 logs, which is true, especially
 in the case of windows.

0:06:34.420000 --> 0:06:41.680000
 So think of event ID 4674 for,
 you know, as privilege use.

0:06:41.680000 --> 0:06:44.180000
 And then we also have IUC harvesting.

0:06:44.180000 --> 0:06:47.900000
 So how do host logs help here?

0:06:47.900000 --> 0:06:52.040000
 Well, logs expose hashes, file parts,
 as you know, we saw earlier on in

0:06:52.040000 --> 0:06:58.240000
 this course, PIDs, process IDs, IPs,
 and user accounts that become search

0:06:58.240000 --> 0:07:04.160000
 pivots. You remember when we were talking
 about pivoting to logs, you

0:07:04.160000 --> 0:07:08.520000
 know, so they become search pivots across
 the enterprise, and then regulatory

0:07:08.520000 --> 0:07:10.500000
 proof and lessons learned.

0:07:10.500000 --> 0:07:17.080000
 So forensics sound log exports under
 pin breach notifications, audits,

0:07:17.080000 --> 0:07:19.380000
 and post incident detection tuning.

0:07:19.380000 --> 0:07:24.140000
 So, you know, this is the role that logs
 plane and investigation specific

0:07:24.140000 --> 0:07:26.540000
 to various IR needs, right?

0:07:26.540000 --> 0:07:29.880000
 And hopefully these examples, you know,
 bring that to light or sort of

0:07:29.880000 --> 0:07:36.140000
 explain the importance of logs and
 why, you know, it shouldn't be, it

0:07:36.140000 --> 0:07:39.780000
 shouldn't be ignored or taken
 lightly as a skill.

0:07:39.780000 --> 0:07:42.840000
 So why log analysis is critical?

0:07:42.840000 --> 0:07:47.300000
 Well, if you think about it, it's the
 easiest or cheapest, I shouldn't

0:07:47.300000 --> 0:07:51.540000
 use the word cheapest, but most accessible
 piece of evidence, right?

0:07:51.540000 --> 0:07:56.200000
 Unlike disk images or memory dumps,
 logs are usually already present and

0:07:56.200000 --> 0:07:57.980000
 relatively simple to acquire.

0:07:57.980000 --> 0:08:02.560000
 Now the means to which you perform
 or you acquire the logs, you know,

0:08:02.560000 --> 0:08:12.100000
 you firstly, you may not need to be
 shipped or forwarded to a scene, you

0:08:12.100000 --> 0:08:17.240000
 can utilize the scene as, you know,
 sort of the first as your starting

0:08:17.240000 --> 0:08:20.440000
 point to analyze logs from
 a particular host.

0:08:20.440000 --> 0:08:25.060000
 But you know, there's also the other
 option or alternative, which is to

0:08:25.060000 --> 0:08:32.480000
 analyze the logs on the actual system
 or to, you know, collect or acquire

0:08:32.480000 --> 0:08:38.200000
 the logs from that system and then,
 you know, copy them over into your

0:08:38.200000 --> 0:08:41.240000
 analysis system and then
 analyze them there.

0:08:41.240000 --> 0:08:43.460000
 We'll get into that shortly.

0:08:43.460000 --> 0:08:47.380000
 Another reason why log analysis is critical
 is because of the high signal

0:08:47.380000 --> 0:08:49.120000
 to noise ratio, right?

0:08:49.120000 --> 0:08:54.700000
 So, you know, properly passed windows
 or, you know, Sysmall and Linux

0:08:54.700000 --> 0:08:59.500000
 audit logs contain, not always the case,
 but generally speaking, contain

0:08:59.500000 --> 0:09:06.740000
 attack, a miter attack, mapable signals
 with relatively few false positives

0:09:06.740000 --> 0:09:09.040000
 and then bridging endpoint and network.

0:09:09.040000 --> 0:09:11.080000
 So, this is correlation right now.

0:09:11.080000 --> 0:09:14.580000
 Let's drill a little bit a little
 bit deeper into this.

0:09:14.580000 --> 0:09:19.280000
 So, you know, things like process IDs
 and socket events give you the ability

0:09:19.280000 --> 0:09:25.540000
 to link host activity with firewall
 or IDS alerts as an example, right?

0:09:25.540000 --> 0:09:29.920000
 Which gives you a more complete storyline
 of the attack activity or allows

0:09:29.920000 --> 0:09:32.220000
 you to understand what the
 attacker did, right?

0:09:32.220000 --> 0:09:40.220000
 With firstly, in terms of the scope of
 the activity and their trade craft,

0:09:40.220000 --> 0:09:45.240000
 but more importantly, because, you know,
 the fact that they're timestamps,

0:09:45.240000 --> 0:09:50.320000
 you're also able to develop
 a timeline of events.

0:09:50.320000 --> 0:09:52.480000
 You then have rapid RUC expansion.

0:09:52.480000 --> 0:09:56.260000
 So, if you think about it, new hashes
 or domains pulled from an endpoint

0:09:56.260000 --> 0:10:01.300000
 to logs can be used to drive proactive
 hunts on thousands of others.

0:10:01.300000 --> 0:10:04.700000
 So, you know, use your IOCs to,
 you know, perform a sweep.

0:10:04.700000 --> 0:10:11.080000
 There's many reasons why, how you can
 use an IOC either during the analysis

0:10:11.080000 --> 0:10:15.820000
 phase or, you know, after we'll
 not get into that right now.

0:10:15.820000 --> 0:10:23.140000
 But that brings us to a very key point
 here or aspect of log analysis.

0:10:23.140000 --> 0:10:26.360000
 And that, you know, it may have been a
 question you've already asked yourself,

0:10:26.360000 --> 0:10:32.400000
 is what exactly do you need to know
 and should you be able to do with

0:10:32.400000 --> 0:10:36.240000
 regard to log analysis
 as an incident respond?

0:10:36.240000 --> 0:10:37.580000
 I need to highlight this.

0:10:37.580000 --> 0:10:42.340000
 So, firstly, on the first column, you
 have some competencies and then,

0:10:42.340000 --> 0:10:46.960000
 you know, details about the competency
 to help you understand it better.

0:10:46.960000 --> 0:10:50.180000
 So, firstly, you need to have
 a log source literacy.

0:10:50.180000 --> 0:10:54.340000
 So, that's why, you know, in the first
 section of the course, we went

0:10:54.340000 --> 0:10:55.460000
 through logging.

0:10:55.460000 --> 0:10:59.740000
 You know, we went through the logging
 process on both Windows and Linux.

0:10:59.740000 --> 0:11:02.280000
 That's the information I was
 trying to give you there.

0:11:02.280000 --> 0:11:06.780000
 But, you know, to be a bit more specific,
 you know, the security on Windows,

0:11:06.780000 --> 0:11:11.700000
 you have the security logs as is more than
 PowerShell or operational scheduled

0:11:11.700000 --> 0:11:14.580000
 tasks, WMI activity.

0:11:14.580000 --> 0:11:18.760000
 And then, you know, Linux, you have
 general control, auth.logs, secure

0:11:18.760000 --> 0:11:24.400000
 audit.logs. You know, the SSH, daemon,
 log and pseudo, and the pseudo

0:11:24.400000 --> 0:11:28.960000
 logs. Then, you also have the EDR
 local caches and application logs.

0:11:28.960000 --> 0:11:31.640000
 So, you know, browser database,
 backup agents.

0:11:31.640000 --> 0:11:33.300000
 So, we cover that quite well.

0:11:33.300000 --> 0:11:36.880000
 But within this section of the course,
 we'll actually be revisiting Windows

0:11:36.880000 --> 0:11:41.900000
 logging, but more specifically, the
 key Windows event IDs that you need

0:11:41.900000 --> 0:11:46.180000
 to know as an incident responder that
 sort of allow you or will give you

0:11:46.180000 --> 0:11:49.720000
 a better understanding of what event
 IDs, you know, correlate to what

0:11:49.720000 --> 0:11:56.000000
 activity. Then, that brings us to what I
 was going to, or the second competency

0:11:56.000000 --> 0:11:58.700000
 here, which is the core
 event IDs and messages.

0:11:58.700000 --> 0:12:02.700000
 So, I wouldn't say you need to memorize
 it in today's day and age.

0:12:02.700000 --> 0:12:06.340000
 And my day I had to, I usually printed
 out cheat sheets of Windows event

0:12:06.340000 --> 0:12:10.180000
 IDs. Also, I had the blue team field
 manual as another reference.

0:12:10.180000 --> 0:12:12.740000
 And I'll be sharing some
 more references with you.

0:12:12.740000 --> 0:12:17.680000
 Nowadays, with a quick Google search
 or even leveraging generative AI,

0:12:17.680000 --> 0:12:23.740000
 you can easily pull up, you know, the
 set of a set of high value or core

0:12:23.740000 --> 0:12:25.780000
 event IDs that you need to be aware of.

0:12:25.780000 --> 0:12:29.640000
 So, I've just given you a couple of examples
 here in the case of Windows.

0:12:29.640000 --> 0:12:33.920000
 You have 4624, 4625, which you should
 be familiar with in this course

0:12:33.920000 --> 0:12:38.360000
 we ran through it, you know, which is
 for log on or authentication attempts.

0:12:38.360000 --> 0:12:44.520000
 And we also talked about the types
 of the types of log ons on Windows,

0:12:44.520000 --> 0:12:46.340000
 which is kind of interesting.

0:12:46.340000 --> 0:12:51.660000
 And then you have 4688, which is process
 start 7 0 4 5 service install.

0:12:51.660000 --> 0:12:54.100000
 And then we have system on 1 3 and 11.

0:12:54.100000 --> 0:13:01.460000
 In the case of Linux, you have ordered
 the user start, exec, V E, and

0:13:01.460000 --> 0:13:04.140000
 then CH mod as an example, right?

0:13:04.140000 --> 0:13:07.380000
 So, what else should you know,
 or should you be able to do?

0:13:07.380000 --> 0:13:08.940000
 Well, you have passing and normalization.


0:13:08.940000 --> 0:13:14.260000
 Now, this is not in my opinion, not that
 important in terms of this being

0:13:14.260000 --> 0:13:18.560000
 a key or core competency with
 regard to log analysis.

0:13:18.560000 --> 0:13:22.100000
 But what this entails is creating or
 tuning field extraction so that,

0:13:22.100000 --> 0:13:28.940000
 you know, fields like user name or event
.user is searchable across sources,

0:13:28.940000 --> 0:13:42.500000
 which is, you know, the type of operating
 system logs you're analyzing.

0:13:42.500000 --> 0:13:44.360000
 So, we'll actually touch on this.

0:13:44.360000 --> 0:13:48.120000
 But then you have your query and pivot
 skills, which, you know, you should

0:13:48.120000 --> 0:13:53.620000
 have been able to build up, at least
 to a certain extent when we took

0:13:53.620000 --> 0:13:56.440000
 a look at using elk and stuff like this.

0:13:56.440000 --> 0:14:01.660000
 But, you know, you should have the ability
 to craft SPL, KQL, SQL or grep

0:14:01.660000 --> 0:14:05.760000
 commands or searches to chain events.

0:14:05.760000 --> 0:14:10.300000
 For example, you know, on the case
 of Windows, chain events like 46880

0:14:10.300000 --> 0:14:16.320000
 CMD to Sysmon3 IP to Sysmon11
 file and quickly switch pivot.

0:14:16.320000 --> 0:14:22.640000
 So, hash to PID to IP username,
 you know, something like this.

0:14:22.640000 --> 0:14:24.860000
 And then you have a timeline
 construction.

0:14:24.860000 --> 0:14:26.240000
 This is very important.

0:14:26.240000 --> 0:14:29.860000
 And of course, again, it's very important
 that you keep in mind this is

0:14:29.860000 --> 0:14:35.580000
 specific to these competencies
 are specific to log analysis.

0:14:35.580000 --> 0:14:39.040000
 But, you know, let's take a look at
 what timeline construction is all

0:14:39.040000 --> 0:14:43.600000
 about. So, you should have the ability
 to export multi log slices to CSV

0:14:43.600000 --> 0:14:50.480000
 or SQLite and load into, you know,
 tools like timeline explorer, plaza

0:14:50.480000 --> 0:14:55.760000
 or time sketch and kibana TSVP to visualize
 the attack sequence, which

0:14:55.760000 --> 0:14:59.320000
 is more important than you would
 think or realize at this point.

0:14:59.320000 --> 0:15:02.360000
 Or if you've already experienced
 it, then you know this.

0:15:02.360000 --> 0:15:06.880000
 There's also a couple of other competencies
 here like IOC extraction and

0:15:06.880000 --> 0:15:08.560000
 enrichment, which we talked about.

0:15:08.560000 --> 0:15:13.940000
 So, you need to be able to pass out
 hashes, IPs, URLs, in essence, IOCs,

0:15:13.940000 --> 0:15:19.200000
 enrich them with sources like virus total
 or threat intelligence in general,

0:15:19.200000 --> 0:15:24.300000
 and then feedback into, you know,
 C months and block lists.

0:15:24.300000 --> 0:15:31.840000
 You then need to have an understanding
 of an ability to perform noise

0:15:31.840000 --> 0:15:35.060000
 reduction and tuning, which we
 also talked about earlier on.

0:15:35.060000 --> 0:15:37.840000
 So, hopefully you can start to see that
 I've been building the foundational

0:15:37.840000 --> 0:15:43.000000
 elements so that we focus at least
 in this section of the course just

0:15:43.000000 --> 0:15:44.120000
 on log analysis.

0:15:44.120000 --> 0:15:48.860000
 So, you should have the ability to
 measure false positive or FP rates,

0:15:48.860000 --> 0:15:52.660000
 build suppression filters or sigma
 rule tweaks and document the impact

0:15:52.660000 --> 0:15:57.140000
 on MTTT, minimum time to response.

0:15:57.140000 --> 0:16:05.740000
 And yeah, MTTT, that's not minimum time
 to response at the MTTT escalation

0:16:05.740000 --> 0:16:11.280000
 rate. That is minimum time
 to triage, apologies.

0:16:11.280000 --> 0:16:15.620000
 And then you have chain
 of custody practices.

0:16:15.620000 --> 0:16:24.200000
 So, you know, hash exported EVTX, JSON,
 log collector versions, and store

0:16:24.200000 --> 0:16:29.140000
 evidence on right once media or an immutable
 bucket in terms of, you know,

0:16:29.140000 --> 0:16:31.780000
 what you should know and what
 you should be able to do.

0:16:31.780000 --> 0:16:35.460000
 So, that's what you should know,
 what you should be able to do.

0:16:35.460000 --> 0:16:39.080000
 And here, I want to sort of
 summarize log analysis.

0:16:39.080000 --> 0:16:43.080000
 So, you can call these your key takeaways,
 but there's still one more

0:16:43.080000 --> 0:16:47.880000
 thing I want to get into, which is I'm
 guessing what you're really interested

0:16:47.880000 --> 0:16:53.540000
 in knowing. So, log analysis just to
 summarize transforms an ambiguous

0:16:53.540000 --> 0:16:58.300000
 alert into a precise host level narrative
 of the incident, or at least

0:16:58.300000 --> 0:17:03.600000
 gives you the opportunity to do so,
 depending again, on the type of the

0:17:03.600000 --> 0:17:06.040000
 instant you're analyzing.

0:17:06.040000 --> 0:17:10.700000
 And as a result of that, mastering the
 art of querying, correlating, and

0:17:10.700000 --> 0:17:15.040000
 interpreting endpoint logs is therefore
 a non-negotiable scale, at least

0:17:15.040000 --> 0:17:20.160000
 in my eyes, and dies of many employees
 in so far as what I've seen.

0:17:20.160000 --> 0:17:24.780000
 For any instant responder who wants
 to validate breaches quickly, scope

0:17:24.780000 --> 0:17:26.980000
 them accurately, very important.

0:17:26.980000 --> 0:17:31.360000
 And this is sort of critical here with
 regards to the outputs or what

0:17:31.360000 --> 0:17:35.200000
 you are supposed to deliver, you know,
 base containment on hard evidence

0:17:35.200000 --> 0:17:42.040000
 and not hunches, because containment
 or all waiting for what you find

0:17:42.040000 --> 0:17:43.700000
 in your analysis.

0:17:43.700000 --> 0:17:47.140000
 And they're saying, okay, tell us what
 to do, what system needs to be

0:17:47.140000 --> 0:17:51.500000
 contained, what do we need to
 do to eradicate the threat.

0:17:51.500000 --> 0:17:58.880000
 And based on that, the system's able to
 be restored or recovered, if required,

0:17:58.880000 --> 0:18:02.620000
 and again, depending on the
 nature of the incident.

0:18:02.620000 --> 0:18:07.180000
 So, the final thing I want to touch
 on is the common types or modes of

0:18:07.180000 --> 0:18:11.140000
 log analysis. So, what do I mean by this?


0:18:11.140000 --> 0:18:14.300000
 Well, if you think about it, you know,
 before I even went into this slide,

0:18:14.300000 --> 0:18:17.700000
 in fact, let's not get into it, because
 this sort of a mental exercise

0:18:17.700000 --> 0:18:19.300000
 I want you to go through.

0:18:19.300000 --> 0:18:23.360000
 So, you know, let's take Windows
 logs, event logs, right?

0:18:23.360000 --> 0:18:27.820000
 So, let's say you have your own computer,
 you may not necessarily have

0:18:27.820000 --> 0:18:30.340000
 it forwarding logs to a theme.

0:18:30.340000 --> 0:18:33.440000
 And let's say, you know, you are hacked
 or that system that you have or

0:18:33.440000 --> 0:18:38.620000
 laptop got infected by ransomware, or
 let's just say, you know, there's

0:18:38.620000 --> 0:18:39.780000
 something wrong with it.

0:18:39.780000 --> 0:18:43.640000
 You don't know what it is, it could
 be malware, but you know, it's very

0:18:43.640000 --> 0:18:45.540000
 clear that it's been compromised.

0:18:45.540000 --> 0:18:48.580000
 Now, we're just talking about
 one endpoint here, right?

0:18:48.580000 --> 0:18:53.120000
 So, how do you go about in terms of
 techniques or what are the various

0:18:53.120000 --> 0:18:58.980000
 ways you can, you know, collect those
 logs, analyze them, so on and so

0:18:58.980000 --> 0:19:02.440000
 forth. And that's what I
 want to touch up on here.

0:19:02.440000 --> 0:19:07.320000
 So, the final thing I'll say is that this
 is all going to depend on, again,

0:19:07.320000 --> 0:19:13.660000
 the type of environment you're analyzing
 in terms of, you know, whether

0:19:13.660000 --> 0:19:16.520000
 logs are being shipped to a theme.

0:19:16.520000 --> 0:19:19.500000
 And a lot of other factors, in fact,
 it's best that we go through this

0:19:19.500000 --> 0:19:21.140000
 because it'll help explain it.

0:19:21.140000 --> 0:19:27.400000
 So, the first not ordered sequentially
 or by, you know, order of importance,

0:19:27.400000 --> 0:19:32.060000
 but the first that comes to my mind
 would be seam-centric analysis or

0:19:32.060000 --> 0:19:35.540000
 for, you know, lack of a better term
 to make it as simple as possible

0:19:35.540000 --> 0:19:39.740000
 to understand, analyzing endpoint
 logs with a seam, right?

0:19:39.740000 --> 0:19:40.800000
 So, how does this work?

0:19:40.800000 --> 0:19:44.200000
 Well, you know, as you already know,
 with regards to how a seam works,

0:19:44.200000 --> 0:19:46.800000
 logs flow into an index platform.

0:19:46.800000 --> 0:19:51.180000
 So, the analyst query with SPL or KQL,
 and then you build correlation

0:19:51.180000 --> 0:19:54.160000
 searches, dashboards, or alerts.

0:19:54.160000 --> 0:19:59.360000
 Okay. So, when does this type of
 or mode of log analysis shine?

0:19:59.360000 --> 0:20:00.760000
 Or when is it most useful?

0:20:00.760000 --> 0:20:05.120000
 Well, when you're dealing with, you know,
 an enterprise-wide scale, cross

0:20:05.120000 --> 0:20:13.760000
-source joins, log retention dates or
 durations, and RBAC and audit built

0:20:13.760000 --> 0:20:18.420000
-in. So, example, you know, stack or tool
 here, you know, be Splunk Enterprise

0:20:18.420000 --> 0:20:23.780000
 Security, Elastic Security, or just
 ELK, as it were, Microsoft Sentinel,

0:20:23.780000 --> 0:20:30.140000
 IBM Curator. So, you know, think of
 any seam, those are just examples.

0:20:30.140000 --> 0:20:34.740000
 But then you have one that, again, you
 may be interested in or, you know,

0:20:34.740000 --> 0:20:39.720000
 one that is the most obvious, even if
 there is a seam present, which is

0:20:39.720000 --> 0:20:45.720000
 local or offline GUI review, not necessarily
 GUI review, but it essentially

0:20:45.720000 --> 0:20:51.160000
 infers that you're physically accessing
 that system, or even remotely,

0:20:51.160000 --> 0:20:57.860000
 for the express purpose of collecting
 those logs from that system and

0:20:57.860000 --> 0:21:00.260000
 then analyzing them, you know.

0:21:00.260000 --> 0:21:02.360000
 But let me explain how it works.

0:21:02.360000 --> 0:21:07.400000
 So, drag and drop the, in the case of
 Windows, EVTX, or log folders into

0:21:07.400000 --> 0:21:09.040000
 a desktop viewer.

0:21:09.040000 --> 0:21:12.680000
 So, you know, Windows event viewer,
 you can choose to analyze the logs

0:21:12.680000 --> 0:21:17.300000
 on the actual system that you're analyzing,
 or you can transfer them to

0:21:17.300000 --> 0:21:22.140000
 your own analysis system, which is,
 you know, quite common for analysis.

0:21:22.140000 --> 0:21:28.080000
 So, you know, you then filter, use rejects
 search and then export, right?

0:21:28.080000 --> 0:21:29.620000
 When does this shine?

0:21:29.620000 --> 0:21:33.000000
 Well, you know, single host, when you're
 dealing with just one system,

0:21:33.000000 --> 0:21:37.420000
 at least at this point, you may, you
 know, you haven't identified others.

0:21:37.420000 --> 0:21:44.260000
 But this is usually the best, or when
 this type, or this mode shines.

0:21:44.260000 --> 0:21:49.860000
 You know, another instance or another
 instance as to where, you know,

0:21:49.860000 --> 0:21:52.660000
 this will really work well is when
 you're dealing with, you know, air

0:21:52.660000 --> 0:21:58.260000
 gapped forensics, and, you know, where
 you want, you know, quick GUI triage.

0:21:58.260000 --> 0:22:03.960000
 Some example tools here would be event
 log explorer, glog, g4, no viewer,

0:22:03.960000 --> 0:22:05.640000
 there's a lot more.

0:22:05.640000 --> 0:22:08.900000
 And then you have CLI or scripted hunts.

0:22:08.900000 --> 0:22:16.300000
 This is not local review, and, you
 know, CLI or scripted hunts can be

0:22:16.300000 --> 0:22:21.360000
 considered one. But the way this works
 is you pass the logs on disk with

0:22:21.360000 --> 0:22:23.640000
 command line tools or scripts.

0:22:23.640000 --> 0:22:26.500000
 So, you can automate searches
 in CI pipelines.

0:22:26.500000 --> 0:22:32.200000
 This is really useful when, you know,
 when you want speed, repeatability,

0:22:32.200000 --> 0:22:35.220000
 and integration with
 DevOps or IR scripts.

0:22:35.220000 --> 0:22:39.760000
 So, an example stack or tool configuration
 would be in the case of Windows,

0:22:39.760000 --> 0:22:44.100000
 you know, a tool like chainsaw and sigma,
 the case you also have in the

0:22:44.100000 --> 0:22:51.660000
 case of Linux grep, org, jq4, JSON formatting,
 and then PowerShell, get

0:22:51.660000 --> 0:22:56.220000
 win event, and then, you know, log
 pass a lizard stuff like this.

0:22:56.220000 --> 0:22:59.020000
 And then you have your live
 response agent queries.

0:22:59.020000 --> 0:23:02.780000
 So, this is where you query logs in
 real time from running endpoint.

0:23:02.780000 --> 0:23:07.120000
 This is typically done with EDRs or,
 you know, tools like Velociraptor.

0:23:07.120000 --> 0:23:10.860000
 But the way, you know, sort of building
 on what I just said, so you pull

0:23:10.860000 --> 0:23:14.800000
 back rows that match specific
 IOC patterns.

0:23:14.800000 --> 0:23:16.240000
 When is this useful?

0:23:16.240000 --> 0:23:27.040000
 Well, when you can access, you know,
 remote access may be quite tricky,

0:23:27.040000 --> 0:23:31.680000
 but you know that it has an EDR, or you
 can remotely access it with tools,

0:23:31.680000 --> 0:23:36.300000
 you know, like an EDR or Velociraptor.

0:23:36.300000 --> 0:23:43.200000
 So, example tools or stack here would
 be Velociraptor VQL, GR, Hans, EDR,

0:23:43.200000 --> 0:23:48.500000
 LiveQuery, so think of Falcon, defend
 endpoint in the case of Microsoft.

0:23:48.500000 --> 0:23:51.580000
 So, those are the common types
 or modes of log analysis.

0:23:51.580000 --> 0:23:55.020000
 Okay, with that being said, that's
 going to be it for theory, at least

0:23:55.020000 --> 0:23:59.160000
 to this point. And as always, I'll
 be seeing you in the next video.