Now that we've got going on with the memory forensics and you got your hands wet with extracting an image from a lab Machine. We also looked at how to use volatility to scan the memory image, to tell us what the operating system is and all that good stuff. Now we're just going to dive a little bit deeper into it and look at some of the really extremely useful plugins for volatility. Of course I do encourage you to dig into some of these on your own. Maybe one day even get to the point that you're writing some. Let's move on and get right into it. We're back at our Kali desktop here or a Kali terminal. We're going to just be going through some of the really good volatility plug-ins that we are able to utilize in the event that we have to use these on a case or something like that. What this one of the first things that we are going to look at is some of the basics here. Now, this profile that we established in the previous session of this Machine,. One of the first things that we talked about was using the PS list. What that does for you is it shows you a list of running processes at the time of the memory dom. Even if there was something, perhaps hiding them, we can still see the running processes here. We can see a command dot EXE. We can see a notepad, we can see Chrome IE running there. A bunch of SPC host which is to be expected, services dot EXE and just a few other running processes there that we're able to see. Another thing that we're able to see is if we run PS3, we can run the plugin PS3. We can actually not only see the running processes but now we can see which processes are running as children of other processes. For example, if we take a look at this instance of command ID EXE, we can see that it's running as a child of Notepad on EXE. Now that right there should already be of concern to you because that instance of Notepad dot EXE is running as a child of Internet Explorer or in this case Edge. Then that version or that of Internet Explorer is running as a child of another version. Just off the top of my head, just off the bat here. If I see that command dot EXE, for example, is running as any iteration or any level of child, grandchild, great grandchild relationship to the browser. I know that's a problem because generally we don't have our browsers invoking command dot EXE for legitimate purposes. The fact that that's going on there causes me some concern to say the least. PS3 is the only thing that shows that to you because I want you to again look at the comparison here. Look at the difference. When we actually run it. As PS list it's easy as look at this and say, well, these are all legitimate processes. Command dot EXE. There's another one. These are legitimate one of those processes, there's nothing bad there. The case here, you can't really say that because again, when we look at PS3 it becomes apparent that that command dot EXE is running in a context as a great grandchild. It appears of one of I Explorer that makes me concerned that there may be something else going on here. Now, when we look at command dot EXE, one of the things that you probably want to consider is trying to figure out if there's a raw command that EXE process running. Maybe we should look and try to see what commands were ran with that command dot EXE instance or a command that EXE instance. One way to do that in volatility is we can invoke what's called the command skin plugin. I'm going to remove PS3 and do command scan there. This stuff right here is a little interesting. Usually when I see that I know that there's been something we're going to look at what's happening here. We can see a few commands that was entered by command on EXE. These were all entered by command dot EXE that has appeared or actually from Com Host would appear of the three 4.3.2. Now this other stuff here was entered from command on EXE with this period of 3968. That all looks like this because what it ends up being is that's our mask. Let's go look and see what period 3968 is. We go back because a lot of this is just going back and forth. So we can see the one that's a child of Internet Explorer is 2232 There's a 3424 right there, and then there is a 3968 conhost that we're looking at as well. That's what makes it interesting because you can counter again see the relationship. Now we know that there were some clear ran command that you will see, but with another instance of it, there were some commands that may not have been clear. Now another volatility plug-in and we'd like to use when we're looking at this type of stuff is console's. If we want run console's, here's the primary difference. When you look at or when you run command scheme, what you see is just commands that were entered. When you run console's, you see not only the command that was entered, but you also see the results of that command being entered. For example, if we go to the top it is, we can see that someone entered the command. Let's go down here. This FTP Command, but not only that, we see what showed up on the screen as well. We can see that they connected it to this server here. Log-in with Infosec, pulls some files down. Again, did a directory listing maybe, there's ls command that was run, to do a directory listing. We could see these commands that were entered from that machine. Keep in mind all these commands, when I showed you how to go over and get the memory dump tool, those commands will run way before we actually did the dot. It keeps in memory command history for a set amount of time. We can also see someone pinging Facebook there. We can see it resolving to that internal IP, which is a similar pattern that we saw earlier. We can also see, if we look at the ARP cache. We can see that someone ran ARP. We can also see that in the resulting ARP, there appear to be like some type of ARP poisoning or man in the middle going on because you have two different IPs in the ARP cache, with the same MAC address. Now this is something if you went to that machine now and looked at the ARP cache, if they stop the attack, you wouldn't see that, but the value of being able to pull a memory DOM and see what was going on with the state of the ARP cache, network connections, all that stuff at that time, is pretty invaluable. This is why we always stress the fact that when you go into a situation and you're not sure, if the machines compromised or not. The safest statement usually do is to make sure you get a memory DOM first. We always talk about following the order of volatility. That's because this state that we've captured here, if you go back an hour from now, you will never see that this connection existed, or you may not or might not ever see that this connection existed, or that we had a duplicate arbitry, or duplicate Mac address in the ARP cache. These are things that if you don't look at this stuff ahead of time, you would never see it. Now another thing that we want to look at here, let's check this out. Now we're gone back and remember a lot of memory forensics is going back and forth, looking at things. Remember when we want the PS3, we saw that command.exe, the one that at least gave us the most concern was a child of notepad, which was a child of iexplore.exe. That's browser. Now we see that the browser in this case was Edge or Internet Explorer. We actually have a volatility plugin called iehistory, that allows us to look at Internet Explorer history. We can see, what this person tried to visit or what they were listening at the time of this compromise, to see how they might have gotten infected, if it was indeed something that happened via the browser. As you can see, that's all they're actually, here's an instance of where they went to that location. You can see all these other locations. There's a login to local machine there. There's a Facebook login, that someone did right there, or they tried to go to Facebook, there's Wireshark download. You can see all of the history here, and there's another visit to Facebook, and of course the cool thing is you do get the date and timestamps here, of when these things were accessed Some other things that we'll get as well, as we can see that all of this history and stuff, a lot of it was associated with very specific processes which gives us some information that trace back from Internet Explorer to go back and see what was going on. The next thing that I want to show you is since we know that there was certain commands line, we know that Internet Explorer was involved in this. Now we want to maybe take a look and see what types of connections there are. In other words, were there any network connections or Internet connections to anything at the time of the actual breech. Now, with that being said, there's actually a volatility plugin called Netscan. If we go ahead and do a netscan, what it shows us is you were able to go to the machine and run netstat. We're looking at it as if we were physically at the machine and we ran a netstat in there. What's interesting there, as you can see, not only listening sockets, but of course you can see connections as well, and you can see the process that spawned that connection. Now here is clearly a TCP connection on port 3333, which is strange and it's established connection, and it's spawned by Internet Explorer. I would be willing to bet you that over that connection right there is probably related to the command data exe section that we see associated with Internet Explorer. Now we don't know that for sure, but that's what we're doing is we've gone through and trying to figure some of these things out. Now some other interesting ones that we might look at. There's one called shellbags, and there's also a hashdump. Let's look at the hashdump first. Now this may or may not be useful in an investigation. What it actually gives you is a dump of all the hashes. These are local hashes, these are the main hashes the only way they'd be Active Directory hashes as if this machine were a domain controller. You'll see that it will dump all the local hashes with force. When we say hashes, we mean the password hashes associated with the users that are on this actual machine now. One of the others that I like to look at is shimcache because it shows application access history and that type thing. If an application was accessed, it'll show up in here. Even if the application is no longer on the system, it still shows up as an entry in the history in shimcache. That is extremely useful as well and we can see it. For example, we can see this and the cool thing is you see the date timestamps all the way back to then, up to the latest or the most recent accesses there. Some of these are more of a concern than others, here's a setup.exe that may be of a little bit of concern here. That was pretty recently. There are several others that you might find that was of concern to you, this power off command or exe that was running there. Some of these others, like the whole iframe. All of these are things that you might consider problems. If you find that there is a process that is concerting to you. You can run a command that we're going to look at later to pool their process actually out of memory. You can take the actual process and take it out of memory. There's a whole lot of what looks like sysadmin or a security researcher tools that appear to be running here. Again, this goes all the way back historically. Another one, there is a shellbags and the thing you have to be careful with shellbags is it's not accessible to all profiles and not accessible to all operating systems. We'll just let it run here. You can clearly see commands and things like that that were run. You can go back and trace it to when it happened, what user ran it, and figure out what they were trying to do at the time based on what you see in there. The shell bags information may be useful as well when you're trying to look at. It's really not like it has anything to do with the demand line. It's basically a group of registry keys that show you certain information about applications behavior. The cool thing is you can't get massive information like the modified access, and create a timer information from these. What I want to do is, if we found a process, let's go back and look at PS list here. If we found that one of these processes concerned this, or we wanted to see what was going on with that process. If there is anything bad with it, what we could do is we could adopt that process. For example, take this notepad instance here, that's got a pit of 544. What we could do is we could use process dump. Let me show you how that works. We want to dump a process, we're going to put it in tmp. The process that we want to dump has got to be pit 544. If we tell volatility to do that, it actually dumps it. The actual process, it carves out of memory even read in its full functioning state and puts it in the location that we told it. In that case that was tmp. If we look in tmp, you can see that that 544 executable, which is no pad there. Just like I showed you earlier with Wireshark, we can take that thing, put it into a lab machine and run it and see what it actually does. Now, in my case, what I'm going to do is take it and put it on virus total. Again, don't do this on a real network in a real case. This keeps me from having to jump through a bunch of Virtual Machines. It allows you to just see it here on one screen. We'll see what Virus Total has to say about that version of notepad. You might be surprised to find that Virus Total can't find something malicious in everything that you'd think maybe it should. All right, so we're going to go and get that bad boy, it's under tmp and the step 544 executable. We'll go ahead and open that up in Virus Total. We'll see what Virus Total has to say about it. Now, most of these are saying that it's okay. What it is, I can tell you it's because we use a good copy of Notepad and we back-doored to with something and that's why all of these are saying that that Notepad instances is okay. The main thing I wanted to show you is that we could take a process out of memory, completely reconstructed just by doing that and it actually works. Like you can actually run it. It's a runnable and executable binary at that point. That's another useful thing about that plug-in that makes it very, very useful. Now what we're going to do is we will continue on with this and look at some more things to get you going with volatility. Because as you can clearly see, there is a lot of usefulness to it and it sets you up to be able to a lot of things that we weren't able to do to from just looking at traffic. Because at the end of the day we are looking at it on the system itself. We're looking at it in a place where things are rarely able to be hidden, we're looking at it directly in memory. There's definitely some more advanced stuff we can get into, such as looking at memory offsets in all that kind of thing. This is where we want to stop It, and want you to really focus on mastering this skill. Getting volatility up and running, being able to pass of memory down with it before we worry about trying to get super, super advanced with it. The main things we want you to be able to utilize a tool. We will stop there for this section and looking forward to seeing you in the next one.
