WEBVTT

0:00:03.980000 --> 0:00:06.960000
 Evidence, triage and collection.

0:00:06.960000 --> 0:00:11.180000
 So this is going to mark the final video
 within this section or subsection

0:00:11.180000 --> 0:00:20.480000
 of incident analysis or the instant
 analysis primer, we're introducing

0:00:20.480000 --> 0:00:23.320000
 you to the analysis phase.

0:00:23.320000 --> 0:00:30.300000
 And this is a very, very important video
 topic that really is very difficult

0:00:30.300000 --> 0:00:35.900000
 to find, you know, publicly, is difficult
 to find out there in terms of

0:00:35.900000 --> 0:00:41.680000
 it being made or, you know, this process
 being explained in a meaningful

0:00:41.680000 --> 0:00:45.280000
 way, in a way that makes sense
 to you as an instant responder.

0:00:45.280000 --> 0:00:50.960000
 It's something that I had to sort
 of develop and formalize myself.

0:00:50.960000 --> 0:00:56.020000
 So I'm actually quite happy with this particular
 video, the material contained

0:00:56.020000 --> 0:01:02.100000
 in here. And that's all to do with,
 as I mentioned, you know, at the end

0:01:02.100000 --> 0:01:09.440000
 of the previous video, with the process
 of determining what evidence or

0:01:09.440000 --> 0:01:16.340000
 data you need to collect for analysis,
 determining what data, what order

0:01:16.340000 --> 0:01:21.120000
 to collect it with before you actually
 get to the collection, or you begin,

0:01:21.120000 --> 0:01:27.320000
 you know, for example, capturing the
 RAM or, you know, all sorts of other

0:01:27.320000 --> 0:01:29.660000
 forensic artifacts or evidence.

0:01:29.660000 --> 0:01:33.600000
 So we're going to touch on both, you
 know, the evidence triage process,

0:01:33.600000 --> 0:01:37.560000
 how it works. And this is, as I said,
 something that I have formalized.

0:01:37.560000 --> 0:01:40.060000
 So hopefully it'll be of value to you.

0:01:40.060000 --> 0:01:42.900000
 And then the collection process.

0:01:42.900000 --> 0:01:47.680000
 So what can be collected, what is typically
 collected for analysis and

0:01:47.680000 --> 0:01:50.400000
 why, as well as some examples of tools.

0:01:50.400000 --> 0:01:56.500000
 Now when we drill deeper into when we'll
 get started in the next section

0:01:56.500000 --> 0:02:02.940000
 with endpoint analysis specifically, you
 know, we'll get quite more specific

0:02:02.940000 --> 0:02:04.940000
 with in terms of the tools.

0:02:04.940000 --> 0:02:08.980000
 And we'll obviously have lab demos that
 will be going through to familiarize

0:02:08.980000 --> 0:02:12.640000
 yourself with not just the process,
 but also the tools themselves.

0:02:12.640000 --> 0:02:16.740000
 With that being said, let's get started
 with the with evidence triage

0:02:16.740000 --> 0:02:19.580000
 and the evidence triage process.

0:02:19.580000 --> 0:02:24.360000
 So evidence triage prioritizing,
 preserving and staying focused.

0:02:24.360000 --> 0:02:28.000000
 That's a sort of very important
 tagline there.

0:02:28.000000 --> 0:02:29.540000
 So let's get started.

0:02:29.540000 --> 0:02:40.860000
 So as we as we explored this, we can
 just respond specifically before

0:02:40.860000 --> 0:02:45.480000
 we get into deep analysis, because remember,
 deep analysis requires these

0:02:45.480000 --> 0:02:47.900000
 artifacts or evidence.

0:02:47.900000 --> 0:02:53.480000
 And I'm now addressing how to decide
 if you remember in the example, in

0:02:53.480000 --> 0:02:57.960000
 the previous video, when we're talking
 about that, you know, that example

0:02:57.960000 --> 0:03:02.560000
 of an incident with regards to, you know,
 this malicious executable called

0:03:02.560000 --> 0:03:09.120000
 beacon.exe. And I laid out the deep analysis
 steps, what, you know, endpoint

0:03:09.120000 --> 0:03:12.640000
 analysis would entail with regard
 to that particular incident.

0:03:12.640000 --> 0:03:16.860000
 I started with, you know,
 analyzing the RAM.

0:03:16.860000 --> 0:03:22.620000
 You know, I said that there's a reason
 why I started with RAM first, but

0:03:22.620000 --> 0:03:26.800000
 we're sort of going back to the point
 when we've completed first response

0:03:26.800000 --> 0:03:30.740000
 and we're validated that an
 incident is legitimate.

0:03:30.740000 --> 0:03:36.040000
 So after an incident is deemed valid,
 is valid or has been validated,

0:03:36.040000 --> 0:03:40.960000
 the responder, as we saw in the example
 in the previous video will potentially

0:03:40.960000 --> 0:03:46.940000
 or will most likely have more artifacts
 to investigate as part of their

0:03:46.940000 --> 0:03:49.660000
 subsequent analysis or deep analysis.

0:03:49.660000 --> 0:03:54.280000
 Now, it goes without saying that in
 order to analyze these artifacts,

0:03:54.280000 --> 0:03:58.700000
 right, like RAM, for example, you need
 to actually collect this evidence

0:03:58.700000 --> 0:04:00.940000
 or data from the endpoints.

0:04:00.940000 --> 0:04:05.240000
 I'm limiting the example or the explanation
 just endpoints are not network

0:04:05.240000 --> 0:04:07.860000
 based analysis or network
 centric analysis.

0:04:07.860000 --> 0:04:09.740000
 So just keep that in mind.

0:04:09.740000 --> 0:04:15.900000
 Now, before we go crazy and start, you
 know, collecting all this evidence

0:04:15.900000 --> 0:04:21.580000
 from all, you know, from the affected
 systems without any plan, and to

0:04:21.580000 --> 0:04:25.400000
 sort of make my point here, before you
 begin the process of data evidence

0:04:25.400000 --> 0:04:30.640000
 data or evidence collection, aka acquisition,
 when you're talking about

0:04:30.640000 --> 0:04:36.880000
 forensic specifically, you need to perform
 an incident specific evidence

0:04:36.880000 --> 0:04:43.440000
 triage process. Why to determine what
 data or evidence to collect and

0:04:43.440000 --> 0:04:50.120000
 equally as importantly, the order in
 which it is to be collected based

0:04:50.120000 --> 0:04:53.220000
 on, you know, various factors
 which I'll get into.

0:04:53.220000 --> 0:04:58.160000
 So evidence triage imposes a quick
 but structured decision process.

0:04:58.160000 --> 0:05:04.660000
 So you, a, collect the right artifacts
 in the right order, highest value,

0:05:04.660000 --> 0:05:06.420000
 most volatile first.

0:05:06.420000 --> 0:05:11.280000
 Don't worry if that sounds a little
 bit too basic or simplified.

0:05:11.280000 --> 0:05:12.700000
 It'll make sense.

0:05:12.700000 --> 0:05:15.400000
 B, maintain chain of custody.

0:05:15.400000 --> 0:05:18.760000
 Now, this course is not focused on
 an incident response, but I need to

0:05:18.760000 --> 0:05:22.500000
 introduce you to this, even though we'll
 be covering it in its own course.

0:05:22.500000 --> 0:05:26.400000
 So every item is legally and
 technically defensible.

0:05:26.400000 --> 0:05:29.460000
 That's very important when you're talking
 about collecting any data, doesn't

0:05:29.460000 --> 0:05:32.920000
 matter whether you intend on analyzing
 it or you've analyzed it.

0:05:32.920000 --> 0:05:35.620000
 Chain of custody is very important.

0:05:35.620000 --> 0:05:41.560000
 And then thirdly, to prevent analysis
 paralysis by using or through the

0:05:41.560000 --> 0:05:48.360000
 use of repeatable or reusable scoring
 matrix instead of ad hoc choices.

0:05:48.360000 --> 0:05:53.900000
 And ad hoc is the way that many
 students, many beginners lean.

0:05:53.900000 --> 0:05:57.380000
 And if you think about it, it actually
 makes sense without a plan or,

0:05:57.380000 --> 0:06:03.580000
 you know, as it states here, a matrix
 to tell you, hey, given the fact

0:06:03.580000 --> 0:06:07.480000
 that you're dealing with this type of
 incident, you need to collect this

0:06:07.480000 --> 0:06:12.880000
 first. And you're collecting it not
 only because it is valuable from a

0:06:12.880000 --> 0:06:18.560000
 forensic investigation perspective,
 you know, based on the fact that it

0:06:18.560000 --> 0:06:25.560000
 has, or potentially has a lot of useful
 data in there or for you, but

0:06:25.560000 --> 0:06:30.260000
 also because of the nature of that
 data and the fact that, again, when

0:06:30.260000 --> 0:06:35.860000
 we're talking about volatile data,
 if you lose time or, you know, you

0:06:35.860000 --> 0:06:40.780000
 sort of lay back and say, oh, yeah,
 I'll get to that, if that system,

0:06:40.780000 --> 0:06:44.460000
 you know, is shut down for
 whatever reason, that's it.

0:06:44.460000 --> 0:06:45.760000
 That data source is gone.

0:06:45.760000 --> 0:06:48.860000
 And in this case, I'm referring
 to, you know, Ram.

0:06:48.860000 --> 0:06:50.680000
 And Ram is very important.

0:06:50.680000 --> 0:06:55.480000
 Or the evidence contained in
 memory is is very important.

0:06:55.480000 --> 0:06:56.480000
 And it's volatile.

0:06:56.480000 --> 0:06:59.620000
 So that's why it's usually at the top,
 especially when you're dealing

0:06:59.620000 --> 0:07:05.380000
 with, especially when you're dealing
 with incidents that are, you know,

0:07:05.380000 --> 0:07:10.380000
 specific to malware or execution of a particular
 program binary or executable.

0:07:10.380000 --> 0:07:17.240000
 So let's, you know, dive deeper into
 evidence triage and, you know, take

0:07:17.240000 --> 0:07:22.460000
 a look at how it shapes the collection
 or acquisition of data or evidence.

0:07:22.460000 --> 0:07:26.840000
 So evidence triage is sort of like
 the decision filter that is applied

0:07:26.840000 --> 0:07:28.220000
 before acquisition.

0:07:28.220000 --> 0:07:30.840000
 And it can only be applied by you.

0:07:30.840000 --> 0:07:33.580000
 And it really answers
 two questions, right?

0:07:33.580000 --> 0:07:37.000000
 And this is what I was able to formalize
 when I thought about all the

0:07:37.000000 --> 0:07:39.380000
 times I'd done analysis.

0:07:39.380000 --> 0:07:41.440000
 What are the questions
 I was asking myself?

0:07:41.440000 --> 0:07:43.020000
 I would usually start with volatility.

0:07:43.020000 --> 0:07:47.840000
 So I'd say, Oh, I really need to get
 the RAM from that system, you know,

0:07:47.840000 --> 0:07:50.060000
 especially if I was dealing with malware.


0:07:50.060000 --> 0:07:56.800000
 But also, you know, RAM is volatile,
 but it also has quite a bit always

0:07:56.800000 --> 0:07:59.500000
 quite a significant amount
 of forensic value.

0:07:59.500000 --> 0:08:02.760000
 But you should always break
 it down into two questions.

0:08:02.760000 --> 0:08:04.420000
 Firstly, forensic value.

0:08:04.420000 --> 0:08:15.960000
 So what artifacts provide
 the highest value of data?

0:08:15.960000 --> 0:08:18.140000
 And so what I would say is that you're
 dealing with a network based attack.

0:08:18.140000 --> 0:08:20.860000
 What why would you be dumping RAM?

0:08:20.860000 --> 0:08:23.760000
 So it needs to be relevant to the incident
 that you're investigating.

0:08:23.760000 --> 0:08:27.660000
 And this is what a lot of beginners
 don't understand is, you know, you

0:08:27.660000 --> 0:08:32.920000
 follow, you try and follow a standardized
 framework or you try and standardize

0:08:32.920000 --> 0:08:37.360000
 it in terms of saying, Oh, I'll do
 this, this, this, this button.

0:08:37.360000 --> 0:08:41.960000
 In most cases, you know, some steps
 or some data sources really don't

0:08:41.960000 --> 0:08:44.480000
 apply. And that's why playbooks
 are so important.

0:08:44.480000 --> 0:08:47.080000
 In any case, that's the first question.

0:08:47.080000 --> 0:08:49.940000
 The second question is all to
 do with volatility, right?

0:08:49.940000 --> 0:08:55.660000
 So which artifacts will disappear
 or change first?

0:08:55.660000 --> 0:09:00.300000
 So when you're talking about volatility,
 you're essentially saying what

0:09:00.300000 --> 0:09:10.420000
 which of these data sources, you know,
 sort of has been a little bit of

0:09:10.420000 --> 0:09:13.340000
 a risk or it's just the
 nature of volatile data.

0:09:13.340000 --> 0:09:16.200000
 And in this case, I'll stick
 to the example of RAM.

0:09:16.200000 --> 0:09:20.100000
 And the fact that, you know, RAM can
 easily be cleared, you know, just

0:09:20.100000 --> 0:09:24.440000
 with one power down, in any case,
 or restart, a lot of it.

0:09:24.440000 --> 0:09:28.480000
 Now there's a lot more you can get even,
 you know, from a system that's

0:09:28.480000 --> 0:09:32.380000
 rebooted, especially on modern versions
 of Windows, but let's not get

0:09:32.380000 --> 0:09:33.380000
 into that right now.

0:09:33.380000 --> 0:09:40.620000
 So how do you perform evidence triage?

0:09:40.620000 --> 0:09:45.500000
 Now, this is a set the, the area
 that I was able to formalize.

0:09:45.500000 --> 0:09:48.920000
 And this is actually something
 that's done.

0:09:48.920000 --> 0:10:00.860000
 And there's a lot of tools or artifacts,
 prospective, remember, the not,

0:10:00.860000 --> 0:10:07.440000
 you know, we're talking about prospectus,
 prospective or prospectus here.

0:10:07.440000 --> 0:10:12.920000
 So responders typically rank each prospective
 artifact on two scales,

0:10:12.920000 --> 0:10:15.600000
 forensic value and volatility.

0:10:15.600000 --> 0:10:19.940000
 And they typically, when it comes down
 to making a decision as to what

0:10:19.940000 --> 0:10:25.520000
 comes first. So let's say you've already
 arrived at, you've already determined

0:10:25.520000 --> 0:10:28.500000
 that, okay, I need to collect RAM,
 because you know, it's a pro we're

0:10:28.500000 --> 0:10:31.780000
 dealing with process execution persistence,
 I need to get Windows registry,

0:10:31.780000 --> 0:10:35.420000
 all of that, how do you determine
 what to collect first?

0:10:35.420000 --> 0:10:49.000000
 You can already do it in your head,
 but you know, you can just go to,

0:10:49.000000 --> 0:10:53.020000
 you know, priority, or
 order of collection.

0:10:53.020000 --> 0:10:56.340000
 So one is equal to low,
 three is equal to high.

0:10:56.340000 --> 0:11:00.180000
 And then you can say that the sum
 total dictates collection order.

0:11:00.180000 --> 0:11:04.780000
 Now this may have confused you to the
 high heavens, but let me put it

0:11:04.780000 --> 0:11:05.900000
 into context here.

0:11:05.900000 --> 0:11:10.320000
 So this is what this is an example of
 a table that I used to, I developed

0:11:10.320000 --> 0:11:12.880000
 and formalized now again.

0:11:12.880000 --> 0:11:17.540000
 This is going to differ, you know, from
 organization to organization or

0:11:17.540000 --> 0:11:19.200000
 from team to team.

0:11:19.200000 --> 0:11:24.860000
 I'm just giving you an example of how you
 can use a logic, you know, mathematics

0:11:24.860000 --> 0:11:29.940000
 to a certain extent, to help you arrive
 or help you make decisions about

0:11:29.940000 --> 0:11:33.920000
 what to start with with regards
 to evidence acquisition.

0:11:33.920000 --> 0:11:40.320000
 So one column, we have the two, I want
 to maintain the terminology I used,

0:11:40.320000 --> 0:11:46.280000
 we have the two scales, right,
 we have forensic value.

0:11:46.280000 --> 0:11:51.920000
 So how much a data source tells you, and
 volatility, how fast it disappears

0:11:51.920000 --> 0:11:54.080000
 or is likely to disappear.

0:11:54.080000 --> 0:11:56.160000
 And then we have the matrix here.

0:11:56.160000 --> 0:12:02.080000
 So we have, you know, three columns,
 we have 1.2.3 points, right?

0:12:02.080000 --> 0:12:06.460000
 In the case of forensic value
 as a factor, one point is low.

0:12:06.460000 --> 0:12:09.980000
 So routine noise, two points is medium.

0:12:09.980000 --> 0:12:13.580000
 So context as it were, and
 then three points is high.

0:12:13.580000 --> 0:12:16.120000
 So direct attacker evidence.

0:12:16.120000 --> 0:12:20.400000
 So what you're essentially saying
 is you're using this matrix.

0:12:20.400000 --> 0:12:33.620000
 So 123, you know, points or you have
 a basic value, you're likely to get

0:12:33.620000 --> 0:12:38.260000
 from a source. So if you're likely to
 get a lot of value or the most value

0:12:38.260000 --> 0:12:42.680000
 from a particular source or high, you
 know, high value from the source,

0:12:42.680000 --> 0:12:47.400000
 which could correlate to direct attacker
 evidence, then you'd say three

0:12:47.400000 --> 0:12:53.360000
 points. Okay. But remember, you have
 to add it to the other scale, which

0:12:53.360000 --> 0:12:56.200000
 is volatility, because
 this is a matrix table.

0:12:56.200000 --> 0:13:04.180000
 Right. So again, in the case
 of logs, that makes sense.

0:13:04.180000 --> 0:13:05.860000
 That's low volatility.

0:13:05.860000 --> 0:13:08.600000
 That data is non volatile.

0:13:08.600000 --> 0:13:10.580000
 You then have two medium.

0:13:10.580000 --> 0:13:14.000000
 Now you're dealing with Sysmon event
 logs, which can be cleared.

0:13:14.000000 --> 0:13:19.620000
 So they're sort of semi, semi non volatile,
 semi volatile with rollover.

0:13:19.620000 --> 0:13:24.260000
 And then three, now you're dealing with,
 you know, the highest volatility

0:13:24.260000 --> 0:13:26.660000
 or data with the highest volatility.

0:13:26.660000 --> 0:13:31.400000
 So high think of RAM active
 sockets running processes.

0:13:31.400000 --> 0:13:38.600000
 So if the data source has a forensic
 value of high, that's three points.

0:13:38.600000 --> 0:13:43.740000
 And it also has a volatility level
 of high, which is three points.

0:13:43.740000 --> 0:13:45.800000
 That gives you a score of six.

0:13:45.800000 --> 0:13:48.160000
 And you start in descending order.

0:13:48.160000 --> 0:13:49.260000
 So how it works?

0:13:49.260000 --> 0:13:59.560000
 Let me say, you know, you're dealing
 with a maximum score, et cetera,

0:13:59.560000 --> 0:14:01.540000
 on both scales or dimensions.

0:14:01.540000 --> 0:14:03.520000
 So forensic value volatility.

0:14:03.520000 --> 0:14:07.600000
 You add the two numbers in the, in
 this particular case of this matrix

0:14:07.600000 --> 0:14:12.760000
 I've given you here, which is a simple
 one, the maximum score that in

0:14:12.760000 --> 0:14:19.180000
 evidence, a data source or evidence
 source can be assigned or can get

0:14:19.180000 --> 0:14:24.160000
 is six. And you collect, you perform your
 evidence collection or acquisition

0:14:24.160000 --> 0:14:27.400000
 based in descending order.

0:14:27.400000 --> 0:14:31.120000
 So the evidence source that has the
 highest score is what you collect

0:14:31.120000 --> 0:14:33.200000
 first. Make sense?

0:14:33.200000 --> 0:14:34.880000
 Let's take a look at an example.

0:14:34.880000 --> 0:14:40.200000
 So I'm still using the same
 two factor scoring matrix.

0:14:40.200000 --> 0:14:42.580000
 And now I'm going to use
 a couple of examples.

0:14:42.580000 --> 0:14:44.520000
 So let's say RAM, right?

0:14:44.520000 --> 0:14:48.960000
 In this case, I think, you know, all of
 us here would agree that the forensic

0:14:48.960000 --> 0:14:51.400000
 value is going to be high.

0:14:51.400000 --> 0:14:58.640000
 Of course, there may be situations where
 based on the incident, RAM really

0:14:58.640000 --> 0:15:02.120000
 will not tell you much, especially,
 you know, if it's if we're talking

0:15:02.120000 --> 0:15:06.000000
 about, you know, network based threat
 or something of that sort, then

0:15:06.000000 --> 0:15:09.080000
 RAM is going to have a forensic
 value of, let's say, one.

0:15:09.080000 --> 0:15:14.600000
 Okay. But the volatility is still high,
 which means it maintains its score

0:15:14.600000 --> 0:15:19.080000
 of three, which means it's, you know,
 if we're dealing with a network

0:15:19.080000 --> 0:15:23.460000
 based incident and RAM was not that valuable
 to us from a, from the perspective

0:15:23.460000 --> 0:15:25.220000
 of forensic value.

0:15:25.220000 --> 0:15:29.520000
 You know, it would be one and
 the total score would be four.

0:15:29.520000 --> 0:15:36.200000
 But in this case, let's just say we're
 dealing with a process or executable.

0:15:36.200000 --> 0:15:42.980000
 RAM contains a lot of forensic value
 about, you know, processes, all that

0:15:42.980000 --> 0:15:47.140000
 good stuff. So it's going to
 have the highest score here.

0:15:47.140000 --> 0:15:51.560000
 So three, in terms of its volatility,
 it's pretty much the highest.

0:15:51.560000 --> 0:15:55.440000
 So three, three plus three is equal
 to six, which means we capture it

0:15:55.440000 --> 0:15:57.620000
 first. It has the highest score.

0:15:57.620000 --> 0:16:00.940000
 Now, we talk about a Sysmon
 log and the forensic value.

0:16:00.940000 --> 0:16:06.920000
 It has a high forensic value
 to us, just like RAM, right?

0:16:06.920000 --> 0:16:13.840000
 But its volatility has a score of, or,
 you know, is medium, which means

0:16:13.840000 --> 0:16:15.440000
 it gets two points.

0:16:15.440000 --> 0:16:16.880000
 Three plus two is five.

0:16:16.880000 --> 0:16:21.080000
 That means it goes, you, you, you collect
 Sysmon logs only after you've

0:16:21.080000 --> 0:16:22.020000
 collected the RAM.

0:16:22.020000 --> 0:16:24.800000
 So you start with RAM, then
 you collect Sysmon logs.

0:16:24.800000 --> 0:16:29.660000
 And then we have, you know, another
 data source would be, or a piece of

0:16:29.660000 --> 0:16:31.800000
 evidence would be a full disk image.

0:16:31.800000 --> 0:16:36.240000
 So in terms of its forensic value,
 medium, that's fair, right?

0:16:36.240000 --> 0:16:41.320000
 And in terms of its volatility, that's
 going to be low, because again,

0:16:41.320000 --> 0:16:45.540000
 based on the matrix here, you can see
 it's specifically refers to a disk

0:16:45.540000 --> 0:16:46.840000
 image or server logs.

0:16:46.840000 --> 0:16:48.900000
 So the score would be three.

0:16:48.900000 --> 0:16:53.100000
 That means it would be placed
 third in our collection list.

0:16:53.100000 --> 0:16:54.720000
 So we would start off with RAM.

0:16:54.720000 --> 0:17:01.340000
 When we have collected RAM, we have
 dumped RAM, we would move on to the

0:17:01.340000 --> 0:17:07.920000
 Sysmon logs. Then after that, we would,
 you know, take an image, a disk

0:17:07.920000 --> 0:17:11.840000
 image, create an image, I should say.

0:17:11.840000 --> 0:17:14.340000
 And I've added some context there.

0:17:14.340000 --> 0:17:19.340000
 So it's after volatile items are safe,
 or you know, being able to take

0:17:19.340000 --> 0:17:22.000000
 or capture that evidence.

0:17:22.000000 --> 0:17:27.000000
 So this is one of the things that I
 was kind of happy about in terms of

0:17:27.000000 --> 0:17:32.960000
 how I laid it out here, because now
 you probably not believe me now, but

0:17:32.960000 --> 0:17:35.880000
 this will be very helpful to
 you as an instant responder.

0:17:35.880000 --> 0:17:38.700000
 And as I said, this is just an example.

0:17:38.700000 --> 0:17:43.660000
 It's a it's a well versed or it's an
 example that factors in, you know,

0:17:43.660000 --> 0:17:50.560000
 what real evidence triage scoring
 matrices or matrices look like.

0:17:50.560000 --> 0:17:53.260000
 But you can definitely
 perform more research.

0:17:53.260000 --> 0:17:57.640000
 This is a very easy way of determining
 based again on the instant that

0:17:57.640000 --> 0:18:01.300000
 you're dealing with and what you're
 trying to identify what evidence.

0:18:01.300000 --> 0:18:06.380000
 What evidence to collect first.

0:18:06.380000 --> 0:18:10.160000
 And again, it's based on it's typically
 going to be based on the forensic

0:18:10.160000 --> 0:18:12.800000
 value. So what you're
 able to get from it.

0:18:12.800000 --> 0:18:17.380000
 What's it? What is its value to your analysis
 in answering those questions?

0:18:17.380000 --> 0:18:18.440000
 Remember, root cause.

0:18:18.440000 --> 0:18:23.200000
 Who what when where the scope
 all that stuff and volatility.

0:18:23.200000 --> 0:18:27.620000
 So. And I've already explained that.

0:18:27.620000 --> 0:18:30.360000
 So hopefully that example makes sense.

0:18:30.360000 --> 0:18:35.820000
 Now, now that we've explored the evidence
 triage process and you know

0:18:35.820000 --> 0:18:39.520000
 about you know how to.

0:18:39.520000 --> 0:18:44.420000
 Determine what evidence you need to
 collect and what to in what order

0:18:44.420000 --> 0:18:47.120000
 to collect it based on forensic
 value and volatility.

0:18:47.120000 --> 0:18:52.580000
 We can now get to the process of actually
 collecting that that data or

0:18:52.580000 --> 0:18:55.260000
 evidence or as it's known acquisition.

0:18:55.260000 --> 0:19:00.400000
 It's formally defined as evidence acquisition
 or data acquisition in digital

0:19:00.400000 --> 0:19:03.000000
 forensics as a specialization.

0:19:03.000000 --> 0:19:06.820000
 So I'm using collection
 here because it's.

0:19:06.820000 --> 0:19:12.740000
 It's sort of used interchangeably with
 acquisition when you're not talking

0:19:12.740000 --> 0:19:16.760000
 about you know specialized digital
 forensics in any case.

0:19:16.760000 --> 0:19:18.080000
 Evidence collection.

0:19:18.080000 --> 0:19:21.520000
 It should be fairly obvious what it
 is, but you know, I'll provide you

0:19:21.520000 --> 0:19:22.580000
 with the proper interest.

0:19:22.580000 --> 0:19:26.340000
 So once an incident has been validated
 scoped and evidence triage has

0:19:26.340000 --> 0:19:30.020000
 been performed. Which is what
 we just took a look at.

0:19:30.020000 --> 0:19:33.460000
 The next step will involve the collection
 or acquisition of evidence to

0:19:33.460000 --> 0:19:34.940000
 support deep analysis.

0:19:34.940000 --> 0:19:38.880000
 So evidence collection or acquisition
 is the process of capturing a full

0:19:38.880000 --> 0:19:44.900000
 or complete defensible copy of every
 artifact that you identified as you

0:19:44.900000 --> 0:19:49.320000
 know important during evidence
 triage for the purposes.

0:19:49.320000 --> 0:19:53.840000
 Or for the purpose of deeper analysis
 so as to answer key questions like

0:19:53.840000 --> 0:19:58.320000
 as I mentioned earlier what was the
 cause of the attack incident.

0:19:58.320000 --> 0:20:03.240000
 How the attack worked unfolded what
 systems were accessed and what was

0:20:03.240000 --> 0:20:07.300000
 changed so the scope what data was accessed
 you know impact and was any

0:20:07.300000 --> 0:20:10.520000
 data stolen that's also impact so.

0:20:10.520000 --> 0:20:15.680000
 Yeah, we're now just dealing with you know
 collecting what we have identified

0:20:15.680000 --> 0:20:21.080000
 as valuable and in the order that we've
 identified it as being valuable

0:20:21.080000 --> 0:20:23.080000
 for our analysis.

0:20:23.080000 --> 0:20:27.080000
 So that brings us now to something very
 important which is the evidence

0:20:27.080000 --> 0:20:30.240000
 collection or acquisition process.

0:20:30.240000 --> 0:20:36.280000
 And some key guidelines not guidelines
 it pretty much is a framework as

0:20:36.280000 --> 0:20:41.280000
 to how you'd go about evidence collection
 or acquisition depending on

0:20:41.280000 --> 0:20:44.440000
 the type of analysis
 you're performing so.

0:20:44.440000 --> 0:20:50.120000
 First things first even when you're talking
 about you know data acquisition

0:20:50.120000 --> 0:20:54.880000
 evidence collection you want to preserve
 the volatile data first that's

0:20:54.880000 --> 0:20:56.420000
 always the case right.

0:20:56.420000 --> 0:21:01.500000
 So the co actions capture live memory
 or RAM the active process lists

0:21:01.500000 --> 0:21:05.340000
 open sockets the ARP or cache tables.

0:21:05.340000 --> 0:21:10.720000
 You stop and you hash the quarantine
 binaries before they're deleted by

0:21:10.720000 --> 0:21:16.300000
 the EDR or EV that's very important you
 need to jump on that immediately.

0:21:16.300000 --> 0:21:20.180000
 So some typical tools and artifacts
 here would be in the case of tools

0:21:20.180000 --> 0:21:21.080000
 you have wind P.

0:21:21.080000 --> 0:21:25.800000
 M. which is used to capture live memory
 or RAM lime which is does the

0:21:25.800000 --> 0:21:31.240000
 same for Linux you have the loss a
 raptor live response you also have

0:21:31.240000 --> 0:21:37.000000
 now else off nets that for you know
 Linux windows networking so checking

0:21:37.000000 --> 0:21:42.080000
 open sockets EDR remote collection APIs
 would be another you know typical

0:21:42.080000 --> 0:21:48.800000
 tool here that you can use to hash the
 quarantine binaries you then secure

0:21:48.800000 --> 0:21:50.540000
 the transient logs.

0:21:50.540000 --> 0:21:56.640000
 So you export the last 24 to 48 hours
 of Sysmon security partial Linux

0:21:56.640000 --> 0:22:03.180000
 logs you know before the rollover and
 you pull Zcosa Ricotta ring buffers

0:22:03.180000 --> 0:22:07.880000
 or switch P caps that's mostly in the
 case or in the context of a network

0:22:07.880000 --> 0:22:09.680000
 centric analysis.

0:22:09.680000 --> 0:22:15.000000
 So some tools that you can use here in
 the case of windows would be windows

0:22:15.000000 --> 0:22:20.580000
 event utility so we have you tell as
 it's called we have EPL windlog beat

0:22:20.580000 --> 0:22:26.480000
 pole TCP dump for network
 traffic Z capture.

0:22:26.480000 --> 0:22:31.660000
 Zeke sorry and then you know capture
 loss BZ2 and then you acquire non

0:22:31.660000 --> 0:22:35.820000
 volatile artifacts so this is when
 you're talking about you know your

0:22:35.820000 --> 0:22:40.680000
 discs so forensic disc or volume images
 registry hives scheduled task

0:22:40.680000 --> 0:22:45.860000
 XML MFT USN journal stuff like this.

0:22:45.860000 --> 0:22:51.300000
 The classic tools are here FTK imager
 you also have DD on Linux and clone

0:22:51.300000 --> 0:22:57.400000
 zilla those arguably you know you pretty
 much I'm sure you know you've

0:22:57.400000 --> 0:22:58.500000
 already heard of them.

0:22:58.500000 --> 0:23:03.940000
 And then you have this is very important
 hash and chain of custody so

0:23:03.940000 --> 0:23:09.840000
 the hashes are what allow you to facilitate
 you know maintaining the chain

0:23:09.840000 --> 0:23:14.960000
 of custody so it is very important that
 you share to fit into the chain

0:23:14.960000 --> 0:23:21.580000
 of custody. What if you generate a
 charto 56 hash of each file at the

0:23:21.580000 --> 0:23:26.360000
 time of capture the time of capture
 that's very important you record who

0:23:26.360000 --> 0:23:33.500000
 what when were. You can store copies
 in right ones or version storage

0:23:33.500000 --> 0:23:36.520000
 so you typically for the evidence that
 you'll be capturing especially

0:23:36.520000 --> 0:23:40.920000
 when you're dealing with you know discs
 and you know valuable data source

0:23:40.920000 --> 0:23:46.480000
 or important data sources is very important
 that you store them in a secure

0:23:46.480000 --> 0:23:51.080000
 storage because again you don't want
 attackers to get access to that and

0:23:51.080000 --> 0:23:55.600000
 they have everything just ready for them
 in you know in the form of images

0:23:55.600000 --> 0:24:02.200000
 right. So, in terms of typical tools
 and artifacts, charto 56 sum, you

0:24:02.200000 --> 0:24:07.140000
 know storage locations would be an
 immutable S3 bucket on AWS and then

0:24:07.140000 --> 0:24:14.500000
 in terms of recording who what when
 where hash you know in a custody log

0:24:14.500000 --> 0:24:17.920000
 you know you could use your instant
 management or handling platform like

0:24:17.920000 --> 0:24:20.720000
 service now or the Hive ticket fields.

0:24:20.720000 --> 0:24:27.640000
 And then validate acquisition so you rehash
 after transfer you mount images

0:24:27.640000 --> 0:24:31.900000
 read only you verify memory dump integrity
 with volatility so you need

0:24:31.900000 --> 0:24:36.420000
 to actually verify that hey you may
 have performed the collection and

0:24:36.420000 --> 0:24:40.680000
 everything looked good but you need
 to verify that you can actually use

0:24:40.680000 --> 0:24:45.460000
 what your your captured or your collected
 whether it be a disk image you

0:24:45.460000 --> 0:24:47.240000
 know you should be able to mount it.

0:24:47.240000 --> 0:24:51.940000
 For those of you that have done disk
 forensics now will not be doing any

0:24:51.940000 --> 0:24:55.820000
 disk forensics in this course because
 that's something that will be taking

0:24:55.820000 --> 0:24:59.520000
 a you know very close look at in the
 digital forensics when in response

0:24:59.520000 --> 0:25:04.080000
 course in this learning path
 so don't worry about that.

0:25:04.080000 --> 0:25:09.160000
 Yeah and in terms of the typical tools
 and artifacts pertinent to you

0:25:09.160000 --> 0:25:13.460000
 know validating acquisitions of evidence
 you know it be the charto 56

0:25:13.460000 --> 0:25:20.720000
 sum. You know the disk image you check
 the hash pertinent to the disk

0:25:20.720000 --> 0:25:27.300000
 images an example volatility image info
 the image info command so on and

0:25:27.300000 --> 0:25:33.740000
 so forth so that's the evidence collection
 acquisition process and sort

0:25:33.740000 --> 0:25:36.900000
 of broken it down into phases
 and core actions.

0:25:36.900000 --> 0:25:39.940000
 Don't worry it'll become clearer.

0:25:39.940000 --> 0:25:43.480000
 So now that we have an understanding
 of the evidence triage and collection

0:25:43.480000 --> 0:25:47.960000
 process we can turn our attention to the
 various sources of evidence typically

0:25:47.960000 --> 0:25:53.320000
 used for analysis and the respective tools
 through which they can be acquired.

0:25:53.320000 --> 0:25:56.820000
 The next slide contains an operational
 checklist that you can reference

0:25:56.820000 --> 0:26:01.620000
 during first response and the deeper
 analysis that follows so you know

0:26:01.620000 --> 0:26:05.760000
 you can always have it at the ready
 and each row will tell you what to

0:26:05.760000 --> 0:26:06.700000
 collect why they can do it.

0:26:06.700000 --> 0:26:10.260000
 So it's valuable and a proven will provide
 you with an example of a proven

0:26:10.260000 --> 0:26:15.140000
 tool or utility that you can use to pull
 or collect that you know evidence

0:26:15.140000 --> 0:26:19.180000
 or that data source as it were.

0:26:19.180000 --> 0:26:23.720000
 The key takeaway from this slide is that
 always hash log and secure every

0:26:23.720000 --> 0:26:27.420000
 artifact immediately to preserve chain
 of custody I'll reiterate that

0:26:27.420000 --> 0:26:36.700000
 again and again because if you miss that
 things get messy really quickly.

0:26:36.700000 --> 0:26:40.020000
 As I said this is I wouldn't say it's
 a checklist is just a reference

0:26:40.020000 --> 0:26:48.240000
 table that you can use whenever you
 want to you know sort of understand

0:26:48.240000 --> 0:26:57.520000
 but also determine you know what evidence
 source contains what or why

0:26:57.520000 --> 0:27:02.020000
 you'd want to collect that evidence
 source and more importantly the go

0:27:02.020000 --> 0:27:05.880000
 to utilities and some quick notes that
 I've added there so you know we

0:27:05.880000 --> 0:27:09.840000
 talk about endpoint logs windows
 Linux in this case.

0:27:09.840000 --> 0:27:13.160000
 The reason you want this is because it's
 the first layer of truth especially

0:27:13.160000 --> 0:27:17.780000
 when we're talking about endpoint
 centric or host based analysis.

0:27:17.780000 --> 0:27:22.580000
 It contains information on process launches
 authentication events script

0:27:22.580000 --> 0:27:28.580000
 blocks script execution program execution
 EDR telemetry you pretty much

0:27:28.580000 --> 0:27:32.500000
 know you know how much information
 is you know windows event logs.

0:27:32.500000 --> 0:27:37.380000
 So in the case of go to utilities that
 you can use to collect this info

0:27:37.380000 --> 0:27:44.120000
 one would be in the case of windows
 the windows event utility you know

0:27:44.120000 --> 0:27:50.840000
 which also has a local EVTX support
 then SISmon and PowerShell via win

0:27:50.840000 --> 0:27:55.620000
 log beat or Splunk and then in the case
 of Linux you know we went through

0:27:55.620000 --> 0:27:59.520000
 and we talked when we were exploring
 Linux logging journal control audit

0:27:59.520000 --> 0:28:05.400000
 the logs then for ram or memory dumps
 the reason you want it is because

0:28:05.400000 --> 0:28:09.400000
 it stores ram typically stores the
 most volatile artifacts these would

0:28:09.400000 --> 0:28:14.120000
 be you know these would include in memory
 malware infected sorry pardon

0:28:14.120000 --> 0:28:15.720000
 me injected the L.

0:28:15.720000 --> 0:28:20.980000
 credentials in LSAS the LSAS process
 cache encryption keys etc.

0:28:20.980000 --> 0:28:24.480000
 So a lot of malware is going to be operating
 in RAM for reasons I've just

0:28:24.480000 --> 0:28:30.220000
 stated now what are some go to utilities
 that can be used to you know

0:28:30.220000 --> 0:28:32.060000
 dump memory or ram.

0:28:32.060000 --> 0:28:35.940000
 Well we have Win P mem which I mentioned
 early on the Velociraptor live

0:28:35.940000 --> 0:28:40.020000
 response module and lime for Linux
 if you want to dump ram on Linux.

0:28:40.020000 --> 0:28:45.340000
 Then you have the disk or volume image
 so the reason you want you know

0:28:45.340000 --> 0:28:50.920000
 a disk image is because it contains really
 full persistence evidence deleted

0:28:50.920000 --> 0:28:55.880000
 files and time stomping rules and it ensures
 repeatable offline work because

0:28:55.880000 --> 0:29:03.120000
 you can always go back to it you know
 and analyze it and try and identify

0:29:03.120000 --> 0:29:05.440000
 or find the information that you want.

0:29:05.440000 --> 0:29:07.760000
 The go to utilities here would be F.T.K.

0:29:07.760000 --> 0:29:13.480000
 image or GUI or the CLI version or functionality
 as it were and clonezilla

0:29:13.480000 --> 0:29:19.140000
 for bit for bit imaging which will not
 get into in this particular course

0:29:19.140000 --> 0:29:26.200000
 with regards to disk for then you have
 process and execution trees so

0:29:26.200000 --> 0:29:30.380000
 this is where you the reason you want
 it is because analysis of parent

0:29:30.380000 --> 0:29:37.040000
 child processes or process chains reveals
 living off the land binaries

0:29:37.040000 --> 0:29:42.140000
 suspicious scripts privilege
 escalation attempts etc.

0:29:42.140000 --> 0:29:47.560000
 And the go to utilities would be an EDR
 console so the process graph system

0:29:47.560000 --> 0:29:53.080000
 tunnels proc dump or process dump process
 explorer as well will actually

0:29:53.080000 --> 0:29:57.760000
 be exploring that within this course
 how to use it and then Velociraptor

0:29:57.760000 --> 0:30:02.400000
 hunt and I've given an example one liner
 there that you can use a Windows

0:30:02.400000 --> 0:30:06.280000
 system PS3 process tree.

0:30:06.280000 --> 0:30:10.960000
 And then we have a couple of other
 evidence sources these are we have

0:30:10.960000 --> 0:30:14.480000
 one here that specific to network centric
 analysis or network based analysis

0:30:14.480000 --> 0:30:19.300000
 which would be a network traffic
 specifically PCAP and NetFlow.

0:30:19.300000 --> 0:30:20.520000
 Why would you want this?

0:30:20.520000 --> 0:30:25.500000
 Well you know it reveals information
 like beacon timing or callbacks you

0:30:25.500000 --> 0:30:33.380000
 know C2 domains attack IP addresses
 malicious domains.

0:30:33.380000 --> 0:30:39.340000
 Exfield payloads you know lateral RDP
 SMB flows lateral movement in general

0:30:39.340000 --> 0:30:44.880000
 and the go you the go to utilities
 here would be TCP dump ring buffer

0:30:44.880000 --> 0:30:47.280000
 sort kernel level.

0:30:47.280000 --> 0:30:53.340000
 Zeke for session logs or key may or
 Molok or full packet indexing and

0:30:53.340000 --> 0:30:59.640000
 NF dump or NF cap D for NetFlow and
 then you have EDR artifacts and that

0:30:59.640000 --> 0:31:04.640000
 that should be fairly obvious as to
 why you'd want it so you get a log

0:31:04.640000 --> 0:31:09.580000
 of real the real time blocking actions
 the quarantine files and the EDR

0:31:09.580000 --> 0:31:13.260000
 captured hashes which is something that
 you know EDRs do or I should say

0:31:13.260000 --> 0:31:14.880000
 a good EDR should do.

0:31:14.880000 --> 0:31:20.340000
 The go to utilities with regards to
 EDR artifacts are you know API polls

0:31:20.340000 --> 0:31:24.880000
 so an example of an EDR that has that
 functionalities crowd strike Falcon

0:31:24.880000 --> 0:31:31.780000
 API. We also have defender for endpoint
 advanced hunting queries sent

0:31:31.780000 --> 0:31:36.020000
 in a one deep visibility I think it's
 called I was not sure about that

0:31:36.020000 --> 0:31:40.320000
 and then browser and use activity artifacts
 this is quite important as

0:31:40.320000 --> 0:31:44.640000
 in as an evidence source it doesn't apply
 in most cases but think of things

0:31:44.640000 --> 0:31:51.240000
 like watering hole attacks are drive by
 downloads and those types of incidents

0:31:51.240000 --> 0:31:53.640000
 you know fishing emails.

0:31:53.640000 --> 0:31:58.020000
 So again why you'd want it as I as it
 stated here initial fishing click

0:31:58.020000 --> 0:32:02.560000
 credential reuse suspicious file downloads
 and some go to utilities would

0:32:02.560000 --> 0:32:08.400000
 be something like hindsight chrome this
 is for chrome or edge forensics.

0:32:08.400000 --> 0:32:13.820000
 You also have jump list passing with
 the JLE CMD shell bags with shell

0:32:13.820000 --> 0:32:20.080000
 bag explorer. So again a lot of this may
 sound you know confusing overwhelming

0:32:20.080000 --> 0:32:22.920000
 but don't worry it'll all make sense now.


0:32:22.920000 --> 0:32:27.780000
 I think I want to reference the evidence
 acquisition workflow or a quick

0:32:27.780000 --> 0:32:33.000000
 workflow that can sort of summarize everything
 that I've said in the previous

0:32:33.000000 --> 0:32:37.160000
 slides in this video so firstly
 prioritized by volatility.

0:32:37.160000 --> 0:32:42.320000
 And you know value so RAM life process
 list transient logs disk image

0:32:42.320000 --> 0:32:47.740000
 use trusted version controls tool version
 control tools this is something

0:32:47.740000 --> 0:32:50.560000
 I didn't mention but it's important
 that I mention it now.

0:32:50.560000 --> 0:32:55.160000
 Keep a hash copy of every acquisition
 binary in your evidence share or

0:32:55.160000 --> 0:32:59.640000
 the location where you're you're keeping
 this stuff hash immediately I'll

0:32:59.640000 --> 0:33:02.860000
 reiterate that again so
 char 256 every dump.

0:33:02.860000 --> 0:33:10.060000
 So you know char 256 some ma'am.raw you
 know the output is displayed there

0:33:10.060000 --> 0:33:14.860000
 log every step so ticket comment or
 dedicated chain of custody form who

0:33:14.860000 --> 0:33:16.640000
 what where when hash.

0:33:16.640000 --> 0:33:20.780000
 Okay just that's an easy way of understanding
 that and secure storage

0:33:20.780000 --> 0:33:26.700000
 so make sure whatever your whatever evidence
 you're collecting or acquiring

0:33:26.700000 --> 0:33:29.980000
 you save in a sick insecure storage.

0:33:29.980000 --> 0:33:36.660000
 And I'm also extending this to you know
 transferring these files you need

0:33:36.660000 --> 0:33:41.240000
 to also ensure that data is secure
 in transit so an example would be a

0:33:41.240000 --> 0:33:45.180000
 right once as three bucket this
 is generally the case nowadays.

0:33:45.180000 --> 0:33:51.020000
 Or evidence NAS with immutability or
 you know basic encrypted external

0:33:51.020000 --> 0:33:55.680000
 drive with Vera crypt or something
 like this that's what I used to use

0:33:55.680000 --> 0:33:56.720000
 in the old days.

0:33:56.720000 --> 0:34:01.460000
 Don't tell anyone but I
 think it's still good.

0:34:01.460000 --> 0:34:06.680000
 So key takeaways to close everything
 up evidence triage is a rapid fire

0:34:06.680000 --> 0:34:11.640000
 prioritization step you decide what
 needs collecting how quickly and in

0:34:11.640000 --> 0:34:15.900000
 what order based on each artifacts
 volatility and forensic value.

0:34:15.900000 --> 0:34:20.600000
 Data acquisition follows from that
 so once priorities are set you use

0:34:20.600000 --> 0:34:24.560000
 the appropriate tools to capture the
 high scoring items first example

0:34:24.560000 --> 0:34:29.320000
 ram down before disk image hashing and
 logging each artifact to preserve

0:34:29.320000 --> 0:34:34.240000
 chain of code. So final paragraph to summarize
 everything think of evidence

0:34:34.240000 --> 0:34:38.280000
 triage is drafting this the shopping
 list under time pressure.

0:34:38.280000 --> 0:34:42.240000
 Okay and acquisition is the act of
 grabbing those items from the shelf

0:34:42.240000 --> 0:34:46.980000
 without the shopping list or without
 triage you risk wasting precious

0:34:46.980000 --> 0:34:51.700000
 minutes on low value or low volatility
 data while the most critical short

0:34:51.700000 --> 0:34:52.760000
 lived evidence disappears.

0:34:52.760000 --> 0:34:57.740000
 Let me explain that a little bit with
 regards to the initial analogy.

0:34:57.740000 --> 0:35:01.140000
 If you don't you know let's say you have
 some shopping to do and you know

0:35:01.140000 --> 0:35:05.020000
 that there's some important stuff that
 you need to buy you know you most

0:35:05.020000 --> 0:35:10.780000
 likely buy other stuff like you
 know snacks and what nots.

0:35:10.780000 --> 0:35:14.520000
 Those aren't really that important
 but there's this key stuff that you

0:35:14.520000 --> 0:35:17.460000
 needed to get whatever they may be.

0:35:17.460000 --> 0:35:21.160000
 I'm not going to give you any examples
 but you can you can sort of infer

0:35:21.160000 --> 0:35:23.180000
 into your own shopping list.

0:35:23.180000 --> 0:35:27.140000
 Now if you didn't make a list you pretty
 much just you know be going with

0:35:27.140000 --> 0:35:35.660000
 the wind as it were and you know you
 might be able to get most of what

0:35:35.660000 --> 0:35:38.560000
 you initially planned to get
 or deemed as critical to get.

0:35:38.560000 --> 0:35:43.380000
 But there's a good chance that you'll
 forget something and hopefully that

0:35:43.380000 --> 0:35:49.880000
 analogy sort of explains evidence triage
 sort of your list of your shopping

0:35:49.880000 --> 0:35:54.660000
 list of evidence and what's the most
 important which you usually put at

0:35:54.660000 --> 0:35:59.040000
 number one. It's starting to come together
 now so that you can pick you

0:35:59.040000 --> 0:36:04.080000
 can get that first so you don't forget
 right and collection is the process

0:36:04.080000 --> 0:36:09.340000
 now all strategically going down
 every aisle in the supermarket.

0:36:09.340000 --> 0:36:14.580000
 You know and checking off
 items of your list.

0:36:14.580000 --> 0:36:23.820000
 So that brings us to the end of this
 video and to the end of the analysis

0:36:23.820000 --> 0:36:28.820000
 primer section of this course now that
 you understand in my opinion really

0:36:28.820000 --> 0:36:35.800000
 well you should understand really quite
 well what analysis is all about

0:36:35.800000 --> 0:36:41.300000
 and the different layers of analysis
 how you go from first response and

0:36:41.300000 --> 0:36:46.860000
 you know the first five minutes or first
 few minutes to determining okay

0:36:46.860000 --> 0:37:06.840000
 we have this incident what do I need
 to collect in order to you know and

0:37:06.840000 --> 0:37:11.920000
 how you go about you know how you go about
 the whole evidence triage process

0:37:11.920000 --> 0:37:17.500000
 and then once you've decided or determined
 what you need to collect and

0:37:17.500000 --> 0:37:23.000000
 in what order you can then begin collecting
 it so with that being said

0:37:23.000000 --> 0:37:26.600000
 that's going to be it for this video
 and I will be seeing you in the next