You are presented with captured traffic from an internal network. Your job is to identify the various users and applications that were working in that network.
The provided PCAP file can be found at Desktop/Module7/Lab19/Network_analysis_lab_Full.pcapng
First, load this PCAP file into Wireshark.
Wireshark has a built-in statistical tool which allows us to get a general overview of the protocols which the captured packets belong to.
This is accessible from Statistics -> Protocol Hierarchy
We can see that the frames we captured can be categorized into three groups; IPV4, IPV6, and ARP frames.
We can see in the second column (percent packets) that IPV4 packets make more than 95% of the captured packets.
TCP constitutes 95% of the IPV4 packets while UDP 5% and the rest is between ICMP and IGMP protocols.
Let's start with UDP since it should be easier. Within the UDP section, we can notice few known application layer protocols. Namely DNS and Bootstrap (DHCP).
We can also find less known protocols such as NetBIOS (for name registration) and SSDP (HTTP based protocol for network service discovery).
In the TCP section, we have SMTP and IMAP (which suggests their mail exchange activities). HTTP and SSL tell us that there is web browsing activity.
We can examine few statistics about the HTTP traffic within the file.
This tells us what type of files were exchanged over HTTP.
One way we can count how many users are within the network is by sorting the packets we have based on the IP address and picking the private IPv4 addresses. Sorting the addresses will make it easy for us to identify different addresses.
Alternatively, we can use the statistical feature again in Wireshark to extract all the addresses within the capture file.
After sorting the IP addresses, we can look for the IPV4 private range which, in small networks, usually starts with 192.168.
The IP that ends with 255 is called the broadcast address, which is used when a device wants to send something to the whole network.
Sometimes, packets can tell us a lot about the operating systems they came from.
Fields such as "TTL," for example, may be used to identify the machine's OS.
On most modern Windows machines, the default Time-to-Live is 128, while the default value for most Linux distributions is 64. Cisco IOS, on the other hand, uses the value 254 as the default TTL.
On a higher layer, HTTP headers, specifically, the user-agent may also be used to identify the user's OS.
In our example, we can look for HTTP traffic that originated from one of the private IPv4 addresses we found earlier using Wireshark filter.
http and ip.src==192.168.153.137
Looking at the user-agent header, we now know that the machine 192.168.153.137 is Windows NT 6.1 (Windows 7) machine.
If we want to analyze the user's web activities, we need to find a way to know what websites the users have requested.
The not-very-smart way to do this would be to filter the traffic we have and examine the HTTP traffic only. Using the filter http. After that, we can follow the HTTP streams for the packets we have.
This is a slightly smarter way is to filter the DNS requests that were made by the users. Since HTTP requests usually get preceded by DNS query asking about the IP of the destination domain, examining the DNS queries that are requesting records of Type A could help know what domains were accessed by the users. Using filter dns.a.
The other way to do this is to look for the HTTP statistics so we can tell which domains were accessed by the users.
The display window will show us the domains and sub-domains requested by the users.
We can click on any displayed domain to get the exact URL that was requested by the user. For example, we can notice that the user has downloaded a file from the BBC website.
We'll get on how to extract that file later.
As discussed earlier, there are two protocols for working with emails; SMTP and IMAP. The latter is used to access to mailbox and view email, while the first is used to send emails. We'll examine the login process first using the imap filter in Wireshark and view the TCP stream option.
The connection starts with the server displaying its time.
The client requests the server capabilities which the server replies to by sending a list of possible operations.
The client requests a challenge-response md5 based authentication.
Challenge response protocol differs from password-based authentication protocol in that the first doesn't send the password itself instead of the server since a challenge to the client cannot be solved unless the client has the right password.
The server sends the challenge in base 64 encoding, and the client sends their response for the challenge using the same encoding scheme.
Since the user supplied the right password, the server replies with an okay message telling the user that the authentication has been successful.
Later that client requests to view his mailbox including the inbox, junk box, trash, etc.
Using the same methodology, we can filter for SMTP protocol tickets to see the emails that were sent during the capture. We need to replace the imap filter with an SMTP filter and view the TCP stream.
The session also starts with the server sending its banner and its time to the client.
The client replies for the better with the extended hello command.
The server offers different operations for the client to choose from.
As we saw earlier the client authenticate using its username and password and then it sends an email to user2 asking them to delay an appointment