In the very first step, we did an NMAP scan over the target.

We found that VSFTPD 2.3.4 is running on port 21 and is vulnerable to attack.

We exploited VSFTPD 2.3.5 running on port 21.

We got the shell access to the target running at 192.168.10.112.

We created a Linux meterpreter shell and copied it to the /var/www directory of Apache. Next, we ran the wget command from the shell and downloaded our newly created meterpreter shell onto the target.

We assigned full privileges to the shell backdoor file via chmod 777 backdoor.elf.

Setting up an exploit handler in a separate window, which is listening on port 4444, we ran the backdoor.elf file on the target.

We got the Linux meterpreter access on the target system, which is 192.168.10.112.

Running the arp command on the compromised system, we found that it was internally connected to a separate network and is connected to another system running on an internal IP address, 192.168.20.4.

We quickly set up an autoroute to the 192.168.20.0/24 network via our meterpreter shell on 192.168.10.112.

Pivoting all the traffic through our meterpreter, we performed a TCP port scan on the target and service identification modules.

We found that target was running vulnerable version of PHP on port 80.

We exploited the system with PHP CGI Argument Injection Vulnerability.

We gained PHP meterpreter access to the internal system of the network running at 192.168.20.4.

We performed similar steps as done previously on the first system, by uploading and executing the backdoor.elf file.

We got Linux meterpreter access to the target.

We ran the arp command to find if there were any other hosts present on the network.

We figured out that there was one more system running on IP address 192.168.20.6 and we performed a TCP port scan.

Scanning all the ports, we figured out that HFS 2.3 was running on port 8080 and was vulnerable to the Remote Command Execution vulnerability.

We exploited the system with the HFS exploit module with Metasploit.

We got the Windows meterpreter access to the target.

We ran a persistence module to maintain access to the target.

The persistence module will try to establish a connection to our system after every few seconds and will open meterpreter access as soon as a handler is up.

We cleared the logs via the event_manager module from meterpreter.