WEBVTT 1 00:00:00.000 --> 00:00:03.450 In this lesson, we will learn about volatile 2 00:00:03.450 --> 00:00:06.630 and non-volatile storage analysis. 3 00:00:06.630 --> 00:00:09.780 Volatile and non-volatile storage analysis 4 00:00:09.780 --> 00:00:13.800 examines both temporary and permanent data storage 5 00:00:13.800 --> 00:00:18.330 to identify evidence of compromise or malicious activity. 6 00:00:18.330 --> 00:00:22.380 Volatile and non-volatile storage analysis concepts 7 00:00:22.380 --> 00:00:27.380 include the order of volatility and forensic imaging. 8 00:00:27.420 --> 00:00:32.400 Volatile storage, such as CPU cache, holds temporary data 9 00:00:32.400 --> 00:00:35.970 that is lost almost immediately in a system. 10 00:00:35.970 --> 00:00:39.510 The order of volatility prioritizes capturing 11 00:00:39.510 --> 00:00:44.100 highly ephemeral data, such as CPU cache, first. 12 00:00:44.100 --> 00:00:47.250 And non-volatile storage, like hard drives, 13 00:00:47.250 --> 00:00:52.140 contains permanent data that persists even after power loss, 14 00:00:52.140 --> 00:00:55.800 and is often analyzed through forensic imaging, 15 00:00:55.800 --> 00:01:00.270 where an exact copy of the data is created for investigation 16 00:01:00.270 --> 00:01:02.670 without altering the original. 17 00:01:02.670 --> 00:01:05.640 Let's learn more about the order of volatility 18 00:01:05.640 --> 00:01:07.920 and forensic imaging. 19 00:01:07.920 --> 00:01:11.400 First, we have the order of volatility. 20 00:01:11.400 --> 00:01:14.730 The order of volatility refers to the sequence 21 00:01:14.730 --> 00:01:17.580 in which digital evidence should be collected 22 00:01:17.580 --> 00:01:20.190 during a forensic investigation. 23 00:01:20.190 --> 00:01:21.990 This sequence is important, 24 00:01:21.990 --> 00:01:24.630 because different types of data vary 25 00:01:24.630 --> 00:01:27.660 in how quickly they are lost or altered. 26 00:01:27.660 --> 00:01:32.660 Volatile data such as CPU cache and RAM, is short-lived, 27 00:01:33.360 --> 00:01:37.110 and disappears as soon as the system is powered off. 28 00:01:37.110 --> 00:01:41.970 While non-volatile data, like that on hard drives, or USBs, 29 00:01:41.970 --> 00:01:44.850 persists even after the shutdown. 30 00:01:44.850 --> 00:01:47.760 So, following the order of volatility 31 00:01:47.760 --> 00:01:49.950 and forensic data collection 32 00:01:49.950 --> 00:01:52.080 ensures that investigators capture 33 00:01:52.080 --> 00:01:56.880 the most transient data first, preserving critical evidence. 34 00:01:56.880 --> 00:02:01.880 RFC, or Request For Comment, 3227, which is titled, 35 00:02:02.107 --> 00:02:06.090 "Guidelines for Evidence Collection and Archiving," 36 00:02:06.090 --> 00:02:08.130 provides a standardized framework 37 00:02:08.130 --> 00:02:11.970 for handling digital evidence in forensic investigations, 38 00:02:11.970 --> 00:02:15.510 outlining the order of volatility and best practices 39 00:02:15.510 --> 00:02:17.910 for preserving data integrity. 40 00:02:17.910 --> 00:02:21.090 According to RFC 3227, 41 00:02:21.090 --> 00:02:26.090 the order of volatility is, one, registers and CPU cache, 42 00:02:26.790 --> 00:02:31.140 two, routing tables, ARP cache, process tables, 43 00:02:31.140 --> 00:02:33.600 kernel statistics, and RAM, 44 00:02:33.600 --> 00:02:37.860 three, temporary file systems, or swap space, 45 00:02:37.860 --> 00:02:39.870 four, disks, 46 00:02:39.870 --> 00:02:44.010 five, remote logging and monitoring data, 47 00:02:44.010 --> 00:02:48.510 six, physical configurations and network topologies, 48 00:02:48.510 --> 00:02:53.510 and seven, archival media such as backup tapes. 49 00:02:53.640 --> 00:02:57.210 This list ensures that highly volatile data, 50 00:02:57.210 --> 00:02:59.010 like registers and cache, 51 00:02:59.010 --> 00:03:01.980 can be collected before less volatile data, 52 00:03:01.980 --> 00:03:03.750 like archival media. 53 00:03:03.750 --> 00:03:08.400 For example, when a forensic analyst arrives at a scene 54 00:03:08.400 --> 00:03:10.770 where a computer is still powered on, 55 00:03:10.770 --> 00:03:14.430 the first step is to capture the CPU registers 56 00:03:14.430 --> 00:03:15.960 and cache data. 57 00:03:15.960 --> 00:03:20.520 This data might only exist for a short period of time, 58 00:03:20.520 --> 00:03:22.890 and can contain key information, 59 00:03:22.890 --> 00:03:26.610 such as the state of active processes, 60 00:03:26.610 --> 00:03:29.130 or encryption keys in use. 61 00:03:29.130 --> 00:03:32.580 Next in the order of collection is RAM, 62 00:03:32.580 --> 00:03:37.020 which contains active processes, network connections, 63 00:03:37.020 --> 00:03:39.210 and system statistics. 64 00:03:39.210 --> 00:03:43.470 So, in this scenario, the CPU registers and cache, 65 00:03:43.470 --> 00:03:45.360 as well as the RAM data, 66 00:03:45.360 --> 00:03:48.030 was still available for collection 67 00:03:48.030 --> 00:03:50.550 because the computer was powered on. 68 00:03:50.550 --> 00:03:52.890 But if the computer was turned off 69 00:03:52.890 --> 00:03:55.020 before capturing this data, 70 00:03:55.020 --> 00:03:59.280 all the data in memory would have been permanently lost. 71 00:03:59.280 --> 00:04:03.780 So, as we move further down the order of volatility, 72 00:04:03.780 --> 00:04:06.210 the data becomes less transient, 73 00:04:06.210 --> 00:04:08.700 but remains just as important. 74 00:04:08.700 --> 00:04:11.190 Disk drives and logs, for example, 75 00:04:11.190 --> 00:04:13.410 are vital to an investigation 76 00:04:13.410 --> 00:04:16.290 because they store persistent information, 77 00:04:16.290 --> 00:04:19.410 like deleted files or system logs. 78 00:04:19.410 --> 00:04:23.850 And while this data is less likely to disappear immediately, 79 00:04:23.850 --> 00:04:27.930 it can still be modified or overwritten over time, 80 00:04:27.930 --> 00:04:32.460 so capturing these sources after the more volatile data 81 00:04:32.460 --> 00:04:35.550 ensures that critical, short-lived information, 82 00:04:35.550 --> 00:04:39.540 such as active network connections or running processes, 83 00:04:39.540 --> 00:04:41.730 has already been secured, 84 00:04:41.730 --> 00:04:44.190 enabling investigators to build 85 00:04:44.190 --> 00:04:48.000 a comprehensive understanding of the incident. 86 00:04:48.000 --> 00:04:51.330 Second, we have forensic imaging. 87 00:04:51.330 --> 00:04:54.300 Forensic imaging is the process of creating 88 00:04:54.300 --> 00:04:59.300 an exact, bit-by-bit copy, or image, of digital data 89 00:04:59.460 --> 00:05:03.600 from a storage device in a way that preserves its integrity 90 00:05:03.600 --> 00:05:06.600 to a standard that can be used in court. 91 00:05:06.600 --> 00:05:09.150 Creating forensically sound images 92 00:05:09.150 --> 00:05:13.740 is the first and most critical step in an investigation. 93 00:05:13.740 --> 00:05:18.740 This process allows analysts to examine and analyze the data 94 00:05:19.200 --> 00:05:22.200 without altering the original source. 95 00:05:22.200 --> 00:05:25.470 Ensuring the original data remains untouched 96 00:05:25.470 --> 00:05:28.410 is essential to keeping evidence intact 97 00:05:28.410 --> 00:05:30.420 and admissible in court. 98 00:05:30.420 --> 00:05:34.980 So, forensic imaging captures not only visible files, 99 00:05:34.980 --> 00:05:38.430 but also slack space, unallocated space, 100 00:05:38.430 --> 00:05:40.740 and even deleted files, 101 00:05:40.740 --> 00:05:44.580 as these can contain traces of malicious activity 102 00:05:44.580 --> 00:05:46.710 or other key evidence. 103 00:05:46.710 --> 00:05:50.970 Slack space is the unused space in a file system 104 00:05:50.970 --> 00:05:53.520 that exists between the end of the file 105 00:05:53.520 --> 00:05:55.890 and the end of the storage unit, 106 00:05:55.890 --> 00:05:58.440 which may be a cluster, or a block, 107 00:05:58.440 --> 00:06:00.540 where that file is stored. 108 00:06:00.540 --> 00:06:04.710 Slack space exists because storage devices allocate space 109 00:06:04.710 --> 00:06:07.650 in fixed sized clusters or blocks, 110 00:06:07.650 --> 00:06:10.050 and if a file does not completely fill 111 00:06:10.050 --> 00:06:11.820 its allocated cluster, 112 00:06:11.820 --> 00:06:14.700 the leftover space is called slack space. 113 00:06:14.700 --> 00:06:16.800 Back to forensic imaging. 114 00:06:16.800 --> 00:06:20.520 There are three common tools used for forensic imaging, 115 00:06:20.520 --> 00:06:25.050 and they are dd, dcfldd, 116 00:06:25.050 --> 00:06:29.550 and the Forensic Toolkit, or FTK Imager. 117 00:06:29.550 --> 00:06:33.870 The dd, command native to Unix and Linux systems, 118 00:06:33.870 --> 00:06:38.100 can create a bit-by-bit copy of a storage device. 119 00:06:38.100 --> 00:06:42.960 For example, when using the dd command for forensic imaging, 120 00:06:42.960 --> 00:06:46.410 an investigator might issue the following command 121 00:06:46.410 --> 00:06:50.160 to create a bit-by-bit copy of the drive. 122 00:06:50.160 --> 00:06:55.160 In this command, the if specifies the input file, 123 00:06:55.710 --> 00:07:00.710 where the forward /dev/sdx is the source device, 124 00:07:02.130 --> 00:07:04.560 or the drive being imaged. 125 00:07:04.560 --> 00:07:08.520 Next, the of defines the output file, 126 00:07:08.520 --> 00:07:12.270 indicating where the disk image will be stored. 127 00:07:12.270 --> 00:07:17.270 The bs=64K sets a block size of 64 kilobytes 128 00:07:17.970 --> 00:07:19.380 to improve performance 129 00:07:19.380 --> 00:07:22.560 by reading and writing larger chunks of data. 130 00:07:22.560 --> 00:07:26.820 And finally, the conv option ensures 131 00:07:26.820 --> 00:07:30.810 that the process will continue even if it encounters errors, 132 00:07:30.810 --> 00:07:32.151 such as bad sectors, 133 00:07:32.151 --> 00:07:34.950 and will fill any gaps with zeros 134 00:07:34.950 --> 00:07:37.380 to maintain data alignment. 135 00:07:37.380 --> 00:07:40.050 Next, the dcfldd, 136 00:07:40.050 --> 00:07:44.010 a forensic version of the standard dd command, 137 00:07:44.010 --> 00:07:47.130 was developed by the U.S. Department of Defense's 138 00:07:47.130 --> 00:07:52.080 Computer Forensics Lab to enhance the functionality of dd 139 00:07:52.080 --> 00:07:56.700 for use in forensic data acquisition and secure wiping. 140 00:07:56.700 --> 00:08:00.060 dcfldd offers added features, 141 00:08:00.060 --> 00:08:04.290 such as on-the-fly hashing, and progress indicators, 142 00:08:04.290 --> 00:08:07.950 which make it more suitable for forensic work. 143 00:08:07.950 --> 00:08:12.360 A use of dcfldd for forensic imaging 144 00:08:12.360 --> 00:08:15.930 might use the command that is on the screen. 145 00:08:15.930 --> 00:08:19.800 This command not only creates a disk image, 146 00:08:19.800 --> 00:08:24.800 but also generates both MD5 and SHA-256 hashes 147 00:08:25.080 --> 00:08:27.720 of the data on-the-fly, 148 00:08:27.720 --> 00:08:29.640 recording these hash values 149 00:08:29.640 --> 00:08:33.810 in a log file named hashlog.txt. 150 00:08:33.810 --> 00:08:38.430 The inclusion of hashing ensures the integrity of the image, 151 00:08:38.430 --> 00:08:40.980 and provides a way to verify 152 00:08:40.980 --> 00:08:45.720 that the image is an exact copy of the original device. 153 00:08:45.720 --> 00:08:49.920 This is especially important in forensic investigations, 154 00:08:49.920 --> 00:08:53.520 where the integrity and authenticity of the data 155 00:08:53.520 --> 00:08:56.520 are critical for legal proceedings. 156 00:08:56.520 --> 00:09:00.870 Finally, the Forensic Toolkit, or FTK Imager, 157 00:09:00.870 --> 00:09:05.870 is a graphical tool that not only creates bit-by-bit copies, 158 00:09:06.150 --> 00:09:09.210 but also automates hash generation 159 00:09:09.210 --> 00:09:11.970 and provides a chain of custody, 160 00:09:11.970 --> 00:09:13.770 ensuring that the integrity 161 00:09:13.770 --> 00:09:18.180 of both the original and the copy can be verified. 162 00:09:18.180 --> 00:09:20.580 These tools ensure that the image 163 00:09:20.580 --> 00:09:25.020 is an exact bit-by-bit replica of the original, 164 00:09:25.020 --> 00:09:30.020 including hidden and deleted data used for investigations. 165 00:09:30.360 --> 00:09:33.420 A key practice during forensic imaging 166 00:09:33.420 --> 00:09:36.210 is the use of a write blocker, 167 00:09:36.210 --> 00:09:39.690 which prevents any accidental modification 168 00:09:39.690 --> 00:09:42.390 to the original storage device 169 00:09:42.390 --> 00:09:44.400 when an investigator's device 170 00:09:44.400 --> 00:09:46.770 is connected to it for imaging. 171 00:09:46.770 --> 00:09:50.550 This guarantees that the original evidential data 172 00:09:50.550 --> 00:09:53.430 remains in an unaltered state. 173 00:09:53.430 --> 00:09:56.610 Additionally, investigators typically follow 174 00:09:56.610 --> 00:09:59.760 the best practice of creating an image 175 00:09:59.760 --> 00:10:02.610 of the original device for storage, 176 00:10:02.610 --> 00:10:06.900 and then creating another image from that stored image 177 00:10:06.900 --> 00:10:08.940 to be used for analysis. 178 00:10:08.940 --> 00:10:13.830 This way, the original device is accessed only once, 179 00:10:13.830 --> 00:10:15.240 even if there is a problem 180 00:10:15.240 --> 00:10:17.970 with the image being used for analysis, 181 00:10:17.970 --> 00:10:20.430 preserving original data integrity, 182 00:10:20.430 --> 00:10:24.720 and minimizing the risk of data tampering or corruption. 183 00:10:24.720 --> 00:10:29.720 So, remember, volatile and non-volatile storage analysis 184 00:10:30.360 --> 00:10:34.170 examines both temporary and permanent data 185 00:10:34.170 --> 00:10:39.060 to uncover evidence of malicious activity or compromise. 186 00:10:39.060 --> 00:10:44.060 Volatile data, such as what's stored in CPU cache or RAM, 187 00:10:44.550 --> 00:10:49.410 is quickly lost, especially when the system powers down. 188 00:10:49.410 --> 00:10:53.850 So, investigators prioritize capturing it first 189 00:10:53.850 --> 00:10:56.790 by following the order of volatility, 190 00:10:56.790 --> 00:10:59.400 the sequence of which is, 191 00:10:59.400 --> 00:11:03.240 number one, CPU registers in cache, 192 00:11:03.240 --> 00:11:08.190 number two, routing tables, ARP cache, process tables, 193 00:11:08.190 --> 00:11:10.620 kernel statistics, and RAM, 194 00:11:10.620 --> 00:11:15.120 number three, temporary file systems or swap space, 195 00:11:15.120 --> 00:11:17.610 number four, disks, 196 00:11:17.610 --> 00:11:21.690 number five, remote logging and monitoring data, 197 00:11:21.690 --> 00:11:26.670 number six, physical configurations and network topologies, 198 00:11:26.670 --> 00:11:30.150 and number seven, archival media. 199 00:11:30.150 --> 00:11:34.230 This process is crucial to forensic investigations, 200 00:11:34.230 --> 00:11:38.220 ensuring that highly ephemeral information is preserved 201 00:11:38.220 --> 00:11:42.330 before moving on to secure more stable data. 202 00:11:42.330 --> 00:11:45.240 Non-volatile data found on hard drives, 203 00:11:45.240 --> 00:11:47.220 or other permanent storage, 204 00:11:47.220 --> 00:11:51.150 is typically then examined through forensic imaging, 205 00:11:51.150 --> 00:11:54.060 where an exact replica of the original data 206 00:11:54.060 --> 00:11:56.160 is created for analysis, 207 00:11:56.160 --> 00:11:59.220 without altering the original source. 208 00:11:59.220 --> 00:12:04.080 Using forensic tools like dd, dcfldd, 209 00:12:04.080 --> 00:12:06.780 or the Forensic Toolkit Imager, 210 00:12:06.780 --> 00:12:10.770 investigators can ensure the integrity of this data 211 00:12:10.770 --> 00:12:13.950 and maintain its admissibility in court, 212 00:12:13.950 --> 00:12:16.620 while preserving the original evidence. 213 00:12:16.620 --> 00:12:20.820 This is typically achieved by creating a bit-by-bit image 214 00:12:20.820 --> 00:12:25.470 of the storage device, including all files, slack space, 215 00:12:25.470 --> 00:12:27.630 and unallocated space, 216 00:12:27.630 --> 00:12:31.800 while using a write blocker to prevent any modifications 217 00:12:31.800 --> 00:12:33.870 to the original data. 218 00:12:33.870 --> 00:12:37.230 The forensic image is then hashed to verify 219 00:12:37.230 --> 00:12:39.210 that it matches the original, 220 00:12:39.210 --> 00:12:43.590 ensuring that any analysis is conducted on the copy, 221 00:12:43.590 --> 00:12:47.430 and the original remains untouched and secure. 222 00:12:47.430 --> 00:12:50.400 This approach safeguards the chain of custody 223 00:12:50.400 --> 00:12:53.460 and protects the integrity of the evidence 224 00:12:53.460 --> 00:12:55.323 throughout the investigation.