Purpose

Every day new devices and applications are added to our networks and with them vulnerabilities more often than we would like to, this makes it very difficult to prevent every breach before they begin, however, this does not mean that we will not employ different technology and efforts to detect attacks while they are happening and one common task on every adversary plan is to get some sort of shell, hence the scope of this set of rules.

We will take a close look on how generic reverse meterpreter HTTPS shells works and attempt to extract different cues that can identify them, since they are pretty common during penetration tests and none targeted attacks.

Since all the traffic is encrypted there is no way we can decode the protocol or look for known commands in clear text, however there is a short instance when the communication is sent in clear text, and this is during the SSL Handshake between the client (exploit + reverse meterpreter) and the server (metasploit handler), from here we can extract two pieces of very important information:

1. SSL/TLS client fingerprint, according to the work done by the salesforce team, there is a way to fingerprint SSL/TLS clients in a reliable way with the JA3 technique, this consist in gathering the values of SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat and represent them as a string like "771,61-53-60-47-10-255,13,," and make an md5 sum for easy storage, we will divert here since our lua installation (Netmon) does not have an md5 library and adding one requires to add the EPEL repositories on CentOS plus other changes, we will not use any hash algorithm but it is possible, also at the moment we do not take into account the Google's GREASE.
2. SSL/TLS x509 certificate, even though the certificates are generated dynamically during our tests we noticed that the Common Name and Issuer are the same and they are a string of lowercase letters ranging from 1-10 chars, at least during our tests a big sample from other OS like android, mac and more architectures are required to verify if this stands true, in the image below you can see that the common name is a random 6 lowercase letters

With this two pieces of information we can identify in a reliable way reverse meterpreter shells over HTTPS, we provide packet captures for two types of meterpreter shells:

1. For the payload using linux/x64/meterpreter_reverse_https we have a JA3 fingerprint of "771,61-53-60-47-10-255,13,,
2. For the palload using windows/x64/meterpreter_reverse_https we have a JA3 fingerprint of "771,49196-49195-49200-49199-159-158-49188-49187-49192-49191-49162-49161-49172-49171-157-156-61-60-53-47-10,5-10-11-13-35-23-65281,29-23-24,0"

Please note that this rules will not detect the meterpreter shell if a custom or valid certificate is provided during the payload generation with msfvenom or veil, because the Flow rule that generates the alarms verify both the client fingerprint and the certificate values of the CN and Issuer are the same and we defined this as an indicator.

Manifest

• Packet_SSLHandshakeProto.lua: DPA rule used to detect ssl handshakes and to generate the meterpreter SSL/TLS fingerprint, once its detected we add a custom field named Shell_Detected_NM. Since before the SSL handshake we don't have a final applicationId (at least that is what we think) we started to unwind the packet based on the protocol defined in the IP header.
• Flow_MeterpreterShell.lua: since packet rules can not raise alarms we created this flow rule to analyze the commonname and issuer metadata fields of the certificate and if they are the same and have a length it is probably a meterpreter shell via https, we do this over https and tcp/ssl/unknown flows.
• evidence/*.pcaps: we added traffic captures from two different binaries of the reverse meterpreter for linux and windows both on 64 bit operating systems.

Dependencies

There is no special dependencies required to test this rules.

Setup

1. Install and enable the Flow_MeterpreterShell.lua file
2. Install and anable the Packet_SSLHandshakeProto.lua file
3. Replay the packet captures provided in the evidence folder
4. Go to the alarms dashboard and check if there is any new alarm for rulename DPA:Flow_Meterpretershell you can drill down over this new alarm, and verify the x509 certificate fields or the packet capture.