WEBVTT 1 00:00:00.160 --> 00:00:02.799 Welcome to the deep dive. This time we're putting on 2 00:00:02.839 --> 00:00:07.000 our digital detective hats and going on a deep dive 3 00:00:07.080 --> 00:00:10.439 into the world of malware analysis. Oh yeah, you've shared 4 00:00:10.480 --> 00:00:13.919 some sections from Packed Learning malware analysis, and frankly, some 5 00:00:14.000 --> 00:00:16.280 of this stuff is already blowing my mind right, but 6 00:00:16.359 --> 00:00:17.920 I know with your help, we're going to break down 7 00:00:17.920 --> 00:00:20.039 these crucial insights and techniques. 8 00:00:20.199 --> 00:00:23.399 Absolutely, it's like learning to think like the enemy, a 9 00:00:23.480 --> 00:00:27.280 digital enemy, that is. We'll uncover how malware operates, the 10 00:00:27.320 --> 00:00:31.600 strategies attackers employ, and most importantly, the tools and methods 11 00:00:31.600 --> 00:00:33.719 experts use to thwart their evil plans. 12 00:00:33.759 --> 00:00:37.159 Okay, so before we get into the super secret spy stuff, sure, 13 00:00:37.280 --> 00:00:40.439 let's start with the basics. Okay, what exactly is malware 14 00:00:40.920 --> 00:00:45.439 and why is analyzing it's so crucial? It seems like 15 00:00:45.560 --> 00:00:47.960 every other day there's a new headline about some data 16 00:00:48.000 --> 00:00:49.640 breach or ransomware attack. 17 00:00:49.840 --> 00:00:52.359 You're right, it's a constant battle out there. It is 18 00:00:52.679 --> 00:00:55.560 malware at its core, is any software designed to wreak 19 00:00:55.640 --> 00:01:02.719 havoc on computer systems or steel sensitive information versus worms, trojans, ransomware, 20 00:01:02.840 --> 00:01:06.959 all those digital bad guys. Analyzing it is like gathering intel. 21 00:01:07.319 --> 00:01:10.680 It helps us understand how it spreads, what it targets, 22 00:01:11.000 --> 00:01:12.799 and what kind of damage it can inflict. 23 00:01:12.920 --> 00:01:13.159 Right. 24 00:01:13.480 --> 00:01:16.640 This knowledge then arms cybersecurity professionals with the tools to 25 00:01:16.680 --> 00:01:20.560 fight back, like creating antivirus software and security patches. 26 00:01:20.799 --> 00:01:24.400 So it's like a digital arms race. Malware developers create 27 00:01:24.439 --> 00:01:28.159 new threats, yeah, exact. Security researchers develop new defenses exactly. 28 00:01:28.879 --> 00:01:32.480 But it's not just about protection, okay. Malware analysis also 29 00:01:32.519 --> 00:01:35.000 plays a crucial role in incident response. 30 00:01:35.239 --> 00:01:35.560 Okay. 31 00:01:35.640 --> 00:01:39.439 If a system's been compromised, it's like a digital autopsy. 32 00:01:40.359 --> 00:01:44.040 Analysts dissect the malware to piece together how it got in, 33 00:01:44.120 --> 00:01:46.680 what it did, and how to prevent it from happening again. 34 00:01:47.200 --> 00:01:50.400 It's like learning from our mistakes digitally speaking. 35 00:01:50.239 --> 00:01:53.840 Got it? So knowing your enemy is just as important 36 00:01:53.840 --> 00:01:57.359 in the digital world as it is in the real world. Yeah, Now, 37 00:01:57.480 --> 00:02:01.879 how do experts actually go about analyze these malicious programs? Well, 38 00:02:02.319 --> 00:02:06.840 the book mentions two main approaches, static and dynamic analysis. 39 00:02:06.920 --> 00:02:09.120 Yes, can you walk us through those absolutely? 40 00:02:09.520 --> 00:02:09.840 Okay. 41 00:02:09.840 --> 00:02:14.560 Static analysis is like examining a suspicious package without opening it. 42 00:02:14.759 --> 00:02:15.080 Okay. 43 00:02:15.120 --> 00:02:19.599 We look for clues on the outside, things like markings, labels, 44 00:02:19.919 --> 00:02:24.360 or even the weight to assess potential threats. Okay, in 45 00:02:24.400 --> 00:02:27.919 the digital world, it means examining the malwaar's code without 46 00:02:27.960 --> 00:02:28.919 actually running it. 47 00:02:29.039 --> 00:02:29.360 Got it. 48 00:02:30.000 --> 00:02:33.680 We're looking for red flags and indicators of compromise, so. 49 00:02:33.800 --> 00:02:36.840 We're basically looking for telltale signs that screen this is 50 00:02:36.879 --> 00:02:37.960 malware exactly. 51 00:02:38.400 --> 00:02:40.639 One of the first things we check is the file signature. 52 00:02:40.960 --> 00:02:43.199 This is a unique sequence of bites at the beginning 53 00:02:43.240 --> 00:02:47.719 of a file that identifies its type, like a digital fingerprint. 54 00:02:47.840 --> 00:02:48.199 I see. 55 00:02:48.520 --> 00:02:52.719 Malware often tries to disguise itself with misleading file extensions, 56 00:02:53.360 --> 00:02:57.159 like labeling an executable file as a harmless image, but 57 00:02:57.280 --> 00:02:59.719 checking the file signature lets us see through the disguise. 58 00:03:00.120 --> 00:03:03.680 Clever those malware developers. But it sounds like security researchers 59 00:03:03.719 --> 00:03:06.240 are one step ahead. Yeah, what are their techniques do 60 00:03:06.280 --> 00:03:07.680 they use in static analysis? 61 00:03:07.840 --> 00:03:11.599 Well, there's actual fingerprinting, which takes the digital fingerprint analogy 62 00:03:11.680 --> 00:03:12.319 even further. 63 00:03:12.560 --> 00:03:12.840 Okay. 64 00:03:13.159 --> 00:03:17.479 We use cryptographic hash functions like MD five or SAHA 65 00:03:17.520 --> 00:03:21.319 two five six to create a unique identifier for the 66 00:03:21.360 --> 00:03:25.000 malware based on its content. Ice This helps us track 67 00:03:25.080 --> 00:03:28.159 specific malware samples, even if they try to change their 68 00:03:28.240 --> 00:03:29.240 name or location. 69 00:03:29.479 --> 00:03:33.039 So it's like having a database of known malware fingerprints. 70 00:03:33.080 --> 00:03:33.560 Exactly. 71 00:03:33.680 --> 00:03:34.199 I see. 72 00:03:34.400 --> 00:03:37.439 We can also extrapt strings from the code. Okay, think 73 00:03:37.479 --> 00:03:40.240 of it like searching for clues in a ransom note. 74 00:03:41.039 --> 00:03:44.599 These strings might reveal website addresses, the malware connects to 75 00:03:44.680 --> 00:03:47.919 files that tries to access wo or even hidden functionality. 76 00:03:48.039 --> 00:03:48.400 Okay. 77 00:03:48.639 --> 00:03:52.159 There are even tools like flaws that can decode ob 78 00:03:52.199 --> 00:03:56.199 puscated strings, essentially secret messages hidden within the code. 79 00:03:56.280 --> 00:03:59.759 Ooh, secret messages. It's like we're cracking a code. Yeah. 80 00:04:00.080 --> 00:04:03.039 What about those packers that malware developers use to make 81 00:04:03.080 --> 00:04:05.680 their code harder to analyze? Yeah, I imagine it's like 82 00:04:05.840 --> 00:04:07.840 trying to read a book that's been shrink wrapped. 83 00:04:08.120 --> 00:04:12.159 That's a great analogy. Packers compress an obfuscate malware code, 84 00:04:12.280 --> 00:04:15.280 making it smaller and more difficult to analyze. But just 85 00:04:15.319 --> 00:04:17.399 like with shrink wrap, we have tools to unpack it. 86 00:04:17.800 --> 00:04:21.279 Packer detection tools can identify which packer was used, and 87 00:04:21.319 --> 00:04:25.120 then unpacking tools can reverse the process, revealing the original code. 88 00:04:25.240 --> 00:04:27.839 Okay, so we can get past those pesky packers. Yes, 89 00:04:27.879 --> 00:04:29.439 what about the pe header? 90 00:04:29.560 --> 00:04:29.879 Yes? 91 00:04:30.040 --> 00:04:32.600 Is that another area of interest for static analysis? 92 00:04:32.600 --> 00:04:36.000 Absolutely? The pehader is like the table of contents for 93 00:04:36.040 --> 00:04:40.199 a Windows executable file. It contains essential information about the 94 00:04:40.240 --> 00:04:45.480 program's structure, its dependencies, and even potential anomalies that might 95 00:04:45.519 --> 00:04:47.000 indicate malicious intent. 96 00:04:47.240 --> 00:04:47.519 Okay. 97 00:04:47.839 --> 00:04:50.279 Analyzing this header it can tell us a lot about 98 00:04:50.279 --> 00:04:53.399 how the malware is organized and what it might try 99 00:04:53.439 --> 00:04:53.680 to do. 100 00:04:54.000 --> 00:04:56.639 It's like getting a sneak peek at the malware's blueprint 101 00:04:56.639 --> 00:04:57.759 before we even try to run. 102 00:04:57.639 --> 00:05:02.040 It exactly okay, And speaking of organismation, analyzing the different 103 00:05:02.040 --> 00:05:06.560 sections within the executable is another key part of static analysis, Okay. 104 00:05:06.600 --> 00:05:10.040 I think of it like dissecting a frog and biology class. 105 00:05:10.319 --> 00:05:14.199 Each section has a specific purpose, either containing code to 106 00:05:14.240 --> 00:05:18.040 be executed or data to be used. Got it. By 107 00:05:18.079 --> 00:05:21.000 examining these sections, we can understand how the malware is 108 00:05:21.000 --> 00:05:23.920 structured and identify potential areas of interest. 109 00:05:24.160 --> 00:05:29.040 Fascinating. So static analysis gives us a pretty comprehensive understanding 110 00:05:29.319 --> 00:05:32.600 of the malware's anatomy and potential behavior. Yeah, but can 111 00:05:32.639 --> 00:05:36.240 we identify which family it belongs to? Just from static analysis? 112 00:05:37.199 --> 00:05:39.199 It seems like there must be tons of different malware 113 00:05:39.199 --> 00:05:39.879 strains out there. 114 00:05:39.920 --> 00:05:43.319 You're right, yeh. The malware world is vast and diverse, right, 115 00:05:43.439 --> 00:05:46.079 But we can use a technique called fuzzy hashing to 116 00:05:46.240 --> 00:05:50.560 identify similarities between different malware samples. Oh okay, it's like 117 00:05:50.600 --> 00:05:53.480 finding those long lost relatives in your family tree, but 118 00:05:53.560 --> 00:05:57.079 for malware. Interesting tools like steep can compare the fuzzy 119 00:05:57.120 --> 00:06:00.519 hashes of different samples and group them into family based 120 00:06:00.560 --> 00:06:02.439 on shared code or characteristics. 121 00:06:02.560 --> 00:06:05.439 So even if the malware tries to change its appearance 122 00:06:05.480 --> 00:06:08.519 slightly exactly, we can still link it to its nefarious 123 00:06:08.519 --> 00:06:09.720 family members exactly. 124 00:06:09.759 --> 00:06:13.680 Of course, there are limitations. Even closely related samples might 125 00:06:13.759 --> 00:06:17.920 have different hash values if they were compiled differently or 126 00:06:18.040 --> 00:06:22.560 slightly modified. But fuzzy hashing gives us a powerful tool 127 00:06:22.680 --> 00:06:25.879 for tracking malware and understanding its evolution sense. 128 00:06:26.000 --> 00:06:29.120 Yeah, and what about Yaiira rules? Ah, those were mentioned 129 00:06:29.120 --> 00:06:29.439 in the book. 130 00:06:29.720 --> 00:06:33.319 Our rules are a malware analyst's best friend. They're like 131 00:06:33.439 --> 00:06:37.399 custom made malware detectors. Think of it like creating a 132 00:06:37.439 --> 00:06:41.480 wanted poster for a specific type of malware. You define 133 00:06:41.480 --> 00:06:45.480 a set of rules based on unique characteristics like specific strings, 134 00:06:45.560 --> 00:06:48.959 bite patterns, or even file sizes. Okay, then you can 135 00:06:49.000 --> 00:06:52.600 scan files against these rules to quickly identify potential threats. 136 00:06:52.959 --> 00:06:55.680 So it's like having a personalized security guard for your 137 00:06:55.720 --> 00:06:59.759 system on the lookout for specific types of malware precisely. Wow. 138 00:07:00.000 --> 00:07:03.040 It helps automate threat detection and makes it much easier 139 00:07:03.079 --> 00:07:04.800 to find known malware families. 140 00:07:04.959 --> 00:07:05.120 Right. 141 00:07:05.519 --> 00:07:10.199 However, yrray rules do have limitations. If a malwaur author 142 00:07:10.319 --> 00:07:13.759 knows about a particular rule, they might modify their code 143 00:07:13.800 --> 00:07:16.839 to evade detection. It's a constant game of cat and mouse. 144 00:07:17.000 --> 00:07:20.040 So it's a constant battle of wits between the malware 145 00:07:20.120 --> 00:07:22.240 developers and the security researchers. 146 00:07:22.319 --> 00:07:24.600 Absolutely, it's one of the things that makes this field 147 00:07:24.639 --> 00:07:27.839 so challenging and exciting it is. But with tools like 148 00:07:27.959 --> 00:07:31.759 Yarra rules, we can stay one step ahead of those 149 00:07:31.839 --> 00:07:32.800 digital bad guys. 150 00:07:33.000 --> 00:07:37.319 Okay, so we've explored static analysis examining the malware without 151 00:07:37.399 --> 00:07:40.319 running it. Yes, now it's time to get our hands 152 00:07:40.360 --> 00:07:43.279 dirty and see this thing in action. Yeah, but before 153 00:07:43.319 --> 00:07:45.720 we unleash the beast, we need to talk about the 154 00:07:45.800 --> 00:07:50.079 lab environment. We don't want to accidentally unleash this malware 155 00:07:50.120 --> 00:07:50.639 on the world. 156 00:07:50.720 --> 00:07:55.199 You're absolutely right. Dynamic analysis involves actually running the malware, 157 00:07:55.639 --> 00:07:59.079 so we need a secure and isolated environment to contain 158 00:07:59.160 --> 00:08:00.480 it and observe its behavior. 159 00:08:00.639 --> 00:08:01.160 Makes sense. 160 00:08:01.439 --> 00:08:04.720 The book recommends a setup with multiple virtual machines. 161 00:08:04.839 --> 00:08:05.079 Okay. 162 00:08:05.399 --> 00:08:10.120 One Windows VM, completely isolated from the network, acts as 163 00:08:10.160 --> 00:08:12.399 our digital sandbox to run the malware. 164 00:08:12.519 --> 00:08:12.839 Got it. 165 00:08:13.160 --> 00:08:16.439 A separate Linux VM serves as a gateway to simulate 166 00:08:16.519 --> 00:08:21.160 Internet services, allowing us to analyze the malware's network communications 167 00:08:21.439 --> 00:08:23.439 without any risk to the outside world. 168 00:08:23.600 --> 00:08:25.720 So it's like setting up a digital Petri dish to 169 00:08:25.800 --> 00:08:28.800 observe the malwaar's behavior precisely. I like it. 170 00:08:28.879 --> 00:08:32.360 This controlled environment allows us to see what the malware 171 00:08:32.480 --> 00:08:36.240 does in real time and gather valuable insights into its 172 00:08:36.240 --> 00:08:37.759 capabilities and intentions. 173 00:08:37.960 --> 00:08:40.279 Okay, our digital lab is all set up. Yeah, we've 174 00:08:40.320 --> 00:08:42.879 got our safety goggles on and we're ready to release 175 00:08:42.919 --> 00:08:44.720 the malware. Okay, what happens next? 176 00:08:44.960 --> 00:08:47.720 First, we always start with a clean snapshot of our 177 00:08:47.799 --> 00:08:52.080 virtual machines, ensuring a pristine system for each analysis. 178 00:08:52.399 --> 00:08:52.799 Okay. 179 00:08:53.159 --> 00:08:56.720 Then before executing the malware, Yeah, we fire up our 180 00:08:56.759 --> 00:09:00.320 monitoring tools at it. These are like our surveillance cameras, right, 181 00:09:00.600 --> 00:09:03.600 capturing the malwares every move I see. We want to 182 00:09:03.639 --> 00:09:07.879 see what files it touches, what registry keys it modifies, 183 00:09:08.000 --> 00:09:09.639 and what processes it spawns. 184 00:09:09.759 --> 00:09:12.519 I'm picturing a whole team of digital detectives huddled around 185 00:09:12.519 --> 00:09:17.120 their screens. Yeah, monitoring the malwares every move. Right. What 186 00:09:17.279 --> 00:09:18.679 kind of tools are in their arsenal? 187 00:09:19.000 --> 00:09:21.759 We have a whole suite of powerful tools at our disposal. 188 00:09:22.360 --> 00:09:25.919 Process monitor is a personal favorite. It captures real time 189 00:09:25.960 --> 00:09:29.960 information about virtually everything the malware does on the system. Wow, 190 00:09:30.000 --> 00:09:32.799 giving us a detailed timeline of its actions. 191 00:09:33.519 --> 00:09:34.320 That's amazing. 192 00:09:34.399 --> 00:09:36.519 It's like having a security camera with X ray vision. 193 00:09:36.720 --> 00:09:40.720 Wow. That sounds incredibly comprehensive. It is, But I imagine 194 00:09:40.759 --> 00:09:44.279 sifting through all that data must be overwhelming. You're right, 195 00:09:44.519 --> 00:09:46.159 like trying to find a needle in a haystack. 196 00:09:46.279 --> 00:09:49.759 You're right. Process monitor can generate a lot of data. 197 00:09:49.879 --> 00:09:52.679 That's where a tool like norabin comes in. The Python 198 00:09:52.720 --> 00:09:57.360 script that works alongside process monitor, applying predefined filters to 199 00:09:57.440 --> 00:10:00.840 highlight the most suspicious events I see. It helps us 200 00:10:00.879 --> 00:10:03.200 separate the signal from the noise and focus on the 201 00:10:03.240 --> 00:10:04.360 malware's footprints. 202 00:10:04.639 --> 00:10:08.039 Love it like a digital magnifying glass. Yes, what other 203 00:10:08.159 --> 00:10:10.600 tools are in our digital detective kit? 204 00:10:11.039 --> 00:10:14.320 Process hacker is another essential tool. It lets us peek 205 00:10:14.320 --> 00:10:19.440 into the system's running processes, examine their attributes, and even 206 00:10:19.559 --> 00:10:21.120 terminate them if necessary. 207 00:10:21.240 --> 00:10:21.600 Got it. 208 00:10:21.600 --> 00:10:23.679 It's like having a direct line to the brain of 209 00:10:23.720 --> 00:10:24.759 the operating system. 210 00:10:25.039 --> 00:10:27.840 And what about the malwaar's attempts to communicate with the 211 00:10:27.879 --> 00:10:30.559 outside world. I imagine we need to keep a close 212 00:10:30.559 --> 00:10:31.840 eye on its network traffic. 213 00:10:31.960 --> 00:10:34.919 Absolutely, Wireshark is our go to tool for that. It 214 00:10:35.120 --> 00:10:38.879 captures packets traveling over the network, allowing us to dissect 215 00:10:38.919 --> 00:10:42.840 the malwar's communications in detail. We can see which servers 216 00:10:42.879 --> 00:10:46.240 it tries to connect to, what data it sends or receives, 217 00:10:46.639 --> 00:10:48.360 and even what protocols it uses. 218 00:10:48.480 --> 00:10:50.840 So even though we've isolated the malware in a virtual 219 00:10:50.960 --> 00:10:53.960 environment exactly, we can still see its attempts to phone 220 00:10:53.960 --> 00:10:55.120 home exactly. 221 00:10:55.279 --> 00:11:01.039 And to make that simulated environment even more realistic, we usetsim. 222 00:11:01.440 --> 00:11:05.279 It runs on our Linux VM and simulates various Internet 223 00:11:05.320 --> 00:11:10.840 services like web servers, DNS servers, and email servers. This way, 224 00:11:10.879 --> 00:11:14.120 the malware thinks it's communicating with the real world, but 225 00:11:14.200 --> 00:11:17.960 we can intercept and analyze its traffic safely within our lab. 226 00:11:18.200 --> 00:11:20.200 So it's like setting a chap and then watching the 227 00:11:20.240 --> 00:11:24.000 malware walk right into it exactly. Okay, our monitoring tools 228 00:11:24.000 --> 00:11:27.840 are running, the malware is executed we're gathering data. What 229 00:11:27.960 --> 00:11:28.720 happens next? 230 00:11:29.120 --> 00:11:32.080 We let the malware run for a specific period, depending 231 00:11:32.120 --> 00:11:35.279 on its nature and our goals. Then we stop the 232 00:11:35.360 --> 00:11:39.399 monitoring tools and begin the most exciting part, analyzing the results. 233 00:11:39.840 --> 00:11:43.679 We sift through the logs, reports, and captured network traffic, 234 00:11:44.240 --> 00:11:46.159 piecing together the malware story. 235 00:11:46.679 --> 00:11:49.919 It's like solving a digital puzzle. Yes, connecting the dots, 236 00:11:50.039 --> 00:11:52.320 finding patterns, and figuring out what it all means. 237 00:11:52.840 --> 00:11:58.720 Precisely. By correlating data from different tools, we can reconstruct 238 00:11:58.759 --> 00:12:03.759 the malware's actions, understand its goals okay, and identify potential 239 00:12:03.840 --> 00:12:07.360 vulnerabilities it exploits got it. For instance, if we see 240 00:12:07.600 --> 00:12:11.759 process monitor flagging, file system changes, and wire sharks showing 241 00:12:11.840 --> 00:12:15.039 data being sent to a specific server, we can infer 242 00:12:15.159 --> 00:12:17.600 that the malware is stealing information. 243 00:12:18.200 --> 00:12:21.679 Amazing, So we can track the malwares every move and 244 00:12:21.759 --> 00:12:26.039 piece together its modis exactly, but to understand them how 245 00:12:26.120 --> 00:12:29.120 it actually accomplishes these tasks, we need to go even 246 00:12:29.240 --> 00:12:31.799 deeper into the world of assembly code. 247 00:12:31.879 --> 00:12:33.840 You're absolutely right, Okay. 248 00:12:33.600 --> 00:12:36.320 I'm ready to level up our analysis skills. Okay, but 249 00:12:36.399 --> 00:12:39.360 before we dive into that world, maybe you can give 250 00:12:39.399 --> 00:12:42.440 me a crash course in assembly code and what it 251 00:12:42.480 --> 00:12:42.960 all means. 252 00:12:43.159 --> 00:12:45.759 Imagine you have a program written in a language like 253 00:12:45.919 --> 00:12:50.759 C plus plus, something that's relatively easy for humans to 254 00:12:50.799 --> 00:12:52.120 read and understand. 255 00:12:52.399 --> 00:12:54.879 Right, I vaguely remember something about that from my computer 256 00:12:54.919 --> 00:12:55.600 science dasee. 257 00:12:55.639 --> 00:12:59.480 Well, assembly language sits between those two extremes. Okay, it's 258 00:12:59.559 --> 00:13:04.240 a human readable representation of that machine code, using knemonics 259 00:13:04.360 --> 00:13:09.000 or short codes to represent different instructions. Disassemblers like IDA 260 00:13:09.159 --> 00:13:13.279 pro translate machine code back into this assembly language, making 261 00:13:13.279 --> 00:13:15.759 it easier for us to understand what the program is doing. 262 00:13:15.840 --> 00:13:18.519 So it's like translating a secret code into something we 263 00:13:18.559 --> 00:13:19.799 can decipher exactly. 264 00:13:20.000 --> 00:13:24.000 And then debuggers like by sixty forty BG allow us 265 00:13:24.039 --> 00:13:27.720 to step through the program's execution, one instruction at a time. 266 00:13:28.200 --> 00:13:31.799 We can watch how the data changes in memory, identify 267 00:13:31.840 --> 00:13:34.919 which functions are called, and even modify the program's behavior 268 00:13:35.000 --> 00:13:35.960 to see how it reacts. 269 00:13:36.039 --> 00:13:39.480 So we're like digital puppeteers controlling the malware's strings. 270 00:13:39.639 --> 00:13:41.600 That's one way to put it. I like it, But 271 00:13:41.759 --> 00:13:44.480 of course, to be effective puppeteers, we need to understand 272 00:13:44.519 --> 00:13:48.440 the language the malware speaks. A solid grasp of assembly 273 00:13:48.519 --> 00:13:52.879 language and the by eighty six architecture, the instruction set 274 00:13:52.960 --> 00:13:56.240 used by most processors is crucial for this type of analysis. 275 00:13:56.480 --> 00:14:00.360 It sounds challenging, but incredibly rewarding. It is learned how 276 00:14:00.399 --> 00:14:03.360 to analyze malware from a high level with static and 277 00:14:03.440 --> 00:14:06.000 dynamic analysis. Yes, and now we're ready to go deep 278 00:14:06.000 --> 00:14:08.840 into the code itself. We've unlocked a whole new level 279 00:14:08.960 --> 00:14:11.679 of malware analysis expertise. 280 00:14:11.279 --> 00:14:14.519 Exactly, and with these skills we can start to uncover 281 00:14:14.600 --> 00:14:18.320 the advanced techniques that malware authors use to evade detection 282 00:14:18.559 --> 00:14:21.399 and achieve their nefarious goals. We can learn how they 283 00:14:21.519 --> 00:14:25.519 hide themselves, yeah, spread to other systems, and steal sensitive information. 284 00:14:25.639 --> 00:14:26.000 Wow. 285 00:14:26.440 --> 00:14:29.600 It's a fascinating and constantly evolving field, it is. 286 00:14:29.799 --> 00:14:33.480 Yeah, welcome back to the deep dive. We're still neck 287 00:14:33.600 --> 00:14:36.080 deep in the world of malware analysis, and last time 288 00:14:36.159 --> 00:14:39.399 things got pretty intense. With static and dynamic analysis techniques, 289 00:14:39.840 --> 00:14:41.679 we even took a peek at the inner workings of 290 00:14:41.679 --> 00:14:43.960 malware through the lens of the assembly code. 291 00:14:44.159 --> 00:14:46.799 That's right. We laid a solid foundation for understanding how 292 00:14:46.799 --> 00:14:49.120 malware behaves and how experts analyze it. 293 00:14:49.240 --> 00:14:51.480 But today we're going even deeper into a realm that 294 00:14:51.639 --> 00:14:55.600 sounds straight out of a crime procedural memory forensics. 295 00:14:55.840 --> 00:14:58.759 It's exactly like a digital crime scene investigation, but instead 296 00:14:58.759 --> 00:15:01.879 of dusting for fingerprints, we're digging into a computer's RAM, 297 00:15:02.360 --> 00:15:05.240 that Voldel memory that holds the system's current state to 298 00:15:05.320 --> 00:15:07.159 find those crucial bits of evidence. 299 00:15:07.279 --> 00:15:09.440 So even if the malware tries to cover its tracks, 300 00:15:09.480 --> 00:15:13.440 erase files, or cleanup registry entries, we might still find 301 00:15:13.480 --> 00:15:16.039 its digital footprints and memory precisely. 302 00:15:17.000 --> 00:15:19.759 Think of it like finding a discarded cigarette butt or 303 00:15:19.759 --> 00:15:22.960 a muddy footprint at a crime scene. The culprint might 304 00:15:23.039 --> 00:15:25.799 have vanished, but they've left behind traces of their presence. 305 00:15:26.679 --> 00:15:30.399 Memory forensics helps us uncover these digital remnants and reconstruct 306 00:15:30.399 --> 00:15:31.000 what happened. 307 00:15:31.120 --> 00:15:34.240 Okay, that's a powerful image. So memory forensics is our 308 00:15:34.279 --> 00:15:37.519 secret weapon, our digital magnifying glass for catching those sneaky 309 00:15:37.519 --> 00:15:40.440 malware actors. But how do we actually get access to 310 00:15:40.480 --> 00:15:42.320 this memory. It's not like we could just crack open 311 00:15:42.320 --> 00:15:43.720 a computer and peer inside. 312 00:15:43.960 --> 00:15:46.879 You're right. Accessing RAM directly is tricky, but we can 313 00:15:46.919 --> 00:15:49.159 capture a snapshot of it a memory gump, at a 314 00:15:49.159 --> 00:15:52.360 specific moment in time. This dump is saved to a 315 00:15:52.399 --> 00:15:54.919 file on disc, which we can then analyze in detail. 316 00:15:55.120 --> 00:15:58.320 It's like freezing the crime scene and then meticulously examining 317 00:15:58.399 --> 00:15:59.240 every detail. 318 00:15:59.360 --> 00:16:02.960 But memory is volatile, right, meaning its contents disappear when 319 00:16:02.960 --> 00:16:05.240 the computer shuts down. So we need to act fast 320 00:16:05.240 --> 00:16:07.200 and use the right tools to capture this memory dump 321 00:16:07.200 --> 00:16:08.000 before it vanishes. 322 00:16:08.320 --> 00:16:11.840 Exactly. We need to be quick on the draw. Digitally speaking, 323 00:16:12.360 --> 00:16:14.679 The book mentions a tool called dump it, which is 324 00:16:14.759 --> 00:16:17.759 part of the Comy toolkit. It's incredibly easy to use. 325 00:16:17.840 --> 00:16:20.720 Run it with administrator privileges, and it'll create a memory 326 00:16:20.799 --> 00:16:23.360 dump file for you. It's like having a digital camera 327 00:16:23.440 --> 00:16:25.440 that can capture the state of the entire system in. 328 00:16:25.399 --> 00:16:28.840 An instant snapshot taken. Now, when we have this memory 329 00:16:28.919 --> 00:16:30.639 dumb file, what do we do with it? 330 00:16:31.000 --> 00:16:33.799 That's where the real fund begins the analysis. We use 331 00:16:33.799 --> 00:16:37.559 a powerful open source framework called volatility to extract all 332 00:16:37.600 --> 00:16:40.600 sorts of valuable information from these memory dumps. It's like 333 00:16:40.679 --> 00:16:43.720 having a Swiss Army knife for memory analysis. It's packed 334 00:16:43.720 --> 00:16:47.279 with plugins that allow us to examine processes, loaded modules, 335 00:16:47.320 --> 00:16:50.840 network connections, and even user activity all from that snapshot 336 00:16:50.879 --> 00:16:51.279 of ram. 337 00:16:51.399 --> 00:16:54.559 Wow, it sounds incredibly versatile. What kind of insights can 338 00:16:54.559 --> 00:16:57.039 we actually gain from this memory analysis? What are we 339 00:16:57.080 --> 00:16:57.559 looking for. 340 00:16:57.919 --> 00:16:59.600 Well, one of the first things we do is check 341 00:16:59.639 --> 00:17:01.879 which processes we're running at the time of the dump. 342 00:17:02.080 --> 00:17:04.640 Volatility has a plug in called slist that essentially gives 343 00:17:04.720 --> 00:17:07.000 us a task manager for the memory dump. We can 344 00:17:07.039 --> 00:17:10.359 see all the running processes, their process IDs, parent processes, 345 00:17:10.440 --> 00:17:11.880 the whole family tree. 346 00:17:11.640 --> 00:17:13.519 So we can see what was running, who started it, 347 00:17:13.559 --> 00:17:16.240 and when. But how does this help us identify malware? 348 00:17:16.759 --> 00:17:19.640 Often malware tries to hide in plain sight by mimicking 349 00:17:19.720 --> 00:17:23.160 legitimate processes. It might use a slightly altered name or 350 00:17:23.200 --> 00:17:26.359 masquerade as a system process. But with slist we can 351 00:17:26.440 --> 00:17:29.519 scrutinize the process lists and look for those subtle discrepancies 352 00:17:29.559 --> 00:17:31.319 that might betray a malicious actor. 353 00:17:31.599 --> 00:17:34.079 It's like spotting a counterfeit bill amongst the stack of 354 00:17:34.119 --> 00:17:37.680 real ones. You need a keen eye for detail exactly. 355 00:17:38.240 --> 00:17:40.640 The book actually gives a great example of this. In 356 00:17:40.680 --> 00:17:44.000 a memory image infected with the Presese malware. The slist 357 00:17:44.039 --> 00:17:49.240 output revealed two suspicious processes, svose dot ex and such 358 00:17:49.279 --> 00:17:50.119 chos dot ex. 359 00:17:50.400 --> 00:17:53.039 With those look almost identical to the legitimate sv cos 360 00:17:53.079 --> 00:17:56.319 dot exx process, which I know handles a bunch of 361 00:17:56.319 --> 00:17:59.359 system services. It's like they just added an extra dot precisely. 362 00:17:59.559 --> 00:18:01.759 That's a classic tactic for malware trying to blend in 363 00:18:01.799 --> 00:18:04.880 by mimicking the names of legitimate processes. But even a 364 00:18:04.880 --> 00:18:07.319 single extra character can be a dead giveaway for a 365 00:18:07.359 --> 00:18:07.839 trained eye. 366 00:18:08.200 --> 00:18:11.799 So SLISS helps us spot those subtle differences and identify 367 00:18:12.079 --> 00:18:15.240 potential malware lurking in the process list. But what if 368 00:18:15.240 --> 00:18:17.839 the malware is even more clever and tries to hide 369 00:18:17.880 --> 00:18:22.240 its processes altogether, like a digital ninja disappearing into the shadows. 370 00:18:22.960 --> 00:18:23.880 Can we still catch it? 371 00:18:23.960 --> 00:18:27.720 Absolutely? Attackers might use a technique called direct kernel object 372 00:18:27.799 --> 00:18:32.160 manipulation or DKM for short, to make their processes invisible 373 00:18:32.200 --> 00:18:33.839 to traditional detection methods. 374 00:18:34.160 --> 00:18:36.920 DKM that sounds serious, what's going on there? 375 00:18:37.440 --> 00:18:40.240 Imagine a puppet master controlling the strings of a puppet show. 376 00:18:40.559 --> 00:18:44.720 With DKM, malware can essentially manipulate the operating system's kernel 377 00:18:44.759 --> 00:18:47.519 its core to hide processes from view. It's like cutting 378 00:18:47.519 --> 00:18:50.079 the strings, so the puppet disappears from the stage, so it's. 379 00:18:49.960 --> 00:18:52.480 Like the malware is tampering with the operating system itself. 380 00:18:52.480 --> 00:18:55.200 That's some next level stuff. But if SLISS relies on 381 00:18:55.240 --> 00:18:57.920 the kernel to provide the process list, how can we 382 00:18:58.000 --> 00:19:00.640 find those hidden processes. Is it even possible? 383 00:19:00.920 --> 00:19:04.519 It is. Thankfully Volatility has another plug in called Scan. 384 00:19:05.440 --> 00:19:09.400 Unlike slist, Scan doesn't solely rely on the kernel's process list. 385 00:19:09.880 --> 00:19:12.960 It uses a technique called pool tag scanning, which is 386 00:19:13.000 --> 00:19:15.319 like having a bloodhound that can sniff out those hidden 387 00:19:15.359 --> 00:19:17.160 processes even if they've gone off the grid. 388 00:19:17.279 --> 00:19:20.480 Okay, I'm intrigued. How does this pool tag scanning work. 389 00:19:20.880 --> 00:19:24.880 The Windows kernel manages memory in chunks called pools. Think 390 00:19:24.880 --> 00:19:28.039 of them like containers for data, and each pool is 391 00:19:28.119 --> 00:19:31.319 tagged with a unique identifier, a pool tag like a 392 00:19:31.400 --> 00:19:35.440 label on a container. Certain kernel objects, including processes, are 393 00:19:35.480 --> 00:19:38.599 always allocated from pools with specific pool tags. 394 00:19:38.599 --> 00:19:40.519 So it's like knowing that all the bananas are stored 395 00:19:40.519 --> 00:19:42.759 in containers labeled B and all the apples are in 396 00:19:42.799 --> 00:19:43.960 containers labeled. 397 00:19:43.640 --> 00:19:46.640 A exactly, and scan can look for those containers with 398 00:19:46.720 --> 00:19:49.880 specific pool tags to find processes even if they've been 399 00:19:49.960 --> 00:19:53.240 unlinked from the main process list. It's like knowing where 400 00:19:53.240 --> 00:19:55.400 to look for the evidence, even if someone has tried 401 00:19:55.400 --> 00:19:55.839