Thanks everybody for coming back. We just finished up our session where we were looking at taking the Ziklag because we've now kind of went through a whole series of getting your introduced to Zeek. And how to use it for incident response and network forensics. And the last series of that video session was to actually show you how to take all three logs and put them together. And the way I ended up was I showed you how using the information that we can get from correlating those logs, we can now jump into tools like Wireshark. And really want you to think about it at least in the scenarios that were playing through here is we might use something like Zeek to look at a wide swath of traffic. Look at the big overall picture and figure out what's interesting and then now using something like Wireshark, we could narrow down and focus. So I don't want you to ever think of these two tools as tools that are used for the same thing. Why Zeek would be more, let's look at all the traffic and see if we can find something that piques our interest. And then once we find something that piques our interest, Wireshark is something that we can use to drill down into that. And look at things more specifically as I showed you in the end of the last session and that leads us into introducing Wireshark. And what I'm going to do here is we're going to utilize this same peak app that we use with all the Ziklag. And we're going to now take that in based on the information that we found in Zeek were going to look through Wireshark and see some interesting things. And what I'll do is I'll do a quick review of what we saw with Zeek just, in case you haven't seen those videos in awhile and then we'll see how that leads us to look for things in Wireshark, right. So let's get to it. All right, so these were Zeek files and this is the log files that we're looking at and if you remember we started off early looking at the connection log. And you're not having illusions here. We are doing a Wireshark session, but again, I just wanted to connect the dots here to connect back to how we got to the point of using Wireshark here. So we looked at that connection log and we took a look at things like source IP. Source port, destination IP. And destination port, right, we got some information when I think we added duration and we had add a protocol to it. Okay, so that is in turn what got us to the point, we saw all this traffic here. We started to say, all right, let's just look at TCP traffic. So we did a filter for just that. So we basically just gripped on TCP. And then look at the TCP traffic, we saw several sessions there. How do we know they were sessions? Remember, we added the history, Ziklag to it, right and history showed us, these are all handshakes that's in the little HSN out coming back in the opposite direction in the big A is act. So all those are handshakes and we saw all these handshakes and connections and then we started playing with things like let's sort it based on different things. Let's sort it based on duration of the connection, right? And remember the duration field is this one. because if you look at the order we've got our filters in, source IP, source port, destination IP, destination port, that's 1, 2, 3, 4 and then 5 is duration, right? So we said, let's sort this based on duration and we did that. And we could do that, but says by simply piping it. Yeah, let's keep our grip TCP. We can take away the history. Just saving real stay here on the screen. And we could grip for TCP and then we can sort based on field 4, it actually field 5 and we can sort numerically. Godspell sort, right? So if we sort field 5 numerically, we can see that at the bottom is the biggest duration at the top is the lowest. We really want that to show up in reverse. So we learn how to reverse the order of sort with the dash R. And now we can see that clearly by far the longest duration was between 131 and 177 on port 443. And if you look at the number of connections, it seems like most of the connections are between our login connections are between 131 and 177 as well as we can see here. All right, so that's kind of how we got to that conclusion. So the next thing is, let's go ahead and take a look at what this looks like if we go into it with that assumption.We looked at a lot of other things in the Zeek logs as well. But the point is, is that let us know and at 131 and 177 are the interesting or the most talking to devices in this traffic. So now if we go ahead and fire up Wireshark and look at this pcap. And this is the same pcap that we were looking at with, Zeek there and then we do a filter all right. And I'm just going to introduce you to filters and this really is were calling an introduction to Wireshark but were saying Introduction to Wireshark for instant response information network forensics. So we're not saying this should be the first time you've ever heard of Wireshark, so some of these basic concepts you should be somewhat familiar with. But if not, you can kind of pick it up as we go as well. So I'm going to now filter based on just those two IPs, right, and let's see what that traffic look like between those two. So we go ahead and introduce that filter. It's going to be 153 and what we see there is, first thing is there's ICMP traffic an echo request it looks like 131 did a ping to 177 and got responses back. Now, if you think back in the log, some of the other things that we saw was some Facebook queries, and there's a whole bunch of pings, and it seems like they're all being redirected there, right. And that too is in the mix of the redirects. So it looks like there's pings going from 177 to 131, and then they're being redirected to Villa 131.2, right. So that already kind of makes me think there's some relaying or something like that going on some replay. But using that information now we can kind of start to see a pattern of these two doing a whole lot of talking. That's a traffic between them on port 8080 there that looks interesting. There's some traffic between them on port 443, so if let's just take the 8080 traffic for example and let's just say follow TCP stream to see what that might look like. And clearly we can see something that does not quite look right there. All right, the fact that we can see a gitexploit.jar. That is already a problem for us. It already introduces a bit of concern there. Now we don't know what that exploit.jar is, but just looking at it here we can see that it may have something to do with Metasploit, there's a payload class that showing up there. So this is definitely what appears to be a Java exploits, that's a dot jar that may be getting pulled down here. Now, of course, this thing is all encrypted, so you can't read it directly and see exactly what it is. But we're now we at least know what it is and we can see right after it got the class that class down it bought down another class or tried to get another class. So definitely looks like the makings of a Java exploit. So now we need to kind of go back and see what else we can find out about what was going on there. Just looking at the traffic between those two. So one of the things we find out, in our Zeek logs, if you remember we did see that there were some queries for facebook.com. Which this is a Business Network, so that really shouldn't be going on. Now, keep in mind I've sanitize all this traffic, all the pcaps, all the IPs, so you won't actually be able to make heads or tails of word of stuff came from. So if we look for a Facebook traffic, we can, Definitely see that there is a get. And somewhere in there there should be a DNS query. So if we clear that filter, And just filter on DNS and then say in an UDP contains Facebook, all right. We can clearly see that there is a query for Facebook going on right there. So it looks like 131 did a query to what looks like a gateway or DNS server for facebook.com, looks like it did it twice. And then it looks like dot two responded and said, hey, if you want to go to Facebook. And that query is what I'm interested in. Lets drill into that response, the query response. So the query looks normal. It's just a standard a query for a record for Facebook, but the response, if we look at the query response, it is suspicious to me that the DNS server is responding and saying that Facebook is at 177. So that tells me one of two things. I believe that either DNS server has been poisoned or that's not actually coming from the DNS server. I think it's one of those two things, right, because 177 is probably not really Facebook. Now this could be legit, it could be some proxying or something like that that the organization has going on internally to proxy all requests out to the Internet. But the reason we don't believe that's because when you go back and look at all the other web traffic, you see that everything else is being allowed out, okay. So we can clearly see that there's a something going on weird here to whatever request in Facebook. We can see a ping for Facebook being re-directed to 177 here. So all of that leads me to believe that there is something, we know that there's looks like a Java exploit that's being pulled down. We also know that it appears to have something to do with Facebook, okay. So that is kind of our introduction to how we can take what we got from Zeke, now we're looking at it a little more granularly with Wireshark. And that's kind of our introduction to using Wireshark to dig and pull away pieces of the hey, okay. So the next thing we're going to do is we're going to go a little bit deeper with Wireshark and try to see exactly if we can find that dot jar file, try to pull it out and see what that thing actually is. And maybe even see if we can see any communications between these two that's not encrypted, all right. So thank you for looking at this session, and we're going to move on to the next session in the next video.
