All righty, let's jump right into this live investigation here. We've got a data breach situation going on. What's happened is the customer's come to us and said, we need to get you guys out here right away. We've got some data that only should have existed on a specific group of servers. It's showed up on the Internet, some of it for sale, so we know that those servers have been compromised. We have a memory dump that we've uploaded for you to take a look at. And we also got some traffic captures that we got from our net witness and all that stuff. So let's go ahead and dive right into it and see if we can help him out. Everybody's freaking out, the sky's falling, the world's ending. Let's see what we can find out about this data breach. Let's jump right into it. All right, we get over to our case here. We've bought over our packet capture file in our memory dump from the server, to see if we can find out here. So let's go ahead and dig into it, just to see if we can prove anything. First thing you want to do, as we did in our foundational stuff, and we were showing you how to utilize these tools, we're going to basically use Zeke to rip apart this peak app to see if we can find anything in there. All right, so we go ahead and look in there, and we can see that we've got a connection log, HTTP log, and all the other logs that we learned about earlier today. So let's go ahead and take a quick look, see what we can find out as related to connections. So we'll start off with the connection log. We're going to try to look and see if there's any interesting connections. So let's go with timestamp. We'll see what we can get with that. We'll go with source address. We'll also go with source IP. And destination IP and port as well. Okay, so let's just take a look at that and see if we find anything interesting there. So we see that there's some traffic between a 137 and a 144 there. That seems to be up and down. Let's go ahead and add duration to the fields. See if that sheds any light on anything and, boy. So if we look at the last column there, which is duration. We can see that there is clearly one session that seems to jump out from the others. So let's go ahead and sort this by duration. That means we're going to send it to sort. And we're going to sort based on, I think the fifth field, maybe. So let's just say K5. And, let's see, 1, 2, 3, 4, 5 lets sort it by field 6. We want this field right here. An we want the sort in reverse order, so we have the biggest at the top. So we're just going to add an n to sort by number, and then an r for reverse order, right? So what we get as a result, we can clearly see that the session that is the longest by far is this session right here. Okay, that is the longest session. Now, in addition to that, we can see that the port that's associated as far as the source port is port 4444. And the destination port appears to be this weird high port here, all right? We can also see some other traffic. Now, the rest of this doesn't look as suspicious, but all the traffic between 137 here and 144 looks a little bit off to us. So let's go ahead and sort that traffic and grep for just that, all right? And we're also going to take off the timestamp for now. So let's grep for 172, And let's look at the 137 address. And then we're going to take the timestamp call off of our filter here. So that looks a little bit more interesting. Now, because we took the timestamp field off, we're going to need to change our sort field to be field 5. All right, and that puts it back to how we were. So now we can see the traffic here. Let's go ahead and add one more help. Thing let's add the history. So we can see where there has been handshakes and stuff like that. So what we can see is there is a, basically a data transfer being sent from the source here. And in this case, our source appears to be this 137. So data is being sent There's an acronym there's a reset. Now and this session can last a long time. We can see some other connections here between these two, where there appears to be a connection that's going on for Port 8081. There also appears to be a connection to Port 8080. And there's some more Port 8081 stuff down here. Okay, so what we know is there's something significant about ports 4444, Port 8081 and Port 8080 between those two. Alright, now that gives us some information, enough information to kind of. Let's go back and forth. Let's take this same p cap that we're looking at We just ripped apart the server hack that peak app. Let's go ahead and throw that thing in Wireshark based on the information that we just learned between those two IPS, and see if we can see anything interesting happening between those two. All right, so we'll immediately throw in a filter For just those two devices. So 172, 16, 78, 137 and traffic between that one and guess what else? We want to do 144 as well. All right? So we filter the traffic down between those two. And right away one thing that we see up here that we didn't really see clearly in Src, is we could see a three way handshake where essentially, One device here, which looks like it was the 137. I initiated a session to 144 on port 8081. And we can see that because of the SYN serverhack there, that session did complete, and it looks like right after that 137 did a get request. And it did get looking for some specific search query operators. So it didn't actually ask for a local file that looks like it's trying to tell the server that it connected to the possibly go get that file from somewhere else. So let's go ahead and see if we can do a follow stream and maybe break that request down. Alright, so there is what the entire request looks like and look at this. This is interesting, it looks like when the attacker connected in the get request it did a search query string operator, that basically told the web server or the server to come back to me media attacker connect to me. On port 8080. And then when you get there, pull down this specific file. Now that's very interesting and what will be more interesting is to see whether or not the server actually obeyed. So now we can focus on port 8080. And see if there's any traffic between those two related to that port. So let's go back to our original filter and let's add to the equation here Port 8080 And sure enough we do see where there appears to be a SYN hack. So it looks like our victim 144 did follow instructions and connect to the attacker on port 8080 here. It looks like that absolutely happened. And then we can see that it did appear to have gotten that weirdly named file. Now that resource that it asked for it looks like it pulled that down and tried to pull it there. Now we can follow stream on that from Port 8080 and see what happened there. And sure enough, it did do a get for that weird filename And then it pulled it down. Right? It pulled that weird stuff down. And that's what we're looking at there. It looks like base 64 for encoding. So whatever this is it's being pulled down is base 64 encoded, probably to evade IDs in and stuff like that, so that it won't know what it is. Okay, that's all Port 8080. So then it looks like eventually that session ended down here. There's our phenac combo, four way combo to end the session, so that session ended down there. So now let's see what happened after that. So we really need to go back and look at just the traffic between these two because we really don't need to see the 8080 traffic. We already saw exactly what happened there, but what we do need to look at potentially is what happened after that. So here's our 8080 traffic. There's a bunch of stuff that went back and forth between them there. And then it appears, That right around here the 8080 session kind of ended, and there's a new three way handshake from the victim. Or actually from, yeah, from the victim to the attacker to port 4444. And it appears that something went over that port there that we could see as well. So there is some traffic at it clearly looks like it's all encrypted. So if we follow stream on that port 4444 traffic, well even though it looks like it's encrypted, we definitely gotta problem here. This is probably something that's executable getting transferred down, all right. That's one of the key things that we can look at there to kind of tell us that, all right. So that is usually not a good sign. Now we don't know what it is, so if we look at it you're just going to see it's encrypted, all the communication's encrypted back and forth. So we can't really tell exactly what was happening between those two here, right. But we know that it had to do with that port, port 4444, and we can see the session all the way through here. We can see all the port 444 traffic, even though we can't tell what exactly they did in there. But you know what, that's where when they used encryption and when they did these weird things like that, this is where you can utilize something like memory to help you out, okay. So now we're going to take and say, all right, well let's look at this. We got some timestamp information over here. Let's first of all make our timestamps look normal. So let's get rid of this decimal stuff here. We're going to go and make our time look like we're used to seeing timestamps. Like that, so we just changed the timestamp format. So now we see 02-09-2020, so February 9, 2020. We can see the first three way handshake that appears. Actually no, let's get rid of the filter there and go all the way to the top, go back to our original filter. And it looks like our first three way handshake, which should have been to port 8081, happened right there at that timestamp. So February 9, 2020, and then here's the timestamp right there of the actual time. So now that we know that information, I'm going to go ahead and, Take our memory dump, the server raw, we're going to run that thing through Volatility so that Volatility can tell us, first of all, what the operating system is. And this time we're actually going to run Volatility from Windows. I get a lot of comments and questions when I do these videos on can these tools run on Windows as well, you always run them Linux? So I'm running Volatility on Windows so you can see that we'll get a same view of that memory. So if we go ahead and run Volatility against the memory dump, here's our memory dump right here. It'll give us a list of processes. And remember, so far we've saw some interesting things in Zeke and in Wireshark that pointed us to looking specifically at this machine in ports 8080, port 4444. And here comes our list of processes coming now. Let's make that little bigger. So we can see there's quite a list of processes, this is pretty typical. We don't know really what all these things are, but we do know that this one definitely sticks out, right. So let's try and see if we can find out what that process is running as a child of. Do you remember how we did that? We gave volatility a pstree command. And what will happen now is will be able to see that process in the context of what else that process is actually running. As a child or grandchild of and that can tell us a lot about what's actually going on here. Right, and this is what I meant by sometimes you have to go back and forth because we did come from the network side that pointed us down here. We're looking at the packets that they gave us and saw all the things that we saw that as far as Wireshark and as far as Zeke. But now we're in memory at the time of when they did this memory dump. And if we looking for that weird process that we didn't know what it was, we find it right there. And there's two scary things going on there, one of those scary things is. That process has spawned an instance of command dot exe a command icon host. Another command dot exe, and then that command dot exe spawned another con host. So I'm already terrified this process as far as knowing that it's not up to any good. Furthermore, I can see that it is running as a child of W script and W script is running as a child of something called hfs.exe. Now we don't know what hfs.exe is, but let's go look at the machine because we're doing an investigation here and see. Well if we look on the desktop of this machine there is an hfs folder. All right, and we feed as hfs.exe process and if we look at the properties of it says it's from the company name rejetto, okay. Go out and research that you find it's just a web service, and we see it running right here. We can see it's listing on a specific port, look at that Jeez, it's listening on port 8081. So now I kind of have a little bit of theory about that, but we don't know. So let's dig into volatility a little bit more and see what else is going on in memory, let's see if we can do a. Connections scan. Or net scan and see if that process is indeed listening on port 8081, because if you remember looking back at the traffic. There was an actual three way handshake to Port 8081 that appears to have started though what we consider to be maybe to rogue activity. And if we look at it, sure enough, we can see that there is a connection to port 389 there. So that's going to be L dot there's an established connection to port 4444 and look at. Let's stop that. All right. So what's interesting here is when we look at these processes, what we end up finding out is there is a connection on port 4444. Lets actually write this to file. Right, so if we look now in that directory, we'll see our. Valnet scan document there, so if we look at that document, I'm going to grip on port 4444 and. In windows we don't really have the command grip, but what we do have is the command find string, which behaves similar to grip. So I'm going to grip on 4444, and look at the process that's listening on port. That has got the connection on port 4444, it's that weird process that we really don't know what the heck it is. So now we've got some idea about that, let's go ahead and see what other interesting things are useful things. We might be able to find out because we can already tell the customer that Much And we're also going to want to dump that weird process which we don't know what it is, but we're going to dump it, try to dump it and we'll just make note. It's period is 3864, right? We'll make another 3864, so we're going to need to try to dump that period. Right, so let's see if we can do that real quick. We should have a directory on the desktop name tip. So let's just verify that. Yeah, there's a tmp there. So let's see if we can dump that process. Which is 3864z speed, so we're going to invoke procdump, this is something I showed you in the fundamentals there when we're looking at windows forensics. And we're going to send it right to tmp. Was it TMP or? Well, we have it named. Yeah, tmp. So we're going to dump it right to that directory. And the process remember is 3864. This process right there. And let's see if it can handle that. Let's see if it'll do it. Now, keeping in mind, we know that in its DNA, this weird process is actually spawn is like a grandchild of hfs.exe. So really what we need to find out, is what we can about this hfs.exe as well, but we'll have to come back to that, so let's go ahead and take this process. Let's see what virus total has to say about it. And this is simulating if we had our own little sandbox that we would throw this in. So we go ahead and throw it up there. It's on the desktop under tmp. 3864 is what we want. See what they got to say about it. And we can definitely see that it's a back door. It's not good. Okay, so based on that, now we have to assume that hfs.exe process, which appears to be legitimate process is probably been compromised, and that may be what has been exploited. Now, the way we'll have to do that is kind of do a little bit deeper investigation. So this is really where we want to stop this particular video or this particular skills section. And then we're going to pick up on the next section and start off right here and dig just a little bit deeper. All right, thanks for watching, hope you enjoyed it. Looking forward to jumping you right into the next one.
