Welcome back again. We're now going to go ahead and look at putting the three specific types of Zeek logs together that we're working on. For this, we're going to dive into a new file here, a new you've log file, because I want to take this opportunity also to take you back to the beginning of how we got the logs or how to generate the logs from the pcap files. We're going to go ahead and do that. Let's get started. We're back at my Kali terminal here and as you can see, I've changed from the case one file to case two. I'm going to go ahead and show you what's in that directory. We have three pcaps. Were going to be working with the first one to cover channeling. I just want to remind you that the way that we get Zeek to parse out is with the dash R flag and we point to the pcap file that we want it to parse. If we look in at directory, we can see that it's expectedly created the associated files and the ones we looked at his CONN log, DNS log and HTTP log. I want to show you where the real power comes is is when you're able to take the three or all of the different types of log files and put them together. To start with, this is a new case so if you've been working on the previous one, this gives you a fresh chance, to start with something new and see if you can count, apply those skills to any log file. We're going to go ahead and utilize what we've learned so far, which is how to parse these logs. We're going to look at the CONN log first. We're using Zeek cut to do that. We're going to start with looking at timestamp and we will also look at originating IP or you could also say Source IP. We're also going to look at destination IP. Let's do ports as well, so let's do source port, source IP, let's also do destination IP, and destination port. Let's start with that information and see if we can find anything that's interesting to us. Let's go back and fix our command. I just what did you see right there I got a typo. I love it when I make mistakes because it just draw out some of the fact that we're going to make mistakes and the key here is this repetition. I did IP instead of ID there, so if you notice it doesn't have a destination port. Let's correct that command. That's your p ID. Now we have the source and destination port. What's interesting as we look at this, we can see some port 53 stuff here, some DNS stuff. We can see some port 80 traffic, then we can see some more port 80 traffic. Then we see some weird port 31337. That port number, 31337 spells elite and hacker slang. We already know something's up there. If we look at some of the other things, we can see some port 137 stuff there. We see some IPv6 communication. Then we see a weird port, 52016 here, which is a source. But the destination of this port is 1900. That's like a broadcast. That's definitely interesting. All the way down at the bottom we see the most interesting, which is a port zero and a port eight. We know that based on and rules of TCP, port zero is technically never supposed to be used. That would be of interest here. That might look confusing, but here's what we find out, because I have seen Malware utilize port zero to communicate and do things, at least internally. Routing, that is going to be a different challenge but I've definitely seen happen internally from host to host. Here's the thing. This is where knowing the format of the Zeek logs comes in and makes things clear because if we specify proto, that's Protocol. I'm just going to add proto to my string there, and we'll see what the protocols are. You notice now that that bottom when it has a port zero, that's actually not TCP or UDP, that's ICMP. What it is is instead of this being a port number, that's an ICMP type and code. What we have is a type zero, which believe it or not, is an echo reply. Then over here is a type eight, which is echo request. It looks like it's saying this Source ICMP packet here is an echo reply. So what that will tell me is that somewhere in this traffic then based on how the ICMP protocol works, there should be an echo requests somewhere, but it turns out there's not. I'm already a little suspicious to this because I've never seen an instance where there's an echo reply, without added associated echo request. But if we go and look through this traffic, pass it, up, down, left or right. We're going to find it there's no echo request anywhere in there. Got this weird situation where there's an echo request or apply without an echo request. Now right away, what that does is it makes me interested in what's going on with that packet. This other stuff just looks like normal Web Communication's, a DNS query and then you go to a web server that's common. Due to more DNS queries, and then you visit a web server. That's common. This is a little bit suspicious, but definitely this ICMP is more suspicious to me than anything else. Now let's take and look at that Timestamp. If we look at the Timestamp wouldn't happen. That happened right around that time. So what I'm going to do is take that Timestamp. I just want to do a quick comparison across the other log files to see what else happened at that time. So I'm just going do a timestamp of source and destination, IP. Let's see, and port. Then what we can do then is come over. We're going to change this from connection log. I want to check the HTTP log first. Now what I'm going to do is I'm going to actually grep for guess what, that Timestamp that we pulled out from the con law. So I'll put that Timestamp in. Lo and behold, a lot of things happened around that time because this is like the seconds or the fractions of seconds over here. So around this point in time, a lot of different things happen there. Now if we look at what we grep for that shows us, we're actually trying to get to. So right around the time that that ICMP echo reply came without an echo request, we saw these other things. Let's take a look at that again and compare it will look at the column on again. We're going to look at proto. I'm going to grep for ICMP because that's the only one that I want to see because I'm just trying to compare down. Now if we look at the specifics of the timestamp, if you look down at the fractions of seconds here, we can see that this happened at like 319006. All these other things tends to be like a little bit later than that. So theoretically, what happened is this echo reply happened first, and then after that, we saw these echo or saw these other TCP connections of port 80 here. Now let's see what we can find out about what else happened around that same time or around that specific protocol in that if we were to take this and go ahead and look at the HTTP log. There's not going be any ICMP in there, so we're not going to grep on that. We're just going to grep and look at it and look at proto. We do see where essentially that whole 216 IP that we see up here is busy. There's a lot of communication going on with that 216 address there. Now, if we go back and look at the common log altogether and we take out any filters or any greps. What you see is that 31337 traffic, a weird way as well. If you'd look at the source and destination, that's how you have to use these in a cross section way. I want to show you, we're going to go back here and look at the HTTP log. So notice the source here is 129 and the destination is 139. Now if we look at the HTTP log, that we looked at earlier, let's look at the one where we grouped on the timestamp. Let's take away that and we just got a grep on the source IP of one nine two, one six eight, 153, 129. We can see word OS communicates is happening here, and if we further come out, and let's grep on the 131, notice we don't see anything happen there. Now let's grep on at 139 and we see nothing happens here as well. However if you remember, if we go back and just look at it overall on the connection side, there's clearly a TCP connection to port three one three three seven on 139. But again, we didn't see that in the HTTP log. So what does that tell us? It tells us that whatever that traffic is, it's definitely not HTTP traffic. So we may want to consider trying to dig into the port three one three three seven traffic and figure out exactly what was going on here, because it is clearly not HTTP traffic. Now, another thing that we're going to focus on is we want to dig into that ICMP packet and see what's up with that. Because it looks like to me just based on it, If we look at this connection log here and we grep on just the IP of 139, we don't need Timestamp for this. If we grep on just 139, and it looks like 139 probably sit in echo reply, and if for some reason at some point after that, that caused 129 to connect back to 139. Because the reason I'm saying that is if we add Timestamp back in there, let's add it at the end. Let's add timestamp to the end here. If we look at it clearly, that happened first. Because look at the breakdown on the in here is 319 is the millisecond fractured seconds there. Then after that, there was actually a connection that went in the opposite direction because 139 apparently sit the echo reply and then immediately after that, less than a second later, 129 reached out and did apparently, a three-way handshake. How do I notice it's a three-way handshake, because it's a connection log and remember we researched earlier, we saw that we could also add another column here, which is history, and history shows us based on what we just said, absolutely, there was clearly a three-way handshake that happen in both these cases. Because remember this is sin, so 129 sin of sin. That means that after this echo reply happen, 129 initiated a three-way handshake because here's our sin, remember the h means handshake or stand act. Then the a is the arch, so remember also that we talked about in a previous discussion that the little letters mean the destination, set that flag. The big letters mean a source in it, so the source in a sin, the destination set back of sin arch and the source in an arch. There's our three-way handshake right there. Then after that three way hand-shake there are some data that was transferred. From source and then the source, the destination, set back an arch and then it sends some data, and then the session apparently ended. So clearly something weird is going on here because it seems that an echo reply from 139 has somehow caused 129 to reach out and connect to it, and that's not how I know ICMP to work. None of the RFC or ICMP tell me that is designed to do that. Looking across these logs like that tells me that something's not right because I can see the connection. I can see a whole bunch of web connections up here to port 80 and some DNS stuff, but this is neither of those. So now there's a connection to happen over port that's a protocol that's not HTTP. It's not a web protocol. So what is it? What do these two communicating about? Right away there, that gives me interests in 129 and 139. What that would lead me to, because we were able to correlate that across these different logs, is I might now go and look at my third log. Remember we looked at DNS log as well, let's see how that comes into play. If I look at the DNS log, and I want to focus on around that same time stamp, I want to see queries, and I want to see answers and I want to see source and destination IP. Then I want to grep based on the timestamp that we were looking at to see where all the stuff happens. If we do that, we can definitely see some DNS queries there for InfoSec Institute. Those are queries like this machine that there's clearly a query for InfoSec Institute, and the answer say as InfoSec Institute is right there. It looks like this machine made that query, and this was the DNS server that responded. Now what were the other queries that happen? Well, if we just look at all the queries, so let's take away to grep of that time stamp, we can see there's also a query for something called blinkdigitalsecurity.com right there. Now, we don't necessarily know exactly what blinkdigitalsecurity.com is. Now, I know what it is because it's like a honeypot domain that I sit up, but that countless sticks out as being different than the other stuff that's in here. Now maybe what I want to do is go back to my HTTP log, and see if there's any connections to blinkdigitalsecurity.com. So let's do that. Let's go look at our HTTP log. I want to look at the host, feel for sure. There absolutely is, what appears to be an HTTP connection to blinkdigitalsecurity.com. Now I'm curious about those things, and what that leads me to is now we can take what we know and dig deeper. Let's review what we know here and we'll take some notes. We know that there are some interesting traffic between 129 and 139. We know that there some, I guess we should spell it interesting. We know that there are some interesting traffic between 129 and blinkdigitalsecurity.com. We don't know what, but we know there's something there. What this does is it sets us up and it gives us some good starting points and look at. Now what I might do is type just that information, I'm going to now jump into Wireshark and our next session coming up is going to be Wireshark. This will serve as a great introduction to how we're going to move from, the zinc logs and zinc into digging a little deeper at the packet level in something like Wireshark. I'm just going to go ahead and start a capture, or actually I won't start a capture. What I will do is I will actually open that pcap. Remember to pcap that we're working from is called coverchannel.pcap. I'm just going to go ahead and open that with WireShark and let's take the information that we know. Note that there's something interesting between 129 and139. If we filter between those two, we can count the seat. Here's what the traffic pattern looks like. Sure enough, there's that long echo reply remember when we looked at our logs a z log, we saw that there is an echo reply and clearly it's showing it right there, echo reply without a request. If we look at that echo reply, now I'm even more suspicious of it, and you know why I am more suspicious of it? Because let me show you what an actual Echo reply looks like. What I'm going to do here is start another instance of Wireshark because this is an aside but I want to show you why I would look at that suspiciously. I'm going to do eth0 and I'm going to filter for icmp traffic, and I'm going to ping my gateway here and I want you to see, let's see what my current IP is. I'm pinging that then I'm going to ping another device that is on my network here, there it is, that one so that's two pings. I want you to see what a normal ping looks like and a ping apply. First off, see there is predictable factors there like see what a number pattern is, the special character pattern, if we look at the other ones, there's our first set of pings but if we look at these there's clearly predictable values in there. If we look at the other ones to that too, those are going to be closer to the top most likely. We'll see the pairs of predictable pattern in there as well. There's clearly predictable patterns to what a ping look like, there's certain structure to it. That structure does not match what we were saying when we looked at Wireshark or when we looked at this pcap in there. This is not the right thing because look at that one, this is random or what appears to be random characters. Now as we look at that and we look at what happened right after, there was clearly a immediately after that icmp reply. There is a connection were 129 reaches out and connects then there's some other traffic that goes on. If we were to follow TCP stream on that traffic, it's all encrypted. Let's look back at that, what we got is an Echo reply that has a weird payload to it and immediately after a reply landed from one machine to the other, the receiving machine initiated three-way handshake to the one that sit the weird Echo reply, then all the traffic between mapper data is encrypted. Nothing weird to look at there right? Absolutely there's something going on there. I would suspect either some exfiltration at the start of the next filtration exercise but now I know to hand this off to reverse engineers or myself, we started working on big initiative trying to see if we can be crypt in this traffic and I'll just go ahead and fast forward and tell you what this is since this won't be one of the cases we work on. This Echo reply packet is an encryption key, this machine 129 has a piece of malware in it, that malware is listening for that echo reply packet with that hidden key. Once it receives that Echo reply packet, it pulls that key out and then it establishes asymmetric tunnel to this machine using that key then they communicate encrypted based on that. It's using icmp to covertly and an overlay deliver an encryption key. When we go back and look at all the traffic, we'll actually even find them malware in there because when we looked at that blink digital security, remember we sought out. Let's do TCP contains blink, look at that, there's a binary named calc.exe that's being pulled down from that blink digital security location. As we extract this thing out and look at it, we'll find this definitely not a good thing, it's a bad file but we'll look at that further in the next section when we actually dig into how to use Wireshark. Thank you for watching and hope you enjoyed it and look forward to seeing you in the next section
