WEBVTT 1 00:00:00.120 --> 00:00:02.720 If you see your computer being hacked right in front 2 00:00:02.759 --> 00:00:05.919 of you, like the cursor moving on its own command prompts, 3 00:00:05.919 --> 00:00:09.400 flashing files, locking up, your first instinct is probably to 4 00:00:09.400 --> 00:00:11.599 just reach around the back of the machine and yank 5 00:00:11.640 --> 00:00:12.960 the power cord out of the wall. 6 00:00:13.039 --> 00:00:16.120 Oh absolutely, I mean it is absolute total panic. You 7 00:00:16.160 --> 00:00:19.199 really just want to stop the bleeding right then and there, right. 8 00:00:19.480 --> 00:00:22.760 But according to the pioneers of modern cyber forensics, doing 9 00:00:22.800 --> 00:00:26.480 that is actually the absolute worst thing you can do. Like, 10 00:00:26.839 --> 00:00:30.039 you aren't stopping the hacker, you are actively destroying the 11 00:00:30.079 --> 00:00:30.760 crime scene. 12 00:00:30.839 --> 00:00:34.159 Yeah, it's a reality of incident response that goes against well, 13 00:00:34.240 --> 00:00:36.840 basically every natural instinct you have. When you kill a 14 00:00:36.880 --> 00:00:40.000 power you just obliterate the most valuable evidence you could 15 00:00:40.039 --> 00:00:41.159 possibly get your hands on. 16 00:00:41.520 --> 00:00:44.479 So welcome to this deep dive. Our mission today is 17 00:00:44.520 --> 00:00:48.399 to explore the incredibly complex, honestly almost magical world of 18 00:00:48.439 --> 00:00:53.880 memory forensics. We're looking at how investigators catch advanced, stealthy malware. 19 00:00:53.799 --> 00:00:55.679 Right, the kind of threats that never even write a 20 00:00:55.719 --> 00:00:57.560 single file to a hard drive. 21 00:00:57.679 --> 00:01:03.320 Exactly, Investigators actually catch them by freezing and analyzing the invisible, 22 00:01:03.359 --> 00:01:06.519 fleeting world of RAM. And we are pulling our insights 23 00:01:06.519 --> 00:01:08.959 today from the definitive guide on the subject. It's called 24 00:01:08.959 --> 00:01:11.079 the Art of Memory Forensics. 25 00:01:10.680 --> 00:01:13.159 Which was written by the creators of the Volatility framework. 26 00:01:13.200 --> 00:01:14.640 By the way, incredible resource. 27 00:01:14.719 --> 00:01:15.319 Yeah, totally. 28 00:01:15.400 --> 00:01:15.640 Yeah. 29 00:01:15.680 --> 00:01:17.640 So we are going on an expedition today for you, 30 00:01:18.280 --> 00:01:21.879 starting from the physical silicon chips on your motherboard all 31 00:01:21.959 --> 00:01:25.680 the way up into the logical, heavily guarded VIP rooms 32 00:01:25.719 --> 00:01:26.879 of the operating system. 33 00:01:27.079 --> 00:01:29.120 And to catch a digital criminal, you really do have 34 00:01:29.159 --> 00:01:32.239 to understand the physical laws of the environment they're operating in, right, 35 00:01:32.319 --> 00:01:35.480 Because software doesn't exist in a vacuum. 36 00:01:34.959 --> 00:01:37.280 Right, It's tied to the physical machine entirely. 37 00:01:37.319 --> 00:01:41.000 It is entirely constrained by the physical hardware. So before 38 00:01:41.000 --> 00:01:42.640 we get into the malware itself, we kind of have 39 00:01:42.680 --> 00:01:46.079 to look at the hardware canvas, specifically the CPU, the 40 00:01:46.120 --> 00:01:48.719 memory management unit, and the RAM itself. 41 00:01:48.959 --> 00:01:53.159 And RAM is well, it's volatile memory. It's literally built 42 00:01:53.280 --> 00:01:57.560 out of microscopic capacitors that require a constant electrical charge 43 00:01:57.599 --> 00:02:01.560 to maintain their state. So no power, no data exactly. 44 00:02:01.719 --> 00:02:04.200 Hence why pulling the plug is such a disaster for 45 00:02:04.239 --> 00:02:05.359 an investigator, right. 46 00:02:05.840 --> 00:02:09.039 But while power loss is a vulnerability for the investigator, 47 00:02:09.400 --> 00:02:13.000 the most mind blowing physical vulnerability for the computer itself 48 00:02:13.080 --> 00:02:14.240 is something called DMA. 49 00:02:14.560 --> 00:02:19.479 Yes, DMA that stands for direct memory access, and I 50 00:02:19.520 --> 00:02:22.599 mean DMA completely changes the threat landscape. 51 00:02:22.639 --> 00:02:25.759 I've definitely heard that term thrown around. How exactly does 52 00:02:25.840 --> 00:02:28.840 DMA work Because normally the CPU is sort of the 53 00:02:28.840 --> 00:02:33.240 boss of the computer, right like, it handles every single request. 54 00:02:33.000 --> 00:02:34.400 Under normal circumstances. 55 00:02:34.479 --> 00:02:37.560 Yes, you can think of the CPU as an overworked CEO. 56 00:02:38.199 --> 00:02:41.039 But to speed things up, hardware designers realize the CPU 57 00:02:41.199 --> 00:02:44.560 really shouldn't waste its time micromanaging every tiny data. 58 00:02:44.240 --> 00:02:46.759 Transfer, so it delegates exactly. 59 00:02:46.639 --> 00:02:49.719 The CPU delegates bulk data transfers to a middle manager, 60 00:02:49.759 --> 00:02:53.000 which is the DMA controller. This manager handles moving massive 61 00:02:53.039 --> 00:02:55.919 amounts of data from say a network card or a 62 00:02:55.919 --> 00:02:59.120 graphics card, straight into the RAM, just completely bypassing the CEO. 63 00:02:59.240 --> 00:03:01.919 Wait, hold on, secon and let's unpack this. If peripheral 64 00:03:01.919 --> 00:03:04.439 devices can use this DMA manager to read and write 65 00:03:04.439 --> 00:03:08.159 directly to the RAM without asking the CPU, doesn't that 66 00:03:08.199 --> 00:03:11.000 mean they're also acting without the operating system's permission? 67 00:03:11.360 --> 00:03:11.560 Yeah? 68 00:03:11.599 --> 00:03:15.120 I mean, isn't that a massive, gaping security backdoor built 69 00:03:15.199 --> 00:03:16.240 right into the motherboard? 70 00:03:16.520 --> 00:03:18.960 What's really fascinating here is that it is exactly that 71 00:03:19.240 --> 00:03:23.680 it's literally a hardware level bypass of all software security. 72 00:03:23.800 --> 00:03:24.719 That is crazy. 73 00:03:24.879 --> 00:03:27.719 Right. Architecture is like the old firewires standard or even 74 00:03:28.000 --> 00:03:32.039 modern PCI express buses. They support devices that act as 75 00:03:32.080 --> 00:03:35.360 bus masters, and a bus master can request control of 76 00:03:35.360 --> 00:03:38.360 the hardware bus and just initiate direct reads and rights 77 00:03:38.400 --> 00:03:41.439 to physical memory, and the OS doesn't know. The operating 78 00:03:41.479 --> 00:03:43.680 system has absolutely no idea that's even happening. 79 00:03:43.759 --> 00:03:47.360 Okay, so if someone plugs a malicious device into the 80 00:03:47.479 --> 00:03:51.080 right port on my machine, that device could theoretically just 81 00:03:51.120 --> 00:03:54.960 siphon off all my passwords or like encryption keys directly 82 00:03:55.000 --> 00:03:58.199 out of the physical memory. Yea, and my antivirus would 83 00:03:58.240 --> 00:03:59.599 just be completely blind. 84 00:03:59.319 --> 00:04:00.560 To itolute blind. 85 00:04:00.599 --> 00:04:03.639 I mean, it is the ultimate double edged sword in cybersecurity. 86 00:04:04.000 --> 00:04:06.520 On one hand, attackers can use this hardware trick to 87 00:04:06.560 --> 00:04:09.800 silently bypass all privileged separations and steal your data. 88 00:04:09.879 --> 00:04:10.599 But on the other. 89 00:04:10.520 --> 00:04:14.759 Hand, forensic investigators use the exact same DMA capability to 90 00:04:14.800 --> 00:04:17.040 copy the contents of an infected computer's RAM. 91 00:04:17.120 --> 00:04:18.800 Oh wow, so they just grab everything. 92 00:04:18.920 --> 00:04:22.399 Yeah, they capture a perfect, pristine image of the crime 93 00:04:22.480 --> 00:04:25.839 scene without tipping off the malware that it's being watched. 94 00:04:26.199 --> 00:04:29.879 That is terrifying but also incredibly clever on the investigator's part, 95 00:04:30.079 --> 00:04:32.759 but brings up a really massive question for me. If 96 00:04:32.800 --> 00:04:35.439 physical memory is just this open playground that could be 97 00:04:35.439 --> 00:04:39.399 directly accessed and overwritten, why hasn't everything just collapsed? 98 00:04:39.560 --> 00:04:41.240 Well, the OS fights back. 99 00:04:41.040 --> 00:04:44.360 But how how is the operating system fighting back to 100 00:04:44.399 --> 00:04:47.759 safely run dozens of programs at the same time, Like 101 00:04:47.839 --> 00:04:50.680 how does your web browser not accidentally overwrite the memory 102 00:04:50.680 --> 00:04:52.079 space of your password manager? 103 00:04:52.240 --> 00:04:53.839 It fights back with an illusion. 104 00:04:54.079 --> 00:04:56.439 We have to move from the physical hardware to a 105 00:04:56.480 --> 00:05:00.879 concept called virtual memory. The operating system really on demand 106 00:05:00.959 --> 00:05:05.600 paging and address translation to keep every single process completely isolated. 107 00:05:05.680 --> 00:05:08.319 Okay, you're losing me just a bit with the terminology there. 108 00:05:08.319 --> 00:05:10.759 What exactly is demand paging? Right? 109 00:05:10.800 --> 00:05:14.519 Sorry? Think of physical RAM as a small, highly efficient 110 00:05:14.560 --> 00:05:18.319 work bench, and your hard drive is a massive, really 111 00:05:18.319 --> 00:05:19.399 slow filing cabinet. 112 00:05:19.560 --> 00:05:21.560 Okay, workbench and filing cabinet, got it. 113 00:05:21.800 --> 00:05:24.879 So demand paging is a system where the OS only 114 00:05:24.920 --> 00:05:27.560 puts the specific parts of a program onto the work 115 00:05:27.639 --> 00:05:31.319 bench that are actively being used right that very second, and. 116 00:05:31.279 --> 00:05:32.879 If a program goes idle if it. 117 00:05:32.800 --> 00:05:35.920 Goes idle, the OS pages it out. It just sweeps 118 00:05:35.959 --> 00:05:38.759 those files off the workbench and back into the filing 119 00:05:38.800 --> 00:05:41.879 cabinet to free up space for whatever you are actively 120 00:05:41.879 --> 00:05:42.240 working on. 121 00:05:42.439 --> 00:05:45.800 Ah okay, got it. So the OS is constantly shuffling 122 00:05:45.839 --> 00:05:48.279 things around behind the scenes, which I assume ties into 123 00:05:48.279 --> 00:05:51.000 that address translation thing you mentioned exactly, because I like 124 00:05:51.040 --> 00:05:54.199 to think of virtual memory like giving every single program 125 00:05:54.240 --> 00:05:56.759 its own fake map of a city, Like as far 126 00:05:56.759 --> 00:05:59.040 as the web browser knows it lives entirely alone at 127 00:05:59.079 --> 00:06:01.839 one main street in this massive, sprawling city. 128 00:06:01.959 --> 00:06:03.560 Yes, that's a great way to look at it. 129 00:06:03.720 --> 00:06:06.480 But then the password manager also thinks it lives alone 130 00:06:06.480 --> 00:06:09.720 at one main street in its own empty city. They 131 00:06:09.800 --> 00:06:12.879 never realize they are actually sharing the exact same physical 132 00:06:12.920 --> 00:06:15.879 silicon chips because the OS is constantly just changing the 133 00:06:15.920 --> 00:06:16.560 street signs. 134 00:06:16.639 --> 00:06:19.600 That is the perfect way to visualize it. Yeah, every 135 00:06:19.680 --> 00:06:24.079 process gets a continuous, flat virtual address space, and the 136 00:06:24.120 --> 00:06:27.480 memory manager chops that fake map up into tiny blocks, 137 00:06:27.560 --> 00:06:30.759 usually four kilobyte pages. Okay, and the physical memory is 138 00:06:30.759 --> 00:06:35.120 also chopped up into four kilobyte frames. The hardware specifically 139 00:06:35.319 --> 00:06:39.480 a component called the memory management unit or MMU, alongside 140 00:06:39.560 --> 00:06:43.360 a special CPU register called CR III. It acts as 141 00:06:43.399 --> 00:06:45.079 the universal translator. 142 00:06:44.680 --> 00:06:46.560 So it maps the fake city map to the real 143 00:06:46.560 --> 00:06:49.720 physical streets precisely. Okay, So what does this all mean 144 00:06:49.759 --> 00:06:52.519 for the investigator? Because if I'm a forensic analyst and 145 00:06:52.560 --> 00:06:54.959 I have a raw physical dump of RAM that I 146 00:06:55.040 --> 00:06:57.959 captured using that DM matrix, we talked about, how on 147 00:06:58.000 --> 00:07:00.279 earth do I find a specific piece of evidence. If 148 00:07:00.279 --> 00:07:02.920 a piece of malware is hiding a stolen password, it's 149 00:07:02.959 --> 00:07:05.519 hiding it at a fake address. That fake address doesn't 150 00:07:05.519 --> 00:07:07.160 exist in my physical dump. 151 00:07:07.120 --> 00:07:09.319 Right, so you have to reverse engineer the illusion. You 152 00:07:09.360 --> 00:07:11.600 basically have to do the exact same math the MMU 153 00:07:11.680 --> 00:07:14.639 hardware does, but you have to do it manually in software. 154 00:07:14.759 --> 00:07:18.360 Oh Man, walk me through that. How do you translate 155 00:07:18.399 --> 00:07:21.240 a fake address to a real one without just getting 156 00:07:21.279 --> 00:07:23.759 totally lost in the sea of hexadesmal numbers. 157 00:07:23.959 --> 00:07:27.879 Well, let's stick with your map analogy. Imagine the virtual address, 158 00:07:28.040 --> 00:07:31.040 the fake address the malware sees is broken down into 159 00:07:31.040 --> 00:07:34.240 three parts, a zip code, a street name, and a 160 00:07:34.279 --> 00:07:34.879 house number. 161 00:07:34.920 --> 00:07:37.240 Okay, zip code, street name, house number. 162 00:07:37.399 --> 00:07:39.759 When you want to find the physical location, you start 163 00:07:39.759 --> 00:07:42.600 by looking at that special CR three register we mentioned 164 00:07:42.920 --> 00:07:45.920 the CR three register acts like a master directory. It 165 00:07:46.000 --> 00:07:48.560 tells you exactly where to find the translation book for 166 00:07:48.600 --> 00:07:50.000 this specific program. 167 00:07:50.079 --> 00:07:51.800 Okay, so the CR three gets me to the right 168 00:07:51.800 --> 00:07:53.360 translation book exactly. 169 00:07:53.560 --> 00:07:55.720 From there, you take the first part of the malware's 170 00:07:55.759 --> 00:07:58.319 fake address, the zip code. You look up that zip 171 00:07:58.319 --> 00:08:00.399 code in the translation book and it points you to 172 00:08:00.439 --> 00:08:03.519 a specific neighborhood in the physical RAM tracking so far, 173 00:08:03.920 --> 00:08:06.319 Then you take the second part of the fake address, 174 00:08:06.399 --> 00:08:09.040 the street name. You look that up and it narrows 175 00:08:09.079 --> 00:08:11.560 your search down to a specific physical. 176 00:08:11.160 --> 00:08:13.040 Block of memory, and then the house number. 177 00:08:13.279 --> 00:08:16.160 Right. Finally, you take the last part of the virtual address, 178 00:08:16.199 --> 00:08:19.920 which is the exact house number or offset that tells 179 00:08:19.959 --> 00:08:22.680 you precisely how many bites down the street you need 180 00:08:22.720 --> 00:08:25.279 to walk to find the stolen password hiding in the 181 00:08:25.279 --> 00:08:26.040 physical RAM. 182 00:08:26.360 --> 00:08:30.519 It's basically a massive scavenger hunt. Like the first clue 183 00:08:30.759 --> 00:08:33.120 gives you the physical location of the second clue, which 184 00:08:33.159 --> 00:08:36.120 gives you the third clue, until you finally find the payload. 185 00:08:36.399 --> 00:08:39.360 It is a literal chain of pointers. And I mean 186 00:08:39.440 --> 00:08:42.960 doing this translation by hand for gigabytes of RAM would 187 00:08:43.000 --> 00:08:44.840 take a human being lifetimes. 188 00:08:45.080 --> 00:08:47.120 Oh yeah, I can't even imagine. 189 00:08:46.759 --> 00:08:49.480 Which is exactly why tools like the Volatility framework are 190 00:08:49.519 --> 00:08:53.519 so revolutionary in memory forensics. Yeah, they emulate this exact 191 00:08:53.559 --> 00:08:58.080 hardware translation process automatically. They basically rebuild the fake city 192 00:08:58.120 --> 00:09:01.000 maps perfectly for every single process. 193 00:09:00.720 --> 00:09:03.639 So the investigator sees the computer exactly as the malware 194 00:09:03.720 --> 00:09:06.399 was seeing it at the exact moment the memory was frozen, 195 00:09:06.679 --> 00:09:10.919 which is incredible, but it raises another huge issue. If 196 00:09:10.960 --> 00:09:14.240 the operating system manages these fake maps and handles all 197 00:09:14.240 --> 00:09:17.600 these translations, then the OS holds all the keys to 198 00:09:17.639 --> 00:09:20.919 the kingdom it does, So, how does the OS protect 199 00:09:20.960 --> 00:09:24.480 its own memory from being overwritten? Like what stops a 200 00:09:24.519 --> 00:09:27.840 malicious program from just reaching out and altering the master 201 00:09:27.919 --> 00:09:28.679 translation book. 202 00:09:28.759 --> 00:09:31.759 This is where we get into strict privileged separation. The 203 00:09:31.840 --> 00:09:35.559 system is divided into rings of trust. On modern architectures, 204 00:09:35.600 --> 00:09:38.279 we primarily talk about ring three and ring zero. 205 00:09:38.440 --> 00:09:41.360 Okay, I love this concept. If we use like a 206 00:09:41.480 --> 00:09:45.120 nightclib analogy, Ring three is user mode. That is the crowded, 207 00:09:45.200 --> 00:09:48.720 chaotic main floor of the club. Exactly all your regular apps, 208 00:09:48.759 --> 00:09:51.759 your browser, your text editor, even the malware. Initially, they 209 00:09:51.840 --> 00:09:53.519 all just party out there on the main floor. They're 210 00:09:53.519 --> 00:09:56.000 completely untrusted. They can only see their own drinks. But 211 00:09:56.120 --> 00:09:59.039 Ring zero, on the other hand, is kernel mode. That 212 00:09:59.159 --> 00:10:03.200 is the ultras cure soundproof VIP room where the core 213 00:10:03.240 --> 00:10:06.080 operating system lives. You can't just walk from the main 214 00:10:06.120 --> 00:10:08.759 floor into the VIP room. You have to ask a bouncer, 215 00:10:09.039 --> 00:10:10.080 and that ask. 216 00:10:10.080 --> 00:10:13.840 Is a highly structured mechanism called a system call. A 217 00:10:14.000 --> 00:10:16.960 user program has to trigger an interrupt, which is essentially 218 00:10:17.120 --> 00:10:19.519 handing a specific request. 219 00:10:19.200 --> 00:10:19.919 To the bouncer. 220 00:10:20.080 --> 00:10:22.679 Okay, now, to make sure the bouncer knows exactly what 221 00:10:22.720 --> 00:10:25.799 to do, the operating system uses something called the IDT. 222 00:10:26.000 --> 00:10:27.759 That's the interrupt descriptor table. 223 00:10:27.919 --> 00:10:30.320 So the IDT is basically the bouncer's rolodex. 224 00:10:30.519 --> 00:10:32.440 That's a great way to think about it. If a 225 00:10:32.480 --> 00:10:34.919 program on the main floor asks to read a file 226 00:10:34.960 --> 00:10:38.440 from the hard drive, the CPU checks the IDT rolodex. 227 00:10:38.759 --> 00:10:41.919 It looks up the exact trusted piece of Ring zero 228 00:10:42.080 --> 00:10:45.279 kernel code that is authorized to safely read files on. 229 00:10:45.279 --> 00:10:47.399 Behalf of the user and it only runs. 230 00:10:47.120 --> 00:10:50.399 That, and it executes only that specific code. The IDT 231 00:10:50.600 --> 00:10:52.200 is absolute gospel. 232 00:10:51.799 --> 00:10:52.480 To the CPU. 233 00:10:53.039 --> 00:10:55.960 It dictates exactly where the hardware jumps to handle any 234 00:10:56.000 --> 00:10:56.879 specific event. 235 00:10:57.200 --> 00:10:59.679 But wait, if that rolodex is the ultimate source of 236 00:10:59.679 --> 00:11:03.080 truth for the CPU. What happens if malware is sophisticated 237 00:11:03.159 --> 00:11:05.799 enough to break into the VIP room, Like, what if 238 00:11:05.840 --> 00:11:08.519 it uses a pen to cross out the operating system's 239 00:11:08.799 --> 00:11:12.039 trusted instructions in the IDT and writes its own malicious 240 00:11:12.039 --> 00:11:13.080 instructions instead. 241 00:11:13.399 --> 00:11:15.840 Well, if malwa manages to do that, you are dealing 242 00:11:15.840 --> 00:11:19.799 with one of the most devastating forms of infection, a rootkit. 243 00:11:20.240 --> 00:11:22.639 Because the IDT is so critical, it's. 244 00:11:22.519 --> 00:11:24.639 A prime target for advanced attackers. 245 00:11:24.879 --> 00:11:26.480 Are there real world examples of that? 246 00:11:26.600 --> 00:11:26.759 Ooh? 247 00:11:26.759 --> 00:11:27.320 Absolutely. 248 00:11:27.840 --> 00:11:30.200 There is a legendary piece of malware discussed in the 249 00:11:30.240 --> 00:11:34.039 forensics community called shadow Walker that did exactly this. It 250 00:11:34.120 --> 00:11:37.200 targeted a very specific entry in the rolodex, the page 251 00:11:37.200 --> 00:11:38.000 fault handler. 252 00:11:38.320 --> 00:11:40.600 A page fault Okay, that's tied to the demand paging 253 00:11:40.600 --> 00:11:43.480 you mentioned earlier, Right, It's what happens when a program 254 00:11:43.519 --> 00:11:46.480 asks for data that the OS has temporarily swept off 255 00:11:46.480 --> 00:11:48.039 the work bench into the filing cabinet. 256 00:11:48.120 --> 00:11:50.679 Exactly when a program asks for that missing data, the 257 00:11:50.720 --> 00:11:55.000 CPU triggers a page fault interrupt usually interrupt zero by E. 258 00:11:55.440 --> 00:11:58.840 The CPU checks the IDT rolodex, finds the OS code 259 00:11:58.879 --> 00:12:01.159 to go fetch the data from the heart and brings it. 260 00:12:01.120 --> 00:12:01.799 Back to the RAM. 261 00:12:02.080 --> 00:12:03.279 So what did shadow Walker do. 262 00:12:03.480 --> 00:12:06.720 Shadow Walker hijacked that specific entry. It crossed out the 263 00:12:06.720 --> 00:12:10.840 OS's instructions and pointed the rolodex to its own malicious code. 264 00:12:10.960 --> 00:12:14.360 Wow. So the rootkit intercepts the request, But how does 265 00:12:14.399 --> 00:12:17.240 that actually hide the malware from an anti virus scan? 266 00:12:17.600 --> 00:12:21.759 By completely desynchronizing the CPU's view of memory. This is 267 00:12:21.759 --> 00:12:25.399 where it gets just brilliantly evil. When a security tool 268 00:12:25.639 --> 00:12:28.440 or an antivirus program tries to read the memory space 269 00:12:28.480 --> 00:12:31.799 where the malware is hiding to scan it for signatures, Yeah, 270 00:12:31.879 --> 00:12:33.600 it inadvertently triggers. 271 00:12:33.159 --> 00:12:33.919 That page fault. 272 00:12:34.320 --> 00:12:37.000 The CPU checks the compromise rolodex and runs the. 273 00:12:37.039 --> 00:12:37.840 Root kit's code. 274 00:12:37.960 --> 00:12:39.879 Oh no, The root kit. 275 00:12:39.879 --> 00:12:41.759 Looks at the request and essentially says, oh, you want 276 00:12:41.799 --> 00:12:43.240 to see what's in this room? Here? Look at this, 277 00:12:43.639 --> 00:12:47.879 and it hands the antivirus a duplicate, completely clean page 278 00:12:47.919 --> 00:12:48.399 of memory. 279 00:12:48.480 --> 00:12:51.320 You are kidding. It feeds the anti virus a fake, 280 00:12:51.519 --> 00:12:53.279 sanitized image exactly. 281 00:12:53.320 --> 00:12:55.799 The anti virus looks at the fake clean page, says 282 00:12:55.879 --> 00:12:58.600 looks fine to me, and moves on. But and this 283 00:12:58.639 --> 00:13:01.480 is the really crucial part. When the CPU actually goes 284 00:13:01.519 --> 00:13:04.200 to execute the code in that same memory space. The 285 00:13:04.320 --> 00:13:08.159 rootkit lets the CPU see the real malicious instructions. 286 00:13:07.600 --> 00:13:09.960 So it separates the read view from the execpo. 287 00:13:10.120 --> 00:13:13.519 Yes, the malware becomes completely invisible to the system itself 288 00:13:13.559 --> 00:13:16.279 because it controls the very eyes of the operating system. 289 00:13:16.519 --> 00:13:21.720 It's literally a digital invisibility cloak. And honestly, that is 290 00:13:21.799 --> 00:13:25.639 exactly why memory forensics is absolutely required here, because if 291 00:13:25.679 --> 00:13:29.039 you pull the raw memory using DMA and you take 292 00:13:29.080 --> 00:13:32.039 that memory dump offline to analyze it from another machine, 293 00:13:32.600 --> 00:13:36.399 the rootkit loses its power. Exactly like the rootkit can't 294 00:13:36.440 --> 00:13:39.720 intercept your gaze if you aren't using the infected operating 295 00:13:39.759 --> 00:13:42.039 system to look at it. You just use your forensic 296 00:13:42.080 --> 00:13:45.279 tools to audit that idt rolodex directly, and you can 297 00:13:45.320 --> 00:13:47.840 clearly see where the bouncer's instructions have been tampered with. 298 00:13:48.200 --> 00:13:51.919 You map out the true landscape, you bypass the rootkits lies, 299 00:13:52.519 --> 00:13:54.720 and you finally find out where the real action is 300 00:13:54.720 --> 00:13:56.080 happening in the physical ram. 301 00:13:56.200 --> 00:13:59.360 Okay, so we've bypassed the hardware back doors, we've translated 302 00:13:59.399 --> 00:14:02.399 the fake virtual we've exposed the root kits hiding in 303 00:14:02.440 --> 00:14:05.240 the VIP room. Once you finally map out the true, 304 00:14:05.360 --> 00:14:09.240 uncorrupted memory landscape, what does the actual evidence look like? 305 00:14:09.320 --> 00:14:11.279 What do you mean like if I'm looking for a 306 00:14:11.279 --> 00:14:14.000 stolen credit card or a secret network connection back to 307 00:14:14.039 --> 00:14:16.960 a hacker server, how is that physically structured? In the RAM? 308 00:14:17.080 --> 00:14:17.879 Ah? Okay? 309 00:14:18.240 --> 00:14:22.399 Well, software is built on fundamental primitive data types, things 310 00:14:22.519 --> 00:14:27.159 like integers, single characters, and pointers. But to manage complex 311 00:14:27.200 --> 00:14:32.120 information efficiently, operating systems group those primitive types into larger 312 00:14:32.240 --> 00:14:35.240 data STRUCTURESTCHA. When you are digging through RAM, the most 313 00:14:35.240 --> 00:14:38.679 common structures you are hunting for are bitmaps, stacks, heaps, 314 00:14:38.720 --> 00:14:39.360 and records. 315 00:14:39.759 --> 00:14:42.960 Let's start with bitmaps, actually, because they are so incredibly elegant. Yeah, 316 00:14:43.000 --> 00:14:45.799 you described this to me, one says a massive hotel. 317 00:14:46.159 --> 00:14:49.039 Yes, think of a massive hotel with exactly sixty five, 318 00:14:49.480 --> 00:14:52.639 five hundred and thirty five rooms. In the computing world. 319 00:14:52.639 --> 00:14:55.840 This perfectly represents all the possible network ports available on 320 00:14:55.879 --> 00:14:59.360 a Windows machine. If the operating system track the status 321 00:14:59.399 --> 00:15:03.200 of every single port using a massive, detailed database, it 322 00:15:03.200 --> 00:15:06.200 would waste a ridiculous amount of memory and processing time. 323 00:15:06.360 --> 00:15:09.080 So instead of a database, it uses a bitmap, which 324 00:15:09.120 --> 00:15:11.679 is just a tiny eight kilobyte ledger, Each room in 325 00:15:11.720 --> 00:15:14.720 the hotel, or each network port gets exactly one single 326 00:15:14.759 --> 00:15:15.960 bit of data allocated to. 327 00:15:15.960 --> 00:15:17.480 It, just a microscopic switch. 328 00:15:17.679 --> 00:15:20.320 Right. A zero means the port is closed, A one 329 00:15:20.360 --> 00:15:21.399 means the port is open. 330 00:15:21.759 --> 00:15:25.679 It is remarkably efficient. If a piece of malware silently 331 00:15:25.720 --> 00:15:29.440 opens a backdoor communication channel on port six, the operating 332 00:15:29.440 --> 00:15:32.519 system just flips the sixth bit in that tiny eight 333 00:15:32.559 --> 00:15:35.919 kilobyte ledger from a zero tool one So simple, right, 334 00:15:36.279 --> 00:15:39.600 And as an investigator, if you can locate that specific 335 00:15:39.679 --> 00:15:42.320 eight kilobyte array in your memory dump, you can read 336 00:15:42.360 --> 00:15:46.480 the binary and instantly know every single open port on 337 00:15:46.519 --> 00:15:49.279 the machine at the exact moment the RAM was captured. 338 00:15:49.639 --> 00:15:53.600 It's a perfect snapshot of the system's state. But I mean, 339 00:15:53.639 --> 00:15:55.279 a single bit just tells me if the door is 340 00:15:55.320 --> 00:15:57.440 open or closed. It is son to tell me who 341 00:15:57.480 --> 00:16:00.639 is walking through the door. Where's the actual data hiding? 342 00:16:00.679 --> 00:16:02.080 Where do I find the passwords? 343 00:16:02.159 --> 00:16:04.120 Well, for the juicy details, you really have to look 344 00:16:04.120 --> 00:16:06.440 at stacks and heaps. The stack is a region of 345 00:16:06.440 --> 00:16:08.600 memory used for temporary execution, like. 346 00:16:08.519 --> 00:16:10.639 When a program runs a specific function. 347 00:16:10.519 --> 00:16:14.440 Exactly like an encryption algorithm. It pushes a temporary stack 348 00:16:14.519 --> 00:16:17.879 frame into memory. This frame holds the local variables the 349 00:16:17.960 --> 00:16:20.919 parameters being passed in the return address. When the function 350 00:16:21.000 --> 00:16:23.879 finishes its job, that frame is popped off the stack. 351 00:16:24.320 --> 00:16:27.919 But popping it off doesn't actually erase the data, does it. 352 00:16:27.919 --> 00:16:30.399 It just tells the system, Hey, this space is available 353 00:16:30.440 --> 00:16:31.360 to be overwritten later. 354 00:16:31.519 --> 00:16:34.919 Exactly the data is still physically there. The ghost of 355 00:16:34.960 --> 00:16:36.840 the function is still sitting in RAM. 356 00:16:37.240 --> 00:16:37.799 Oh wow. 357 00:16:37.960 --> 00:16:40.240 Yeah. If you find a remnant stack frame in a 358 00:16:40.320 --> 00:16:44.240 memory dump, you might extract the exact encryption key the 359 00:16:44.279 --> 00:16:48.559 malware passed to a function milliseconds before the RAM was captured. 360 00:16:48.720 --> 00:16:52.399 Or maybe like pull out the raw, unencrypted text of 361 00:16:52.440 --> 00:16:55.320 a chat log that was hitting on the stack just 362 00:16:55.399 --> 00:16:57.679 before the malwar encrypted it to send it out over 363 00:16:57.679 --> 00:16:58.200 the network. 364 00:16:58.240 --> 00:16:59.200 You absolutely could. 365 00:16:59.279 --> 00:17:01.879 You are literally catching the malware with its pants down, 366 00:17:02.159 --> 00:17:03.679 right in the middle of a thought process. 367 00:17:03.879 --> 00:17:07.240 But stacks are temporary. What if the malware needs long 368 00:17:07.359 --> 00:17:10.839 term storage, Say it's scraping a massive database of user 369 00:17:10.880 --> 00:17:13.799 credentials and needs to hold them in memory for hours 370 00:17:13.839 --> 00:17:15.079 before exultrating them. 371 00:17:15.200 --> 00:17:17.920 That is where the heap comes in. Unlike the stack, 372 00:17:18.000 --> 00:17:21.400 which is highly structured and temporary, the heap is used 373 00:17:21.400 --> 00:17:25.240 for dynamic long term memory allocation. When a program needs 374 00:17:25.279 --> 00:17:28.839 a massive chunk of memory to store unpredictable amounts of data, 375 00:17:28.880 --> 00:17:32.559 like a growing list of stolen passwords, it asks the 376 00:17:32.599 --> 00:17:34.640 OS to carve out a space in the heap. 377 00:17:35.079 --> 00:17:38.880 The heap is messy, it's really fragmented, but it stays there. 378 00:17:39.000 --> 00:17:42.279 But the data stays there persistently, yes, until the program 379 00:17:42.319 --> 00:17:44.160 explicitly tells the OS to free it. 380 00:17:44.559 --> 00:17:47.680 So as an investigator, I'm scouring the heap for those 381 00:17:47.759 --> 00:17:51.200 large payloads. But whether I'm looking at the stack or 382 00:17:51.240 --> 00:17:54.599 the heap, I still need context. Like if I find 383 00:17:54.640 --> 00:17:57.119 an IP address floating in memory, how do I know 384 00:17:57.119 --> 00:17:59.480 if it's a malicious connection or just the user checking 385 00:17:59.519 --> 00:17:59.960 their email? 386 00:18:00.279 --> 00:18:03.279 That brings us to the final critical structure records or 387 00:18:03.319 --> 00:18:06.799 what developers call C structs. The core of most operating 388 00:18:06.839 --> 00:18:09.160 systems is written in the C programming language. 389 00:18:09.240 --> 00:18:10.759 Okay, C strucks right. In C. 390 00:18:11.079 --> 00:18:13.039 A struct is a way to group different types of 391 00:18:13.119 --> 00:18:16.680 data together under one logical umbrella. The perfect example is 392 00:18:16.759 --> 00:18:18.119 a network connection struck. 393 00:18:18.359 --> 00:18:21.119 So instead of a messy pile of data, it's highly organized, 394 00:18:21.119 --> 00:18:24.319 like a perfectly formatted ID card. For every single network 395 00:18:24.319 --> 00:18:25.599 connection precisely. 396 00:18:26.200 --> 00:18:28.920 This single IV card record might hold a two byte 397 00:18:28.920 --> 00:18:32.559 integer for an identification number, another two byte integer for 398 00:18:32.599 --> 00:18:35.599 the remote port, a four byte value for the IP address, 399 00:18:36.039 --> 00:18:39.480 and a thirty two character array for the remote host name. 400 00:18:39.599 --> 00:18:41.599 And because it's so structured. 401 00:18:41.319 --> 00:18:45.400