[00:03.060 --> 00:07.960]  Okay, first of all, let me just let everybody know that I am actually...
[00:07.960 --> 00:08.920]  Excuse me.
[00:08.920 --> 00:10.580]  Hey, sound guy, turn it up, dude.
[00:10.880 --> 00:15.060]  Dude, I yelled at Jeopardy two nights in a row and got trashed two nights in a row.
[00:15.060 --> 00:16.780]  You're lucky I'm even upright.
[00:17.800 --> 00:20.140]  No, because we got ripped off!
[00:22.240 --> 00:26.840]  Okay, first of all, let me let you know that I am not RS.
[00:26.840 --> 00:35.620]  He was requested by his employer, the man, not to actually give this talk.
[00:35.760 --> 00:40.800]  So, since I'm a friend of his and I've done some forensic stuff in the past,
[00:40.800 --> 00:44.880]  I'm more of a network monkey than a file system monkey.
[00:45.000 --> 00:49.920]  And so he asked me if I'd be willing to give this talk so that you guys didn't get screwed out of one talk.
[00:50.300 --> 00:53.000]  I had no idea he was quite this popular.
[00:53.000 --> 00:57.980]  I thought it'd be about three of you and my friends who wanted to go drink afterwards.
[00:58.420 --> 01:00.080]  So here it goes.
[01:05.400 --> 01:06.300]  Okay.
[01:09.600 --> 01:19.420]  Basically, the talk that Rob was wanting to give is kind of an intro to file system analysis.
[01:19.420 --> 01:22.860]  Actually, it won't be in a discussion of analysis.
[01:28.200 --> 01:28.820]  Okay.
[01:28.820 --> 01:29.580]  Can you roll them up?
[01:29.580 --> 01:32.360]  Yeah, can the sound guys just boost it a little?
[01:32.360 --> 01:35.400]  By sound guy, we mean you. Can you slap the pots? No?
[01:35.480 --> 01:36.000]  No.
[01:36.140 --> 01:36.720]  All right.
[01:37.060 --> 01:38.100]  Can I walk over there and do it?
[01:38.100 --> 01:38.880]  Is that better?
[01:39.380 --> 01:42.120]  Can everybody here at this point still know?
[01:45.460 --> 01:46.480]  How about now?
[01:48.040 --> 01:48.760]  Can you hear me now?
[01:48.760 --> 01:49.080]  Wow.
[01:49.320 --> 01:50.160]  Can you hear me now?
[01:51.880 --> 01:53.520]  Hey, it's a Verizon commercial.
[01:53.680 --> 01:54.180]  Okay.
[01:56.100 --> 02:23.620]  Basically, the talk that Rob has asked me to present today is essentially a very basic introduction into how to properly acquire data from a potentially compromised system or a suspect system and the legal aspects of what you have to keep in mind when you want to ensure that you have everything done properly
[02:23.620 --> 02:25.800]  when presenting it in a court of law.
[02:27.020 --> 02:31.000]  So, I will do my best to get through the slides.
[02:31.000 --> 02:37.520]  If you ask me a question that I cannot answer, hopefully Rob is around here somewhere and he will unofficially answer your question.
[02:39.420 --> 02:40.680]  But here we go.
[02:40.680 --> 02:41.040]  All right.
[02:41.040 --> 03:04.840]  Basically, the most important thing you need to keep in mind is that when you have a system that you suspect has been tampered with or has something that you're interested in checking, you have to ensure that you do not alter or contribute to the modification of files on that file system.
[03:05.760 --> 03:08.980]  Because that's the first way...
[03:08.980 --> 03:13.760]  Anytime you actually open a file, you modify it, whether you realize it or not.
[03:13.760 --> 03:16.160]  You change the access times.
[03:16.160 --> 03:22.140]  You change quite a lot of very subtle metadata associated with that file.
[03:22.140 --> 03:34.200]  So, it's important that you follow certain very, very strict procedures to try and intrude as little as possible on the suspect system.
[03:35.540 --> 03:38.600]  Oh, and by the way, the typos are not mine.
[03:42.140 --> 03:56.320]  So, one of the first things you have to consider is whether or not, if it's a running system, you have to actually look at the entire aspect of what the system is doing.
[03:56.340 --> 03:59.200]  You have to consider, is it connected to a network?
[03:59.240 --> 04:00.320]  Is it currently powered up?
[04:00.320 --> 04:01.260]  Is it powered down?
[04:01.260 --> 04:06.320]  If it's powered up, is there data that's actually held in memory that you want to try and access?
[04:09.320 --> 04:13.720]  Because some people, when they tamper a system, will leave a trojan behind.
[04:13.820 --> 04:25.000]  And as soon as they see some sort of shutdown procedure or whatever, it will remove whatever data you might have actually been interested in.
[04:25.000 --> 04:37.760]  So, you have to actually be very careful about not doing something without thinking through thoroughly first what may be the ramifications of what you're doing.
[04:46.780 --> 04:53.820]  But as Rob says here, actually you only get one chance to do it right.
[04:54.620 --> 05:06.100]  Because, as I mentioned previously, if the system has been trojaned, there's a good possibility that if you're not careful and you do the wrong thing, you lose everything you were actually interested in.
[05:06.980 --> 05:15.940]  There's many, many ways to actually acquire the data without modifying it too much.
[05:15.940 --> 05:22.100]  I personally, some of the things that Rob has in here, I haven't used because, frankly, I'm a Unix bigot.
[05:26.900 --> 05:32.180]  Also, every intrusion is a unique situation.
[05:32.180 --> 05:43.500]  I mean, it could be a standalone system, we could be talking about ATMs, it could be a system that's connected to a network, it could be a multi-home system, you don't know.
[05:43.500 --> 05:54.750]  So, you actually have to be very careful and document your entire data acquisition process.
[05:55.160 --> 06:05.860]  And by documentation, I actually mean photographs, notes, as well as acquiring the actual file system data that you're interested in.
[06:06.840 --> 06:26.740]  Basically, what the talk will cover is what are you actually trying to accomplish with the forensic acquisition of the file systems and what things can make that difficult or impossible, depending on how badly you screw up.
[06:29.520 --> 06:50.060]  We will also cover the proper preparation of evidence media so that it is admissible in court and, if done correctly, doesn't get struck down or mitigated, as well as the proper handling of the suspect system.
[06:50.060 --> 06:59.360]  You're not actually going to utilize the potentially compromised system for anything more than acquiring a copy of the data off of it.
[06:59.900 --> 07:16.360]  And then, at that point, you will enter the suspect media into your chain of custody so that you can have a very distinct trail of who has had access to the suspect media and when and what was performed.
[07:16.360 --> 07:35.560]  So, this is all basically required for your court cases to ensure that there is no doubt that whatever was being alleged to have been found on the suspect media was not put there by you or somebody else involved in the prosecution.
[07:37.140 --> 07:40.480]  There's actually multiple ways to do it, as I mentioned earlier.
[07:40.480 --> 07:45.940]  There are hardware solutions for accessing a copy of the data on the suspect media.
[07:45.940 --> 07:51.240]  There are also software mechanisms for doing the same thing.
[07:51.900 --> 08:00.260]  They all have certain abilities that make them unique, and they all have their limitations.
[08:00.260 --> 08:09.460]  So, you may actually want to use more than one method to acquire your suspect media data for later analysis.
[08:09.460 --> 08:21.400]  And the other thing you're probably going to want to do is use some kind of integrity verification mechanism.
[08:21.400 --> 08:36.000]  Generally, that would be a cryptographic hashing that you would take of the file system image so that you can further prove that it has not been tampered or altered in any way since you acquired the data.
[08:37.120 --> 08:40.640]  I am not a lawyer, and Rob also is not a lawyer.
[08:41.160 --> 08:45.860]  So, do not consider this talk as legal advice or legal opinion.
[08:46.700 --> 08:54.740]  Neither of us actually speak for anyone other than ourselves, and most often we don't do that very well.
[08:55.280 --> 09:03.900]  So, if you actually want to do these things, if you do it in the privacy of your own home or whatever, that's fine.
[09:03.900 --> 09:20.660]  If you decide after sitting through this talk that you're now a forensic specialist, and you go and try and perform a data acquisition on a suspect's system at your work, and you screw up the boss's computer and he's pissed off, not my fault.
[09:21.160 --> 09:32.760]  So, you really ought to check with the policies of your organization, your IT staff, your legal staff, before using any of these tools in an investigation.
[09:32.760 --> 09:51.880]  And I, frankly, would suggest that you spend a lot of time doing this before you even think you're going to do it properly, because it is a very exact and very precise process that must be followed in order to not taint the data that you're going to present in court.
[09:53.400 --> 10:03.220]  This is basically a glossary of terms that you should be familiar with to make the talk a little bit more understandable.
[10:03.220 --> 10:15.840]  By digital evidence, basically that is the file system on the suspect system that you're trying to acquire.
[10:16.500 --> 10:27.540]  Suspect or original drive, suspect media or original drive media is basically the possibly tainted system or the possibly malicious system that you're interested in.
[10:27.540 --> 10:47.990]  Forensics media or evidence drive or media is basically the tools that you will use to acquire the... it's basically the system that you will use to actually acquire the data off the suspect system.
[10:49.210 --> 11:12.870]  Acquisitions and imaging, basically that's two different terms for grabbing all the data off the suspect system. Imaging is just basically creating one or more image files of the suspect system that are a bit-for-bit copy so that you get everything, not just the files that are on there, you get the slack space.
[11:13.970 --> 11:29.530]  Many people don't actually realize that when you delete a file, you're not actually erasing that file. What you're doing is deleting an entry in a master database on the drive that says it's okay to overwrite this space on the drive, but that doesn't necessarily happen right away.
[11:30.570 --> 11:55.650]  And not only that, when you copy a file, you quite often don't copy just what you think you're copying. If you open up a document and you write a couple of things into it and then save it and then you open it up later and delete one of those things because you decide that whoever you're giving the document to has no reason to know that stuff, that data is actually still lying around.
[11:55.650 --> 12:16.570]  So when you copy that file over somewhere else, what you thought you deleted is actually still there in what's called slack space. And so you have to be very, very careful about imaging the entire file system so that you get things that are in slack space that may actually be pertinent to what you're interested in.
[12:18.550 --> 12:44.490]  Okay. The next thing is chain of custody. Chain of custody is basically nothing more than a hard copy of every individual who's had access to the suspect system as well as the forensic media system and what they did and when they did it and things like that because these have to be... the chain of custody is an admissible item in a court case.
[12:44.490 --> 13:11.350]  Verification hashes and checksums. That's what I mentioned earlier about wanting to create a hash to check the integrity of your acquisition file system so that you can prove it's not been tampered with.
[13:11.350 --> 13:32.810]  The integrity has not been tainted at all on your system because if everybody in a particular area has access to your forensic acquisition system, then you can't prove that somebody hasn't altered that to modify whatever data you're trying to acquire to hide whatever they're interested in hiding.
[13:32.810 --> 13:52.730]  Trusted forensics... the trusted forensic environment just basically means having a means of proving that your acquisition system is exactly what you think it is and nothing more. Original copies and work copies. Basically the way...
[13:52.730 --> 13:54.870]  If they can't figure that out, they're pretty weak, dude.
[13:54.870 --> 14:09.210]  I know. But basically the way you do it is you never actually want to do any analysis on your suspect system. You want to capture all the data from the suspect system onto a separate piece of media.
[14:09.210 --> 14:39.190]  That separate piece of media actually then is what gets admitted to court and quite often you will have that as your means of analysis too. So what happens is you basically capture all the data off the suspect system and once you've done so and the system has been entered into the chain of custody, then that suspect system is placed in a locked space where nobody has access to it anymore.
[14:40.290 --> 14:56.310]  Okay, it does not fully cover acquiring volatile system information. Basically there's only slight information here on how to actually capture data that resides in memory on a running system.
[14:57.170 --> 15:05.790]  There's too many different systems and too many different ways to actually do it in a 50 minute talk to adequately explain all this.
[15:07.410 --> 15:28.330]  Quite often when you're trying to grab data from memory, your system will write out temporary files and things like that to the file system so you have to be very careful that when you're trying to grab volatile data, you're not modifying the file system that you're interested in as well.
[15:29.970 --> 15:49.210]  The third point is, as I said, it's a very exacting process. So you want to make sure that you know exactly what you're going to do and carefully step through those. Don't take any shortcuts.
[15:49.210 --> 16:12.930]  And frankly, when I have done forensic acquisitions or some of my staff, I will actually have a written set of steps and insist that they follow them. No matter how many times they've done it, that's the only really way you can carefully not miss something or potentially taint the system you're interested in.
[16:15.490 --> 16:35.670]  Examples of volatile data would be run time and performance stats, which is basically in most Unix systems, things in the pseudo-proc file system. Time, date, time zone settings, all these things are volatile because some of them are easily changed.
[16:35.670 --> 17:03.110]  The active running process listings is another volatile thing, because as I mentioned earlier, if there's a Trojan and you trigger that Trojan, it may either stop running whatever process that it was running that you were probably interested in, or if some of you have attended the Rootkit talks, you'll see that they can hide those processes, keep them running, but you won't be able to actually find them.
[17:03.110 --> 17:26.270]  Logged in user listings, that obviously is for a network-connected system. Open files, libraries, DLLs in use. Basically, it's different for every system, but you can easily find all the files that are currently in use through the system processes.
[17:26.270 --> 17:49.690]  And again, if you're not careful, if there's a Trojan or if it's a network-enabled system and the person that is doing what you're interested in is actually online and finds out, they may stop what they're doing, unload any libraries that are being used by whatever process they're doing, and you will lose data that you potentially need in your prosecution.
[17:49.690 --> 18:16.910]  Network activity, again, obviously, for a network-enabled system is what actually is going on. If you walk up to the system and immediately pull the network cable out of it, you may actually lose data that you're interested in for your prosecution, because that may trigger whatever network system process was going on to either stop or, well, obviously it won't be communicating anymore.
[18:16.910 --> 18:36.750]  And that may trigger it to stop or hide itself. Perhaps the data you're actually interested in is an ongoing streaming of pornographic material or illegal file-sharing activities. And if you're not careful, those things that you need to acquire may stop.
[18:36.750 --> 18:44.990]  It goes back to being very careful about following your steps and not deviating from those.
[18:47.010 --> 18:50.090]  I'm going to move on.
[18:51.790 --> 19:00.610]  We're not going to cover cellular phones, PDAs, wireless and wired network communications, wireless programmable keyboards and EEPROMs.
[19:00.610 --> 19:04.650]  It would just simply take too long, and obviously I'm taking too long as it is.
[19:09.250 --> 19:18.190]  The first bullet up here is actually something that is quite often overlooked by people that don't do this all the time.
[19:19.290 --> 19:35.450]  It is potentially a crime scene, so you want to make sure that if you're going in and looking at the system, you want to ensure that if you start tapping away on the keyboard, you're not destroying fingerprint evidence that might be there.
[19:35.450 --> 19:53.530]  As I mentioned before, you definitely want to document the entire area that you're working in photographically, so that if somebody comes up and says, well, that wasn't my system, you have visual evidence that whatever they're claiming is probably not true.
[19:53.530 --> 20:07.870]  You want to take a look at every cable connection, whether the system is network-enabled, if it's connected to a wireless network, if it's connected to a Cat5 fiber network, if it's multi-home, if there are modems.
[20:07.930 --> 20:14.330]  You want to carefully document all that, both in written form and in photographic form.
[20:15.150 --> 20:30.610]  And consider every incident as if it's going to trial, which basically goes back to set up a certain set of steps to follow and don't deviate from them regardless.
[20:30.610 --> 20:41.970]  Because if it goes to trial, you're going to need all the evidence that you gather. If it doesn't go to trial, it's no big deal. Having more evidence is actually a good thing.
[20:43.530 --> 20:49.230]  Yes, do not examine your evidence at all until you've properly made a forensic image.
[20:50.190 --> 21:00.290]  The reason that he says that is basically because if you're not careful, you will taint the data by altering access times and things like that.
[21:00.290 --> 21:19.470]  So you want to make sure that you have a complete and thorough forensic image so that if somebody questions something, you can actually go back and acquire a second copy of the suspect data without having to access the suspect system.
[21:20.810 --> 21:27.390]  You should try to interact with the system as little as possible.
[21:27.390 --> 21:43.590]  If you have to sit down at the suspect system itself, you need to be very careful. Generally, you want to not ever do anything or attempt to check anything on the suspect system. You want to actually make a copy instead.
[21:45.790 --> 21:58.050]  And again, store everything in a safe location, which basically, generally for me, since I work for the government, and yes, you can spot the fed now, it means a GSA safe with a high security lock.
[21:58.050 --> 22:11.750]  That's another means that gets documented in the chain of custody that proves that it was difficult, if not impossible, for someone to have tainted the system data that you're presenting in your court case.
[22:16.740 --> 22:29.180]  Pretty much all this just really says is to keep track of what you fucking do. I mean, if you're ever going into a government investigation, you're going to be working with people who have done other types of investigations, mostly physical, and you just need to make sure you don't taint the digital data.
[22:29.180 --> 22:34.460]  The chain of custody is exactly the same for physical data as digital data, as long as you don't taint it.
[22:35.020 --> 22:42.300]  All these things are just reiterating how you have to be careful not to taint what you have, not to modify anything, and only work on copies of it.
[22:42.300 --> 22:52.660]  It's a very simple concept where anyone who's ever blown out some data on your home, or on any machine you're working on, back up first, work on your backups, don't work on the true copies, and it's just very important forensic analysis.
[22:53.020 --> 22:57.420]  Right, and the first two kind of reiterate what I've already beaten to death.
[22:57.420 --> 23:06.220]  But, now collate mail, DNS, and other network and service logs to support and verify your findings.
[23:06.220 --> 23:09.980]  Not everything you're interested in is actually right there on the suspect's system.
[23:09.980 --> 23:23.540]  You may actually have network processes like mail being sent out if the system is taken over by a bulk mail or whatever, and you're going to find corroborating evidence on other systems on that network.
[23:23.540 --> 23:30.380]  So, don't just consider the suspect's system as the sole thing to be investigated.
[23:30.980 --> 23:43.300]  And always be able to verify the integrity of your evidence. That basically means be very careful about creating your file system images, and then create cryptographic hashes of them.
[23:43.300 --> 23:54.460]  Whether you use MD5, SHA1, whatever, you need to be able to prove at some point that nothing on the suspect's system has been altered.
[23:56.040 --> 24:00.880]  Yes, never use a tool you're not familiar with on live or original evidence.
[24:00.880 --> 24:09.320]  Again, this just basically says, if you don't know how the system works, then find someone else, find an adult to help you.
[24:10.880 --> 24:14.060]  Or a 12-year-old boy, or a 12-year-old girl, man.
[24:15.600 --> 24:23.340]  Okay, this is some more of the documentation. You want to itemize all the actual hardware involved.
[24:23.740 --> 24:36.420]  With the physical context, I mean, you want to sit down at some point after you've gotten your file system data off, and document the actual computer system that's involved, or systems.
[24:36.420 --> 24:46.980]  And you'll want to actually, as the example that's given here, you're going to want to actually document everything that uniquely identifies every piece of hardware in that system.
[24:47.540 --> 24:50.260]  Basically, it's just be incredibly anal.
[24:51.080 --> 25:03.680]  Because a defense lawyer is going to challenge everything possible, and you have to be very careful and capable of proving that nothing has been changed, nothing has been swapped out, nothing has been modified or tainted.
[25:04.340 --> 25:18.540]  Logical context is basically, on a Unix system, for example, or even on a Windows box, all the mounted file systems, whether they're network mounts, whether they're local mounts, whatever.
[25:18.540 --> 25:34.640]  You want to actually document all the logical things as well to, again, prove that when they see the suspect system in court, that it's exactly the way it was when you began your forensic investigation.
[25:36.040 --> 25:56.480]  Because you will be, if it goes to trial, you will end up testifying as to exactly what you did, how you did it, and why what you did hasn't caused the data that's being entered into the legal record to be tainted or suspicious.
[25:57.020 --> 26:06.340]  Chain of custody quite often will be challenged. That's why you need to keep a very full chain of custody, very thorough, yes.
[26:10.190 --> 26:11.630]  Have to be what?
[26:13.050 --> 26:22.950]  Ah, the question is, does the person doing the data acquisition have to be an independent person so that there's no conflict of interest?
[26:23.690 --> 26:41.190]  Well, it really depends on the situation. I mean, if it's, in Rob's case, basically, he works for Health and Human Services, and they quite often have to deal with, you know, potential medical fraud and things like that.
[26:42.070 --> 26:56.390]  So they're not letting the IT staff of the office investigate that. And yes, quite often you want to make sure that the person is independent, because if you can't trust your forensic investigator, then how can you trust the evidence that's being given to you to take the trial?
[26:56.390 --> 27:22.630]  So yeah, you would want to make sure it's an independent individual or company. Quite often, though, in large companies, they will have, you know, a data security team and a forensics team that, while they work for the same company, they have no vested interest in protecting any particular person in that company.
[27:22.630 --> 27:34.310]  So essentially, they are independent as much as a company employee could be. But yeah, I mean, if you have the chance to get somebody who's independent totally from the outside, yeah, that's probably the best way to do it.
[27:37.200 --> 27:43.200]  There's one question. We do need to bang through this stuff pretty fast, but let's hit the question real quick, and then we'll bang through it fast. What's your question?
[27:54.480 --> 28:23.280]  Correct. Documenting the hardware and everything is, if I didn't make that clear, you would actually do that after you've already assured that you've acquired all the data you're interested in on the suspect system, all the file system data, all the volatile data and everything, and you're convinced that, okay, there's nothing else I want to, you know, I will need to gather from this running system or this system,
[28:23.280 --> 28:44.300]  you know, I'm interested in, now I can actually begin to document the components of the system itself. So yes, that will come at the very end, because as Rob pointed out to me, some of the things that he investigates, it's physicians' offices, and they can't afford to have the potentially compromised system removed from the office.
[28:44.300 --> 29:01.060]  So, you know, basically you have to try and document everything, and then get a verifiable forensic image, and then leave the actual suspect system, you know, running in that office, because you can't.
[29:01.600 --> 29:07.520]  So, all right. Some of the things that you basically need to understand is...
[29:07.520 --> 29:12.580]  I think everybody in here, if they don't understand a partition table and file system, they need a beating.
[29:12.580 --> 29:18.960]  Well, do you guys want me to go over file system? Okay. Then we'll move through. Fine. No problem.
[29:18.960 --> 29:20.500]  Yeah, all that stuff. Partition files is possible.
[29:20.500 --> 29:24.580]  Hey, if something is basically beating a dead horse, let me know, because...
[29:26.880 --> 29:28.080]  Thank you.
[29:28.780 --> 29:32.300]  You know, keep in mind, we were in jeopardy two nights in a row.
[29:32.840 --> 29:34.040]  Beer is evil.
[29:34.400 --> 29:35.780]  No, it's beautiful.
[29:35.780 --> 29:44.680]  All right. Your goals. Basically, you want to make an exact copy of the backup. Basically, this is more beating a dead horse, it looks like.
[29:45.480 --> 29:46.380]  Yep, skip that one.
[29:46.940 --> 29:48.000]  All right, don't fuck with it.
[29:48.000 --> 29:50.760]  I got plenty of tools, yeah. Well, I've only...
[29:50.760 --> 29:51.760]  Hit the second part.
[29:52.220 --> 30:03.380]  All right. Yeah. One thing that you have to keep in mind, a lot of drives now will have host protected area, you know, device configuration overlays, things like that.
[30:03.380 --> 30:14.420]  And you have to be very careful with your tools to ensure that when you're acquiring data off the actual hard drive file system, that you're getting the entire contents of the file system.
[30:14.420 --> 30:21.780]  That you're not missing some portions of the system that are being hidden by the BIOS or the drive BIOS.
[30:24.280 --> 30:31.780]  In older Linux 2.4 ones, for example, some of the hard drives with odd number of sectors would...
[30:33.480 --> 30:43.420]  If you weren't careful about how you acquired that file image, you would actually miss a portion of the drive because the drive itself would report back that it was smaller than it really was.
[30:46.340 --> 30:49.700]  Tool needs to be tested by an independent entity.
[30:49.700 --> 30:53.840]  Basically, don't write your own forensic tools is all this says.
[30:54.320 --> 31:06.300]  Go use something that has been proven to work and proven to do exactly what you want and what you expect so that you can back that up in a court of law.
[31:08.600 --> 31:10.020]  More dead horse.
[31:11.200 --> 31:14.880]  One other thing, preparation of the forensic hard drive.
[31:14.880 --> 31:28.980]  Basically, the drive that you're going to use, drive or tape, that you're going to use as a copy of the suspect system, you want to wipe that drive before you actually use it.
[31:28.980 --> 31:34.920]  And as is suggested here, you want to wipe it with a known pattern.
[31:34.920 --> 31:39.860]  You don't want to use like dev random because you don't want random stuff overriding that drive.
[31:39.860 --> 31:52.660]  You want to use something like dev zero so that it's all zeros so that you can guarantee that everything that gets put on that drive was put on that drive when you did so.
[31:52.720 --> 31:54.620]  None of it was pre-existing.
[31:56.240 --> 31:58.880]  And this basically ensures that.
[31:58.880 --> 32:03.620]  And this will also be part of your documented investigation notes.
[32:04.140 --> 32:05.280]  All right.
[32:05.380 --> 32:18.580]  And again, some of the host protected area and things like that, you have to make sure that whatever tool you're using to format the drive prior to using it will actually overwrite those areas as well.
[32:19.920 --> 32:21.860]  This is how to do it.
[32:22.440 --> 32:24.420]  Yeah, read the CD if you don't want to wipe your drive.
[32:24.420 --> 32:35.480]  Yeah, DBAN is a very nice CD-ROM based system that will work on both x86 and Macs if you have to deal with a Mac OS system.
[32:35.880 --> 32:47.880]  Gdisk, these are basically just a lot of known trusted tools for properly wiping the forensics acquisition system before you actually begin to use it.
[32:51.400 --> 32:52.620]  All right, yeah.
[32:52.660 --> 32:59.220]  Basically, DD, the nice thing about DD is that, you know, it does a bit for a bit of coffee.
[32:59.220 --> 33:08.300]  And then afterwards make a cryptographic hash to prove that later, I'll get to you, to prove that nothing has changed.
[33:08.300 --> 33:29.280]  The CryptCat and NetSea, which is actually NetCat, there's a way, if your system is running and you need to access, you want to save the stuff on a forensic system that's actually on a network or somewhere else,
[33:29.280 --> 33:39.100]  you can pipe the output from DD to NetCat so that you're actually not storing your acquired image locally anywhere.
[33:39.100 --> 33:48.960]  You're actually storing it somewhere else, which is another means of ensuring that you don't modify anything volatile or existing on the file system.
[33:49.500 --> 33:51.360]  Yeah, you had a question back there?
[33:51.360 --> 34:03.210]  That is true. And I'll go back to the first caveat, which is this is not my slide.
[34:03.970 --> 34:06.350]  Yeah, we'll get there later in the slide. We'll spank through them pretty quick.
[34:06.350 --> 34:11.210]  All right. Quite often, quite often, if you're doing this by hand, it's a slow process.
[34:11.210 --> 34:18.810]  There are hardware systems that will image the drives thoroughly that will do it very well and far more quickly.
[34:21.450 --> 34:22.530]  Let's see.
[34:22.530 --> 34:28.150]  Basically just saying in real life you run across shit that you're not expecting. You're not going to run into the perfect scenario every time.
[34:28.290 --> 34:34.970]  And because of that, shit happens. Your hardware may not work right. You may go to plug into a port that's busted.
[34:35.130 --> 34:42.270]  The keyboard may be cracked in half. You never know what's going to happen. Sometimes shit happens. So cover your ass.
[34:42.590 --> 34:43.030]  Yeah.
[34:44.770 --> 34:45.650]  No.
[34:46.170 --> 34:51.490]  No, never yank the power. If you just yank the power, you're losing so much of all the information, you're screwed.
[34:51.490 --> 34:56.350]  Yeah. Yanking the power, everything that was being held in RAM, gone.
[34:56.810 --> 35:07.970]  And if you sat in on the rootkit talks that were presented here, there are actually rootkits now that live in RAM, live in memory solely.
[35:07.970 --> 35:10.410]  And you'll lose that. You'll lose all evidence of it.
[35:11.330 --> 35:15.370]  Well, it depends on what you do. And if you are going to shut down, if you can do your data removal first.
[35:15.630 --> 35:19.850]  It's all in the path of every machine is different and what you can do is different in every situation.
[35:19.850 --> 35:23.610]  In some situations, you'll walk in there and be able to just image everything, including the RAM.
[35:23.630 --> 35:27.530]  In some situations, you'll walk in there and some guy will start shooting at you and put a bolt through his computer.
[35:27.650 --> 35:29.190]  Different situation, different times.
[35:30.010 --> 35:36.550]  Right. You obviously don't want to install your forensic environment on the suspect system.
[35:36.810 --> 35:44.790]  So what you want to do... some people actually use the suspect system to create copies of the suspect system.
[35:44.790 --> 35:48.230]  I personally don't prefer that that be done.
[35:48.350 --> 35:58.810]  But one way to do so is to have a bootable DOS Linux or BSD disk that has been designed specifically for forensic use.
[35:58.810 --> 36:03.470]  And I believe he has examples of some of those as we go along.
[36:03.470 --> 36:15.870]  ImageMaster is one that actually has a pre-configured, I think it's a Win98 environment, that has actually been modified specifically for forensic use.
[36:16.470 --> 36:23.930]  Knoppix is a reasonably user-friendly method for doing this, although there are caveats.
[36:23.930 --> 36:38.250]  You have to throw the noswap command line at your kernel bootup, because otherwise one of the problems with some of the Knoppix systems is that basically if it finds swap space, it'll try mounting it.
[36:38.270 --> 36:50.410]  And when it goes and starts looking at all the drives attached to the system that it's booting, when it finds your suspect file system, if it finds the swap space on there,
[36:50.410 --> 37:00.330]  it's going to go ahead and bring it up, at which point you're losing the integrity of some of the data on that file system.
[37:01.050 --> 37:11.250]  Older versions, and if you do use Knoppix, you need to be very, very careful to make sure you use one of the more recent releases, because older versions do have some issues.
[37:11.270 --> 37:17.590]  For example, some of the older ones, even if you gave the noswap command to the command line, it would just happily ignore it.
[37:20.110 --> 37:27.010]  And the caveat of being not just because the version is newer doesn't mean that it doesn't have a different bug that will affect you.
[37:27.010 --> 37:35.830]  So never actually go fire up Knoppix to do your forensics without actually having done it somewhere else first, so that you, again, have a trusted forensic environment,
[37:35.830 --> 37:42.890]  and you know exactly how it's going to act and what's going to happen, so that you can protect the integrity of the suspect system that you're interested in.
[37:45.290 --> 37:52.430]  Again, this just goes over some of the basics of how to build the forensics system environment.
[37:52.450 --> 37:57.590]  Yeah, go to those links if you want to get good shit.
[37:57.590 --> 38:05.290]  Yeah. Modcom, I believe, is a DOS-based one, which is actually pretty good.
[38:05.290 --> 38:15.070]  NCase, the forensics version of NCase, the licensing doesn't actually require you to pay for it.
[38:16.110 --> 38:17.690]  More stuff, just go to all these sites.
[38:17.690 --> 38:26.970]  Sure. Fire is actually a Knoppix-based one. These are all URLs, and I believe they will have Rob's slides up on the DEF CON site, so you can get them from there.
[38:26.970 --> 38:30.450]  I saw some of the Penguin Sleuthgate guys around here.
[38:31.530 --> 38:39.350]  Let's see. These are commercial hardware solutions. These are systems that actually will do the data acquisition for you, but it's a hardware device,
[38:39.350 --> 38:48.330]  which, as was mentioned earlier, depending on how big the suspect file system is, it could take hours.
[38:48.330 --> 39:01.330]  And some of these systems have been built and optimized to the point where they, like ImageMaster, I believe will get a throughput of something like two gigs,
[39:02.930 --> 39:08.810]  like two gigs a minute, and on a large drive, that's kind of nice, rather than taking a day or two.
[39:08.810 --> 39:15.550]  Just as a side note, I personally don't do data forensics, but a division of the company I work for does, and we just released a press release,
[39:15.550 --> 39:22.450]  which, I don't know what the fuck it means, I don't know what a computer does, hell, but we evidently did five terabytes of data in under 24 hours,
[39:22.450 --> 39:27.070]  and did forensic analysis and everything else, so they say that's good, but that sounds like a lot of data to me.
[39:27.430 --> 39:29.670]  That would take a hell of a long time with some of those other solutions.
[39:30.750 --> 39:32.590]  And just more.
[39:34.550 --> 39:45.610]  These are just examples of, if you're using a tape system, for example, if you have a RAID system and you need to get some data from a previous day for your investigation,
[39:45.610 --> 39:53.170]  these are methods that you can use to actually read data off the tape to put it onto your forensic environment for analysis later.
[39:56.010 --> 40:01.030]  These are other means of creating your forensic media.
[40:01.430 --> 40:13.430]  Hardware write blockers. This is basically a hardware solution to ensure that you don't actually modify the suspect drive.
[40:14.270 --> 40:20.130]  I personally use a Unix environment so that I can mount the suspect system read-only.
[40:20.130 --> 40:24.370]  That's not always possible with Windows systems.
[40:27.680 --> 40:34.100]  Again, here's just examples of software write blockers.
[40:36.780 --> 40:46.160]  One of the things you want to do is, possibly you may be having to acquire a RAID image.
[40:46.160 --> 40:57.520]  So you're going to want to have your forensic system to be as optimized and powerful as you possibly can to make the process not be a lengthy, horrible thing.
[40:58.180 --> 41:06.460]  So promised ATA RAID, serial RAID, is actually a very reasonable and inexpensive RAID solution.
[41:07.500 --> 41:13.800]  These are, again, commercial software data acquisition solutions.
[41:17.820 --> 41:19.600]  And more dead horses.
[41:20.720 --> 41:23.880]  And then the free solutions.
[41:25.380 --> 41:36.240]  These actually are forensic acquisition systems that are available to law enforcement only.
[41:36.240 --> 41:51.640]  They essentially do the same thing that all the other ones do, but they've been specifically designed to ensure that they actually do what is required to properly prosecute.
[41:54.180 --> 42:02.040]  And these will snap back an in-case enterprise are capable of doing imaging over the network.
[42:03.080 --> 42:06.760]  That way you don't have to do things like DD and then pipe it out to Netcat and things like that.
[42:06.760 --> 42:10.900]  Of course, they're quite expensive as well.
[42:12.560 --> 42:19.780]  Okay, basically, if the system is running RAID, you need to be very familiar with how RAID works.
[42:19.780 --> 42:27.700]  And what each different type of RAID, how it's set up, so that you ensure that when you do acquire the RAID array,
[42:27.700 --> 42:36.700]  that you, again, are acquiring the entirety of the virtual file system that makes up that system.
[42:37.960 --> 42:42.760]  This is an interesting thing that I actually didn't know until I talked to Rob yesterday.
[42:42.760 --> 42:56.460]  On macOS, on more recent versions of macOS, if you actually hold up the T key, hold the T key down on boot up, it boots up into what it refers to as disk mode.
[42:56.460 --> 43:08.060]  And that Mac then essentially becomes an external firewall drive that you can use as a live forensics environment to toss data onto.
[43:09.720 --> 43:19.520]  Image integrity, there's checksums, there's hashes, these are all different means for verifying and providing proof of the integrity of the suspect system data.
[43:23.400 --> 43:30.860]  Yeah, MD5 actually recently, they've discovered that there are possibility of collisions.
[43:30.940 --> 43:43.700]  Thus, I would say a good defense lawyer might be able to bring up enough technical data to prove that the MD5 hash may not actually be valid.
[43:43.700 --> 43:49.380]  At least enough to create doubt, which would then sink your prosecution.
[43:49.380 --> 43:58.880]  So, I personally prefer SH8-1 some. These are just commercial versions of hashing applications.
[44:01.280 --> 44:10.400]  These are different formats. The one I've basically talked about the entire time is DD, is basically a raw bit-for-bit copy of the drive.
[44:10.400 --> 44:27.220]  In case, quite often all the commercial systems are capable of reading the disk image, the proprietary disk images that are made by all the different other products, like InCase, SafePak, SnapPak, and Smart.
[44:28.300 --> 44:39.420]  Basically, for more information, these are a lot of URLs where you can find a ton of information on data forensics.
[44:39.420 --> 44:50.940]  And there actually is a forensics mailing list. I currently don't know what... I think it's on security focus, so you might check.
[44:50.960 --> 44:52.160]  And that's about it.
[44:52.380 --> 44:53.580]  Questions?
[45:09.850 --> 45:21.410]  On the other systems that may actually affect it, that are on the network, you don't actually need to get a forensic image of that server.
[45:21.410 --> 45:25.110]  Because that's just an external system that just supplements what you're doing.
[45:28.580 --> 45:50.740]  It is difficult, but being very careful about documenting what you did to get that corroborating data and doing things like, okay, I took a snap of the file system, make a hash of that log file, and then enter all that into your chain of custody documentation, that will help.
[45:50.740 --> 45:54.180]  It's all about documenting. Even if you can't verify things, it's all about documenting.
[45:54.180 --> 45:57.020]  Yeah, basically it's just document the hell out of everything.
[46:00.560 --> 46:02.540]  Yes, sir, on the right side.
[46:05.640 --> 46:08.680]  There's various programs. Almost all of those programs can handle it.
[46:08.940 --> 46:15.200]  Yeah, some of the commercial products will actually access the memory contents as well.
[46:15.420 --> 46:25.620]  I personally will just cap the contents of the kernel proc file system and cat it out across the net to another system.
[46:26.400 --> 46:27.640]  Left side.
[46:30.420 --> 46:31.380]  Louder.
[46:44.770 --> 46:49.390]  Yeah, yeah, so I generally will not use DD on a live system.
[46:49.570 --> 46:58.910]  What I will do is try to document, the few times I've had to do forensic, as I said, I'm more of a network security monkey than a forensics guy.
[46:58.910 --> 47:08.710]  But the few times I have done investigations on potentially compromised systems, basically I did not do the DD copy.
[47:09.790 --> 47:11.470]  On the running system.
[47:11.590 --> 47:20.530]  I got on the running system as unobtrusively as I possibly could, documented the hell out of everything that was on there as much as possible.
[47:20.530 --> 47:23.670]  Of course, you're never guaranteed you're going to get everything.
[47:23.670 --> 47:29.450]  If there's a really, really well done rootkit on there, you're probably not going to find it.
[47:29.450 --> 47:32.970]  But you try your best to find everything that's potentially running.
[47:32.970 --> 47:41.230]  And then eventually at some point you do shut down the system and then you make your bit for bit copy of the hard drive itself.
[47:41.670 --> 47:55.510]  And as I mentioned with respect to RAID systems, you actually not only have to ensure that you get all the data from the RAID system, but that you can actually recreate that RAID array properly.
[47:55.570 --> 47:59.730]  So that it will not be questioned by the defense.
[48:00.090 --> 48:02.950]  Well, it will not be successfully questioned and thrown out.
[48:02.970 --> 48:07.710]  You can prove that you acquired that and that you acquired it properly.
[48:07.710 --> 48:12.790]  And what the jury is being presented with is exactly what was on the suspect's system.
[48:12.790 --> 48:18.790]  But yeah, you will have to power down the system before you take the image of the actual file system itself.
[48:19.410 --> 48:20.070]  Yes.
[48:31.900 --> 48:32.660]  Yes.
[48:53.270 --> 48:57.070]  If properly entered into the chain of custody, yes.
[48:57.070 --> 49:04.810]  And if you're very careful about documenting how you acquired that data and all that, yeah.
[49:18.230 --> 49:20.270]  Yeah, absolutely.
[49:20.630 --> 49:23.150]  We need to go? Alright, thanks.
[49:23.530 --> 49:24.510]  Thanks Aaron.