This chapter will teach you how to use Wireshark to analyze network security issues, such as analyzing malware traffic and foot printing attempts. You will learn how to use Wireshark for network security analysis. This chapter will cover the following topics:
- Analyzing port scanning, foot printing, and attack activities
- Lab up—port scanning with Nmap
- Analyzing brute force attacks
- Lab up—analyzing brute force attacks
- Inspecting malicious traffic
- Lab up—inspecting malicious traffic
- Solving real-world CTF challenges
- Practice questions
Up to this chapter, I have tried to make you aware of how one should use Wireshark to analyze the packets flowing around. We have just focused on how to use this sniffing tool for basic analysis purposes. However, what I am about to tell you is that in most of the places, Wireshark is used for security-analysis purpose, ranging from basic footprinting attacks to advanced Trojan-based attacks.
Using a couple of scenarios in my virtual lab, I will try to duplicate the most common one, along with capturing the live traffic between the attacker and the victim. Later on, we will dissect the trace file to get an idea of how malicious traffic looks like. We will use this knowledge base to create IDS/IPS or firewall signatures in an attempt to protect our internal critical infrastructure by analyzing the traffic shown in Wireshark.
To achieve all this, you need to change your perspective a little bit. In other words, you need to act and think like a security professional who is in charge of the corporate network and constantly working to tighten the perimeter that will make the attack process more complex for bad users. We can start all of this by analyzing the packets captured for our daily usual traffic and also duplicate certain scenarios.
The primary step in the exploitation process is to collect as much information as you can. In today's world, gathering specific and relevant information about a person or an organization is not so difficult (using search engines), and this is where everything begins. A lot of security professionals will start launching attacks directly on the targets, which is not appropriate in the beginning. Let's say, for example, there is an ABC Corp. Ltd. located in the next block, and an XYZ attacker is planning to exploit it in terms of physical security (to get entry to the server rooms or any high-valued target available inside). To do so, the first thing the attacker should know is the working hours and the non-working hours. Then, they should know about the working days in the targeted company. The attacker should also know about the physical layout of the building the company is located in, and they should have some basic knowledge about the security policy. With all this information, the attacker should be able to identify the weak points inside the premises that might be an easy target and can give access to what they are looking for. Did you notice what just happened in the preceding scenario? We assumed that the attacker is collecting useful information and then planning and figuring out the easy targets to attack, because following this approach will improve the chances of success. Footprinting and reconnaissance are synonyms for the term information gathering. The chances of success would be higher if you are following the planned approach.
Let's use the same approach in targeting an organization using networks. The first step would be to identify the public IP address of the organization, the subnet it belongs to, and the range of IP addresses allocated to the organization. This basic information can be passively (without directly interacting with the company's network) collected through the use of DNS lookup services available online. We can try to check whether zone transfer is available, which can give some juicy and granular details regarding the organization's infrastructure we are targeting. After you have collected the basic information and have mapped the basic layout, you are ready to perform a port scan. I would prefer that you do a ping sweep first, which will tell you about the live machines over the network, and from where you will get to know more about the network (while performing a ping sweep, you can modify the TTL value to figure out the internal LAN architecture).
Before we go ahead and try duplicating the most common scenarios, I want you to visualize the local virtual computer infrastructure I have created for practice purpose. Refer to the following figure:
Hopefully, now you have a rough idea about my internal network that I'll be working with. The access point located at 192.168.1.1 assigns the IP address to all these devices using DHCP (the DHCP range starts from 192.168.1.100 and continues up to 192.168.1.110; it means I can have a maximum of 10 DHCP clients at one instance). For this chapter, the IP address for our attacking machine is static assigned to 192.168.1.106.
Let's begin with our first scenario where an attacker would try to perform a ping sweep attack over the subnet, and the traffic generated is captured by our sniffer listening through its interface in the promiscuous mode Refer to the following figure that displays the traffic pattern that was generated after running a bash script the script pings each IP starting from 100 to 110):
Figure 7.1: Ping sweep
Starting from packet 1–4, the Kali box started generating an ARP request because of the ICMP ping command issued, but none of those IP's are allocated. Hence, we did not receive any replies. In packet 5, Kali box sent a ping request to 105, and the reply for it was received in packet 14, which means the device is on. Then, in packet 7, an ARP request was sent to 103, but this IP might also be unallocated for the instance, so no reply again. In packets 8–10, Kali box sent an ICMP request packet to IP's 102, 101, and 100. The reply for the same can be seen in packets 13 and 15 from IP's 101 and 100. For 102, we did not receive any reply. It might be any device blocking our ping probes or some mobile device not responding to the ping probes. Finally, in packet number 17, we can see that the access point is informing the Kali Machine about its physical address. If you scroll down through your trace file, you would see various replies from online devices describing their physical addresses.
The next step in the process would be to scan any specific device that you would like to target. Let's suppose I want to target my Win7 machine running at IP 192.168.1.105. My next step should be to check for available services running on that box. By services, I mean HTTP daemons, mail server daemons, FTP server, and so on. You might be wondering what a half-open scan is? Look at the process of a TCP three-way handshake we discussed, where the client initiates the connection by sending a SYN packet if the server is available. Then, the client receives the SYN, ACK packet, and in return, the client sends an ACK packet to the server for completing the handshake process.
Now, what would happen if the ACK packet sent in the last step of the TCP handshake is never sent to the server? The server will wait for a specific period before terminating the handshake process initiated by the client, and the connection to the specific TCP service would never be completed. That's why this type of scan is called half-open scan. This is a very common scanning technique used by the majority of users who are involved in malicious activities, being aware of such traffic pattern could help us in identifying future risks. I initiated the half-open scan from Kali box to target Win7 box. I am using Nmap, which is an open source tool available for every platform and can be downloaded for free from http://nmap.org (to use the tool, you can refer to various tutorials available online). The traffic generated because of the SYN scan is captured and shown in the following screenshot:
Figure 7.2: Half-open scan
There are three kinds of replies that you can see after the scanning is completed: Open, Closed, and Filtered. Now, the point to discuss is what these states mean and what relation do these states have with the packet shown in the preceding screenshot. Let's look at the states in more detail here:
- Open: If a service is open, then a
SYN,ACKpacket will be sent back to your machine for taking the TCP handshake process to the next step of completion. In packet26, Kali sent anSYNrequest to port 135 and received aSYN,ACKreply in packet28. - Closed: If a service is not available to respond, then you would receive an RST packet that confirms that the service/daemon is currently not running. In packet
22, aSYNrequest was sent destined to port113. In packet25, the RST packet for the same is received. It states that the service is not available at this moment. - Filtered: Sometimes, a firewall might be configured between you and your target that might be intercepting your requests and would be dropping them without forwarding them to the target. In such scenarios, you might be seeing port states such as
open|filtered,closed|filtered, or justfiltered. - Let's suppose you are trying to scan an HTTP webserver that is outside your VLAN and is restricted by the firewall from your machine. Then, the handshake process would never move to the second step, that is, you will never receive a reply of any kind. You will not receive any
SYN,ACKorRSTpacket.
Using this scan type, you can identify the state of the services running. However, using this kind of scan type will generate a hefty amount of traffic too. The scan I initiated was completed in 1.76 seconds, and in such a short time, it generated 2024 packets between the two machines. Now, this proves disadvantageous. Any well-configured IDS/IPS can figure out such activity very easily, which will in turn trigger an alert to notify the security admins. Nmap has configurable switches that can help you out in these situations too.
Being aware of the operating system running on the target takes the scanning process to the next step in the methodology. If the attacker knows about the OS you are running, the patch level of your OS, and the version of your OS, then it would be quite simple to structure the attack process and will increase the chances of success.
There are a couple of tools available in Kali that will let you identify the target's OS. It is not 100 percent accurate, and it is correct most of the times. Now, how do you think a simple tool is available to identify the remote machine's OS? I will tell you the secret. Every OS has a different way of implementing the TCP stack. So, a packet received from the remote machine will have certain fields in it such as TTL, fragment offset, and most importantly window size. By comparing the values in the packet with the database we have, it will tell you the OS. For example, if you try to ping a Windows machine, the TTL value returned would be 128, and if you ping a Linux machine, the TTL value would be 64 most of the time. Simple, isn't?
There are two types of fingerprinting: active and passive. They are described here:
- Active fingerprinting: When you are directly interacting with the system, the requests and responses are directly shared between you and the target. This kind of scan can be really dangerous and is not stealthy. The captured packets will give you values that can be matched with the signature we have to identify the OS running on the remote machine.
- Passive fingerprinting: When you are just listening for the packets originated or destined to the target, the values in the packets can be examined in order to identify the OS running. A disadvantage off passive type scan is that it is not as accurate as active fingerprinting. But the process would be stealthier than active scans.
Using the nmap scan, I will try to fingerprint a machine at IP 192.168.1.109 and 192.168.1.104 and see what kind of traffic is generated due to such requests. The type of scan we will witness is active scanning, and we will be directly interacting with the systems. We won't just rely on Nmap's output to confirm the OS. The packet that would be returned to our attacking machine is the base of all necessary information, which I will try to dissect for your better understanding.
I will use the nmap –O 192.168.1.109,192.168.1.104 command for active OS fingerprinting, where the –O switch is for checking the OS and its version. Refer to the following two screenshots to compare the outputs they present to us:
Using just the TTL field, we can verify that the first traffic we captured is from some Linux/Macintosh-based machine, as the TTL value is 64. The second traffic screenshot belongs to a Windows machine as the TTL value is set to 128.
Secondly, the maximum segment size highlighted at the bottom can also be a deciding factor for OS fingerprinting. In both cases, it is 1460. The value is correct if you are talking about a Linux-based machine, but if it is a Windows machine, then you might observe that the value is 1440 most of the time.
For both Linux and Windows platforms, the Fragment Offset field should be 0 (not set). See how, simply by observing basic fields in the TCP header and IP header, we were able to fingerprint on our own. Now let's see what nmap has to say.
Refer to the following screenshots for illustration:
Figure 7.3: nmap output for 192.168.1.104
The nmap output for the machine IP 192.168.1.104 detects that the machine might be one of these OSes running (in the red box). I think what we figured out and it is quite close. OS detection by nmap is done by analyzing the requests and responses traffic that the target machine generates.
The nmap output for the machine at 192.168.1.109 says that it is a Windows server machine, may be SP1 or SP2. This time, the result is more accurate than the previous one. We also presumed that it would be a Windows OS, and it is.
The traffic generated from both these scans would be quite similar to the SYN scan traffic where the TCP handshake request and ICMP request/replies can be seen. Once the attacker's machine running nmap receives the replies for the requests made, it will start analyzing and comparing the results with the database of the results it already has. Thus, in the end, after comparing the values, Nmap will present you with the most accurate results.
So, if you are seeing a lot of RST or RST, ACK packets sent from one of your internal LAN machines, then it is something that you should be worried about. Better create signatures for such traffic in your firewall so that they can alert you.