CompTIA Pentest+ PT0-002 – Section 5: Active Reconnaissance Part 6

47. Networking Traffic Analysis (OBJ 2.3)

In this lesson, we’re going to conduct some basic network traffic analysis. Now, for the exam, you need to be able to understand how to analyze the results of a reconnaissance exercise as you look at network traffic. You can do this either using Wireshark or tcpdump, or some other tool. For the exam, they are not going to be specific on the tool being used, but instead, they may show you a couple of lines from a small packet capture, either in the format of tcpdump or Wireshark, and ask you to conduct some basic analysis on it to identify what services were being used, what ports and protocols were being used, and possibly what vulnerabilities you might see inside that network traffic.

Let’s go ahead and jump into Wireshark first, and then we’ll go and look at tcpdump. Wireshark is a packet analyzer to be able to pull apart some network traffic and show you the different layers of the OSI model, but for right now, I just want you to focus on how I’m pulling apart these different layers and the type of information I can get from Wireshark. Now, the first thing we need to do is have a file to look at.

So, I have couple of different packet captures, and I’m just going to open one up here, and it’s going to be right here. This is an HTTP connection. So, what I’m showing here on the screen is everything that happened for one computer to make a request, from my computer to a server and back. So, as you can see here, it starts at time zero, the source IP is my machine that sent the request, and the destination IP is the server I’m trying to go to. That’s how we read these things. It’s time, source, destination, the protocol used, in this case TCP, and then the information that was sent.

As you go through, you’ll see there’s this two-way conversation going back and forth between the two, and what you’re seeing here is actually the session traffic that was captured from one host to one server. Now, as I scroll down a little bit further, you’re going to see it goes down to 43 different line items happened, it took 30 seconds total, and we’re going to go in and look at some of this information. So, let me go into this first packet, and here in the middle section, you’ll see that we have frame one.

This was the first frame. Now, going back to our OSI model, what is frame? Where do frames operate? Well, they operate at layer two, so I should expect to see some layer two data in here. What type of things are layer two data? Well, things like MAC addresses. So, if I open this up, you’re going to see that the encapsulation type was Ethernet, which is a layer two protocol. We can see the time it arrived, we can see the time that it left. We can see what frame number it was and how long the frame was.

We can see how much was captured and all that type of information there. Next, if I go into Ethernet Two, this, again, is part of Ethernet, which is layer two, and inside layer two, we can see our destination and our source. So, this is our destination. This is the server I was trying to get to, it’s the MAC address, and underneath it, we can see the source, which is the machine that I had that made the request, and it happened over IPv4, and if I bring this down, you can actually see even further details. Now, the next thing I’m going to look at is IPv4. When I start talking about IP, what are we talking about now?

We’re talking about layer three because we’re talking about internet protocol. This means that we’re going to have source and destination IPs, as you can see here, highlighted in blue. And if I open that up, you’ll see that this was version four, we can see the header length, and then we can actually dig into that packet. The big thing we want to take away is layer two was MAC addresses, layer three was IPs.

Now, when we go to layer four, we’re going to be talking about, did we use TCP or UDP? In this case, we used TCP, so this is our layer four of the OSI model, and as you can see, we’re building up each of these layers, and all of that was one packet, one 62-bit packet that we captured. So, the next one I’m going to do is the one that came back from the server to the host. So, we sent the SYN over, and now we got back a SYN-ACK.

As we look at that, we can see the same type of information, the same layout each time. You’ll see that we have our frame, our layer two addresses, our IP addresses, and then our TCP protocol, layer four. So, layer two, layer two, layer three, layer four, okay, and we can go through the entire packet and look at each and every one of them. Now, if I want to figure out what was happening during this session, I can do that as well.

So, if I go in here, I can see that there was a GET request over HTTP. Now, HTTP is a protocol, it’s an application, so this is actually a layer seven capture here. And what was done, if I open this up, I can see that they went to the server ethereal.com, they were using Mozilla, which is Firefox, and that they came from this webpage, ethereal.com/development.html, and they clicked on the link for download.HTML, and that’s what we’re asking for. We’re asking for the webpage download.HTML at this point. This, then, is acknowledged by the server and goes back and forth as they’re getting more and more data, and eventually we get that webpage downloaded.

In fact, if I right-click on this, I can tell it to follow the stream, and I can see what that webpage looked like. Now, this webpage is being shown to me in HTML because that’s how webpages are sent, but this is exactly what this person got when they went to that website, and we captured all of that in those network packets. I could actually copy this, make it into an HTML file, and then load it up inside of Internet Explorer or Edge, or Google Chrome, or Firefox, and be able to look at all of that. So, I think that’s enough of that capture. Let’s take a look at another one and see if it looks similar. The next one I’m going to look at is this one here that says FTP, and what FTP is going to do, it’s a file transfer protocol. It’s going to be very similar. You’re going to see that we went from a source to a destination, and then went back and forth a whole bunch of different times. And in this case, it was a much longer stream, 561 different packets went through that were captured.

So, if I go back to the first one, you’ll see that there was this acknowledgement, and they went back and forth, and we can go through here and see frame, again, that’s layer two, Ethernet. And so, again, we can see the source and the destination as far as those MAC addresses. If we go down to the next one, we go up to layer three. We’re now seeing the source and destination IP addresses, and when we get to layer four, we’re able to see that this was a TCP session, Transmission Control Protocol.

And so, again, if I wanted to, I can right-click this and follow that stream. Now, when I follow that stream, what am I going to see? I’m not going to see a pretty webpage because this was FTP traffic. Somebody was downloading a file. All of this, if I convert it back into its hexadecimal or binary format, let’s go to Raw, for instance, I can copy this in and try to figure out what type of file it was and put that back together. And that’s what happens with network forensics and digital forensics. You can capture everything going over the network into these pcap files, and you’ll be able to open them inside of Wireshark to see what type of traffic is being used on the network.

Really, you’re going to be focused mostly on this screen, the source and the destination, the protocol, and even the ports. You could see here, it went from port 80, the web port, to port 2727. The server then answered up from 2727 back to port 80, and they went back and forth throughout this communication. Let’s open up one more. We’re going to open up Telnet. Now, Telnet is a way to remotely control a computer.

Again, you’re going to see that we have the time, the source, the destination, and the protocol, just like we did before. We have our SYN, SYN-ACK, ACK, which is that three-way handshake, and again, down here, we have layer two, layer two, layer three, and layer four. Now, in the Protocol column, you’re going to see TCP, but you’re also going to see this Telnet data, and that is an application, so this is layer seven again, just like we saw with HTTP before. And if I go over here, I can see that layer seven now is added, and I get different information for that.

If I go through and right-click it and follow that stream, let’s see what we get this time. There we go. So, what we’re seeing is the person and their session when they tried to connect to a Telnet server. So, what you see in blue is what the server sent back. So, when they connected, the server said, hey, I’m an OpenBSD server, log in. What the person did was they typed F-A-A-E, which you can see is red. That’s what the user sent to the server, and the blue is what the server displayed on the screen, which was F-A-K-E, so their username was “fake”. Then it asked for their password, and the user typed in “user”. So, their username is “fake” and their password is “user”. At this point, they were able to log into the server and start running commands. They ran the ls command, which, if you remember from A+, on a UNIX system, it’s going to list the contents of a directory, and then they did it again, ls-a. They wanted to see it going across the side, and you saw, this is what came back.

This is the list of directories. Then they tried to run a program, sbin/ping, www.yahoo.com, and that is showing that they tried to do a ping from this Telnet server out to yahoo.com and they received this information back. Now, we’re seeing the entire conversation, we’re seeing both halves, but if I wanted to see just what one person sent to the other, I can see the server side. It’s a lot easier to read, right? But now I don’t see that password.

I don’t see the commands that got sent over. When I go here and I switch it over to the client’s side, this is what they typed in. I can see that they typed in “user”, which was their password, “fake”, which was their username, and then the commands, the list command, the list all, and the sbin/ping, www.yahoo.com, and then exit.

So, you can see how this is useful, where we can start digging into this stuff. Next, I’m going to show you a little bit about how we use tcpdump. Now, my goal here is not to make you an expert in it because for the exam, you don’t actually have to know how to use tcpdump, but you should be familiar with the fact that tcpdump and Wireshark are both used to capture packets and then analyze those packet captures. tcpdump is a text-based program, and you use it inside the command line.

Now, what I’m going to do here is, first, I’m going to start using tcpdump inside my Mac OS X environment. It comes installed by default inside Mac as well as in Linux. If you’re going to use tcpdump, you need to know what interface you’re connected to the network on. In my case, it’s en0. So, to use it, I’m going to do sudo because you must be running this with administrative permissions to be able to turn your card into promiscuous mode, and then tcpdump-I, and then your interface, en0 if you’re on a Mac. If you’re on a Linux machine, it should be eth0. So, I’ll go ahead and type in en0 and hit Enter.

Now, at this point, I’m putting my card into promiscuous mode and I’m starting to look at everything that’s going across the network. And here you see information going across the screen, showing me all sorts of different connections that are happening on this network, both from my computer and other computers on the network. Now, this isn’t nearly as helpful as being able to look at things slowly or by filtering it down, but that’s okay because we can do that using tcpdump as well.

Instead of displaying it to the screen, I’m going to go ahead and hit Ctrl+C, and that’s going to pause that and cancel my collection, and now I can see a couple of things here. If we start up towards the top, you’ll see that my IP address is 10.128.1.130. The first line there is actually going from my computer over port 57963 to that particular website that you see, which is 1e100.net. It’s doing this over HTTPS, which is port 443. There was no flags in that packet. There was an acknowledgement that was received.

You can see the windowing, the options, and the value. That is one packet with one timestamp. Then you go down to the next one, there’s another one, and the next one, there’s another one, and there’s lots of information here. Now, let’s say, instead of looking at data from all different things on the network, I only wanted to see things that came from my computer. Could I do that? Well, certainly. What I can do is clear my screen, and then I will use sudo tcpdump.

I will type in source, which is the IP I want to collect from, and in my case, it is going to be 10.128.1.130, and then I will hit Enter. Now, all you’re going to see here is traffic going from the .130, my host, to somewhere else on the network, and right now there’s not much going on because I’m sitting here talking to you and not browsing the internet. But if I was browsing the internet and doing other connections, those would all be showing up here.

What you’re seeing here is a lot of different beaconing and keepalive traffic for different programs I have on my computer, and that’s what we’re seeing here. Now, the next thing we want to do is go ahead and hit Ctrl+C, and this is also helpful, but again, it’s not extremely helpful because if I had this running on a large enterprise network, there’d be so much data whizzing by my screen, I wouldn’t be able to read it all. So, we’d want to write that to a file.

How do we do that? Well, again, I’m going to clear my screen so I can go to the top, and I’ll bring up the last command I did. If we want to do this and write it to its file, we can just type in -w and then the file name that we want. And so, in my case, I’m going to call it host130.pcap, and then hit Enter. Now that information is going to go into a file that’s going to be captured on my hard drive. As it’s sitting there listening, it’s picking up any traffic that’s going from that source, 10.128.1.130, and it’s writing it to the file host130.pcap.

Now, once we have enough of that, we can hit Ctrl+C, and in this case, we captured 161 packets of information. Again, it’s very little information right now because it’s basically background tasks on this computer because I’m not actively running things because I’m not sitting there browsing the internet. Now, if I wanted to be able to see that information, I can do that by doing sudo tcpdump, and then -r, and then the file that I did, host130.pcap. When I hit Enter,

I’m going to see all 161 packets from that file and display them to the screen. Here’s the first bunch, and then it’s going to keep reading them and displaying them to the screen. Now, again, that’s a lot of information, and I only did that for about five or 10 seconds. If I had this running all day, that’d be way too much information to go through. So, instead, we would want to start filtering that information, and we can do that based on a lot of different things. For instance, if I look at this particular packet right here, you can see that it is going from the host at 130 over port 5475, and it’s going out to the broadcast of the network at .255.255 over port 5474. If I just wanted to see every time that there was a beaconing that was going out like that, I can do that. And so, what I’ll do is I’ll hit Clear, I would type in sudo tcpdump, source, src, and then port, the port I want to see. In this case, that was 5475.

And then, again, I need to read it from the file, so -r host130.pcap. If I don’t put the -r host130.pcap, what it’s going to do is it’s going to look at the live traffic, and anytime it sees a source port of 5475, it would display it to the screen. But in this case, I want to go through and analyze what I already captured, so as I did that, you can see here a handful of times that that happened. Now, if this was malware it was beaconing out, I could see exactly when that happened. In this case, this particular packet is being sent out every second, 19:06:51, 19:06:52, 19:06:53.

Now, this is just the header we’re seeing, and we can see this is a UDP packet that’s being sent out with a length of five. Well, what if you wanted to look inside this packet and see what was actually sent? Can you do that? Well, sure you can. We can do the exact same thing we just did and then add the command -x, which will show the packet’s contents in both hex and ASCII. So, let me go ahead and clear my screen, and then go here and add -x. Now I see all those packets again, done by time, and here I see the IP where it’s going from, where it’s going to, UDP, length five. Then you’re seeing that five bytes of data. Notice here, we see it in hex first, and then we see it in ASCII on the right-hand side.

This will allow us to go through and see what was being sent. This can be extremely helpful if somebody’s using something like FTP or HTTP, where things are being sent in the clear. Now, as I said, what I did here was just a very, very quick demonstration to show you some of the capabilities of this tool. If you want to learn more, I recommend you go into the man pages for tcpdump, and just type in man tcpdump, and hit Enter. This will bring up the manual, and you can see all of the different options and all of the different ways you can filter down content. Remember, you can filter during collection or you can filter after you’ve collected, when you’re reading things. Why would you want to do one versus the other? Well, again, let’s say I was running a big, large enterprise network.

One of the organizations I worked for, we ran a network with tens of thousands of computers, and so, if I said, show me everything that’s coming from this particular IP address or this particular port, or is beaconing out to a known bad actor’s command-and-control server, that could be a ton of information. So, we would want to just filter down on the collection because we’re only interested in what we are looking for instead of every single packet sent across the network internally or out to the internet. And so this is why it’s important for you to think about, what are you trying to collect, and filter that down on the collection to reduce the size. On the other hand, if you’re not sure what you’re trying to collect yet, you may collect everything, which can take up tons of space, and then filter it down as you start reading through and going through those logs.

• Category: Uncategorized