Bypassing Detection for a Reverse Meterpreter Shell

This post discusses the creation of an executable which spawns a reverse Meterpreter shell. All the tools used in this post are publicly available. In the process, I will explain bypass of an IPS (Intrusion Prevention System) that detects staged Meterpreter connection, even if it is on HTTPS! Note that this post does not cover building any executable from scratch, but rather discusses using the already available tools in conjunction with each other.

I was engaged in two red team assessment projects recently. The scenarios were as follows:

1. In one scenario, I had administrator privileges on a public server via SQLMap OS shell. In this case, I aimed to get a stable shell with more privileges.
2. In the second scenario, I had client’s laptop. I was connected to the internal network and the system was a part of a domain.

In both the cases, I aimed to gather a reverse Meterpreter shell on my server in AWS (Amazon Web Services) and then leverage the privileges to perform further attacks. This technique was successful in both the cases with a little modification such as outbound port, etc.

After some research on AV evasion, I came across some cool techniques and tools which I will describe in detail. To simulate similar scenarios which I faced, I set up a simulated infrastructure using virtual machines and AWS. The setup was as follows:

• Windows 7 Professional 64 bit (hosted on VM on local machine)
• Symantec Endpoint Protection 14.0 – with updated signatures (Installed on Win7)
• Kali Linux on AWS
• Ubuntu on AWS

Part 1: SSL Blocking and Bypass

Little peek into Metasploit’s Reverse HTTPS payload and detection by AVs

I had generated an executable successfully which spawned a reverse Meterpreter (reverse_https) shell to a server on AWS. Everything worked like a charm and it was time to test on a system with an antivirus running.

I ran the executable on the VM with Symantec Endpoint Protection enabled.. The executable ran, but the session could not be established as the connection was caught by the AV’s IPS module; stating that a Meterpreter connection has been detected and blocked. Uh oh! How could the encrypted connection be detected by an IPS? So, let’s investigate what happened.

To bypass the egress restrictions, attackers usually use a port which is most likely to be allowed, while spawning a reverse shell, e.g., 80, 53, 443, etc. Though using these ports can bypass the filtering rules on the devices such as Firewalls, but more intelligent data inspection devices such as an IPS can read the data transfer such as an initial stager and trigger active controls to block the connection and alert the administrator.

Wonderfully, in 2011, Metasploit added support for reverse HTTPS connections which allowed the use of encrypted channel using real SSL sessions. Thus, the connection cannot be inspected without any SSL proxy. In my case, even though I used reverse Meterpreter payload (windows/meterpreter/reverse_https), but it was still detected by the IPS module of the Symantec AV.

Upon further investigation, I found a post by Erik. An interesting fact that I realized is that, during SSL communication, some of the data, specifically SSL certificate, is sent over cleartext. So, AV scans certain attributes of the certificate to check if any malicious activity is being performed. As a result, even when SSL reverse shell is used, AV identifies the certificate; that it belongs to Metasploit and blocks the reverse connection flagging it as Meterpreter payload.

Metasploit’s Reverse HTTPS Certificate Validation by AV

To test the blocking by AV, I had set up listener in Metasploit. The payload chosen was “windows/reverse/meterpreter/https” and the port was 443. Note that no payload was created; only the listener was set up as shown below:

Once the listener was ready, I ran Wireshark and opened the reverse handler URL. The following capture shows cleartext data during the initial SSL handshake. The server has sent the certificate in response to the client’s ‘hello’ request in cleartext, as shown in below image:

Then, I opened the reverse handler URL in different browsers and captured the traffic using Wireshark. I analysed the Wireshark capture using NetworkMiner, which is a network forensic analysis tool.

Three different certificates were extracted. Details of two certificates are shown in the below given screenshots:

As shown, the certificates have different random data. The details such as CN is not valid and is random. Even the validity is random and not same in both the certificates.

IPS Signature Based Analysis in Action

Now that we have retrieved the certificates, let’s test these against Symantec Endpoint protection.

I simply copied the reverse handler URL and opened it in the browser. Immediately, the URL is blocked by Symantec IPS; detecting the connection as reverse Meterpreter HTTPS.

The below screenshot shows alert generated by Symantec:

The signature details confirm that it detects and blocks reverse HTTPS Meterpreter activity.

Conclusion on AV Detection

The initial SSL connection is in cleartext, wherein the certificate details are shared, and a simple SSL connection to HTTPS handler with no payload is also detected by IPS. This concludes that IPS module of the AV scans the certificate during initial SSL handshake and then checks for certain attributes in X.509 certificate. The attributes might include issuer details, domain name, etc.

SSL Impersonation – Bypassing SSL detection

Once I concluded the reason for blocking of reverse HTTPS Meterpreter payload, I wanted to find a way to use custom certificate instead of default Metasploit certificate. For this, you can either generate your own self signed certificate or use Metasploit’s SSL impersonation module.

The module (auxiliary/gather/impersonate_ssl) creates a self-signed certificate with details of remote certificate; making the certificate look genuine. The similar technique is used in Paranoid Meterpreter which is used to secure staged connection by verifying SHA1 hash of the certificate at both ends, so that someone cannot hack the hacker 🙂

Let’s generate the certificate using SSL impersonation module:

Now, we need to set our handler to use the newly generated certificate by using the option handlersslcert and stagerverifysslcert.

Once the handler is run and is accessed using browser over HTTPS, Symantec does not detect the payload. Mission accomplished!

Part 2: Payload Generation

After I found a way to secure my staged connection and bypass detection by IPS, I moved on to the creation of the payload.

To generate the payload, I followed these steps:

1. Use Metasploit to generate Meterpreter reverse HTTPS payload configured with impersonated SSL certificate.
2. Use Don’t Kill My Cat (DKMC) which generates an obfuscated shellcode and embedded inside polyglot images.
3. Generate PowerShell command using DKMC which downloads the payload with embedded shellcode and then executes the shellcode.
4. Create an HTA file with the above generated PowerShell code embedded in it.

Generating shellcode using Metasploit

First, I generated a payload using Metasploit. In this, you need to make sure that handlercert and stagerverifycert is set. To bypass egress port filtering, I checked the outbound port access by performing an outbound port scan (not discussed in this post) and found port 443 was open in one case and port 53 in another. For this simulation, I have used port 443.

Generating malicious BMP with DKMC

Once this shellcode is generated, I used DKMC to embed obfuscated shellcode in a BMP image and create a PowerShell command to download and execute shellcode from BMP file. DKMC has modules as shown in the below given screenshot:

To obfuscate the raw shellcode generated by using Metasploit, use sc module first. This will generate the shellcode in a hex format.

Now, copy this shellcode and generate a malicious BMP file using the gen module.

The BMP payload has been generated now. I hosted the BMP on an Ubuntu server in AWS. Now, I needed to download the image on the victim’s server and then execute the embedded shellcode. I used PowerShell module of DKMC for this. Use ps module to generate the PowerShell command.

This generates a PowerShell command with hidden flag and encoded payload.

The next part is delivery of this payload. The delivery can be done in multiple ways:

• If you have access to the victim’s system and you want a more privileged Meterpreter shell, then you can simply run the command in the Windows shell to get a reverse shell on your C&C.
• The payload can be saved in .ps1 (PowerShell script) and then executed from there.
• The link can be embedded in some other executable such as HTA; and then delivered via phishing, USB baiting, etc.

As I had access to systems in both the cases, I ran the command directly in the Windows shell to obtain a reverse shell on Kali in AWS.

However, to create an ideal executable which can be delivered to a victim’s system to spawn a shell, let’s explore the third case – creating of an HTA.

Embedding PowerShell code in encrypted HTA

I used Demiguise, which creates an HTML file with an encrypted HTA file. When a user visits the HTML file on the web, the HTA file is decrypted dynamically within the browser. The goal is to bypass the content of the file-inspection. Though, in this case, our payload is already able to bypass the AV. So, we will use this simply as a medium to deliver and run our PowerShell command.

The following command generates a file named horizon.html which has encrypted horizon.hta which in turn has embedded PowerShell payload.

Final Action

I hosted the HTML file on a web server in AWS and accessed the file from a Windows 7 machine, which was running Symantec AV. Upon accessing the HTML page, an HTA file is downloaded.

Then, I set up the listener on AWS. In this we need to configure the handler to use the previously generated self-signed SSL certificate.

Once the HTA file is run, it spawns reverse Meterpreter shell over HTTPS. Note that SHA1 hash of the signature is verified on the listener before the connection is established.

The following screenshot shows the reverse connection status in a network activity monitoring console of Symantec; which shows the reverse shell spawned to my Kali on AWS under PowerShell process. Awesome!

Conclusion – Basic Flow

So, in conclusion, the basic flow is as follows:

Step 1: Impersonate the SSL certificate

Step 2: Create shellcode configured with the impersonated SSL certificate

Step 3: Embed obfuscated shellcode in a BMP image

Step 4: Set up the listener configured with the impersonated SSL certificate to bypass detection of staged connection by an IPS.

Step 5: Generate PowerShell command to download and execute the payload.

Step 6: Generate an HTA file embedded with PowerShell code.

At the time of writing, the executable has been tested on Symantec, Kaspersky, AVG and Windows Defender and the executable as well as the connection is not being detected.