AdSense

Friday, June 10, 2016

METASPLOIT - Windows 7 - Reverse Shell TCP Allports


WINDOWS 7 - REVERSE SHELL TCP ALLPORTS

- Layout for this process:


So far we have considered blocking only some specific ports. However, in this case the OUTBOUND rule blocks a set or range of ports, for instance from 3000 to 6000:






- Now, reverse_tcp_allports payload is converted into an executable file. This module tries to connect back to the attacker on all possible TCP ports, from 1 to 65535. In this way, the payload will try sistematically to go port by port until it finds one open or allowed by the firewall.

- Later, we'll see the reason because LPORT is still 4444, although it is inside the range of blocked ports by the firewall.





- Checking that it is an executable file:



- Because all connections on 3000 to 6000 are going to be blocked by the firewall, the first allowed connection will be on port 6001. However, because the attacker does not know it, he tries to redirect connections to a well-known port like 4444. For achieving that goal Iptables can be used.



- First, all Iptables rules are cleared:




- Then, connections on the range 3000:6000 plus 6001 are redirected to local port 4444 (that is the reason because LPORT = 4444):



- The attacker sets up a handler exploit, waiting the connection from the victim:




- Also, a web server is running on the attacker side:



The client or victim connects, downloads and runs the executable reverse_tcp_allports.exe:


A meterpreter session is successfully achieved on the attacker side:














It is interesting to compare netstat output from both sides. From the attacker perspective the connection is on local port 4444:







On the other hand, from the victim's point of view, the connection comes from remote port 6001, as expected, because the ports from 3000 to 6000 are blocked by the firewall, and in that range only port 6001 was redirected towards port 4444 by Iptables:







METASPLOIT - Windows 7 - Reverse Shell HTTPS / HTTP



WINDOWS 7 - REVERSE SHELL HTTPS / HTTP

- Layout to this exercise:




- In the previous exercise an OUTBOUND rule was created with Windows Advanced Firewall for Security for blocking reverse shell connections to remote port TCP 4444, used by default by Metasploit:



   





- However, this rule would not block OUTBOUND connections to any other remote port, for instance port 443 (HTTPS) or port 80 (HTTP).

- On next two exercises, let's see how it is possible to install backdoors on the victim machine, bypassing firewalls, using Social Engineering so that the victim downloads executables files from the attacker's wep page.



REVERSE_HTTPS.exe

- Let's create the executable reverse_https.exe, using msfvenom and meterpreter reverse_https payload:




- Checking that it is an executable file for Windows:




The attacker opens a web server on port 8000:




- Also, the attacker Kali sets up a handler exploit with local port 443 (HTTPS) and local IP, waiting for the victim:




Then, the victim Windows 7 connects to the web server, downloads and runs the executable reverse_https.exe:




- Automatically, a meterpreter session is open on the attacker's console, and the post exploitation process can be started:






REVERSE_HTTP.exe

- Same goal could be achieved with HTTP protocol. The attacker creates the binary reverse_http.exe with msfvenom. In this case the LPORT corresponds to 80 (HTTP), and local IP corresponds to the attacker's machine:




The file is executable on Microsoft systems:






A web server is set up by the attacker:




- Also, a handler exploit waits until the clients connects and runs the binary:





- The victim Windows 7 downloads and runs reverse_http.exe:




- Automatically, a meterpreter session is achieved on the attacker's machine:





METASPLOIT - Windows 7 - Reverse TCP Shell


WINDOWS 7 - REVERSE TCP SHELL


- Layout for this exercise:





- As seen in previous case bind_tcp.exe is detected by Windows Firewall, and its action blocked unless the victim allows it to be run. It happens that firewalls are usually more aware watching INBOUND than OUTBOUND connections. So, for real world scenarios, using payloads working on OUTBOUND connections would be more successful, for instance creating reverse shells from the victim to the attacker. 

- The procedure would be similar than before, with the only difference that now the reverse_tcp would be used:












- As done with previous case, for this example the Windows Firewall is also connected at the victim computer, because the goal is to show how reverse_tcp.exe is not detected and blocked by the normal inbound firewall:






The attacker Kali sets up a web server on port 8000:






- The victim Windows 7 downloads the executable reverse_tcp.exe:













Then, the attacker uses a multihandler exploit and a meterpreter payload, waiting until the victim executes the reverse backdoor. It is important to notice than LHOST option corresponds to the attacker's IP:






- The victim runs reverse_tcp.exe:




















Though the executable is running on the victim, no sign of firewall detection appears:




- At the Kali attacker side a meterpreter session is succesfully achieved, allowing post exploitation of the victim Windows 7:






- However, Windows 7 has also a so called Windows Firewall with Advanced Security, whichs allows to create special rules for OUTBOUND connections. In this specific case, it would be possible to create a rule to block the action of reverse_tcp.exe, because the advanced firewall would detect the executable.

- Let's create a rule which blocks OUTBOUND connections to the remote port 4444 (generally used by Metasploit):









The new rule takes the port as a parameter to be controlled:







- The rule applies to port TCP 4444, remote port used by the attacker Kali with Metasploit:






- The action to be taken by the new rule would be to block the OUTBOUND connection to remote port TCP 4444:






- The rule applies to any type of domain or network location:






- The name for the rule is "Blocking reverse_tcp.exe":













- From the attacker side, a handler is waiting for the client connection:




The victim runs the executable reverse_tcp.exe:









- However, nothing happens in this case because of the presence of the new rule created by the Windows Firewall with Advanced Security, and the attack is unsuccessful:








- Anyway, it is not very usual that System Administrators create OUTBOUND rules on firewalls, so this late case of an specific rule blocking a reverse shell connection is not very common, although desirable, of course.