WEBVTT

0:00:03.880000 --> 0:00:06.600000
 Live response versus dead box.

0:00:06.600000 --> 0:00:12.020000
 So as I mentioned, towards the latter
 stages of the previous video, I

0:00:12.020000 --> 0:00:15.960000
 wanted to explain this concept because
 it is quite important and is something

0:00:15.960000 --> 0:00:21.240000
 that at least operationally you're
 going to need to be aware of.

0:00:21.240000 --> 0:00:28.860000
 And you're going to need to understand
 the context that this sort of involves

0:00:28.860000 --> 0:00:40.720000
 or entails or how this affects evidence
 collection and the requirements

0:00:40.720000 --> 0:00:46.000000
 that lead to you choosing one over the
 other with regards to collection

0:00:46.000000 --> 0:00:52.780000
 of evidence. So this is not really to
 do with the type but more also various

0:00:52.780000 --> 0:00:56.960000
 other factors. Now, just want to point
 out that you may have been asking

0:00:56.960000 --> 0:01:00.300000
 when are we going to get to the practical
 stuff and don't worry, that's

0:01:00.300000 --> 0:01:02.080000
 going to be the next video.

0:01:02.080000 --> 0:01:07.000000
 So, you know, some of this or I should
 say all of this theoretical knowledge

0:01:07.000000 --> 0:01:11.960000
 is very important because without it,
 you're going to be blind or you

0:01:11.960000 --> 0:01:16.120000
 not really understand what you're doing
 but more importantly, why we're

0:01:16.120000 --> 0:01:17.000000
 doing something.

0:01:17.000000 --> 0:01:24.440000
 So I think I've set a really good foundation
 with regards to you really

0:01:24.440000 --> 0:01:26.580000
 understanding what analysis is about.

0:01:26.580000 --> 0:01:30.480000
 And with this, I think, you know, the
 phases that follow or the various

0:01:30.480000 --> 0:01:35.120000
 types of endpoint analysis that we will
 be engaging in practically will

0:01:35.120000 --> 0:01:37.820000
 be much easier for you to grasp.

0:01:37.820000 --> 0:01:44.320000
 And from that point on, it's just a matter
 of continual practice and exposure,

0:01:44.320000 --> 0:01:50.240000
 you know, to each of those types or categories
 of analysis and, you know,

0:01:50.240000 --> 0:01:57.820000
 the more specifically, the evidence
 data that is pertinent to each of

0:01:57.820000 --> 0:02:01.280000
 those types or categories
 of endpoint analysis.

0:02:01.280000 --> 0:02:04.100000
 In any case, I don't want to
 waste too much of your time.

0:02:04.100000 --> 0:02:07.600000
 What is live response and dead box?

0:02:07.600000 --> 0:02:10.180000
 You know, very, very strange names here.

0:02:10.180000 --> 0:02:16.260000
 Well, when an endpoint is under investigation
 or analysis, right, responders,

0:02:16.260000 --> 0:02:22.140000
 in addition to knowing what to collect
 based on the type of instant they're

0:02:22.140000 --> 0:02:27.900000
 dealing with or responding to and the
 order in which, you know, the evidence

0:02:27.900000 --> 0:02:31.840000
 is to be collected must also
 make another decision.

0:02:31.840000 --> 0:02:36.640000
 And this may not come up all the time,
 but responders must choose between

0:02:36.640000 --> 0:02:39.700000
 two evidence collection strategies.

0:02:39.700000 --> 0:02:43.600000
 So live response and dead box are evidence
 collection strategies pertinent

0:02:43.600000 --> 0:02:47.480000
 pertinent to endpoint analysis, right?

0:02:47.480000 --> 0:02:50.020000
 So live response, what is this all about?


0:02:50.020000 --> 0:02:56.480000
 Well, as the name, as the name suggests,
 live response grabs or works

0:02:56.480000 --> 0:03:01.940000
 by grabbing volatile data like running
 processes, RAM, resident malware

0:03:01.940000 --> 0:03:05.920000
 and active network sockets while
 the system is still powered on.

0:03:05.920000 --> 0:03:10.160000
 So what this means, whenever your live
 response, it means you're you're

0:03:10.160000 --> 0:03:17.500000
 getting evidence, whatever it may be,
 from a system that's currently online,

0:03:17.500000 --> 0:03:20.620000
 or that is currently up, right?

0:03:20.620000 --> 0:03:25.500000
 And the reason or the rational for that
 is, you know, to preserve evidence

0:03:25.500000 --> 0:03:27.820000
 that is volatile in nature.

0:03:27.820000 --> 0:03:34.860000
 Now, when we talk about dead box forensics
 or dead boxes as a collection

0:03:34.860000 --> 0:03:39.500000
 and evidence collections strategy or
 technique, this is where, you know,

0:03:39.500000 --> 0:03:41.880000
 you're powering down the host, right?

0:03:41.880000 --> 0:03:43.760000
 You're taking it offline.

0:03:43.760000 --> 0:03:48.100000
 You're pretty much, you know, for all
 intents and purposes, disabling

0:03:48.100000 --> 0:03:50.620000
 it, right? But why are you doing that?

0:03:50.620000 --> 0:03:53.740000
 Well, you're doing this for a
 very specific use case, right?

0:03:53.740000 --> 0:04:00.940000
 And this use case is acquiring bit for
 bit disk images for pristine court

0:04:00.940000 --> 0:04:02.580000
 defensible analysis.

0:04:02.580000 --> 0:04:08.680000
 But of course, the sacrifice being
 the sacrifice in this case will be

0:04:08.680000 --> 0:04:13.860000
 that in memory artifacts, you know, you
 will not be able to get them because

0:04:13.860000 --> 0:04:16.820000
 you're turning the system,
 you're powering it off.

0:04:16.820000 --> 0:04:22.260000
 And you're obviously going to, you
 may disrupt operations, right?

0:04:22.260000 --> 0:04:28.480000
 Because of the system is a critical system
 or, you know, business critical

0:04:28.480000 --> 0:04:31.120000
 as it were downtime is
 going to cost money.

0:04:31.120000 --> 0:04:33.020000
 So it's going to disrupt operations.

0:04:33.020000 --> 0:04:37.580000
 Consequently, it, you know, it may
 affect the organization financially

0:04:37.580000 --> 0:04:39.260000
 or reputationally.

0:04:39.260000 --> 0:04:43.980000
 So the key thing that I wanted to point
 out here is not really what each

0:04:43.980000 --> 0:04:50.000000
 of these two is or what each of these
 two are with regards to, you know,

0:04:50.000000 --> 0:04:52.800000
 evidence collection or them being
 evidence collection strategies.

0:04:52.800000 --> 0:05:00.260000
 It's more so when you apply each approach
 or knowing when to apply each

0:05:00.260000 --> 0:05:03.540000
 approach or how to combine them.

0:05:03.540000 --> 0:05:06.960000
 And this ensures critical evidence is
 captured without needless business

0:05:06.960000 --> 0:05:11.400000
 impact. And there's many reasons why
 you'd go for, you know, dead box

0:05:11.400000 --> 0:05:15.180000
 over live response, you know, the
 nature of the incident being one.

0:05:15.180000 --> 0:05:16.740000
 And there's a plethora of reasons.

0:05:16.740000 --> 0:05:21.480000
 But this is very important for you to
 understand at least theoretically.

0:05:21.480000 --> 0:05:26.780000
 So let's take a look at live response
 and, you know, what it is, when

0:05:26.780000 --> 0:05:30.740000
 to use it, what it entails, the
 advantages, the trade offs, etc.

0:05:30.740000 --> 0:05:34.120000
 Right. So we have the aspect
 and then the summary.

0:05:34.120000 --> 0:05:38.460000
 So in the, in, in terms of the definition,
 what it is, evidence, this

0:05:38.460000 --> 0:05:41.660000
 is, you know, evidence collection while
 the machine is still powered on

0:05:41.660000 --> 0:05:45.680000
 and running. And, you know, typically
 involves the use of an agent or

0:05:45.680000 --> 0:05:50.000000
 short scripts to pull volatile artifacts
 without shutting the host down.

0:05:50.000000 --> 0:05:54.500000
 So in most cases, it's going
 to be quite automated, right?

0:05:54.500000 --> 0:06:00.040000
 And when to use this, a, when, you know,
 active threats are still beakening

0:06:00.040000 --> 0:06:03.920000
 or moving laterally, so you don't want
 to, you know, shut down the system.

0:06:03.920000 --> 0:06:08.500000
 When the host provides critical services
 and an immediate shutdown would

0:06:08.500000 --> 0:06:09.680000
 harm the business.

0:06:09.680000 --> 0:06:13.080000
 So you have to, you know, just by virtue
 of that fact, the fact that it's

0:06:13.080000 --> 0:06:18.400000
 a, you know, providing critical services,
 you just need to resort to live

0:06:18.400000 --> 0:06:22.380000
 response, not that there's anything
 bad inherently about live response,

0:06:22.380000 --> 0:06:26.560000
 but you also have to account for the
 fact that if the attacker or the

0:06:26.560000 --> 0:06:32.180000
 threat is still active, that, you know,
 you're, you're potentially providing

0:06:32.180000 --> 0:06:37.860000
 an ability for the threat to propagate,
 right, or to extend its scope.

0:06:37.860000 --> 0:06:42.220000
 In any case, another reason is to,
 you know, when to use this, when to

0:06:42.220000 --> 0:06:46.040000
 use live response is when you need
 to capture highly volatile data, so

0:06:46.040000 --> 0:06:50.260000
 process memory, network sockets, RAM,
 only malware, stuff like this, which

0:06:50.260000 --> 0:06:51.520000
 you're already familiar with.

0:06:51.520000 --> 0:06:53.180000
 We discussed this, right?

0:06:53.180000 --> 0:06:54.620000
 And what does it entail?

0:06:54.620000 --> 0:07:00.020000
 So when I say what it entails, what I really
 mean is what does this typically

0:07:00.020000 --> 0:07:04.380000
 look like? So, you know, deploy a live
 response tool, it could be the

0:07:04.380000 --> 0:07:09.080000
 loss wrapped a GRR, CrowdStrike, RTR,
 or remote PowerShell, you typically

0:07:09.080000 --> 0:07:13.540000
 see remote PowerShell being utilized
 quite a lot and there's some really

0:07:13.540000 --> 0:07:21.420000
 good live response PowerShell scripts
 that, you know, facilitate live

0:07:21.420000 --> 0:07:22.880000
 response quite well.

0:07:22.880000 --> 0:07:29.860000
 You then grab RAM dump, running processes,
 loaded DLLs, active connections,

0:07:29.860000 --> 0:07:33.700000
 clipboard, something that a lot of people
 forget or don't think is that

0:07:33.700000 --> 0:07:40.020000
 important? In memory registry, dark
 corner logs, so, you know, log file

0:07:40.020000 --> 0:07:45.780000
 recent DVTX and then hash each artifact,
 copy to secure share and log

0:07:45.780000 --> 0:07:49.740000
 every step in the ticket I've reiterated
 in the previous section.

0:07:49.740000 --> 0:07:51.860000
 So what are the advantages
 and trade-offs?

0:07:51.860000 --> 0:07:56.900000
 So advantages, A preserves evidence
 that vanishes a shutdown, B allows

0:07:56.900000 --> 0:08:01.220000
 quick containment actions, so isolation,
 process kill without full power

0:08:01.220000 --> 0:08:06.140000
 off, which is great, and then minimal
 disruption if done correctly, which

0:08:06.140000 --> 0:08:12.980000
 is the trade-offs, you know, there's
 a risk of altering evidence, so new

0:08:12.980000 --> 0:08:19.360000
 files, touching time stamps, that
 happens quite frequently.

0:08:19.360000 --> 0:08:25.040000
 Secondly, if you're dealing with some
 advanced gear or advanced malware,

0:08:25.040000 --> 0:08:32.340000
 the malware may detect this and
 react in a not so nice way.

0:08:32.340000 --> 0:08:37.380000
 And the other or the final trade-off here
 is that it requires tight procedural

0:08:37.380000 --> 0:08:42.620000
 control to remain defensible in court,
 because again, a live system and

0:08:42.620000 --> 0:08:47.140000
 speaking about the risk of altering evidence,
 not intentionally, but that

0:08:47.140000 --> 0:08:57.680000
 sort of reduces the accuracy of the
 evidence or, yeah, the accuracy of

0:08:57.680000 --> 0:09:01.740000
 the evidence. And, you know, when it's
 a live, when you're performing

0:09:01.740000 --> 0:09:05.280000
 live response, there's a lot of opportunity
 to, you know, modify stuff

0:09:05.280000 --> 0:09:09.660000
 and, you know, all that jazz in any
 case, where we talk about dead box,

0:09:09.660000 --> 0:09:11.480000
 what is dead box all about?

0:09:11.480000 --> 0:09:14.460000
 This is evidence collection after
 the machine is powered off.

0:09:14.460000 --> 0:09:19.300000
 Typically, as I mentioned in the introduction,
 a bit for bit image of

0:09:19.300000 --> 0:09:24.700000
 disks or volumes, plus post-mortem analysis
 of that static media or offset

0:09:24.700000 --> 0:09:29.740000
 static media, when to use this, a, when
 the threat is contained, or the

0:09:29.740000 --> 0:09:31.960000
 host can be safely taken offline.

0:09:31.960000 --> 0:09:34.580000
 So this is when you get
 into dead box stuff.

0:09:34.580000 --> 0:09:39.320000
 B, legal or regulatory requirements,
 demand a pristine unchanged snapshot.

0:09:39.320000 --> 0:09:46.560000
 That's, you know, that's one of those
 caveats that usually leads to, you

0:09:46.560000 --> 0:09:50.240000
 know, dead box being performed or is
 one of the primary reasons why you

0:09:50.240000 --> 0:09:55.920000
 have it because there, when, when, when
 snapshots are required for, you

0:09:55.920000 --> 0:10:03.760000
 know, legal or regulatory requirements
 or compliance, another still continuing

0:10:03.760000 --> 0:10:06.640000
 on, you know, what's another
 use case here?

0:10:06.640000 --> 0:10:10.560000
 Well, when you need to examine deep
 disk artifacts, so think of deleted

0:10:10.560000 --> 0:10:15.240000
 files, time stomps or, you know, slack
 space, for example, without risk

0:10:15.240000 --> 0:10:18.460000
 of live tampering, which
 is very, very important.

0:10:18.460000 --> 0:10:22.240000
 It may not seem that important, but
 especially when you're getting into

0:10:22.240000 --> 0:10:27.080000
 stuff like deleted files, you need to,
 you know, capture bit for bit image

0:10:27.080000 --> 0:10:30.040000
 of disks or volumes, right?

0:10:30.040000 --> 0:10:31.600000
 So what does it entail?

0:10:31.600000 --> 0:10:34.480000
 What does it typically look like?

0:10:34.480000 --> 0:10:37.940000
 Shut down or yank power in, you
 know, when things are bad.

0:10:37.940000 --> 0:10:41.800000
 And of course, I added a caveat there.

0:10:41.800000 --> 0:10:45.220000
 Only if safe to do so and if approved.

0:10:45.220000 --> 0:10:50.380000
 Removing drives or booting from trusted
 forensic media, capturing full

0:10:50.380000 --> 0:11:07.360000
 disk or volume images with tools like
 FTK, imager, DD on Linux or clone

0:11:07.360000 --> 0:11:09.940000
 test of the best there
 that I've listed out.

0:11:09.940000 --> 0:11:13.140000
 The advantages are forensic
 soundness, right?

0:11:13.140000 --> 0:11:18.600000
 So there's a little to no risk of evidence
 alteration, if done correctly.

0:11:18.600000 --> 0:11:24.680000
 Secondly, enables deep file system and
 slack space analysis and see malware

0:11:24.680000 --> 0:11:26.560000
 cannot react or self destruct.

0:11:26.560000 --> 0:11:32.200000
 So you pretty much shut down the system
 and then you take your image,

0:11:32.200000 --> 0:11:35.700000
 right? So the malware cannot do anything.


0:11:35.700000 --> 0:11:37.880000
 You know, it has no time to react.

0:11:37.880000 --> 0:11:41.780000
 It's your when you take the image, you're
 analyzing it as it was at the

0:11:41.780000 --> 0:11:46.120000
 point when you turned off the
 system or shut it down, right?

0:11:46.120000 --> 0:11:48.140000
 And then you have trade offs, right?

0:11:48.140000 --> 0:11:52.060000
 The first trade off most obvious
 is there's no volatile artifact.

0:11:52.060000 --> 0:11:55.920000
 So Ram only implants and live
 network state are lost.

0:11:55.920000 --> 0:12:06.120000
 So in the event you are going to check
 down systems, you're going to lose

0:12:06.120000 --> 0:12:10.180000
 volatile artifacts, not
 to say that that's bad.

0:12:10.180000 --> 0:12:11.820000
 It's a trade off, right?

0:12:11.820000 --> 0:12:17.340000
 The other second, you know, an obvious
 trade off is going to be system

0:12:17.340000 --> 0:12:24.240000
 downtime, which will or may impact
 operations, but it will to it's all

0:12:24.240000 --> 0:12:26.180000
 a matter of degree, right?

0:12:26.180000 --> 0:12:31.880000
 And one of the biggest disadvantages
 is especially depending on the number

0:12:31.880000 --> 0:12:41.860000
 of systems that you're, you know, you're
 actually trying to image the

0:12:41.860000 --> 0:12:45.840000
 imaging of large disks is going to be
 slow and is storage intensive, you

0:12:45.840000 --> 0:12:48.780000
 know, that goes without saying.

0:12:48.780000 --> 0:12:51.040000
 So choosing between them.

0:12:51.040000 --> 0:12:54.240000
 Firstly, you have volatility
 versus business impact.

0:12:54.240000 --> 0:12:57.760000
 So if data and memory is critical and
 the host must stay up, live response

0:12:57.760000 --> 0:13:03.240000
 first. If threats are dormant or the
 host can be pulled offline safely,

0:13:03.240000 --> 0:13:05.100000
 dead box is safer.

0:13:05.100000 --> 0:13:09.580000
 Because you can all, you know, apart
 from losing in memory artifacts,

0:13:09.580000 --> 0:13:18.400000
 you can always bring up the system at the
 later time in sort of a containment

0:13:18.400000 --> 0:13:22.260000
 agency. So if there's, you know, an
 ongoing C2 beacon or communication,

0:13:22.260000 --> 0:13:26.840000
 isolate the network, run live response
 to grab RAM, then image the disk.

0:13:26.840000 --> 0:13:30.060000
 When there's no active communication,
 you can shut down clearly and proceed

0:13:30.060000 --> 0:13:31.700000
 to dead box imaging.

0:13:31.700000 --> 0:13:35.580000
 Then of course, you have legal or regulatory
 requirements in terms of

0:13:35.580000 --> 0:13:39.480000
 a factor determining factor in choosing
 between one or the other.

0:13:39.480000 --> 0:13:43.940000
 So some jurisdictions prefer live capture
 of RAM plus dead box imaging

0:13:43.940000 --> 0:13:45.900000
 for a complete chain of custody.

0:13:45.900000 --> 0:13:51.320000
 Of course, this is going to be very
 nuanced, dependent on jurisdictions

0:13:51.320000 --> 0:13:55.280000
 and, you know, different types of regulatory
 requirements or compliance

0:13:55.280000 --> 0:14:00.540000
 requirements. So the key takeaway to
 finalize this and to usher us now

0:14:00.540000 --> 0:14:04.440000
 into endpoint analysis beginning
 with log analysis.

0:14:04.440000 --> 0:14:11.980000
 Let's, let's summarize everything with
 regards to live response and dead

0:14:11.980000 --> 0:14:17.160000
 box. So live response saves what disappears
 first, dead box imaging preserves

0:14:17.160000 --> 0:14:19.820000
 everything that lasts.

0:14:19.820000 --> 0:14:22.820000
 That's the best, I guess, that's
 the best way to understand this.

0:14:22.820000 --> 0:14:28.740000
 And underlying that a skill responder
 knows or should know when to employ

0:14:28.740000 --> 0:14:34.040000
 one, the other or a carefully
 sequenced blend of both.

0:14:34.040000 --> 0:14:38.220000
 So with that being said, that brings
 us to the end of this video.

0:14:38.220000 --> 0:14:40.280000
 And I'll be seeing you in the next video.