All right everybody, welcome back. Thanks again for tuning in, this is our second technical deep dive as far as a live investigation goes. We're looking at a live ongoing incident here. The scenario is basically that we've been called in to assist, we got to the organization and we were like, what do you got? They were like, "Oh, we don't know, we just noted that data on these servers should only exist on the servers and we know that they've ended up somewhere else. We don't have any alerts, we don't have any IVS alerts or anything like that." That's telling us but we just know that there's got to be something on these machines. So they don't have any traffic captures or anything like that to help us with. I wanted to put this one together in this way to let you see what it's like when you get there and there's nothing, like you have to really capture and figure out everything. Another thing I want to point out too is in this scenario, they didn't really detect anything. We're starting off in detection generally when you come in as a third party, the detections have already been done and you're just helping out. But in this case, they haven't really detected anything they kind of have, because they know that data is somewhere that it shouldn't be, but they haven't detected anything in the network on the suspects' systems. We're doing like a hybrid joint thing here and that's really how it is in a real-world. You're not always going to go into these incidents and you're going to be able to follow those phases like a piece of paper, it doesn't work that way. Sometimes you're mixing in with them, they've already done some detection. They've got some data, you use that in this case they've got nothing. Let's go ahead and jump right into this system and see what we got. We don't really know anything yet, we don't really have anything. First thing I'm going to do is a couple of rules that I told you about. Number one is we always want to follow the order volatility, we talked about that. I'm going to quickly do a memory dump to see what's currently in memory. We got our same memory tool, the MRC tool, I'm going to go ahead and run it. Say yes, I want to accept it. I'm going to tell it to go ahead and dump the memory dump, we can just put it right on the desktop. We're going to call this Livehack.raw, and we'll start that dump. Its finished, it put it right there. The next thing is we got that dump, I'm going to go ahead and push it somewhere remote so that, if we need to we can utilize it. We are on the desktop here. Another reason I might also be doing this is maybe I've got a team that's going to go ahead and start analyzing this memory dump while I'm doing my other stuff here, so I'm pushing that memory dump off to an external driver, to a network location, whatever the case may be. Now we're confident that we've captured the memory in the state that it is right now. You really don't want to mess this up because you can't go back from that, you never have a time. There's no way to go back to that point in time if you don't do it in that point in time. Now we've captured a memory dump right here, we know that based on what they're saying they think they may be compromised. If there is a live thing here, if you notice the first thing I did, the first thing was build a memory dump. Now if I didn't have a memory dump tool along here, the first thing I do is put that memory dump tool on and dump that memory. That way, whatever the attackers going to cover their tracks, they probably would have not had enough time specifically to get all the stuff on a memory. Follow that order volatility, we did the memory dump. Now I'm going to run a few commands here, these are just one of those commands. There's like a list of things that I always do. One is immediately get a dump of whatever's running, and task manager would task list. We're just going to write that to file. I also look at netstat to see listening ports, and we're going to write that to the same file. I'm just going to append it. I'll also usually go ahead and do an arp dump, I want to see the arp cast to see who is communicating with most recently. I will also go ahead and do a SC query, because I want to see running processes and it's able services and things like that. We're going to put that there. Then lastly, I'll also do a system info because I want to see patch level and all that good stuff as well to see if I happen to be missing anything. We're starting off the investigation here or did detection because we haven't detected anything. We don't have any alerts, they don't have any alerts. We don't have any traffic. They told us they didn't have any traffic files to show us. We're starting that it's seen if we can detect anything and going ahead and collecting any evidence that we might need right away. Now, the next thing I'm going to do before I invoke anymore services, anymore resources to this because it could be a false call is, I'm going to go ahead and push this live hack file over as well. I got both the Romney readout and the results of me running all these commands, I've got that all in one file over on this other machine. Now, the next thing is, we got that. Let's go ahead and take a look. I'm going to look in Task Manager just to see what I've see. Everything looks pretty good there, and nothing weird going on. Command Data EXE and there's a little. That's a little weird. I don't know what our command is. But we'll deal with that later. It's probably some company process. I'll go ahead and look at next part and see if there's any weird listing Sockets or anything like that. No, everything appears to be okay. There, these are normal Window services on these Ports here. That's not anything uncoordinated. All of that stuff looks okay. If we look at the Desktop, there's nothing really weird on the Desktop here, on all these Folders look normal. So far we don't really have anything yet. Now, let's go ahead and see if we can start getting anywhere as far as finding out what's going on with the System. One of the first things that we want to do is, we're going to go now to my Kali and I'm going to pull down those Files. We're going to go to our LiveBreachCase Folder here. I'm going to pull down both those Files of memory dump and the other one. Let's get the memory dump first because it's the biggest. I swear I always get so happy when I make mistakes because I'm hoping that students would be like, "I look at the [inaudible]." I know I'm okay if I jacket it up. I just did the same thing again. Now, we've got both the Text File, which is the results of running the process list and looking at netstat. We have, in addition to that, the ROM memory dump. Now, I'm going to use that information and we're going to start off with volatility. We're going to start off looking at the memory dump first and see if we can just get it to give us a PS list. Let's go ahead and do that. I'm going to run volatility. We're going to give it the File of the [inaudible]. I'm going to give it the profile and see if we can get a PS. Lists action going here because if we can get that to run in mostly PS list because mostly if we can get that to run in, everything else should run okay for us. We did get PS list to run just fine. What it did is, it gave us the list of running processes. Now, this is from the view of memory. This is a list of running processes looking from inside Memory, pass the Kernel. Now, we want to see what that looks like from the standpoint of, if we want that machine and ran. Guess what? Since we did that dump, we got this File right here, that we can look at, and we can compare running processes here. Here's what the machine says. It looks to match up a little bit. We get System, SMS, MSS, CRSS, winlogon, services.exe. It's matching up. So far we got almost a [inaudible] to match. Everything matches up all the way down, got this MSDTC then we keep looking over here. Suddenly we see us then doesn't quite match up. Now we have nc process here, but in this one we don't have that, right? Because if we took this thing and we ran a more against it and we gripped for nc.exe, we see it's not there now if we just grab for.exe of course, we see that there is executables, but there's no nc.exe. So why? We clearly don't see that here, but when we look at it from the perspective of memory, there's clearly a nc.exe running right there. okay? Now we got our first area of concern. Now we can say we think we've detected something because number one, I know what nc.exe is, even if they rename it to something else, the fact that I see it here and I don't see it in other which still makes me suspicious of it. I also see some other things. I see that in the memory dot, but I don't see [inaudible] over here. Alright, one thing I do see though, is our command. exe over here on the actual machine. If I look for that over here, I see it as well. So some things are matching up and some art. Right now, I'll most concerned with the things that don't match up. So let's do a pstree and try to see were we got our problem. What I'm seeing here is we got system at the root there. All these other things are running under system, including svchost then you got this running under the svchost and then we're back under system, was still under system here, were actually under services now, Our services has got three dots. So everything under that is under services then we got svchost Okay this is running under services, which we don't know what that is yet. The nc.exe is running under this. Comand.exe is running under nc.exe. Our command.exe is running under her. So we got, this is the mother, this is the child, grandchild, grand grand child. These four critters right here are connected. Those were ones at a given me concerned because out of all of those, only this one shows up when we look at the list of processes that we actually generate it from the machine itself over here, only one of those show up. Our command shows up with H6. Does nc, doesn't. So that is concerning to me. Alright. What that means then is we need to now go ahead and put together a statement saying that, okay, yes. We found something. We don't know what, but we know for sure that there's something that's able to hide processes, even from a machine where someone's running as Admin on it. Let's go ahead and look at a few more things in memory. All right, what else that we run when we looked at the machine itself? Well, we did run netstat. All right. Utilizing the stuff that we've learned about memory and how to do basic mirror forensics. We just got to stick with the basics and see what else we can find out. So when we run netstat, let's look at that because we already know that there's some processes that don't quite match up. Let us now see what we can find traffic wise and that's minimized this one as well. Oops, this is the wrong one. I'm just kind of organizing these so we can see traffic in both directions here. All right. So let's look how can we look at network connections? Well, there is a volatility plugin called con-scan. Let's look at that first, see if that tells us anything. We can clearly see some connections there. Then let's look at netstat on this one. We're going to more that file again and I'm going to just grep for listening. Actually, no. We won't grape for anything. Let's just go look at sockets. There's our sockets and what volatility is telling us from the memory dump is, look at we got three connects here. We got one connection to some web address out here on port 80. We got another web address connects now here to port 80 on this 40 address and then we got some connection to port 300 to this other machine here. There's something going on with port 300 and if you look over here, next step tells us there's no port 300, but clearly there is because it's connected and you don't even see any connection show up here. That tells us again that this is something if it's able to hide sockets and processes from the operating system as an admin, you know it's next level. What we're going to do now is see about finding out what processes have this connection open because it tells us, look it, here's a connection, its port 300. What that means, because if you look down here, let's see if we can find established. All right, there we go. If we look over here, we can see that the Pid that's got that port 300 connection there, because these are established connections, is Pid 1848. Now, if you look in this list, do we see a Pid 1848? No, there is no Pid 1848. But how can we check that from volatility? Well, if we look at the memory dot and go back to our Pstree and remember we're looking for Pid 1848. Do we see one? Spread it to make this a little bit smaller. We can see all the process. Well, look at that. We do have our Pid 1848 right there. It's that nc.exe. So what we can say conclusively then is that based on this nc.exe is a process that's listening on port 3000 and it's allowing a connection from this other IP address on that port. Because when we look at the con scan, that's what it tells us. It says, look, your victim is listening on port 300. It's connected to this machine on that port, so 137 is connected currently to it on port 300 via this nc.exe process. That nc.exe process, by the way, is a child process of hxdef100.exe. We don't know what either one of those are yet. Now we can take that information, we can go tell them, for sure there is an infection. For sure there is a connection going outside on a port and the port doesn't even show up on a machine itself. Now you've got to definitely go scrambling. We need to pull some traffic, we need to monitor traffic to and from this machine. I'm going to go ahead and make the call here because really the customer are the principals who make the call that we just try to eradicate everything right away. I'm going to go ahead and make a call and say, look, we don't know enough here. This is a relatively not common case. I'm going to want to do some more observation. Let's see if we can get a tap or some rule going on a network on routers, switches, listening devices, whatever, to monitor this port 300 traffic that's going outbound and see where it's going to and what it's trying to do. Now that gets us up to the point of the text and we've detected that yes, there's something there. We don't know what it is. Now, we actually need to dive into the investigation and containment part to figure out what it is. I'm purposely leaving this. I want you to see how this stuff overlaps. It's really never going to be black and white. You cut the line right here. Now we're immediately into eradication. That's not how it works. It really does work like this. Now, technically, I am moving out of the Texan because now we've detected it like we see it. There's no signatures, there's no alerts. We have discovered the IOC and one of them is that, if you see on a system that there's processes running when you do a memory dump that you can't see when you tell the system to show you on processes, that is one axle IOC behavior right their. Also, we can start off with port 300 as the listening port. It might be other ports, but definitely port 300, or a port that's listening when you look at it in memory, when you do a memory dump, look at it, but if you look at it from the machine itself, you don't see that port. These are all things that tell us, this is the behavior of this piece of malware. Now the next thing I'm going to do is we're going to go ahead and jump out. We're going to stop here in this session on the detection part and in the next part, we're going to start digging in this thing, trying to figure out exactly what it is. Because now we need to do the the containment and on investigation. We need to investigate, figure out what it is, give a containment strategy, contain it, and then we'll be moving on eventually to eradication. Hopefully, you got something out of this. Thank you for watching. Let's move on to the next step.
