All right, hello everyone and welcome back and thank you for tuning in. We're getting to the most exciting part of this skills set for me which is we get into the hands on part. Which is really what we put the skills path together for is to kind of get you some hands on show you some things that you need to know about how we do incident response and really touching on the network forensics and the memory forensics part of it. So in this session, we're going to introduce you to Zeek. And we will use that throughout the rest of the hands on part, of course. But we're going to get an introduction to it now and then we're also going to essentially use it to look at the connection log. Will follow a session with a deep dive into the HTTP log, and then eventually to DNS log and you account to see how they all tie together, will tie it all together with the final session on this before we move on to other things. So let's get right to the hands on. Different types of traffic, if we only want to see tcp for example, or udp, we could filter on that. Just using basic Linux command line grip, and that type of thing. Now the next thing that I want to kind of show you here is, one cause service okay. And sometimes you won't even see anything with service. But let me explain to you what it is. So if you look at service, this is basically the application ID, right? That the application set across the wire as that connection was going, so you know this session identified itself as http. This will identified itself as dns, and so forth, and so on. So you can use that, to see what the session identified itself is. Now just to kind of give you a hint as to how, fun we're going to get with this. Imagine application that identified itself as http. But you drill into it, and look into it, and it turns out it's ftp, or something like that. All right, now we have something interesting happening in the traffic, so that's why it's important to have that available to look at that as well. Another field is, dnr duration. If you want to see how long a session lasted. We can give it duration, and we can see the duration of all the sessions here. And that's going to turn out to be massively important as well, as we start working on cases when we get more towards the actual end of this. And you'll see, how that turns into something that ends up being very, very useful as well. So definitely, considered that, and look at that, when we get into it a little bit later on. Another thing that you want to consider as well, is combining these. So before we get too far, let me just show you how we could, for example, combine duration, protocol, and if we wanted to do user ID for example, right? So we can see, how long a session lasted? What protocol it was? And its unique identifier? Okay, and you can continue to add things in that, as you go, you don't have to get it all at one point. Some other things that you might consider include, source, and destination IP, and things like that. Now the way that we show that, Let's just take out uid. Let's just do, Originating IP, and responded IP, all right. And just kind of remember in your head that, originating means where it starts at your source IP, and responded means, where it's going, and that's the responding IP, or your destination IP. So if we enter those, now you can see. The duration of the session, the protocol, the source IP, and then the destination IP. Okay. So we could see all of those, we can actually see how they all actually work there. And you can kind of filter, and sort based on these, and will do absolutely a lot of sorting, and stuff like that. Some other things you can see is, the origin, and destination bytes, or how big the session is in byte count. So if I wanted to add that, I could just simply say, I believe its origin in bytes. For the origin bytes, right? So we can see the size of the pack, the how big the session was in bytes count, and then you could even add responded. To that as well. Alright, so now we can see both. So that's a few useful things that we can do with just the connection mob. Now we're going to definitely do a whole lot more with it, and I want to kind of show you one a few other things, that we find very useful. One of those is going to be something called connection state. Okay, so if we take all these sessions, What do we have here? One of the things we can add, is we could add to it, connection state, and that's going to just be conn state. Alright, so what we get with that is, if you look all the way to the right, and I'm purposely putting add in the fills to the right, so you can see. What we see here is, the session state or The connection state of the sessions at the time that this traffic follows dunk. So these letters over here all have codes to it. Now let's go and look at, for example, s0. Okay, what that means is there was a connection attempt, but there was no reply. So someone sent a send, and then there was no reply to come back to answer that connection request, all right. Now if we look at, For example, the one under it, SHR, what that means is the respondent sent a sent at, and then a fin with no origin send. So there was a send at sent and a fin sent without a session ever opening up there. So that could be something, these could be things that we could look at to kind of see weird behavior in the protocol. Now when you see, for example, RSTO, what that means is there was an established session and then it was aborted. Okay, so there was a session and then that session got aborted. There could be lots of different reasons for that, but that's what that actually means. Now, down here at the bottom, one of the more significant ones is when you see s1, all right. What s1 means is a connection has been established and it's still going on, so that's an active connection right there. Now keep in mind we can also use Zeke to run it live, so we could run this against live traffic. We don't have to run it necessarily against historical traffic. So this shows you all this state, this TCP session state. And if you wanted you could grip out just TCP, right, you could grip out just the TCP fields and that would take away all the ICMP and the UDP stuff, right. So we could actually do that. We could just say grip TCP, and then suddenly we're only looking at TCP traffic and we're not looking at ICMP and all that other stuff, okay. Now another field, one more field that I want to show you, is one called history, okay. And this is one of the more significant ones because when you look at history what it actually shows you, and let's add that to the end here. These weird letters over here to the right, all the way to the right, what that shows you is actually TCP flags and the history of those flags. So for example, if we take this one right here, this weird one that looks like shatter. What that is is the capital S means that the the originator or the source sent this in, okay, and then after that there's a HA or an H, and what that is is that means handshake. So one of the ways that you want to decipher this is anytime its upper case, it means it's the source IP. If it's lower case, it means it's the respondent or destination IP. So in this case we got the source machine that sent us in, so 131 here sent us in. The destination machine sent back a sent ack, and then the source machine sent an ack. So that pattern of little s, excuse me, big S, little h, big A, that means a handshake has happened, all right. Now, the capital D means data from the source side, so that means a three way handshake happened, that's what that is. And then the source machine set some data, and then the destination machine responded to that data with an ack. And then the destination machines sent some data. And then the destination machine sent a reset to close that session, all right. That's the history behind that session right there, okay. So that is very, very powerful because now if you understand that, if you understand that the pattern of big S, little h, big A means a three way handshake was completed. Then we could filter on just connections by doing that. We could say only show me where a three way handshake's completed, and I could say that by saying grep for TCP and then out of that result grep for, Big S, Little H, Big A. And now we see only the connections or the 3-Way Handshakes. Now we could decipher the other things for example, we see a 3-Way Handshake here. All right then we see the D which means the source sent data. The destinations in an act and then the destination set data and then there was a FIN to basically start the closing of the session, because that little f means FIN. Then the source sent a FIN back because that's the 4-Way come over where we closed down a session, and then there was a reset in the session was over. All right. On this one, there was no FIN closer on there was just a reset to closer session. Here there was a FIN, so you can see like first of all of these are actual connections, but just as importantly you can see how those sessions ended. And that can tell you a lot about what type of session it was, right? And that some of the stuff that we're going to use as we move forward to dig a little bit deeper into this. Now with these things remember, you can sort this stuff by protocol and by other whole bunch of other different things, for example. If I wanted you to see only the top, you know 10 or so TCP sessions based on duration. Out of what we've got here, watch what I'm going to add. I'm going to do the repeat the same command, and then I'm going to say only show me, I want to do a sort, I want to sort by number, I want to to use the first field because the first field I called out is duration, so I don't need to specify field number here. So I'm going to say, sort all of this by number and it sorts it by the 1st field. Now notice it has the lowest duration at the top and the longest duration at the bottom. I want to be the opposite, so I'm going to say, all right we'll sort that in reverse order. And now I have my highest duration at the top, lowest at the bottom, and then I want to say, just show me, let's do a head. And now I can see my top talkers there. So we've filtered on quite a few things, we've said show me source and destination IP, show me the protocol, but only show me TCP. We grep that out there. We want to see history and we want to see flag, you know session state. We only want to see connections, we grep that out here, where there's actual connections, we want to sort it by duration, and we sorted in reverse order. So we can see that these two sessions here, based on how we broke that down, appear to be the longest two durations. Now we also have byte size in there. So what if I wanted to sort this by respondent, byte size, right? So I could take that and say all right, well responded byte size is this field, so that's going to be field 1,2,3,4,5,6. If I wanted to sort that by field 6, I could just tell my sort -k6 and that's telling it to use field 6 to sort and notice it made the sort order now based on respondents byte size. Right, so the key to this session right here, is really to get you to get into these fundamentals of how to use Zeek for passing this connection log. Because when we get into a real case here shortly, you're going to need those, we're going to be using those skills to get into that Pi Cap file. Find the things that are weird or abnormal or are significant or interesting. And then use that to drill down even further because then will be pushing into Wireshark and then later in the memory forensics. But it all starts here with a lot of traffic and then we use a tool like Zeek to help us narrow that down to interesting traffic, right? Even if it's buried inside normal traffic, we can find it and then we use that to do a little deeper look with something like Wireshark and then once we have all those artifacts we know what to look for in memory on the machines that we have memory access to. And that's what that boils down to. Okay, so that's the end of this session, we're going to stop on that right there and then we're going to move on to the next session, or we're going to be looking at the HTTP log.
