Moving right along, we're going to move into looking at the Zeek Http log we are in a previous session, took deep dive into the connection log. Let's move right into the Http log. Let's get to the demo. As we're back at our console here in Kali, we're going to be looking at how to dig into the Http log, just like we did the other log earlier. This will be important for us to get a handle around just what types of Http traffic we can see. I'm going to start off just like we did before. Just like what the connection log we are going to look and see that, with the Http log there is a timestamp feel that we can look at right away here, and it shows you timestamp just like we did with the connection log. One thing to remember here is cross-referencing are associating these timestamp values, and lining them up can give you a lot of insight as far as when you try to do like timeline analysis or something like that. That's something important to keep in your mind. I also want to go right back to-. We talked about user ID earlier. Just like what the connection log, when we look for user ID in the ACTP log, we see the same user IDs. Just you want to keep in the back of your mind that these user IDs are globally used across the zinc logs. We could take that same value right there, and we could go look that up in the connection log and we'd see it. We're going to use that later as a way for us to put things together. Now another one I like, let's take off UID. Another one that I like to use is the method, so when it says method and when we use method, it's talking about the Http method. Will there be GET, POST, head or whatever methods you happen to be using. We can see that what the method is and we can sort by that, which is going to turn out be very useful as well. Another thing we can look at is host. Host is very useful because it shows us the Http host that the GET requests or the POST requests was going to. You can see, there's a lot of them go into msn.com there. One thing that we can do, is we could basically make that only show us unique values. If I did, just for host, which gives us that one thing that might be useful as we could take that and we can pipe it to unique. It always shows us, unique instances. We can also make it what the unique we could basically, sort it and give it count, so we can see how many times a specific URL or host showed up and then we might even sort that, All right, we can take that unique and then we can say sort that force by number in reverse order and now we see which host gap the most number of hits there. All right, so that's a sum of things you can do with the Http value. We can see, where traffic is going. Who's getting the most traffic based on number of hits, but one interesting thing, we'll find out when we start cross-referencing this, with the connection log later. Is it just because a host is getting the most hits doesn't necessarily mean it's generating the most traffic. That could work either way and we'll see that and see how that could help us out. Now you can add to-, your method here we could add URI, like so, and then we can see the actual URLs that we were going to at the time. We are also able to look at refers, like if there's any refers, We can look at user agents, if you want to assist do that, let's take this and we can take all this off for now. I'm going to do host and user agent. What that shows us is which browsers happen to be in use at the time of that Http communication. There's Firefox, there's some Internet Explorer or some Microsoft Edge that we saw down at the bottom there. We can see that we can see what browser was being utilized, whatever the communication happen to be. In addition to host and user agent, which are going to turn out to be useful. We can also look at status code, which is basically the web server's response to your request. If I wanted to look for, the status codes I could do for examples at us. Now we can see the 200s versus the 304s versus a 300s. Whatever it is we have to be looking for, we can see the success or failure of any of those requests. Now, obviously, just like we looked at earlier, source and destination IPs, we can also add that this feel of how respondent, source and destination was funded is pretty universal. If I did ID origin that means source address and then I ID respondent, and that translates to destination address. Just for those of you that are used to notating it or thinking of it that way. That's what those terms mean there. We can clearly see some connections here. We see some interesting ones that don't have a host name. It's just IP addresses. Those are always interesting because it usually Intel's someone trying to hide something or something like that. How often do we connect to just IP addresses? If you have your end-users doing their normal computer and they will usually always be connecting off to some host or something like that. We can look at other things like source and destination port as well. That would look something like this. We could do that. Now what you see showing up is the port right here for the Source Address. If we want the port for the destination address, we just add P for port for that. Now, I always like to put the ports after the associated. If I'm doing source address and destination address, I want to have source port and destination behind each one of those are respectively, so we can see what the whole session looks like. For example, we can say, oh, for sure, 131 came out a source port 49227 and connected to 177 via HTTP to port 80. We can see the whole communication path there. We can also see that 131 connected to 177 on port 80 here. That might be significant or something that we might care about later on. But these are all the things that we're interested in seeing and we'll see how that plays out in a little bit when we did a little bit deeper into it. You can get source destination port IP. We can also even get the message lake on the size of the body, how big the data is. Let's add that field. Lets just take away status code, just give her some space here as far as what the output looks like. But we can actually do the message body. We can say, if the web server responded, let's do response, body not cody. I'll link like that. It shows us the link or the size of the response body of whatever that HTTP requests was. That could definitely be useful for just a whole lot of reasons I don't want to give aware or surprised of stuff that we're doing. But you can also look at the request body length as well. For example, I might take away ports, and request body length here. I can do that just by saying request body length again there. I am going to take away some of the stuff, I'm going to take away to ports. Now you can see source and destination IP. You can also see the request size versus the response size, which again can be useful. As you can see, all of those are requests are zero, which is what you should be seeing in normal communications. Things that fall outside that might be something of interest. Now, you can try to make it so you do info codes. For example, if we added info code, it'll show us what the info code was for that particular session. Again, that can be useful. It's supposed to be one thing, but you look and you see that it's actually something else. What these again, the same way that we did with the connection log. You can sort all of this data based on whatever you wanted to sort it based on. One of the things I did introduce here was I introduce unique, but we will add that in to some later stuff that we're going to do when we start combining these. The next log that I want you to focus on, and do take your time and spend your time through these because you really want to recall these from memory. The ones that are important anyways. If I'm looking to hire someone to do forensics, I expect even at an entry level for you to be able to do most of these things without me having to give you a step-by-step on doing. You want to practice these things to get that skill to become the muscle memory, so that when have to be creative and looking for stuff, the commands and the right filters that you need to use just come naturally to you. That's it for that particular ACTP log. The next section we're going to be looking at the DNS log.
