There are many reconnaissance tools that may be built-into your operating system. In this video, you’ll learn about traceroute, nslookup, ping, pathping, netstat, and more.
The traceroute command allows you to map an entire path between two devices to know exactly what routers may be between point A and point B. This uses the tracert command if you’re in Windows, and if you’re running Linux, Unix, or Mac OS, you’ll use traceroute. The information displayed by traceroute is being received by routers on the network via ICMP Time to Live Exceeded error messages.
You’ll send packets out to the network. Those packets will cause the routers to create an error message, and send that error message back to you. And the traceroute command uses those error messages in order to build that route.
The parameter that we’re going to manipulate to cause these error messages to occur is the TTL, or Time To Live message. This is a value within the IP packet that designates how many hops or routers a particular packet should go through until it is allowed to be dropped by the routers. This is commonly used to prevent loops on the network, but it’s also very useful when you’re using the traceroute command.
As you’ll see when we run this command, it is very common for these routers to send back these ICMP Time Exceeded messages. But there are some firewalls or routers that will filter out, or not respond, to these types of messages. So there may be gaps when you’re performing these traceroutes where some of these devices are filtering out those messages.
The traceroute command in one operating system will probably be slightly different than a traceroute command used in a different operating system. They may use different protocols and different methods to be able to transmit to the network. For example, Windows uses ICMP echo requests, which is exactly the same information that is sent during a ping command.
So throughout the path, as we are building this route, we’re going to receive ICMP Time Exceeded messages. And when we finally make it to the far side, we will ultimately receive an ICMP echo reply. Unfortunately, ICMP as a protocol, is one that is commonly filtered. So you may find that running traceroute in Windows does not work as well as running traceroute in Linux or Mac OS.
To get around this problem, you can modify what type of protocol you’re sending out and there are options within Linux, Unix, Mac OS, and other operating systems to let you modify what information you’re sending to the network.
To give you an idea of just how much this varies between operating systems, in Windows we’re using ICMP, but in iOS, we’re sending UDP datagrams over port 33434. We can, of course, make changes to this and modify what we’re sending, but you can see there are big differences depending on what operating system you’re using.
Let’s step through the process of really what’s happening behind the scenes when we perform a traceroute command. We’re going to run a traceroute through this very busy network. We have Sam, who is on one side of the network, and Sam is going to run a traceroute to Jack’s machine, on the other side of the network.
You can see there are a number of switches and routers between Sam and Jack. Sam is going to start by sending this message to Jack with the Time To Live equal to 1. When that hits the first router, the Time To Live will be decreased to 0. And a router is designed to drop any packets that have a TTL equal to 0.
At that point, it will also send a message back to the original station, telling it that its message didn’t get through because the Time To Live was exceeded. When Sam’s computer receives TTL exceeded message, it notes that it took two milliseconds to receive that, and it received it from router one’s IP address, which is 10.10.10.1.
Now Sam performs exactly the same message, sending information to Jack’s IP address, but it changes the TTL to 2. The first router receives the message with TTL equal to 2. Since it’s going through the router, it decreases the TTL by 1, continues sending it on its way, and when that message is received by router three, the TTL is set to 0, which causes a TTL exceeded message to be sent back to the original workstation. And Sam makes a note again, that took one millisecond, and it was received from 172.16.1.2, which is the IP address of router three.
This process occurs again, with Sam now setting the TTL equal to 3. It makes its way through the network from router one to router three. This time it makes it all the way to router four before the TTL is exceeded. And that message is sent back to Sam’s workstation. This is one millisecond later, and 172.16.3.1 is the router that reported that message.
Sam now sends another message to the network with TTL equal to 4. That means it will make it through the first router, it will move to the second router, finally to router four, TTL is still equal to 1, and it makes it all the way to Jack’s workstation.
Jack’s workstation will also decrease the TTL by 1, which means the TTL will be exceeded, and that message will be sent all the way back to Sam. But this time, the IP address that was received was the original destination IP address, and our traceroute is now done.
Let’s watch this happen now in real time as we run the traceroute command. I’m going to run this traceroute command to Quad9, which is a DNS provider. And when we hit enter, you can see it run through the traceroute process. Does that very quickly through the 13 hops that made it all the way to DNS9.quad9.net.
Each step along the way gives an IP address, where we receive the ICMP message from, and it gives three different options by default because it tries three times on each one of those hops.
On the last hop, on all three of those different tests, we received an exclamation mark Z, which means connection to that particular IP address is administratively prohibited.
Now that we know what this route looks like, we can compare it later on if we run into a problem. For example, if we ran this traceroute later and it stopped at hop seven, we would know exactly where this problem was occurring, and we could focus our efforts on resolving the network outage at that particular point.
Another useful reconnaissance tool is querying a name server to gather information about the devices that might be on a network. We can do this with two common commands. One is the nslookup command, and the other is the dig command.
The nslookup command is common in Windows, Linux, Mac OS, and other operating systems. And they can query a DNS server to determine names and IP addresses. You’ll find that nslookup is slowly being deprecated from a number of these operating systems, so it may be that your operating system doesn’t have nslookup, but it does have the dig command.
Dig is effectively the replacement for nslookup, but it does have some additional functionality as well. This is probably going to be the first choice you use. And there are ways to install this on Windows, which doesn’t necessarily include the dig command by default. You’ll find information on that at ProfessorMesser.link/digwin.
Let’s start with the nslookup command, and we’ll query the domain ProfessorMesser.com. The results are coming directly from Quad9, and you can see that the answers provide us with three separate IP addresses for the same ProfessorMesser.com domain.
This is by default, because I do have some redundancy built into the connections to my web server, and you can see how the redundancy works using Cloudflare. Let’s run the same query again, but instead of using nslookup, let’s use dig to ProfessorMesser.com.
It’s going to, again, query the Quad9 server, because that is my default DNS on this machine. You can see a lot of other messages about what we are querying and the answers that we are receiving. In the answer section we’re getting a lot more information than we got with the nslookup command because we can see the domain name, we can see time out information for caching, we can see that this is an address record, and you can see all of the different IP addresses that are found on that particular DNS server.
If you’re performing some type of analysis or reconnaissance on your network, then you’ll need to know the IP address of the device that you’re connected to. And there are two ways to do this, depending on the operating system you’re using. You can commonly use ipconfig and ifconfig to gather those details.
This is going to tell you about the IP configuration of this device, and any other information about the network adapters in this computer. If you’re running in Windows, this is the ipconfig command, and in Linux, this is commonly the ifconfig command.
In Windows, we run the ipconfig command. And we can see DNS suffix information, IP address, subnet mask, and default gateway. If you need more details about this particular configuration, we can run the ipconfig command again, but use the /all option, which provides us with much more detail.
We can see things like the description of the network interface card, Mac addresses, additional details regarding the DHCP lease, and other important IP address information.
In Linux or Mac OS, you would commonly run the ifconfig command. And on my system, I have a number of different adapters because of all of the different virtualization clients, but if I scroll up a bit you’ll find the physical address on this device, which is EN0. And you can get information about this device such as its Mac address, IP address information, and IPv6, and here’s my IPv4 address, which is 10.1.10.249.
Sometimes you just want to know if a device happens to be on the network. And an easy way to find that information is by using the ping command. Ping is a troubleshooting tool that you will use constantly to be able to see if a device is communicating on the network, or if it happens to be assigned to another device.
This is a utility that’s been around since 1983. And Mike Muuss created this and named it from the sound that sonar makes when you ping another device. Let’s run the ping command to see if device 9.9.9.9 is responding to our messages.
So we’ll use the ping command to that Quad9 address. And you can see we immediately get responses back for that particular IP address, and we have around trip time, and Time To Live information associated with that as well.
This will continue to ping in my operating system until I use the Control C command, and then that will give us a summary of how these pings have worked from the time we started the ping until the time we interrupted it.
In Windows there’s a command that merges together the functionality of ping and traceroute to create a single command called pathping. Pathping will run a traceroute to a destination IP address to determine what routes may be between your local device and the one that you’re running as part of pathping.
Once that’s complete, pathping will measure the round trip time to every hop along the way. And you’ll be able to see exactly how much information was sent to that hop, and how many of those packets may have been dropped.
Pathping takes a number of minutes to run. So instead, I’ve taken the output and put it on the screen here. I ran pathping on my Windows device to IP address 8.8.8.8, which is the Google DNS server.
Pathping created this very familiar traceroute, and then began the process of computing statistics for each one of these hops along the way. Once pathping creates that report, we now have a comprehensive view of exactly what’s happening on the network between these two locations.
We have a round trip time to each one of those hops, we can see how much traffic may have been lost on the network from the source to here and on this node, and you get a percentages of each step along the way. So you can see most of this, we were losing no traffic.
Nothing was lost. Of the 100 messages sent, we received all of them. Until we got all the way down to this particular hop, you can see that 100 packets were sent, and 100 packets were lost, making this a 100% loss for this particular IP address.
It’s probably the case that this IP address is administratively configured to drop this type of traffic, and so once it hit that particular route, it wasn’t able to get any statistics. The pathping did continue however, and we do have statistics for the hop right after that, which was the Google DNS server.
There may be times when you’re looking at a set of local log files, or you’re looking through a packet capture, and you’re seeing some IP addresses that a device may be communicating with. And you might want to know more about the conversations taking place across the network to that IP address.
One way that you can begin gathering some of this reconnaissance is by using the netstat command. This stands for Network statistics, and it’s very good at showing us exactly what IP addresses may be communicating into our device, and what IP addresses our device may be communicating to. There are many different options available in netstat, making it a very powerful reconnaissance tool.
But let’s look at three different options that can really help you. The first is netstat-a, which will show all active connections that are being used currently on that device.
If you’re in Windows, you may want to use the netstat-b command. If you’re in Windows, you may want to use the netstat-b command. This will associate the Windows binary with the IP address conversation.
And lastly, if you would like just IP addresses, and not resolve names, you can include the -n option on the command line.
To use the -b option in Windows, you have to start your command prompt in administrator mode. So I’ve open to new command prompt with that elevated permission. And I’m going to use the netstat command with all of those options, the -a, the -b, and the -n. It will then go through the process of evaluating what conversations are occurring between my device and others.
And if I scroll up, you can see a number of the different executables that are using the network. Some of these are internal to Windows, others are executables we might expect, such as onedrive.exe, or microsoft.photos.exe.
And if you’re using a browser, like I am with Google Chrome, you’ll see all of the different sessions the Google Chrome is using to communicate between my local IP address and an IP address on the internet.
In my local network, there are a number of devices that are currently active. And I know what the IP address of those devices is, but often you won’t know what the Mac address of those devices might be. And sometimes that Mac address is important, especially if we’re performing some type of packet analysis.
One way that you could determine what that Mac address is is to look at the local ARP table. And you can do that by using the ARP command with the -a option.
Let’s look at our cache with the ARP-a command. And you can see on my network there are a number of devices that are stored in my ARP cache. Probably the most important one for me is my local router, which is 10.1.10.1, and you can see the Mac address of that device.
Now if I ping another device on my network– so let’s ping 10.1.10.249. And now let’s again look at our ARP cache, and you’ll see that the Mac address for 10.1.10.249 has been added, and there’s the Mac address of that local device.
It’s often useful to know what the next route might be outside of a network, or what other routes may be available or configured on a particular device. There are a number of different ways to do this, depending on the operating system you’re using. In Windows, the command is route print. And in Linux and Mac OS, you would use the netstat command with a -r option.
On this particular device, there is a single route out to the internet, and it’s my only route. So if I perform a route print, I should see my default route of 0.0.0.0 with a netmask of 0.0.0.0.
That designates my default route, and you could see that that route is to 10.1.10.1 on this particular network. This is my local IP address. And the metric of 25 is the lowest in this list. So that’s the one that has the priority.
On my Mac OS device, let’s run the netstat command with a -r. And this will list out all the IPv4 routes, and IPv6 routes on my device. If I scroll up a bit, you can see the default route. And this is to the same route as my Windows device, which is 10.1.10.1.
I do have some other routes from this particular device. For example, if we scroll down a bit, you can see the 10.10.10/24 network, and it’s communicating to a router at 10.1.10.211. I have another network that I route to, which is my 192.168.254 network, and it also can be reached by going to 10.1.10.211.