Lab 5
This lab continued from lab 4 with using Kali Linux to scan on a network. This lab focused on using Wireshark to scan packets/frames on the network and see the contents of that traffic.
Exercise 1
This exercise covered setting up the VMs in the lab environment. The lab suggests to use port mirroring, but for my environment I will be using a switch with promiscuous mode enabled. This will allow the Kali VM to see all the traffic on the network regardless of whether the traffic is directed at the Kali VM or not. I also had to set up the Kali machine with a static IP
Exercise 2
This exercise involved scanning the network for frames using Wireshark.
Here is a DNS frame being sent to 10.1.0.100 which is a Windows VM from 10.1.0.1 which is the DC. The frame is a response frame:
Exercise 3
In this exercise I made a share with a file in it, then I accessed the share from another machine while scanning with Wireshark. The frames that the share was sent with were not encrypted so I was able to see the contents of the file that was accessed in cleartext. This makes it clear that using basic share settings is not secure and even though permissions are required to access the share, the data sent over the network is fully open for malicious intervention. Using some form of encryption would make data exchanges much more secure and resistant to being intercepted maliciously.
Making the share:
Making the share:
Unencrypted frame with cleartext password:
Exercise 4
This exercise covered sending a file through a backdoor using Netcat.
With the first attempt to send the file, it failed. The reason this didn't work is because the port that Netcat was using was not open on the firewall this meant that there was an attempt to connect, but no response. Changing the firewall settings to open the port allowed the connection. When the file was sent, it was possible to see the file in cleartext like in exercise 3.
Attempt to connect with no response because the port is closed:
With the first attempt to send the file, it failed. The reason this didn't work is because the port that Netcat was using was not open on the firewall this meant that there was an attempt to connect, but no response. Changing the firewall settings to open the port allowed the connection. When the file was sent, it was possible to see the file in cleartext like in exercise 3.
Attempt to connect with no response because the port is closed:
determining the port which Netcat uses:
Cleartext file in a frame after opening the port and transferring the file:
Critical Thinking
This lab showed how unsecure file shares can be, and the importance of securing traffic with encryption. I also was reminded of the importance of least privilege, because by keeping permissions locked down and only having ports that are needed open, you can greatly reduce the risk of backdoors and other unwanted behaviour on the network.
No comments:
Post a Comment