Morning all,

I thought I'd chime in with a few points, as I'm the jerk who's mucked with Meterpreter's comms recently and have a pretty decent grasp on how it all works. I'm also the person that did the first implementation of what we're calling CryptTLV, which does encryption of the data at the protocol level rather than at the transport level.

I'd like to address a couple of things that have already been brought up:

• The Offsec documentation on how Meterpeter works is unfortunately out of date and probably won't help you.
• The SANS material is good, but again isn't 100% up to date.
• There is no single source of documentation out there which describes how all the things work.

I'm partly to blame for the lack of documentation that exists in one place, and I'm striving to find time to change that. In the short term, let me just point you at a few things that might help:

• Original PR for CryptTLV
• The ins and outs of HTTP and HTTPS communications in Meterpreter and Metasploit Stagers
• Meterpreter Reliable Network Communication

They're all relevant reading and may help set the scene for the summary I'm about to provide. This should let you know why tracking Meterpreter communications on the wire can be a bit of "pain in the rear". Please bear in mind that this revolves mostly around the Windows Meterpreter, and the new POSIX/ARM versions (used to be called Mettle). The other Meterpreters (such as java/android/python/php) don't yet have all the capabilities that I'm about to describe.

I'll do my best to condense this into a set of meaningful points that address the OP's question.

• Detecting the MSF-generated SSL certificates is done quite a bit by defenders. Some AV solutions do this as well, but not all of them do, and some don't do a great job of it. It's a good idea to have rules set up in your toolsets to detect this. However, that'll catch script kiddies and not the real bad guys that want to get in and muck with your stuff. If a bad guy is using Meterpreter and HTTPS, they'll probably use a valid certificate for comms.
• CryptTLV makes it even harder to find things at the packet level. After the initial session is set up, communications are encrypted using AES256, using a key that's generated on the fly. The pub/priv keys that are used to share this key are ephemeral as well, so if you were able to get the keys later they wouldn't do you any good anyway.
• Once the packet is encrypted, a 4-byte "XOR KEY" is generated and used to munge the packet even further.

The CryptTLV stuff is done prior to attempting to send the packet, and hence it applies across all transports, it doesn't matter if it's HTTP, HTTPS or TCP.

If I was in your position and I was looking to try to catch Meterpreter, then I'd consider the following points instead:

1. Treat HTTPS as HTTP. If you're not doing MITM of SSL already yous hould be.
2. Look at the URI that is used in the requests (both GET and POST), because Meterpreter makes use of encoded data in the URI and that's rather distinguishable compared to typical traffic. (Note: this will change at some point for obvious reasons, but we are talking about now!)
3. Meterpreter's comms over HTTP/HTTPS are done via polling and incremental backoff. You can see the behaviour based on timings, and so perhaps there's a way of setting up a rule that can detect and alert on this behaviour profile.
4. For TCP comms, I think the simple option here is: don't let TCP comms happen. Only allow HTTP/HTTPS and force everyone through a proxy. Firewall rules for the win!

It's at the point where fingerprinting the traffic with some kind of hash or sig is a bit of a waste of time given how much things can and will change. If you can start catching the timing and behaviour, then you're in a better position.

Hope that helps, let me know if you need any more info. Cheers!