This post discusses 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 IPS that detects staged Meterpreter connection, even if it is on HTTPS ! Note that this post doesn’t cover building any executable from scratch, but rather discusses using 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 second scenario, I had client’s laptop. I was connected to the internal network and the system was part of a domain .

In both cases, I aimed to gather a reverse Meterpreter shell on my server in AWS 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 really cool techniques and tools which will I describe in detail. To simulate similar scenarios which I faced, I set up infra 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

Before starting from the beginning, lets jump in middle of my engagement. I had generated an executable successfully which spawned a reverse Meterpreter(reverse_https) shell on a server in AWS. Everything worked like a charm and it was time to test on a system with an antivirus.

I ran the executable on VM; running Symantec Endpoint Protection and then a surprise. 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. What the hell ! How could my encrypted connection be detected by an IPS? So, lets look into 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 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.

After 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 clear text. 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 blocking by AV, I set up listener in listener in Metasploit. The payload chosen was “windows/reverse/meterpreter/https” and port was 443. Note that no payload was created;only listener was set up.

1.png

Once the listener was ready, I ran Wireshark and opened the reverse handler URL. The following capture shows clear text data during initial SSL handshake. The server has sent the certificate in response to client hello request, in clear text.

2018-04-24_13-44-02.png

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

Three different certificates were extracted. Details of 2 certificates is shown below:

3.png

4.png

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 is not same in both the certificates.

IPS Signature Based Analysis in Action

Not that we have retrieved the certificates, lets 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.

14.png

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

15.png

Conclusion on AV Detection

The initial SSL connection is in clear text, wherein 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 needed to find a way to use custom certificate instead of default Metasploit certificate. For this, you can either generate our own self signed certificate or use Metaploit’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 🙂

Lets generate the certificate using SSL impersonation module:

16.png

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

3.png

Once the handler is run and is accessed using browser over HTTPS, the payload is not detected by Symantec.

4

Part 2: Payload Generation

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

To generate payload, I followed the following steps:

  1. Use Metaploit to generate Meterpreter revere 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 above generated Powershell code embedded in it.

Generating shellcode using Metasploit

So, firstly, I generated payload using Metaspolit. In this, you need to make sure that handlercert and stagerverifycert is set. For bypass egress port filtering, I checked outbound port access by performing 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.

5

Generating malicious BMP with DKMC

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

9.png

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

6

Now, copy this shellcode and generate a malicious bmp using gen module.

7.png

The bmp payload has been generated now. I hosted the BMP on 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.

8.png

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 system and you want a more privileged Meterpreter shell, you can simply run the command in the Windows shell to get reverse shell on your C&C.
  • The payload can be saved in .ps1 (Powershell script) and then run 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 Windows shell to obtain a reverse shell on Kali in AWS.

However, to create an ideal executable which can be delivered on a victim’s system to spawn a shell, lets 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 user visits the HTML file on the web, the HTA file is decrypted dynamically within the browser. The goal is to bypass content of 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.

10.png

Final Action

I hosted the html file on web server in AWS and accessed the file from Win 7 machine, which was running Symantec AV. Upon access the html page, an HTA file is downloaded.

11.png

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

12.png

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.

13.png

The following screenshot shows reverse connection status in network activity monitoring console of Symantec; which shows reverse shell spawned to my Kali on AWS under Powershell process. What an irony !

14.png

Conclusion – Basic Flow

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

Step 1: Impersonate SSL certificate

Step 2: Create shellcode configured with impersonated SSL certificate

Step 3: Embed obfuscated shellcode in a BMP image

Step 4: Set up listener configured with 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 as well as the connection is not being detected by any AV or endpoint control. I have specifically checked the whole process on Symantec, Kaspersky, AVG and Windows Defender.

Thanks for reading.

1 Reply to “Bypassing Detection for a Reverse Meterpreter Shell”

  1. I am using Windows 10 latest version as a victim on host machine and Kali linux 2018.2 on virtual box as an attacker. I reproduced above steps with my local ip configurations and servers. But when I execute the powershell code in cmd or as .ps1 file with or with administrator privileges it is neither showing anything nor any meterpreter session.
    Kindly help me to solve or to debug this problem. I’m stuck. Please..

Leave a Reply

Your email address will not be published. Required fields are marked *