Next we're going to be looking at the DNS log, and it's just another one of the zeek logs that we'll be digging into. The DNS log is very useful for the simple fact that you see queries, you see where people, or devices, or malware was trying to resolve or where it was trying to go. Let's go ahead and take a look at that. All right. As you can see, we're back at my Kali console here. We're going to go ahead and take a look at the DNS log like we did the others, and what you see is, it's formatted similarly to the other logs, but it's got quite different information in there. We can can clearly see queries, we can see UIDs which we talked about earlier that helps us uniquely identify a session. We can see source IP, source port, destination IP, dest port, protocol, transaction ID, query, query class, query name, query type, query type name, return code, returned code name, we can see all that stuff in there. Again, this is important from when we tried to see were a piece of malware, or a user, or something like that was trying to actually go or end up. We will parse it would zeek cut just like we have the others. One of the first things we're going to look at will be basically to verify that we can see a user ID. When we look at UID, you can see that they look exactly the same way they looked in the HTTP log. Like if we did the same query for HTTP instead of DNS, you see the same types of UIDs, and if we did connect log, you see the same IDs. This is what I meant by these. These are like the glue that holds together all the different pieces here. Now what we're going to do is since we don't just right now yet care about UIDs, what I do want to show you is a couple things. In the DNS lab, we're going to look at source IP address, we're also going to look at query, because query basically is, what is it that this device is trying to get to, this person is trying to get to. We look at that. That was seeded, it formats it nicely for us. It shows us, here's the origin IP, here is where it was querying to go to. In other words, it was trying to go here. Here's the source IP at the top there, and it was trying to go to Facebook. Maybe I'm interested to see, what was this person trying to do? What's going on with Facebook here? Because one of the number 1 ways malware gets into organizations, is via things like social media, phishing via social media, etc. We might want to see, let's see how could we look at just a Facebook queries. Well, we could come out here and say, grep Facebook, and now we see all three of. There's actually three queries of Facebook and then all appear to be coming from 131. Seems like 131 really want to get to Facebook. The next thing is, I need to see what the answers were. Like this is the query, this is where the person is trying to go, and then let's see the answer. How do we do that? Well, we just add answers. Oops. Definitely don't want to add as a grep string. I'm so happy when I make mistakes because, I love it when you guys see that I absolutely jack up stuff too. So if you make mistakes on this stuff, don't feel like something's wrong with you, we all make mistakes. When we do that, what we can see is okay, so, here's the query for Facebook, right here, and the query response was 177. Now, that's weird because Facebook doesn't exist on this internal non routable IP address, but we see there's also query where the real Facebook actually is reached out to as well. Now what I want to do, is go ahead and add responding IP because we know which IP asked for Facebook. We know that the DNS server respondent with that in this case. But now we want to see what DNS server was that respondent. I'm going to go ahead and throw in there at the end destination id, which we do with id respondent or responding IP. We can see that that part looks right, it does look like the gateway. This would make me think it's a gateway or rotten device or something being such a low number. It's just a common IP scheme, but it looks like a gateway device or something like that did respond, but it responded in a weird way and told 131 that Facebook is at 177. Now, that's a little interesting to me because of the fact that it counted alluding to Facebook being an internal IP address, which shouldn't be right unless they go and so we're proxying or weird DNS cache or something like that. But that doesn't really seem right. Now, we don't know yet whether or not it's right. But just based on what we see there on the surface, it definitely looks like something is not quite right there. That's what we're looking at with this.Now we can add other things. For example, we can add TTLs, we can add round trip times, we can add even protocol. If I wanted, I could add protocol here at the end and verify that it is UDP. Now, we could have a DNS query happen over TCP. Large queries, some of them do go over TCP. But nine times out of 10, a DNS query is going to be over UDP, which is what we're actually witnessing here. These are great pieces of information to help us as we dig deeper. Because later on, some of the things that we're going to need to ask ourselves is, what else is going on at this time? If I take, for example, certain timestamp, so let's add timestamp at the end here and I look at those timestamps, I could start to look for the other logs for what was going on around that same time. This timestamp of the second right here, I can grab that's graspable. One thing I might do, is take the first part of that timestamp, look at the TCP connection log, and do a timestamp grab and just grep for anything related to timestamp that we just copied. We can see some things did happen run, run that time. Now if we're basing our query off time, let's go ahead and say well, what was that one on at that time? We got timestamp that would have ripping off of. Let's look at source IP and destination IP. Well low and behold, not surprising. Around that same time, there appears to be communication from 131 and 32. And then shortly after communication from 177 and 131 and that pattern seems to repeat there. That little smudge it right there, is going to lead us to some interesting things as we go and start work in a case and treating this log, it's a case file and dig into it. There's a lot of really interesting, really cool information that we're going to be able to dig out. Don't forget to spend some time looking at all the fields in the DNS log. You'll be able to pull some of that stuff out and do some interesting things with it. Hopefully you enjoyed this one. See you in the next session.
