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.

METASPLOIT - Windows 7 - Bind TCP Shell

WINDOWS 7 - BIND TCP SHELL

- Layout for this exercise:

- msfvenom converts Metasploit payloads into executable or binary files. In this case, the 
windows/meterpreter/bind_tcp payload is converted into a Microsoft executable file (.exe) with these options:

-a x86 = architecture x86
-f exe = format executable

- The command file checks that bind_tcp.exe is of PE32 type. PE (Portable Executable) is a file format for executables, object code, DLLs, Font files, and others used in 32 and 64 bits versions of Windows operating systems. 

- From the Kali attacker side, a SimpleHTTPServer is run, accepting connections on port 8000:

- The victim Windows 7 connects to the attacker's web server and downloads bind_tcp.exe:

- The client or victim Windows 7 has downloaded bind_tcp.exe, a backdoor that in case of being executed will trigger an undesired Internet connection between attacker and victim.

- The attacker detects that bind_tcp.exe has been downloaded on the client side, from IP 192.168.1.14:

- Then, the attacker sets up a handler exploit with the payload meterpreter, waiting until the victim runs the executable. The RHOST is the IP 192.168.1.14, corresponding to the victim: 

- On the client side, the victim executes bind_tcp.exe:





- Now, Windows 7 is running bind_tcp.exe:





- As a consequence, on the attacker side a meterpreter session is automatically created by the handler:

- Running netstat on both Windows 7 and Kali shows how a connection has been established between the victim and the attacker:

- However, the bind_tcp.exe executable would be stopped in case of presence of firewall. Let's see what happens if Windows Firewall is "on":

- If the victim runs bind_tcp.exe Windows Firewall immediately detects and blocks its execution:

- Only if the victim clicked Allow access option (which would be unwise) , the executable would be run.

-  The conclusion is that Bind Shell payloads don't work with firewalls, because these programs or devices are usually configured to detect INBOUND connections. The solution would be to use OUTBOUND connections, like those provided by Reverse Shell payloads.