LIVE: 🕵️ Memory Forensics | Blue Cape | Cybersecurity

today. Welcome back to another Wednesday TCM stream. I will be your host today. How's everyone doing today? How's everyone feeling? Hopefully better than me. I don't know if you can hear it, but I've been pretty sick since Friday. So, I'm getting better though. Getting over it. Looks like we have quite a few people in the chat. I started to do longer countdowns just so we get more people in um by the time the stream actually starts. See what do we have here? Zen Carter, welcome back. Another familiar face. Welcome to the stream. We have Glaciality. Welcome. quite a few folks that have come to other streams before. Always nice to see repeat viewers. What is this about? Uh we're going to be doing some memory forensics today, so we'll probably get into that shortly. Brit was abducted by aliens. Yeah. That checks out. Hello TCM. Hello to you my friend. Hello. Packet watchdog. Welcome. Mr. Edmonds. Oh no, you got sick too. Yep, I know how it feels. This weird intro music. Yeah, I should probably get some better tunes for the intros, but that was just one of the defaults. I like Tyler Ramsby's streams. He usually has some rap music playing during his intros. Uh, which tool are we going to use today? Yes, good question. We're going to use volatility, one of my favorite memory forensic tools. I think we've done uh done a few other boxes in the past in previous live streams, but this one in particular, um, I guess I'll just um introduce what we're going to be doing today. This actually comes from the practical Windows forensics course uh over at BlueCape. Um a nice uh friend of TCM, Marcus Shelber, um who used to have the PWF course on the TCM Academy, but um you can now find it on Blue Cape Security. Um he was kind enough to give me access to the course cuz um there's some interesting labs uh that you can take in the course and I thought doing a memory forensics one would be nice to showcase on a stream. So, um, I'll never say no to a memory image to dissect. It's always fun. Um, usually a good time. Um, so that's what we're going to be doing today. I think it'll be a nice little walk through. So, we'll get into that momentarily while I catch up on the questions here. It's a little bit distracting. Um, how do I do this? There we go. Yes, today is forensics. Like every other Wednesday I'm on here, it seems. Yeah, I never like that EDM music that Alex always played. Just so loud. Especially for you where it's probably like the morning, right? At least here it's like noon, so it's a good wake up. No, I couldn't stand that song. Just finished your two courses. A great experience. Thanks a lot. Oh, that's awesome to hear. I'm glad you enjoyed them. I assume hopefully you're talking about the security operations courses. Uh if you're talking about other TCM courses, I'm sure they were fantastic as well. Um but no, that's awesome to hear. Blue team, yes. Yeah, that's what we're doing. Oo, that's a good um a slight introduction on autopsy one day. Yeah, that's a good idea. I think um maybe the next time I'll stream I'll try to find a Sherlock that's like a deeper like investigation where we get a memory image and um we could use autopsy for that. I'll write that down so I don't forget. I'll try to do that next stream.

We got Digital Andrew in the chat. Welcome. We're actually going to be streaming. Yeah, I guess I can say we're going to be streaming next week as well. Um uh Digital Andrew and I, Mr. Bellini. So, um stay tuned for next Wednesday as well. I'm looking forward to that. We have some fun stuff uh in the pipeline that we'll be able to talk about next week. Almost finishing the PAP. Nice. Congrats. Hope you enjoyed it. Uh if you take the exam, best of luck on it. Um I'm sure you will find much success if you've enjoyed the course. Uh when can we expect a new TCM forensics course? I don't have a date. Sorry. Um but what we're going to be doing is um I really want to go into sort of deep dive forensics on a bunch of different topics. So um we won't be able to release that as like one main release. So, what we're going to do is probably similar to how we did uh or how Alex did the expert level um web course uh where it was sort of like a drip release where um you would sort of have these standalone smaller courses uh as individual modules. So, I think we're going to go that way and sort of modularize it because um I don't think it can fit into one sort of monolithic course like the sock courses. Um I think what I really want to do is focus on um an individual um you know area of forensics. uh for example registry forensics that could be uh you know an entire 5 to 10 hours on its own um and so that'll probably be considered its own course but sort of in um uh an overarching sort of Windows forensics pathway um I think is the goal and so uh we'll be doing that as sort of a drip release throughout the year um and I think uh we're aiming for the end of March for at least our first kind of drip um which will be um a new kind of way that we can deliver more frequent um courses and more frequent labs and training, which I think will be super cool. Yeah, if you didn't catch Bellini's latest video last Friday, was last Friday. Yeah, last Friday. Um I thought that was super cool. He shows off uh kind of I guess you'd call it a vulnerability in pretty much any cheap uh kind of IoT camera. um and actually demonstrates how you could sort of patch in your own malicious code uh into the um uh sort of the chip there. So, it's super cool video, very nicely uh demonstrated and unlike me, he was able to condense it so it's not like a 45minute video. So, um I need to take some tips from him. Oh, Glacial Ali, that's awesome. You started your sock 2011. I hope you enjoy the class. Um, that's super exciting and best of luck on the PAT. I look forward to hearing your thoughts. Um, speaking of which, just in general for anyone interested, we do have um a live training coming up uh near the end of March. It's going to be March 23rd to 25th. one of our instructors is going to be doing the sock level 2 live class. So, if you are interested, uh I'm sure Brit will drop a link at some point throughout the chat um to get more details on uh some of our live training offerings. Yes, Matt Brown does uh awesome videos on IoT. Um he's collaborated with Mr. Bellini as well. So, another great friend of the channel. Um, so definitely check out Matt Brown. All right, let us open up our screen share again. Um, just because I know at some point I'm going to lose my ability to talk because that's how it's been since Friday. Um, with whatever cold I have going on. I thought it was strep throat, but apparently not. something viral. Um, so let's just sort of introduce what we're going to be doing here today. Um, again, this comes from the practical Windows Forensics uh course over on Blue Cape, which was recently uh retired from the academy, sadly, but uh if you do want to take the course, again, it's offered on BlueCape. Um, you know, Marcus is a great instructor. he's put together some awesome labs which um specifically the uh memory forensics one kind of section of the course kind of caught my eye and I thought um you know there's a good there's a nice little um memory image that we could take a look at least introduce volatility maybe some um uh different plugins that we could use sort of the I guess my general process um when it comes to memory forensics so we'll keep it uh relatively um simple today um as much as we can you know doing memory forensics but uh I think

overall all it'll be a nice sort of introduction. Um but I don't want to showcase too much of the course or anything. Um they do have individual labs too over at um uh Blue Cape. So maybe future streams will be able to do some of those. Marcus was super grateful and gave me access. So uh so with this essentially the course has you creating your own artifacts. you essentially um run an attack script which implements a ton of different hostbased artifacts on your system and then you go ahead and triage and uh sort of acquire the memory, the disk image, the triage image. Um and so you get to work with all those artifacts that you just created um throughout the course, which I thought was a really cool way of going through it. And one of the artifacts um is the memory capture, right? is one of the first things you typically want to do uh when you come across um you know a computer of interest, right? Uh whether it be in a compromise scenario or you know um something like a traditional uh you know legal or criminal sort of case like a um insider threat, you know, whatever it is. Um typically you don't want to lose your volatile evidence, right? So that's really the first thing you do is acquire memory um before you do anything else, right? You don't pull the plug. uh you need to get your hands on memory because oftent times if you don't um there's so much um on systems that you lose and you uh unless you get lucky with something like a page file or a hybrid file uh or volume shadow copies but um you know typically if we're thinking about memory uh you know page filer or hibernation files are pretty much your only other option if you don't capture memory um and there's certain things in memory that uh a disk image is never going to have right um active processes is active network connections. Um you know a ton of uh of information that you can only get through uh memory analysis and acquisition. And so um what we have here is uh where is it? We have our Windows 10 memory capture. File. We also have the hash which is always a good idea to make sure we have that integrity. But if I were to run uh you know a hashing algorithm over this file um it's pretty large, right? So it'll probably take a long time to get those results. But with that uh we can start to dig in uh to this memory file um which was uh provided for us in the VM. Uh and so we can go through sort of the general process of um you know figure out metadata about the memory capture, making sure we're working with the right capture. Uh we can start listing out processes, network connections. Uh we can dig into the registry if we want to. Uh we can start dumping out files. uh we can look at you know all the different web browser activity um going on in a memory file right there's so much we could do uh and there's so many questions that can only be answered by looking at a memory capture so that's sort of the general introduction as to why we're doing this here right um and sadly it's a little bit difficult right which is why we kind of need to have specialized tools like volatility or uh meroc FS is a really cool one uh because now when we think about um like disk based evidence, right? Um we sort of have a nice hierarchy, right? We have folders, we have files. Uh if we're taking a triage image, right, we can pick out specific files like uh the master file table that we want to look at, you know, specific artifacts. We don't really have that luxury uh when we're working with memory, right? It's just sort of the way the memory structures and the data, the way it's presented um uh you know, it's not really how memory works, right? So we need things like volatility that can parse through a memory capture and give us options through plugins to actually extract the information that we need. Um there is a tool that I mentioned called merock fs. I'm not sure if it's um included in this course VM or if it's covered. Um it might be uh but it's another uh fantastic memory tool that sort of aims to do that um sort of uh taking the memory structures uh out of the memory and sort of putting it into a directory-l like structure which is uh super cool like visually um that makes our analysis feel a lot more at home. Um but in this case I want to use volatility again it's sort of the most common tool out there um sort of open source uh very common uh for this kind of thing. And so, uh, what I typically like to do, um, you know, with anytime I go into memory analysis is, um, you know, a standard kind of not checklist, but like a standard thing, um, that I typically like to check. I like to list out the processes, right? Uh, look at network connections. Uh, maybe we're tying processes over to network connections. uh maybe we're looking for specific indicators uh in the form of like IP addresses or port numbers uh you know different connections uh and their associated processes. Um right on the process side we can get the process ids which we can then use to sort of correlate. Uh we can actually pull out

images or we can dump out processes if we want to. Uh we can look at the parent child relationships. Um uh things like the command line invocations of those processes. And so there's a ton that we can dig into. Um, again, I mentioned it earlier. We can look at registry hives and different keys that we can dump out uh or we can dump out individual files as well. And so, Volatility gives us a ton of plugins to do exactly that. And so, I have Volatility already installed on this VM. So, if I just call V with the help option there, it's going to list out basically uh everything we might want to do uh specifically on our Windows capture here. So the way it works is um again volatility is multiplatform and so we can run different Mac related uh plugins different Linux related plugins for example PS list here uh or uh we have a ton of different Windows plugins that we can run and so this is sort of the syntax we need to call the operating system that we're targeting uh and then we usually have this different uh directory structure of plugins right so we have under privileges here we have the priv plugin um or uh we have things like PS tree right or PS scan PS list very common uh when we're dealing with processes. And so first thing I usually like to run just to sort of get my bearings is um Windows. info or you know uh depending on what you're working with Linux. info, Mac. info basically um to kind of enumerate or pull back um metadata about our capture itself. Right? Uh in volatility 2, this is volatility 3, fortunately the latest and greatest. Um, but back in two, we had to use the image info plugin. Um, uh, and it was really important to do so because we had to extract things like the operating system version, the profile, um, uh, in order for us to, uh, figure out what platform we need to target with our plugins. Um, but this has sort of been uh a different approach in Volatility 3. And so what I can do here is run um the f argument here to provide our image, right? The file. So, it's going to be winint 10 uh memory. And I'm just going to call windows. info. And this is going to parse as we can see here uh what are called symbol tables. We can see this is sort of um a local symbol table that has been downloaded on this VM. And the idea uh is that this is kind of the map that um tells us where or tells volatility where the different um kernel and memory structures are, right? And how everything is sort of laid out in memory. Uh because each version of the operating system is going to have its own kind of layout essentially, right? And so volatility needs to know uh where do I go, right? How do I format uh this memory image to find and pull out what you need? Um right, where are the um things like the e-process structures or uh what offsets do I need to know about? Um and again, this kind of used to be a pain in Volatility 2 because we had to figure out uh the platform and provide that with every command. Um but Volatility 3 is fortunately a little bit smarter and we can feed it in those symbol tables. Um again either locally or if we had internet access it can go out uh and actually fetch those from the repository. So very cool. But uh again very simple here. All we get are things like the uh for example the major and minor version of the operating system. Right? So we could just Google this. Um I don't think this VM has internet access but we could Google that sort of uh this number here and say what Windows version is this and it'll tell us sort of the major and minor version. Sort of break it down. Uh we can see the system route right? So where is the Windows directory located? Uh we can see the system time of when this capture was taken. uh the product version. So we can see Windows 10, right? Um so a ton of different uh nice to sort of get our bearings here before we start digging into things like processes. Um and so actually it's usually a good idea just to save this over to a file, right? So I'll just call this info. txt just so I can reference it and not have to run volatility each time. And so now if I run cat info, there we go. We have our information nice and saved here for us. Yeah, it's a lot of options and volatility. Um, lot of plugins. Um, let me pull up the chat here. I have three monitors, but apparently it's not enough for me to multitask well enough. Yeah. how to install Ubuntu safe. Um, if you take most of our courses, there's usually a guide on installing Ubuntu, but um, you're on YouTube, right? So, put that into the search bar on YouTube and you'll find a ton of, uh, videos on how to do that. Fortunately, it's not too complex depending on what hypervisor you're using.

All right, so uh, we sort of haven't done much analysis yet, right? we've just sort of listed out I would say just metadata about our capture. So let's start digging into uh probably the most exciting artifact in a memory capture which are the processes right there's generally two different ways uh to enumerate things like processes or uh network connections uh different things in volatility there's generally two approaches um so we have sort of the list approach uh and also the scan approach um and so for example if I were to run this again instead of windows info. Uh I could run pslist um to sort of as the name suggests list out the processes just like running a ps command on a live system for example, right? Or task list uh or get-process in PowerShell. Um and what that's going to do is sort of walk through uh the active process list in the capture and sort of show us what the running processes were at the time of capture, right? Uh, but we also have PS scan, which I don't think I'm going to run because I think it's going to take a lot longer. Uh, sometimes volatility just um uh really likes to take its time, especially during some of the scan plugins. Um, but that's it's sort of going to take a different approach and scan for different e-rocess objects or structures in the memory and it can try to find processes that have been unlin, right, or terminated or uh more or less hidden from when we just run a PS scan, right? And so it can be a more verbose way of listing out processes or older processes. Um you know a lot of time we think about memory and RAM right we think about currently what is currently happening uh an active snapshot but we can actually get some historical information in RAM as well um with a lot of caveats right uh and we can do that by looking at unlin or um terminated processes as well using something like PS scan but anyways I'm just going to run PS list here um to just sort of again look at that um uh that VAD tree and sort of list out uh what is sort of noted as actively running. All right. What I should do also is save that out to a file just so I can start to maybe use GP and cut this up if I wanted to. Um, but what we're really doing here is we can see in the columns at the top very similar to just running like a task list in Windows, right? So we're getting things like the process ID, uh the parent process ID, right? So we can start to make sense of uh some of these um parent child relationships, right? So we can see what is spawning which there's an easier way to do that which we'll get to in a second. We can see the image file name, right? So the binary um we can see things like the offset in memory, right? So what is the location of where this was found? We can see things like the threads, the handles, the session ID. uh you see this Windows on Windows 64 here telling us if it's a 64-bit uh process or 32-bit process um creation time, exit time, right? So we can get even some time stamp information as well. So we get a ton of information just from running ps list. Uh but obviously we're just seeing a list of processes here, right? So uh unless we see something named like malware. exe, right? or something uh very obvious. Uh if we see references maybe to PowerShell being spawned from Winword, right? So if we're looking for those sort of behavioral uh anomalies, right? Um and we can see Sysmon was running at the time of capture. Uh here's PowerShell, right? So we can see um it was spawned by 5684. And I'm sure if we look through this or do a GP, we can figure out what spawned PowerShell. Um we can see uh atomic service. That's interesting. Um actually I think this is part of that install script that you go through in the course right so you're running atomic red team right so this is one of the binaries that get executed we can see notepad was running uh and a bunch of like service host processes and so that's one way to do it right we can start to go down the list again we can save that out to a file I'll just call that pslistex just so we get a copy of that and we can start to g out uh for whatever we want right so if I grap out ps list. Uh we found that PowerShell was spawned by uh 5684. And so what I can do is GP 5684 against that and we can see explore. exe was the parent there, right? So GP nicely highlights that for us. Um so we can see it spawned security health that sort of system tray. We can see the virtual box tray, one drive, um but it also spawned PowerShell, right? So this is the process ID of PowerShell. So I can also maybe search for that to see if it spawned anything. Right? So kind of walking through this manually, we can see container host was spawned, which is quite common if you spawn something like cmd or

powershell. But again, I keep saying there's an easier way to do this of course. Uh and that's by using PS tree. So if you've sort of done um you know live response on a Linux operating system, for example, you might be familiar with PS3. It's sort of the exact same concept here. uh just doing so through volatility. Um, interestingly on a Windows memory image, right? So, what I'll do is just change our plugin here to PS3. Save that out to PS3. txt. Just give this one a moment. Usually takes a bit longer because we're going to see it includes a lot more interesting uh fields for us to take a look at. There we go. Uh, is this ethical hacking? No, it's uh kind of the opposite. Maybe not. That would be unethical hacking. What I mean is this is sort of the defense side of things. So, we're doing ethical uh forensics, I guess you could say. Maybe the system was ethically hacked and now we're ethically uh analyzing it. The number of monitors you need is always n plus one. That's the truest thing I've seen this week. All right. So, I'm going to uh type out our PS3 uh output here. And it's going to be a little bit hard to follow, especially in the command line, unfortunately. Um what I might be able to do more commonly is open this up in Notepad, um or whatever sort of text editor we have on the system. Um, so let me see. Should be under cases here. Uh, whoops. Yeah, we're in the mount directory. So, where's that going to be? Uh, cases. There we go. So, we have pslist uh psree. ext. can open it up in believe there's VS Code on here just to make it a little bit easier to read. So, let that open up. You want to hack NASA and Facebook? You are not on the right channel for that, unfortunately. All right, we'll get just give this a second to go here. Um, but as that loads, I can sort of maybe try to explain what we're looking at here, even though again it is kind of a mess in the command line, especially zoomed in like this. But you can see we have these long lines here and some of them have these different asterisks here. So this is telling us sort of the hierarchy or um uh sort of the relationship between processes. And so uh we can see this one has two here this two little stars um search indexer. And we can see this one under here has three indicating that sort of the relationship of what was being spawned by which right? Um and so again it is kind of hard when we're just scrolling through like this. But for example, here's a good example. We can see the system process of four, right? Um is spawning these different system processes, right? And so a lot of this is just normal system activity. Uh typically we want to look at uh focus our analysis early on in sort of the user land side, usually near the bottom where we get these higher process IDs. Um but that's just sort of a general low hanging fruit kind of thing. There we go. That looks a little bit better because it's not sort of being word wrapped. So, let me try to zoom in. And so, let's try to find that PowerShell example again just to sort of um graphically uh showcase it a little bit better. Uh there we go. Whoops. Zoomed out. And so, we can see explore. exe. And as we scroll through, we get a lot more information, right? So we can even see um uh the sort of volume that it's sort of found on and also the location uh the full path to the binary that was um executing the process right so we can see windows explore. exe exe right it look looks good looks normal here uh as we go down we can see we have um sort of two here because it was spawned by user nit and then we have again the box tray one drive uh it looks like we have powershell here right so the powershell process was spawned from again the common location of powershell

uh what else do we have here so we have notepad down at the bottom and why is it at the bottom It looks like it's kind of an orphan process, right? It has a parent ID, parent process ID, but I don't think this is going to be found in the file, right? So, it's just listed here, but it's not actually existing, right? So, whatever spawn notepad. exe has since exited uh or just didn't exist, right? So, um, it doesn't have that asterisk that we would expect, uh, indicating that it was spawned, um, you know, from something in the list, which is interesting. Um, so it's kind of an orphan process, you call it, right? So, I kind of want to know how this spawned now. Um, right, cuz typically it would be spawn if it's Notepad, uh, it would be going through Explorer, right? Or maybe the command line, right? So, you could you can open up Notepad from PowerShell if you wanted to, for example. Uh, but just seeing it on its own is a little bit interesting to me. Uh what we can do is look at where it was spawned from. It looks like it is in fact Whoops. Uh the legitimate Notepad binary, right? Or at least it's executing from the legitimate location. Uh but there's a ton more that we can look into in processes to uh sort of uh corroborate that fact, right? Um what was the other one? Oh, that atomic service we can look at too. Let me try to find that. There we go. Uh, we can see it was spawned from 624. And we can see a bunch of these service hosts here also spawned by 624. So I'm assuming 624 here is going to be services. exe. Um, let me try to find that. That's probably going to be way up here. Yep, there we go. So services. exe. We just see a ton of different service host processes, right? The sort of um service container on Windows systems that sort of execute and manage services on the system. And typically services there are a lot of different services running on a system, right? So that's why we see so many different service host processes. Um another common kind of uh target for malware, right? If you can get a process running uh as service host or um you know make it look like it's service host, right? you might not um you might not notice it as an analyst just because you're sort of inundated by so many different service host processes. Um but if we have the command line, which we do, we should see that um they all should have the K argument here pointing to um a service group, right? So again, that's one of those lowhanging indicators um that would indicate that hey, maybe this is not a legitimate service host process. I think we've done a different box in the past where that was sort of the finding, right? Um there was a masquerading service host process that didn't have the K argument which was a nice giveaway uh that we want to dig into it further. All right. So again, I am a little bit suspicious on the notepad process. It is executing from the right place. But as we can see here, how do we know that the binary hasn't been replaced or um maybe injected into? Right? So that's what we're going to continue looking at as we uh sort of have now narrowed our focus on this notepad process. All right. So let me clear this out. What we can do now um for example uh we can also look at um actually let's just grab the command lines of those processes right so this is another way that we could quickly sort of enumerate that uh and then we'll look at um sort of the modules to see if anything has been injected into that process and so uh instead of pst we can run something like uh windows docomandline if we run the help page here we should be able to narrow it down to specific PIDs or process ids, right? And so, uh, the ones we're interested in, again, I'm just I'm picking on that PowerShell process, uh, also the atomic, uh, service process. So, let me grab, uh, 6988. We also want Notepad, so 6552 and then 6572. Whoops. So, we can just put those in um, in sequential order there. So it'll grab the command lines from all three of those. So 6988, 6572, um, and then 6552. All right. And again, we can just see uh the full command lines now of where those were executing from. And so again, that's another way um that we could see uh for example

looks like this PowerShell process was part of that atomic red team um sort of atomic right that simulation that was being run. Uh specifically the atomic service here we can see where that service binary is running from. Looks like it's found under T1543, right? So we can even see a miter id here. Again, this is sort of a simulation um uh kind of action here to create the artifacts. And so we can see the specific atomic that was run. Um and again we can see notepad here. All right. So let's dump out that uh that process there, right? That notepad process. And so what we could do is run volatility again. And instead of Windows command line, we could run Oh, looks like we have Mr. Blue Cape himself here. Welcome to the stream. Yeah, we're having some fun going through this uh Windows 10 memory image here. I'm a little bit suspicious of this notepad process and so we're going to keep digging into it. All right. And so again, we could dump out um the process itself right out of memory, which is super cool. And then we can use whatever kind of disk analysis capabilities we have, right? Um so that's one way we can sort of reach into our memory capture and pull out things that we need. Um and so to do that and we just sort of need to highlight um the process ID that we want. And so we can provide the PID there and we can also provide the dump option as well. And so again this 6552 we can target that and then I can provide dump here. All right. And there we go. And this is going to pull out um again we can see the file here that was saved. We're going to see the process ID. name of the process uh the memory offset. And also it's going to save that as a DMP file. Um, if I were to run file against this file that we pulled out, we can see it's a PE or portable 32 executable, right? Uh, and so we can start to make some sense of the file headers there. Uh, you know, if we really wanted to, we could start running things like strings against the file um, and start to do some static analysis. We're not going to get into all this, right? Uh, we could grab the hash value of the file as it was executing in memory, right? So we can run shop 256 sum against uh the hash there and that could be another indicator um uh that we can look at. Uh it's a little bit we have to be a bit careful with pulling hashes out of uh actively running processes in memory uh because as sort of the different modules kind of open up as the process is executing that can change the hash. So we don't always have the exact same static hash as we would as the binary the file on disk, right? Um, but again, what I would typically do is send this over to a reverse engineer, right? Someone much smarter than me to dig into this file. Um, another thing as we're sort of thinking about how this is an orphan process and it's a little bit suspicious here. Uh, it is running from the right directory, but maybe we're suspicious that um maybe some of the code was injected, right? Or maybe a module was injected. Um, we have a ton of different options and volatil volatility to look at that, right? Someone I think someone mentioned um uh let me try to find it. Someone mentioned process hollowing um right process injection. Volatility has a ton of great uh plugins that we can use to really start to surface that information to us um and take away a lot of the manual pain of looking at um uh you know some really low-level indicators, right? And so malind is a good example. Uh what we're going to run here is uh DLL list for example um to pull out uh the listing of the DLL modules loaded into the process. Right? So that can be a nice um highle way to list out what uh modules are running with the process. And so for example what we could do is run Windows uh DL list. If I just run the help option here, uh we can see it's going to list out the loaded DLS in a particular Windows memory image and we can provide it a specific process ID, right? And so we can even dump them out, right? Which we'll do if we find something interesting. And so again, I'm going to call the same process ID here of 6552. Actually, what I should do, I should have saved that out to a file. But anyways, we can sort of make sense of this. Actually, no. I'm gonna rerun that. Cool.

Then let me open this up. All right. So now we have a list of all those loaded DLs for that notepad process, right? We can see the uh the sort of location, right? The path of where uh they were loaded from. And so we see a lot of uh you know, for the most part expected kind of runtime modules, right? We have NDLL, um, kernel 32, right? Kernel base, um, you know, a ton of, uh, standard processes here. Uh, but let me try to zoom out a little bit. I know there's a just a ton of text on screen, which is not always fun for people to watch on stream, but near bottom here, we can see a suspicious looking DLL, right? Um, obviously we're running an atomic uh, simulation here, so the indicators are going to be very obvious, right? Right, we can see the exact uh miter ID here. I'm pretty sure this is DLL injection as a technique. Let me just look this up. Um yeah, process injection, right? Uh so that's exactly what's sort of being created here and we can see the path of where it was executing from right and so we saw this directory earlier when we were looking at that atomic service process and so again operating from sort of the same location and we can see the exact DL that was loaded and so what we can do uh why is it suspicious because this is not a standard DL that notepad. exe exe uh is going to import, right? We can see like again the standard kind of Windows uh system kind of DLS at the top here. Uh we can see different libraries that Notepad or a tool like Notepad would want to import, right? We can see text input framework. Uh we can look this up and see what exactly it does. But again, if we see something that's being pulled in from a non-system 32 location, right, in this case, it's coming from uh this atomic red team folder, which again is super obvious in this context because if you know what atomic red team is, you know it's sort of an attack simulation uh framework, right? Um but if we again if we see something from maybe a temp location or just a suspicious loca location, yeah, someone said if you spot the miter tags, it's very obvious in this case, right? Um, but again, it's just not something that would normally be uh executing from uh or normally be loaded into Notepad. exe, right? Um, if we wanted to do more of like a baseline comparison, we could open up a clean sort of sandbox machine, right? A Windows system, open up Notepad and grab the same artifacts, right? We could look at the DLL list from a known clean Notepad process and just compare the results, right? Um, and we would eventually find that, hey, there's been an additional DLL loaded into this uh suspicious one. And so now we've sort of found that we can also dump out the DLL from memory too, right? So again, volatility is a lifesaver here. Um, really makes our lives easier. I think we just run the dump option here as well as the name, right? So we want to do grab specifically uh we can specify some reax here to match a DL name. Right? So we can just use that uh um what's it called? Yeah, we can just use that MITER ID here um to limit our result, right? Just so we pull out the one. And so make sure we have the process ID. Uh the name here I'm just going to call T1 Whoops. 1055. DLL. Wait, no. I think it's 001 dl. Yeah, just copy and paste that and then just the dump option there. Uh, are you using cmd on Kali Linux? No, this is not Kali Linux. This is a uh Windows analyst machine which um again is part of the practical Windows forensics course. Um so you get sort of this nice browserbased VM uh which is a Windows VM but it has um the Windows subsystem for Linux installed right and so I have an Ubuntu prompt here um that's running on Windows but through uh WSL. Yeah, there you go. So that's WSL under Windows. It's a lot easier to run volatility on a Linux system, I find. Um, so what do we Yeah, so we got that dump file there. We can see similar to the process, it's going to give us the PID, uh, the name of the DL and sort of the offset there as a dump file. And so again, just like with the file itself, I can run um, Whoops, let me extend my time here. That would

be helpful. I can run file on that. We can see again it's a DLL file, right, that's being loaded in. Uh we can see for example, again, we could run strings on it, but we're not going to get into um uh static malware analysis or reverse engineering on this stream. I would just send this to someone much smarter to me than me to look into this. Right? But again, even just running something like strings, we might be able to pull out some interesting uh information here. Right? We can see a reference to a repository here and we see a PDB file. U but again this is just pulling out user readable uh kind of um comments or strings or variable names that are found in the compiled uh DLL. Right? So again not always a silver bullet uh on its own but it might be able to give us some slight indicators but we see a bunch of gibberish here right um in this case. Uh but again we could also um run like a hashing algorithm right so MD5 sum against uh that same file and again same kind of caution as before um we have to be careful about hashes that we're pulling out of memory uh just because again it's they can be very volatile right it's it we might not always get a one to one um as the file on disk um but I have to do that let me copy this this on a separate screen. Um, just so I can run virus total here and then I'll paste the results into here. There we go. And so if I do look up that hash on virus total, make sure that is sharing. There we go. Uh, it actually we do get some hits interestingly enough. So this um DLL, this specific one uh must have been uploaded at some point because we do get uh the different hashes and we can see that at least two vendors flagged as malicious. But again, if we were to see everything as undetected here, that wouldn't be too far out of the norm. Um even if this were a really malicious file um because again uh we can't always trust the static hashes that we're getting out of memory. But that is interesting that it was caught at least by two vendors. All right. And so we did find some evidence here of DLL injection, right? We found the Notepad process which was running as an orphan process. Interestingly, um, and when we zoomed into that and started to pull out uh or list out the DLS, we did find a suspicious one here. Uh, which again in this case, fortunately, Whoops. That's my timer to uh remind myself, but the platform did it for me. There you go. So, um yeah, again, in this case, fortunately, it's not actually malicious. This is just a an atomic red team simulation, but it is legitimate um you know, actual DL injection going on here, which is interesting. Uh so, I did want to end off talking about registry as well. um because there's another example that you can go through in the course which I think is a really good example of um looking at registry uh in memory captures as well and I think someone mentioned fileless malware before um this is a good uh sort of example of that we can find too and so amazingly you know with volatility we can also uh interrogate the registry and different registry hives and values and keys um because the registry is kind of always loaded into active memory when the system's running right so um those registry hives, right? Those hive files uh on disk kind of open up on a live system uh into what we commonly see on a live system as like HKLM or HQ local machine, HQ current user uh and etc. Right? And so we can use um the print key uh plugin here. So let me go back and back this out. We can run Windows. print key. Actually, I think it's Windows. registry. Sometimes you have to go two layers deep um to find your plugin. Otherwise, it'll yell at you. Yeah, there you go. So, that's what that MITER ID is referring to, right? And so, in a real investigation, you're not going to see malware named as um MITER IDs, right? Uh but if you're running an attack simulation script or framework like Atomic Red Team, um that's why they do this is so you know if you're hunting for this um you know sort of you found the needle in the haststack, right? You you understand what technique is being simulated here um and what mitigations and detections you can do uh from the defensive side, right? And so super cool actually.

Uh, is there a big difference between volatility 2 and three in terms of commands? There actually kind of is. Um, fortunately, most of, you know, the breadandut kind of things, your PS lists, right? You're listing out processes, network connections, registry stuff. A lot of that carried over. um I would say the most common kind of uh plugins, but there were um you know some really rare kind of super useful plugins on Volatility 2 that just haven't been ported over just because um it can be a little bit of an effort um just because the way it's been rearchitected. Um you can't just sort of onetoone uh copy over a plugin. You sort of have to rewrite it for Volatility 3. Um, and even though it's been out for a little bit now, um, not every plugin, uh, has been moved over. But again, there are also new plugins that have been written for Volatility 3 that you can't find on two. And so, uh, what I've actually found, you know, even currently recently, um, is is, uh, running both versions on the same sort of analyst machine just for those cases where you really need to run something from two that you can't run in three or vice versa. And so, um, but yeah, it is an open source project, right? So if you find something that you really want moved over um and if you understand the tool and what it's doing, you could write your own plugin, right? So or you can contribute and and help move things over and and um again contribute to the project, which I think is super cool. Yes, that's yeah, we're going to do uh some of the real investigations from the labs here. Um, I just figured this would be kind of a nice stream to sort of walk through um some of the different plugins and introduce volatility and then we can start to dig in um to some of the real labs in uh in Blue Capes Labs uh because they do have um some super cool um scenarios that you can do. Right. This is just um sort of walking through in my own way some of the some of what's uh shown in the course um with some of the course artifacts, but there's also a whole section where um you have labs like individual scenarios. So I think that's what we'll do. Um but just to end it off on registry again, we can print out keys here. And so um we can also list out um the hives too, right? So we can run hive list um to actually list out uh you know hey what red tree hives can we start to dig into or interrogate on the system and specifically um one that we could look at here and I'm just jumping a little bit ahead just to uh make sure the stream doesn't go too long but um I'm going to look for the userclass. dat that file uh for in this case your user that you sort of set up all the artifacts for is called ie user. Um and so this is one uh that we can pull out here. Uh the user class uhdat files specifically for this user. Uh someone said does volatility have a module for netstat? Yes, it does. Um and so you can just like with ps list and pscan um you have uh netstat is the name of the module. You also have net scan as well um to really sort of um if you want to be more verbose and maybe look at um previously terminated or uh inactive connections as well. And so um just like with processes, you can also do the same with network connections. All right. And so we're going to target this userclass. dat file because again someone mentioned fileless malware before. Um there's a good example in this registry hive that we can look at. Um we can try to do it in two different ways. we'll do it um in memory and we can also look at registry explorer really quickly cuz um I think there's also a really cool way that we could find it quicker um with registry explorer uh again that would assume we have access to the registry hive uh in our triage collection which fortunately we do. Um, and so, uh, what we can do is look at the offset here for this specific hive. And then we can, um, specifically print keys from, in this case, userclass. dat. So, I'll just grab this here. What I'll do is run, uh, print key. Again, I'm going to provide the well, let me just run help here to see the options. I'm going to provide offset here of the hive itself. And so, I'll just paste that in. And the key that we want to pull here is just called atomic red team. Right? And I'm just doing this to showcase uh the value here as an example. Obviously, there would be no way for you to know this unless um you know, again, go through the course. It's really uh fun course. So let's let's hope that this works here. Yeah, there we And so now we're pulling out the value uh of this key here, this atomic red team key, which is found in that userclass. dative. And we can see we have um a key called art or atomic red team. And the value here looks very suspicious, right? I think a ton of you are going to recognize what we're looking at here. You

might not know what it uh decodes to, but you can probably recognize the encoding method used, which is probably the most common form of again fileless uh malware in the registry. Um we're going to see these suspicious long B 64 strings. Um it's kind of a very common uh you can say malware execution technique. Um often a persistence technique. Um, and again, sometimes you'll see this referred to as fileless malware because it's generally going to be executed in a way where you don't have a malicious script saved or mapped to somewhere on disk, right? It's sort of encoded and hidden in the registry like this. Uh, it can then be sort of executed from memory in PowerShell, for example, or called in different ways. Um but again I kind of have some qualms with that fileless malware term when it's used in this context just because again the registry at the end of the day is still on disk right uh but anyways uh it's still a very common technique that um I think is a good demonstration in this example as well right where we can find uh directly from a memory capture which is super cool so if I copy this here um if I open up cyershe might be able to decode Let make sure I grab that. There we go. Yes. Is it space 64? You are correct. Right. Um and even if we didn't know, I mean it is once you've seen enough B 64, you can tell by the padding at the end, right? The equal sign and just the character set in use. Um I think if we run magic here, it'll tell us uh yeah, so it's telling us, you know, this is probably base 64, right? Um and it'll even decode it for us. So um if I drag over from B 64 we can see it is running some PowerShell right. So uh this sort of encoded uh registry value here uh decodes to this right. So fortunately again not actually malicious in this case. It's just uh giving us a little hello message here. But the way it could execute is kind of in that fileless kind of in memory kind of way. Right? you could run uh ex and point it over to this value here, right? And it'll execute. And so super cool. Um the other reason I want to show this is because I think this is going to work. Um we can also look at uh a hunting technique uh for this exact kind of thing. Um and to do that, we're going to step out of memory for a second and we can look at the registry itself. And so, uh, the tool of choice in my opinion is going to always be registry explorer, which should be on this system. Uh, let me go into full screen. I might have to dig for it. Uh oh, it's going to be here. Yeah, under easy tools. Um, let's go to Registry Explorer and just open this up quickly. I want to I'm pretty sure this is going to work. There's a nice little uh find capability in registry explorer that uh Eric Zimmerman has put in um which really makes finding uh these fileless malware kind of techniques uh quite trivial um believe it or not. So, um, let me just wait for this to load for a second. See if we have any questions in the chat. Yeah, can't really let go of volatility, too. Yeah, at least not yet. Hey. Yeah, I'm glad you could catch the stream as well. Um, like I said, we're going to be streaming next Wednesday, too. Uh, Mr. Bellini and myself. So, um, be sure to, uh, stick around next week if you want to chat some more. All right. So, we have registry explorer um, open up here, right? And so if we didn't know what to search for, again there are some common um you know persistence keys in the registry like the run keys, the run ones keys um that we usually um can pretty quickly um navigate through um uh also uh which can be found in the local machine or in the current user. Um again there some of the lowhanging fruit there. But what if we really wanted to hunt for those suspicious B 64 strings like that anywhere in a registry, right? Um, and so what we can do here is open up um the userclass. dative for that IE user, which we should be able to find in the triage collection. Um, which going to be under here

I'm pretty sure. Yep. And so again, if you go through the course, you're actually going to go through the acquisition process, right? That triage acquisition. Uh, and you're going to pull out, you know, those different registry hives, which uh we really want to dig into when we're doing registry forensics, right? Um, and so if I go under users here, we can always find the userclass. dat file under the users's app data. Uh, specifically under local and then Microsoft um, and then Windows. And we see here we have userclass. dat. We'll open that up there uh, in registry explorer. And then assuming this works, this is going to be very quick, right? So I'm going to go under tools here to find. And it's a little bit just the way the tool is, it's a little bit zoomed out. So hopefully you can see here. Um but this is an extremely useful way to hunt for strings anywhere in the registry, right? Uh we can use reax, we can use we can hunt for the key names, value data, the value names, even value slack. Um so a ton of different um uh ways to pull back information. We can even set up time stamps for the last write times uh of those keys themselves. U but we also have this little trick here called B 64 in values. And all we need to do here is just click on search. And it's going to look at based on the default length here of 50 characters. It's going to pull back any instances of there being a base 64 string of 50 characters or more. And you can see when we ran that, we immediately found uh what we're looking for, right? So if I double click on that, it takes us right to this location uh under atomic red team. We can see the art value here and the data of that value, which is that B 64 string. we go data interpreter here. We can even sort of decode that from base 64. Again, I know this is super tiny. U but that's a way we sort of could have uh hunted for that very quickly as you can see. And so super cool. Um I think that was a nice kind of look at doing some memory forensics, even a little bit of registry forensics as well. Um and all in all, uh I did not do the course justice. So, uh, definitely if you're going through the PD PWF course on BlueCape, um, there's a whole memory um, forensics section which um, you're going to go through similar artifacts and look at the memory image and really um, start to dig through um, all the different things you can find after an attack has occurred. And so, um, again, I really want to thank Marcus for giving me access to the course. It's super cool. And also the labs, too, which we can hopefully do on some future streams. So, that was a lot of fun. Uh, let me return to the chat and we can wind down the stream for today. All righty. Let me look at some of the pin questions here and get caught up. Cool. Yeah, thank you. Um, I'm trying to think. Um, I believe yes, in the the live the sock uh level one live training, we do have some volatility labs in there. Um, but uh this lab from today was over on Blue Cape. So, uh, if you do want to see more of that, um, uh, again, there are some labs you can check out there. Uh, Hack the Box has a few volatility labs that I know about. Uh, Try Hackne probably does as well. Um, I'm trying to think like all the the blue team kind of training lab um, places typically have at least one or two uh, memory forensics investigations you can do. Uh, if you go back on the stream, I know we've done some before. Uh if you just search for volatility or memory forensics on our live stream page, you should find some more uh examples of that as well. Yes, we yeah, we could have uh dug into the network connections as well. Uh that's something that we didn't do, but um again, if we want to start to correlate processes with um active network connections, that's a great way we can do it as well. All right. Oh, good question here. Does a PowerShell process count as suspicious? I mean, not really on its own. Um, it always depends on the context, right? So what user uh you know what user account um and that's another plugin we could have run is um get user SIDS is we can see what user accounts and privileges are running certain processes. Um so we can see if it's running as

in an administrator context we can see the user account that executed it. Um but again if it's um you know an accountant running PowerShell that's a little bit you know it' be a little bit more suspicious than maybe an IT or a help desk user. Um but also we can look at the behavior as well, right? The context around it. Uh what spawned this PowerShell process, right? Um was it a Microsoft Word document that spawned PowerShell, right? Maybe through some kind of macro. That would be a lot more suspicious than um again it is hard to say because it depends on the user as well as the context around it. You can also see what other uh processes PowerShell has spawned, right? Does it have any children? Yeah. So that yeah, that was that fileless malware question. So um hopefully you saw a good example of that where we had some B 64 in the registry. Um which was technically um at least from the definitions I've seen is referred to as fileless malware. Um but again you didn't see that in uh in the PS3 output, right? We didn't see that in our processes um because it probably because it wasn't actively executing. But we did see the string itself uh was set to run PowerShell, right? So um we would see PowerShell being run if it were executed or uh whatever kind of um whatever kind of process it was calling that script. All right. Well, I think I'm going to go drink some honey and try to fix my voice before next Wednesday at least so we can stream again. But thank you so much everyone. Um again, thank you to Blue Cape as well for providing the labs. That was super fun. Uh we'll definitely do some more in the future. And so hope you have a great rest of your week. Um, and again, I will see you next Wednesday with Bellini and myself uh to talk about um yeah, maybe I'll say we're going to do a fun CTF uh and we're going to talk about um what's up and coming for TCM. So, thank you everyone. Have a great rest of your