In this article, we are going to focus on a tool that caught my attention. This is a tool that creates a fake Windows Logon Screen and then forces the user to enter the correct credentials and then relay the credentials to the attacker. It can work in different scenarios.

This tool was developed by Arris Huijgen. I have already talked about the working of the tool. It doesn’t do much other than that.  To better understand the working of this tool, I will be performing a practical on the said tool using the systems configured as depicted.

Download the executables for the practical by clicking here.

Table of Content

• Configurations used in Practical
• Scenario
• Payload Creation
• Starting Listener
• Uploading the FakeLogonScreen Executable
• Credentials Entering on Target Side
• Grabbing the Credentials
• Additional Information
• Mitigations

Configurations used in Practical

Attacker:

    OS: Kali Linux 2020.1

    IP: 192.168.1.13

Target:

    OS: Windows 10 (Build 18363)

    IP: 192.168.1.11

Scenario

There is a system that is connected to the same network as the attacker and the attacker is hunting for the credentials of the Target System. The Information that the target already has is the IP Address and the knowledge of the OS system. This kind of information is quite easy to get by.

Payload Creation

Now, to get started I used the msfvenom tool to craft a payload according to the OS of my Target System. I provided my Kali’s IP Address as the LHOST. As the target machine was running Windows, I made my payload an executable file that can be executed easily. After crafting the payload, I ran a Python One-liner to create an HTTP server which will host the payload at the port 80 of the target machine.

Now in a real-life scenario, the attacker will use some kind of Social Engineering Attack to manipulate the target user to download this malicious payload on their system. This can be done long before performing the actual attack.

Starting Listener

Since we have our payload ready and hosted. Now we need to start a listener where we will receive our session from the payload. After setting up the proper configuration, I went straight up to the Target Machine and executed the payload. Again, this is a lab environment demonstration. Real-Life Scenarios will vary. 

Uploading the FakeLogonScreen Executable

After getting the meterpreter session, we upload the FakeLogonScreen.exe to the Target System. This executable can be found in the directory that is cloned. After successful upload, we get onto the command line of the target machine using the shell command. Now we run the executable as shown in the image given.

Credentials Entering on Target Side

As soon as we ran the executable through the shell, all the current windows on the Target System get minimized and a login screen pops up as shown in the image given. This seems a pretty real logon screen. The target user assumes that there must be an accidental log off. So, to assume his/her work, the target user unknowingly enters the credentials.

Now to demonstrate that the password is checked, we first entered the wrong credentials. The Logon Screen gave back an error “The password is incorrect. Try again”. This proves that the target user has to enter the valid credentials to get through.

Next, we entered the valid credentials and we see that all the minimized windows are restored back to the way they were.

Grabbing the Credentials

Let’s head back to our attacker machine to see if we were able to grab those passwords. As shown in the image given below, we see that the FakeLogonScreen listener works similar to a key logger. We first entered the “wrong password” in the password field to check the false cases. Then we entered the correct password “123” and we successfully grabbed the password for the target user.

Additional Information

I contacted the author of this tool to find out how effective this tool works in multiple desktop setups. When executed in multiple desktop setups, all the other desktop screen turns black. Also if the target user has configured a customized background, then that customized background is shown. This is a plus point in an office environment as those systems have a custom company image for Logon Screen.

We also have another executable in the zip file we downloaded earlier. It is named “FakeLogonScreenToFile.exe”. This file works in a similar way but along-with displaying the password, it stores the password at the following location:

%LOCALAPPDATA%\Microsoft\user.db

This tool also works on Windows 7. Although it has reached its EOL still there are a huge number of systems that are running Windows 7 on the Production. If required, it can be found inside the “DOTNET35” directory.

You can also integrate this tool to work with Cobalt Strike. Check out here.

Mitigations

• Verify Download Sources.
• Monitor the AppData Directory for the user.db file.
• Properly check all the links in the Logon Screen.
• Implement a Password Change Policy of a shorter duration.

Author: Pavandeep Singh is a Technical Writer, Researcher and Penetration Tester. Can be Contacted on Twitter and LinkedIn

In this article, we will learn about TShark which is a well-known network protocol analyzer. It lets us capture the data packets, from the live network. It also allows us, to read or analyze the previously captured data packets of a saved file.

Table of content

• Network traffic
• Introduction to TShark
• List interfaces
• Capture traffic
• Capture the interface in promiscuous mode
• Capture the packet count
• Read and Write in a file
• Verbose mode
• Output Formats
• Difference between decoded packets and encoded packets
• Converting PDML file HTML page
• Capturing packets of a particular port
• Display filter

Network traffic

As we know, network traffic or data traffic is the amount of data transferring across the network at some given point of time. Network data, in computer networks, is in the form of network data packets. Analyzing these network packets provides network security as it helps us to monitor traffic. As a benefit, if there is some unusual amount of data traffic in a network which is a possible sign of an attack then Tshark can help us know before it too late and the attack can be terminated as data traffic reports provide insights into preventing some good attacks.

Traffic volume is a term which comes under network traffic analyzing. Network traffic volume is the measure of the total work done. It is defined as the average data traffic intensity and time period of its network data packet study.

Introduction to TShark

Tshark, a well known and powerful command-line tool and is used as a network analyzer. It is developed by Wireshark. It’s working structure is quite similar to Tcpdump, but it has some powerful decoders and filters. TShark is capable of capturing the data packets information of different network layers and display them in different formats.

TShark is used to analyze real-time network traffic and it can read .pcap files to analyze the information, dig into the details of those connections, helping security professionals to identify their network problem.

TShark is a command-line based tool, which can do anything that Wireshark does. So let us start our learning process with TShark and therefore launch this tool and explore its options. To check out all the parameters, use the following command :

List interfaces

TShark prints a list of the interfaces whose traffic it can capture. Each interface is referred to by their serial number and as you can see it is followed by a text description of the network interface. These interfaces can be specified using -i parameter; which is used to specify the network whose traffic we want to capture. And to check out these interfaces you can use the parameter -D as shown in the image below :

Capture traffic

Let’s now try to capture traffic, we have various choice of interface to capture traffic and therefore one can choose whichever depending on their needs and requirement. But in our scenario, the interface which we are going to use is “eth0”. In order to capture traffic, we need to initiate one too as we are testing on a controlled network and for that use ping command and then to capture traffic we have to just specify the interface name by using -i parameter as shown in the image below :

As we can clearly see it is performing its three-way handshake, then starts the process of ICMP request and reply.

Promiscuous mode

In the networking, promiscuous mode is used as an interface controller that causes tshark to pass all the traffic it receives to the CPU rather than passing the frames to the promiscuous mode is normally used for packet sniffing that can take place on a router or on a computer connected to a wired network or a part of LAN.

When using this mode, we will need to configure it with the help of ifconfig so that it let us capture the data packets of the whole network. Therefore, we will start by pinging a website and try to capture its data packets.

Now, configure the promiscuous mode by following these commands and try to capture the packets :

Packet count

Tshark has amazing features with which we can work more efficiently and we can access these features using various parameters. One such parameter is ‘-c’, it lets us capture the exact amount of data that we require and it will display only those. This option helps us to refine the outcome of captured traffic.

As we can clearly see in the image above that it stops after the 10 counts.

Read and Write in a file

In Tshark we can write and read into .pcap file. Write option (-w) allows us to write raw packet data output to a standard .pcap file whereas read option (-r) help us to read that raw output data packets in our desired manner. To write the packets into a .pcap file use the following command :

And to read the said .pcap file use the following command :

Verbose mode

The verbose mode provides us with additional details of a packet in traffic. Using the verbose mode, we can see the information that each packet contains and for this option we can use the parameter -V.

Output formats

For our convenience, in tshark, we have -T option that lets us save decoded packets in various output formats. It can set the format of the output in the way that it becomes easy to understand. To see all the available options type the following command :

PDML

PDML stands for Packet Details Mark-Up Language which is an XML based. This information is quite equivalent to the verbose mode which we used earlier. And to have output in this format type the following command :

PS

PS stands for PostScript. This output is in a form of oneliner summary of each data packets or multi-line detail view of each data packets depending upon each data packet specification. These one-liners are very quick to understand as well as reliable. For this, use the following command :

PSML

PSML stands for Packet Summary Mark-Up Language. It is also an XML based format like PDML which summarises the detailed information of the packets. And for this format type :

JSON

JSON stands for Java-Script Object Notation. It is an open standard file format that displays text in a readable form. The information in this format is fully documented and referred at wolfram. To see that packets in this format, type :

EK

It is newline delimited JSON format function for bulk import into the elastic search option. And for this format use the following command :

Text

Text is a human-readable one lines summary of each of the packets. This is the simplest of the formats. And for this, use the following command :

Tabs

This option is quite similar to the text except, it includes an ASCII horizontal tab (oxo9) character as the delimiter between each column. To try this, type :

 

Difference between decoded packets and encoded packets

When we try to write the live data packets in a .pcap format file; we compress all that data packets in smaller segments. To better understand these data packets we need to decode them which leads to a difference in the size of the file and to check the size of any given file at the given moment use the following command :

Like we discussed there is a huge difference in these files, that’s why we use decoding techniques to extract this information.

Converting PDML file HTML page

The only difference between the Wireshark and tshark is that Wireshark is a GUI based tool and tshark is a command-line based tool. But with the help of some external source, we can also view our data packets in HTML. So to achieve that first, we need to save our data packets in PDML format and then convert it into an XML file using the following command :

The XML file will be saved at location /usr/share/wireshark/pdml2html.xsl. So, we are going to use xsltproc tool to execute this file it which will help us to create our HTML page. Creating the HTML page will format all the unnecessary information and only let us view the usable data. To create the HTML use following command 

To open the HTML page in the browser, refer to the above image and use the following command :

Capturing packets of a particular port

A lot of times we use Wireshark on a dedicated port. And by using the -f option we can capture data packets of a particular port. It helps us to better analyze the data packets of the network. We are using this feature to capture TCP port 80 and the command for this is :

Display filter

Display filter was introduced by Wireshark. It helps us to filter the captured data packets or live data packets. With the help of this filter, we can request for any kind of filter that we want to capture in the live environment.

In our scenario, we apply the GET request filter to capture only GET request from the traffic and for, use the following command :

Conclusion

This article focuses on the basic commands and functionality of tshark as it is the first article in the series. So get yourself familiar with the features of it as and stay tuned for the advance features of tshark in our next article.

Author: Shubham Sharma is a Pentester, Cybersecurity Researcher and Enthusiast, contact here.

In this article, you will learn the multiple ways to maintain access or create a persistent backdoor with the help of the Metasploit Framework on the host machine which you have compromised.

Table of Content

Persistence Backdoor

Pre-requisites

Methods for Generating persistence using Metasploit

• Persistence_service
• Mitigation method for persistence_service exploit.
• Persistence_exe
• Mitigation method for persistence_exe exploit.
• Registry_persistence
• Mitigation method for Registry_persistence exploit.
• Persistence through Netcat.
• Persistence through Remote Desktop Protocol.

 Conclusion

Persistence Backdoor

The word Persistence is simply known as permanent hence in this post, we are sharing the multiple methods to generate a permanent backdoor within the victim machine.

As there is a lot of hard work required to exploit any system and once the system is exploited successfully you need more time for further examine or penetrate the victim’s system but at that time if victim shut down his system or changed the credentials then all your hard work will be spoiled. That’s why maintaining access is an important phase of penetration testing. Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials and other interruptions that could cut off their access.

Pre-requisites

Window 10 -Victim System

Kali Linux – Attacker (Metasploit Framework)

Note: For creating a persistence backdoor, you should have a compromised machine of the victim with meterpreter session to continue all practices that are taught in this post.

Methods for Generating persistence using Metasploit

Let’s start, we already have compromised the window 10 (victim’s PC) and have meterpreter session along with the admin rights. To know how to get admin access click here. Now, we want to leave a permanent backdoor in the victim system that will provide a reverse connection for the next time.

Service Persistence

This Module will generate and upload an executable to a remote host, next will make it a persistent service. It will create a new service which will start the payload whenever the service is running. Admin or system privilege is required.

Thus, we will run the following commands on Kali Linux to run the above-listed module:

Above said module which will generate and upload an executable on the victim’s system under the /temp directory as  “lVFC.exe” and will make it a persistence service.

If the victim reboots the system, the previous meterpreter session will be closed. Only we need to set up the multi handler to run the payload by using the following commands:

Once the victim system starts, automatically we will gain the meterpreter session again.

When the PC is started automatically some of its services starts by default so persistence_service exploit creates a new service that will start the payload whenever the service is running. In the below image you can see the executable file IVFC.exe is running under username System and we can verify its path.

C:/Windows/Temp/IVFC.exe

Mitigation method for persistence_service exploit

First of all, identify the unfamiliar files which are running and then stop the running executable format file i.e. IVFC.exe and delete it from the temp directory.

Persistence_exe

This is the second method to maintain access to the victim’s PC. Under this scenario, we already have meterpreter session of the victim’s PC and it has user access.

This module will upload an executable to the victim’s system and make it persistent. It can be installed as a user, system or service. We will use this module by using the session 1(already compromised system’session) and set the rexpath (remote executable path), through this payload file will create on victim’s PC but due to persistence script, it will save under temp directory with default.exe name(change the name under rexname option ) and will set it to autorun under the registry path mentioned in below image.

 To run this module, type the following commands:

After, successful execution of the above module, now we have to set up the multi handle by using the following command:

Once the victim reboots its PC and the login into it, automatically we will get the meterpreter session.

In the below image you can see the function of persistence_exe, which will create the autorun service under the registry editor path:

due to which service will start running as soon as the victim’s PC starts. Its default file creates under the temp directory.

Mitigation Method for Persistence_exe

First, remove the entry from the registry editor under the path:

And then delete the executable payload file under the temp directory and reboot the system.

Registry Persistence

A registry is the core part of the window and contains a surplus of raw data. Attackers love to choose windows registry locations to hook their codes so that files or codes cannot be detected by scans for suspicious activities.

This module will install a payload that is executed during boot. It will be executed either at user logon or system startup via the registry value in “CurrentVersion\Run” (depending on privilege and selected method). The payload will be installed completely in the registry.

Since we already have compromised the victim’s Pc and have the meterpreter session along with the user privileges. Use the following command to execute the registry persistence.

Once the exploit executed, it will create a registry key under HKCU\software\wl4cN9w and installed key as highlighted in the image.

If the victim reboots the system, meterpreter session will dead get the session again just set up the multi handler payload and execute it.

Once the victim’s machine will start and as the victim will log in into the system, automatically we will get the meterpreter session again due to the autorun script under the registry which is installed by the attacker. Successfully registry _persistence is executed.

Through the below image you can verify the path of registry key created by registry_persistence exploit.

Persistence through Netcat

Netcat or nc is a utility tool that uses TCP and UDP connections to read and write in a network. It can be used for both attack and security. In the case of attack, it can be driven by scripts which makes it quite dependable back-end and if we talk about security, it helps us to debug the network along with investing it. To read more about netcat please refer https://www.hackingarticles.in/comprehensive-guide-on-netcat/.

Now we are going to make a persistence Netcat backdoor on the compromised system. As we already have meterpreter session, upload netcat.exe into system32 file of victim’s pc by using the following command:

The next step is to set the netcat to listen on the random port i.e.4445, open the port on startup and make the connection.

Use the following command:

On successful netcat connection, we get the shell of the victim’s PC.

We will add the new rule in the firewall named as ‘netcat’ in which inbound connection will allow for port 4445 by using the interactive cmd prompt running a command called netsh. Type the following command:

To check the operational mode and port status run the command:

When the victim reboots the system again, we will get the netcat shell. On Kali Linux(attacker system) run the following command to connect our netcat backdoor via port 4445.

Persistence through RDP

After having the meterpreter session of the already compromised targeted system. We will utilize Carlos Perez’s getgui script which enables Remote Desktop and creates a user account to login to it.

Username: Nisha

Password: 123

Run the following command:

With the help of the following module, it is possible to apply the ‘sticky keys’ hack to a session with appropriate rights. The hack provides a means to get a SYSTEM shell using UI-level interaction at an RDP login screen or via a UAC confirmation dialog.

As you can see here that we sticky is added successfully, now to launch the exploit at an RDP or UAC by press shift key 5 times.

Now we will check the connection using rdesktop and review the certificate and type Yes. By using the following command

Congrats !!! finally we get the Gui mode of the victim’s system.

 Conclusion

Persistence does not require any authentication to connect with the victim’s system. To complete the penetration testing, always remember to clean up the processes and the backdoor services on the victim’s host.

Author: Nisha Sharma is trained in Certified Ethical hacking and Bug Bounty Hunter. Connect with her here

Introduction:

When we say “ping,” we often are just limiting its definition to checking whether a host is alive or not. In my opinion, while this purpose is correct, its technical details are often ignored. Many network administrators are unable to answer what ping is in details; or how it works. So in this research-based article, I am going to present some points that I didn’t know before starting to read about the topic.

Tools used: Wireshark, command prompt/terminal, https://www.rapidtables.com/convert/number/hex-to-ascii.html

In this article, practicals are based on a Windows 10 x64 system to ping a Debian Linux x64 bit architecture. While this shouldn’t matter in many cases, it matters for a certain part where we calculate TTL and an anomaly case as well. More of that later though. While reading about this topic I learnt tons of new stuff that for me, as a penetration tester, would definitely be useful to understand in-depth how those exploits are working.

Let’s get to the good stuff now.

Table of Content:

• OSI Model
• Ethernet, IP and ICMP protocols
• Ping command and ping packet
• Wireshark and basic filters
• How is a datagram sent to destination host (understanding layers involved using Wireshark)
• Understanding data size in ping
• MTU in IEEE 802.3i
• Fragmentation in ping
• Anomaly in ping

OSI Model:

OSI stands for Open System Interconnection is a reference model that describes how information from a software application in one computer moves through a physical medium to the software application in another computer.

It has seven layers and each layer performs a special network task. They are as follows:

Each layer has a specific task to do and we’re not going into depth with each and every one of them. Let’s save that for another day. Let’s focus on layers 1, 2 and 3 for now.

Layer 1, 2 and layer 3 combined are responsible for the effective transmission of ICMP packets.

Ethernet, IP and ICMP Protocols

While “pinging” a system, layers 1, 2 and 3 are in action. Each layer defines its own “format of protocol options” known as a header. It precedes the actual data to be sent and has information such as the source IP, destination IP, checksum, type of protocol etc. And when it is attached with the actual data to be sent, it forms a protocol data unit which is renamed as per the layer.

Default protocol data units (PDU) in these layers are:

• Layer 1: bits
• Layer 2: frame
• Layer 3: packet
• Layer 4: datagram

We’ll be using these terms quite often and it is important to be clear what these terms mean. While the data is travelling through these layers, it is converted virtually into its own PDU.

Ethernet

IEEE 802.3 is a set of standards and protocols that define Ethernet-based networks. Ethernet technologies are primarily used in LANs. There are a number of versions in IEEE 802.3 such as the 802.3a, 802.3i etc. When we ping, there is some data sent to the destination host and in a specific format.

Ethernet header:

IP (Internet Protocol)

It is the principal communications protocol for relaying datagrams across network boundaries. IP has the task of delivering packets from the source to the host solely based on the IP address in the packet headers. IP defines packet structures that encapsulate the data and headers.

ICMP (Internet Control Message Protocol)

Since IP does not have an inbuilt mechanism for error control and sending control messages, ICMP is here to provide that functionality. It is a supporting protocol used by network devices like routers for sending error messages.

Ping

Ping is a computer networking utility used to test the reachability of a host on IP network. Ping operates by sending ICMP Echo request packets and waits for ICMP Echo replies. This reports error, TTL, packet loss etc. One ping request is a combination of Ethernet, IP and ICMP headers and data.

Useful ping options in windows and Linux are:

Windows:

Options	Functionalities
-t	To see statistics and continue – type Control-Break; To stop – type Control-C. Ping the specified host until stopped.
-a	Resolve addresses to hostnames.
-n count	The number of echo requests to send.
-l size	Send buffer size.
-f	Set Don’t Fragment flag in packet (IPv4-only).
-i TTL	Time To Live.
-v TOS	Type Of Service (IPv4-only. This setting has been deprecated and has no effect on the type of service field in the IP Header).
-r count	Record route for count hops (IPv4-only).
-s count	Timestamp for count hops (IPv4-only).
-j host-list	Loose source route along host-list (IPv4-only).
-k host-list	Strict source route along host-list (IPv4-only).
-w timeout	Timeout in milliseconds to wait for each reply.
-R	Use the routing header to test reverse route also (IPv6-only). Per RFC 5095 the use of this routing header has been deprecated. Some systems may drop echo requests if this header is used.
-S srcaddr	Source address to use.
-c	Compartment Routing compartment identifier.
-p	Ping a Hyper-V Network Virtualization provider address.
-4	Force using IPv4.
-6	Force using IPv6.

Linux:

Options	Functionalities
-a	use audible ping
-A	use adaptive ping
-B	sticky source address
-c <count>	stop after <count> replies
-D	print timestamps
-d	use SO_DEBUG socket option
-f	flood ping
-h	print help and exit
-I <interface>	either interface name or address
-i <interval>	seconds between sending each packet
-L	suppress loopback of multicast packets
-l <preload>	send <preload> number of packages while waiting replies
-m <mark>	tag the packets going out
-M <pmtud opt>	define mtu discovery, can be one of <do|dont|want>
-n	no dns name resolution
-O	report outstanding replies
-p <pattern>	contents of padding byte
-q	quiet output
-Q <tclass>	use quality of service <tclass> bits
-s <size>	use <size> as number of data bytes to be sent
-S <size>	use <size> as SO_SNDBUF socket option value
-t <ttl>	define time to live
-U	print user-to-user latency
-v	verbose output
-V	print version and exit
-w <deadline>	reply wait <deadline> in seconds
-W <timeout>	time to wait for response

IPv4 options:

Options	Functionalities
-4	use IPv4
-b	allow pinging broadcast
-R	record route
-T <timestamp>	define timestamp, can be one of <tsonly|tsandaddr|tsprespec>

IPv6 options:

Options	Functionalities
-6	use IPv6
-F <flowlabel>	define flow label, default is random
-N <nodeinfo opt>	use icmp6 node info query, try <help> as argument

Ping sends out IP packets with ICMP_Echo_Request to the destination and waits for its reply (IP packet with ICMP_Echo_Reply).

The ICMP packet is encapsulated in an IPv4 packet. The general composition of the IP datagram is as follows:

When a ping command is sent to the host, the datagram is encapsulating Ethernet header, IP header, ICMP header and payload too. The minimum size of an IPv4 header is 20 bytes and the maximum size is 60 bytes.

The default size of payload data in ping in windows is 32 bytes. Let’s add 20 bytes of IP header in it and 8 bytes of ICMP header. 32+20+8, it comes out to be 60 bytes.

But, when we analyse ping in Wireshark, the size of the frame written in the log is 74 bytes. This is because while pinging, we would need the destination and source MAC address as well, which is available in the Ethernet header.

So, 14 + 20 + 8 + 32 = 74 bytes.

So, ping sends an encapsulated IP packet which is a combination of:

Ethernet header + IP header + ICMP header + ICMP payload

But, keep on reading for very interesting cases that made me write this article.

Wireshark and Basic Filters

Wireshark is a freely available network monitoring tool that is able to log all the traffic incoming and outgoing from a single NIC card. I won’t be telling how to set up Wireshark and start logging, please use this tutorial for it.
In the above case, when we ping a Linux system from a windows system, we see something like:

Let’s go step by step and see what just happened.

1. I’ve pinged IP address 192.168.217.128 from my source IP 192.168.238.1 and captured just one packet to see clearly the action.
2. On the top, there is a Wireshark filter applied for the IP address that goes like addr == 192.168.217.128
3. Some other useful Wireshark filters are:
   http or dns

4. Next, you can see the total length of the datagram sent, that is, 74 bytes, as already explained above.
5. Then you can see, in yellow, Ethernet frame. Here, you’ll find the Ethernet header.
6. After that is the IPv4 packet. IP is used to deliver packets from source to destination based on the IP addresses.
7. Finally, we see the ICMP header and payload data.
8. All these layers are involved in a simple ping over IEEE 802.3. In the next section, we’ll learn how to analyse a packet data using Wireshark to get an in-depth view of packet forensics.

How is a datagram sent to the destination?

When a datagram is sent from source to destination, in our case, when we ping, the format of the datagram is as follows:

We’ll ping a destination with default options:

Let’s start analysing the traffic in Wireshark now.

I just captured a single datagram in Wireshark when I pinged a destination host and analysed it layer by layer.

Talking about Layer 2 here, we can see that Ethernet type 2 is being used.

As we talked in point 2, Ethernet frame sent with ping includes the source and destination MAC along with the type of protocol being used.

0000   00 0c 29 d7 b1 35 00 50 56 c0 00 08      08 00

           Destination MAC         Source MAC          EtherType

                (6 bytes)                      (6 bytes)             (2 bytes)

The most important field here is the EtherType field as on analysing these bytes we can find the protocol that was used in the communication. This is really essential for forensics point of view and some of the most important hex values are:

Ethernet Types	Hex Value
ARP	08 06
IPv4	08 00
IPv6	86 dd
IEEE 802.1Q	81 00

Moving on to layer 3, we see an IP packet, since obviously ping is using IP protocol to check if a host is alive or not. Here is the observation of the hex dump of IP packet:

0000   ….45           00              00 3c da 40 00 00 80        01 2c ad c0 a8 d9 01

        Header    Type              Total                        TTL     Protocol        Source IP

        Length     of service     Length

        (1 byte)    (1 byte)       (2 bytes)                 (1 byte)  (1 byte)          (4 bytes)

0010   c0 a8 d9 80

           Destination IP

              (4 bytes)

From the analysis of this IP packet, we observe that IP header is then added to the Ethernet frame to make a packet that has the above-mentioned options specified. By analysing this data we can observe a lot of different things. Some of which are:

TTL:

OS	Hex Value TTL	Decimal Value TTL
Windows	80	128
Linux	40	64
Mac	39	57

Type Of Protocol:

Protocol	Hex Value	Decimal Value
ICMP	1	1
TCP	6	6
EGP	8	8
UDP	11	11

One really interesting thing to note is the Header Length. We see that header length is written as 45 in hex which comes out to be 69 which is not possible. On further breaking down this byte, we see that the first nibble (half byte) tells the version of the protocol.

4 = hex value = 4 (version of protocol), that is IPv4

5 = hex value = IHL (Internet Header Length) = next for bits

And so on (total length = 00 3c = 60 bytes)

A datagram is completed and transported when ICMP header is added in Layer 3. We know that IP lacks error control mechanism, so ping uses ICMP to serve that purpose. ICMP protocol is specified in IP header as we saw above and hence, it is important to analyse ICMP header to better understand the underlying mechanism of ping.

0000     08            00              4d 53 00 01 00 08 61 62 63 64 65 66 67 68

           Type        Code           Checksum                         Data

           (1 byte)    (1 byte)       (2 bytes)                         (32 bytes)

0010   69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61

0020   62 63 64 65 66 67 68 69

Type: It is the type of request of ICMP request sent. According to IANA, there are 45 assigned requests.

We can see, 08 as the Type of request which symbolises Echo request. When one system pings another system, it sends a Type 8 request and if the host is alive, the host sends back Type 0 (Echo Reply) request.

Code: It is simply the hex value of the type of ICMP request message. It ranges from 0 to 15 for each of the types. This reference is taken from Wikipedia:

Checksum: “The checksum is the 16-bit one’s complement of the one’s complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero. If the total length is odd, the received data is padded with one octet of zeros for computing the checksum. This checksum may be replaced in the future.” – RFC 792

So, to calculate the checksum, we have to split the ICMP header and payload data into multiple pairs of 2 bytes each, calculate the one’s complement of first two bytes, add with the next one and repeat it till all the bytes are exhausted.

Here, checksum status is shown as good and correct, so we need not look any further.

Data: Contains other essential data like timestamp, sequence number, magic number etc.

Data size in ping

According to RFC 791, an IP can handle a datagram of maximum size 65,535 bytes. However, by default, the data in ping is 32 bytes and the whole datagram is by default 60 bytes in case of windows. Adding 14 extra bytes of Ethernet header, it comes out to be 74 bytes which we see in Wireshark. Focus on the colour codes here:

Red= ICMP payload data size

Green= Total length of the IPv4 packet

Maroon= Total length of the datagram

Let’s talk about Linux now. The default IP packet size in Linux’s case is 56 bytes. Adding extra 28 bytes of IP and ICMP header makes it 84 bytes. Adding more 14 Ethernet frame header bytes makes it 98 bytes.

However, we can add data as per our wish, as long as it remains under 65,535 bytes using the ping –l option in Windows. This also has some limitations. Let’s talk about them in the next section.

MTU in IEEE 802.3i

MTU stands for Maximum Transmission Unit and it is the size of the largest Protocol Data Unit that can be communicated in a single network-layer operation. IEEE 802.3 standards restrict the minimum to 48 bytes and the maximum to 1500 bytes. So, if I am to transfer more than 1500 bytes of data in a single datagram, it would be fragmented into multiple packets.

To understand MTU, we’ll take up four cases:

Data payload size=200 bytes, 1472 bytes, 2000 bytes, 65500 bytes

Payload size 200 bytes:

We see that the size of IPv4 datagram comes out to be 242 bytes. This is a result of 200 payload bytes + 8 bytes ICMP header + 20 bytes of IP header + 14 bytes of Ethernet header. The noticeable thing here is that still a single datagram is sent and no fragmentation is done. Let’s push the limit to MTU now.

Now let’s push the limits of ping packet to the MTU, that is, 1500 bytes in case of an IEEE 802.3.

Notice some things here. We have not set the data size as 1500 which is the MTU rather 1472 due to the fact that protocol has some bytes for the headers in reserve.

20 bytes of IP and 8 bytes of ICMP headers are automatically added in every transaction as we’ve seen. So, 1500-28=1472 is the maximum payload data size that we can specify in a ping command.

These 1500 bytes are then collated with ethernet header and finally, a datagram of 1514 bytes is transferred.

So, what will happen when this data size is increased from 1472? Let’s check out.

Fragmentation in ping

IP fragmentation or ping fragmentation is a process in which a packet exceeding the size of MTU is broken into multiple pieces and transacted to the destination host. RFC 791 has the procedure for IP fragmentation, transmission and reassembly of packets.

Let’s increase the size of the data payload to 2000 bytes and let’s see what happens.

Now, we can see that fragmentation is done and the datagram is split into two fragments of size 1480 and 520 bytes. Why?

The first fragment is 1500 bytes in total length but the data is only 1480 because 20 bytes are always in reserve for IP protocol header, and the second fragment is 520 bytes in payload data size.

First fragment= 1480 (data size) + 20 (IP header)

Second fragment= 520 (data size) + 20 (IP header) + 8 (ICMP header)

It is important to note that ICMP header is not added in the first fragment and it will only be added when the whole datagram is complete. It is because ICMP is responsible for error control and it calculates the checksum. For checksum to be calculated, whole data should be transmitted first and hence, ICMP header is not added in the initial fragments but only in the last fragment.

Now we push these limits to the maximum size.

Here, the datagram is split into multiple 44 fragments of 1480 bytes each and the last packet is 408 (minus 28= 380 bytes) bytes in size.

You must not get confused here. 65500 is the maximum size of a payload that we can specify in ping.

However, each of the 44 frames is of size 1500 bytes and the last frame is 388+20+8 bytes, which comes out to be 66416 bytes. Hence, the cumulative size of a packet datagram can be at max 66416 bytes.

Add on extra 14 bytes of Ethernet header, it comes out to be: 67,046 bytes.

Anomaly in Ping

Let’s focus on a case when the payload size is specified as 0. Let’s see what the protocols do with 0 bytes of data.

As expected, the request goes with 42 bytes (20 + 8 + 14) with 0 bytes of data but wait, why does the reply come back as 60 bytes?

On analysing the hex dump, we see that a Linux system is replying with 18 null bytes of data.

If we specify ping –s 0 in Linux machine, maybe we get some answer.

Okay, so in the terminal, we see “pinging with 0 (28) bytes of data” which means 28 bytes of IP plus ICMP header and 0-byte data. BUT, Wireshark shows us something size of 60 bytes and has again added an extra 18 bytes.

Turns out that these 18 bytes are Ethernet padding bytes and that’s why this anomaly has arisen. IEEE 802.3 adds extra bytes if data is less than 18 bytes in case of Linux known as padding bytes or pad bytes.

Let’s specify a data in the range: 1<x<18 for example, 10 bytes. Let’s see what happens.

In Wireshark, we see the size is still 60 bytes. And 10 bytes have been written by the hex values from 0 to 9, while rest of them are still null bytes.

It is safe to say the same anomaly will exist when we specify data in the multiples of 1480 since the last fragment will have 0 bytes of data to be sent and padding would be added.

This was an interesting anomaly and made us understood some details of the IEEE 802.3 standards difference in Windows and Linux.

Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. contact here