This is going to be our continuation of Wireshark. You'll get to see how we continue to move this case forward and are able to extract the information that we need from being able to pull out the needed data. Let's jump right into it. Here's where we left off. We had figured out that there was definitely some traffic Interesting between 192,168,153, 131 and 177, we saw that 131 apparently thought that 177 was Facebook. We also saw that it went there, tried to download a page and downloading a Java file named Exploit that Jar. Remember we found that by looking at port 8080 traffic between those. Just to be clear, if you wanted to filter on traffic on the port, we could add to this filter and just do TCP port 8080. That would narrow it down. One thing we saw on that 8080 traffic when we follow TCP stream on it, we saw that this Exploit that Jar file is being pulled down. We saw some Metasploit looking stuff here we subtle payload class. Then we saw a com.class coming down at the end here. All the makings of a Java Exploit is what it looks like. We don't know what that Java exploit is that's what we were getting ready to do is dig deeper. We can go back and as I always say, part of the network forensics is you're moving a bunch of hay from around a bunch of needles and as you find needles, you put that hay back in there to give you context and then you move forward with that. After that Exploit that Jar, we want to see what happened. After that got pulled down is when that 8080 connection actually started. Because if you look at it, we're over port 80. Then we got to port 8080 and got the Exploit that Jar. Let's see what happened after that. They'd obviously went down. Looks like it pulled it twice there. Once it got it, the traffic switches here, from port 8080. Remember we are got a filter of these two. We can just scroll like that and not worry about a bunch of other traffic as missing it. As long as it's staying in port 8080; we could say not equal to port 8080 as well if we wanted to rule out everything else. One of the thing we can do is we can exclude a port. We can say,&& not equal to TCP port, or actually with the TCP port is not equal to 8080. We could do that. That will take out the 8080 traffic that we were looking at there. As we go and look through this. Because I want to see the whole picture here. We see that eventually the traffic goes from port 8080 right about here. It switches over between those two to port 443 because there is a SYN, SYN ACK, and there's an ACK. There's a three-way handshake were connection to port 443. There it looks like some Ajax stuff getting posted and some other things going on. What we see there is continuation of the connection. As we scroll down and look at what else is happening over that connection, you can do it manually like this and just go one at a time or we could grab one of the packets and follow TCP stream on it. Low and behold what we see there is all the commands that were being entered or the attacker was able to get in. We know that, that Java Exploit probably gave him a command shell, because that's what it looks like he's able to do here. Creating these keatron users and keatron initials there. We'll get stuff that's going on as far as they get in there. We can see what the attacker was doing. What the attacker created looks like he got a local Admin account built there. Looks like he was after some specific types of data as well. Now, we have some theories about that. That takes us to where we are basically now going to be able to go back and communicate to the shareholders or to whoever we are working for in this particular incident and tell them some specific factual information. We know for sure that they were able to download, get some malicious software or malicious Java applet onto the victim. Now, the next logical step is going to be what did they touch, what we saw that they touched. But now we need to try to figure out exactly what it is that Java file does. That leads us to another piece here of something we could do at Wireshark. One of the things that I don't see talked about often is we can actually extract a file, pull a file completely back out of Wireshark and utilize that file. If I go to File, and Export Objects, I can go to HTTP and it'll show me all the objects that were transferred. One of them that we're interested is that exploit.jar. If I just scroll and look for that thing, I can see it right there. It's broken down into equal pieces. If I go and say, let me save that, and it asks me where I want to save it. I'm just going to save it for now in the same directory. Now if you go look back in our current case directory that we're working in here, we can see that we've successfully exported our curve right out of the traffic, that exploit.jar file. Now, the next step is we want to try to break that thing down. What we're going to do is I'm going to put it onto, because this is a Windows Exploit obviously. What we saw in the Traffic is it's a Windows machine that's being exploited that is connecting to, we would have seen that in the headers and things like that. But this jar file, this.java file, we're going to put it in the same environment that it was potentially being exploited and investigate it. This is getting a little bit outside of Wireshark, but I wanted to show you what the end result of this would look like. I'm going to put that thing up there. We've put it there, now let's go over and look at that machine. We'll jump right over to the machine that we just put that on. It's on this machine and we put it in this FTP directory here. So let's go to that and there's the Exploit.jar file. Now fortunately, I've went and gotten this because we know it's a Java, it's a.jar file. If you didn't know that, as an investigator, you could just research how do I open.jar files. Everything will tell you, well, Java's files are not really compiled, they're just compressed, so we just need a Java decompiler. The one that we're going to use here is called jd-gui, and I just like it because it's easy. There's not a lot of training that you have to give someone. We're going to use jd-gui to open the.jar file, that we extracted out of the Traffic, from that compromised network. I'm just going to tell it to go and open that file. It's right there. Actually, put it in here, want to make sure you get the right one. We were in FTP and its exploit.jar right there. We open that thing up and now we can actually deconstruct it or decompress it, and we can see everything about what that applet or that Java file, that.jar file does. We can see the payload, what was put inside it. We definitely now have verified that it's definitely a Metasploit generated exploit here, and we can go and learn everything about it, everything that it does. We can see more about the payload here. We can see that this binary was pushed down. If I went to that machine, that physical machine that's compromised here, I'd be looking in memory for this binary or looking for that binary to be hid somewhere. Because we can clearly see that that's associated and was pushed down as part of this exploit. The reason I say memory is because this actually is quite a nice median to what our next section in this skills path is going to be, which is now that we've gotten the network traffic overall from Zik. We've drilled down into what we found in Zik to look at it more specifically and a lot deeper with Wireshark or something. You could use other tools. Now that we've gotten Wireshark to tell us exactly where the infection went, where the compromise went, and what kind it was, we can go to those devices and look at them more specifically. Nine times out of ten, when we're talking about the vice level, some of your most valuable, if not the most valuable evidence, and things that they're going to tell you to store are going to be things that show up in memory. That is the nice linear and that takes us right into memory forensics, which is the part that we'll be dealing with after this to get us back to this point. But the cool thing is we were able to right out extract that binary here. Another part of that is if we go look at the, let's go back to our Kali now. So back at our Kali, if we look and if you remember, I kind of jump onto a case two, in the close out of the Zik session to show you a different file that had some other weird stuff going. Remember we looked at the covert channel. Let's look at that and I'll show you how we can still, even with that one, extract interesting information out. We've decided based on that that there is some interesting traffic between the 129 address and the 139 address. If you're having trouble remembering that, just go back and look at the Zik, tying them all together video but this is the sample that I threw up to show you how we could look across these logs to answer a question. But one of the things I want to point out is when we do that, some of the stuff that we saw was we saw that there's definitely some traffic to Blink, so we did a filter. TCP contains Blink, and we found that there was a GET for something called supercalc.exe. Well, remember, if we can do that, if we can extract that jar, why not try to extract that exe right out of the traffic? Well, Wireshark allows us to do that. Remember? Because we can go just like we just did with the export that jar, go to Export Objects, HTTP. There's that supercalc.exe file. We can go ahead and save that thing, save it to the same location there, and then we can repeat that process of simply getting it, putting it over on the other machine and just seeing what it does. If we went and ran that thing, it would absolutely run a calculator, but who knows what else is going on in the background. We'd have to set up a sandbox machine and study what's happening in memory with it to see what else it does. Again, that's why I'm showing you where the cut off point is because we will be doing exactly what I just described in memory forensics. In the meantime, if you've got an AV or [inaudible] based product, look at what we can do. We can also go out to somewhere like VirusTotal. Listen, don't do this in a real case. If you're on a real case inside somebody's network, do not take malware samples or anything else like that and put it on VirusTotal, and the reason I'm telling you that is because you don't know what that malware has inside. You don't know what its payload is. You don't know what it's collected. So you could be inadvertently taking a piece of malware that you've pulled out of the environment, putting it on somewhere like VirusTotal and end up inadvertently exposing some of that corporations internal data to the world because of the fact that you decided to do that. So don't do that because that malware could be collecting information. Let's go look at this binary. We've extracted the supercalc , let's throw that up. You can clearly see that VirusTotal is saying like yeap, this thing is really, really bad. All the vendors on here saying it's batch ran semantic. Panda, FireEye, they're all saying it's really bad. There's a few who did miss it, but that's not our point. The point is we extracted it right out of traffic, right out of a PCAP, put it right on a VirusTotal and VirusTotal told us immediately that is bad. So now we have the ammunition and we have the knowledge and a proper hypotheses to go digging into memory of these machines that are have compromised, and that's what we're going to be moving into memory forensics with the next section in this path. Hopefully this has been beneficial to you and I'm looking forward to diving into memory with you in the next section. Thanks for watching.
