Blog Post

Encrypted traffic analysis to identify Metasploit HTTPS reverse shell with Awake

The Metasploit framework is a widely used penetration testing tool used by both defensive and offensive teams as well as attackers because it supports an ever-increasing list of exploits and different attack methods. One such capability is the reverse HTTPS stager that allows all communication between the infected system and the MSF console to be encrypted through SSL. As this traffic is encrypted, there is no way to identify this activity in the network. However, security analysts do not have to be blind to this activity. By combining destination analytics with encrypted traffic analysis, it is possible to identify the Metasploit HTTPS reverse shell. Let’s see how.

Below is the default Metasploit Server Certificate as it appears in Wireshark:

Most of the properties are random but we can still identify certain properties of the MSF Server Certificate, such as:

  1. Self-Signed Certificate – Certificate issuer organization and name will be the same as the Subject organization and name
  2. Certificate issuer locality is always blank
  3. Country code of the certificate will be hardcoded to US
  4. There will only ever be 1 Server certificate presented
  5. Server certificate state, issuer state will be always 2 char
  6. Organizational unit will not contain white space

The screenshot below shows the extracted searchable TLS certificate data from Metasploit reverse HTTPS shell traffic within Awake:

Awake is able to extract rich sets of data for each TLS communication. For example, it can extract TLS server/client certificate properties like Issuer organization, Issuer organizational unit, Issuer state, country code, certificate validity, etc. Importantly, all these stored data sets are fully searchable, which is very helpful when threat hunting or investigating any security incident.

Image result for but wait there's more

I am sure you are thinking, that while this might be a way to detect Metasploit HTTPS traffic, this method is also likely to create significant numbers of false positives. So, can we do better? My colleague Troy Kent talked about application fingerprinting and encrypted traffic analysis in a prior webinar and that’s what helps us narrow the aperture. In this case, we look specifically for the certificate parameters but for traffic originating from TLS clients that are non-browser and non-mobile devices.

As Troy’s webinar mentions, our methods differ from less mature methods like JA3 TLS fingerprinting by considering more information from the network in order to accurately profile the source of TLS traffic.

Moreover, by leveraging Awake’s source and destination analytics that detect and categorize different types of devices, operating systems, destinations, and domains in the network, it is possible to identify specific types of devices. By combining all the information that is made easily available in Awake (certificate properties, non-browser TLS traffic, traffic from specific device types) we are able to detect a Metasploit HTTPS reverse shell in customer environments with nearly zero false positives.

When working from contextually meaningful primitives, it is possible to represent—and leverage—an unthinkable amount of extremely accurate and flexible capabilities to bolster your team’s security posture. How will you leverage Awake?

Hirosh Joseph
Hirosh Joseph

Security Researcher