Tweaking Metasploit to Evade
Encrypted C2 Traffic Detection

Pentesters put themselves in the shoes of attackers [13] to test the security of their client’s systems. Remote control of compromised assets plays a major role in pentesting; this is achieved through the deployment of payloads and the communication between the payloads and the pentester’s command and control software [4]. Detecting this communication is important for security operations, not as much to detect legitimate pentesters as to detect actual attackers that use pentesting tools [10]. This poses a challenge to the legitimate pentester – if C2 communications are blocked how can the pentester uncover vulnerabilities and other security issues elsewhere in the target system? IP-specific rules for the pentester could be enacted by the client’s IT staff to allow the pentester’s traffic, but this goes against the premise that a pentest is as good as the assumptions for the attacks are weak. Clients may not take seriously the security issues that the pentester finds if they think the attack is only possible because they allowed it. One way for the pentester to overcome these difficulties is to modify its C2 traffic in order to avoid detection.

In this paper we explore different ways in which the pentester can modify its traffic and what is the impact of those modifications in evading a detector. Pentesting C2 traffic can be distinguished from other, non-C2 traffic with machine learning techniques. Machine learning is especially relevant if the C2 traffic is encrypted and blacklisting server IPs or certificates is not viable because of inexpensive certificate replacement or cloud-based server-side IP sharing [6]. Different pentesting frameworks are likely to have different C2 traffic profiles that a machine learning-based detector may need to learn to distinguish from normal traffic. An approach for C2 traffic communication is to have the payload periodically open a connection to the server, inquiring for orders or reporting results. This ends up creating a regular traffic pattern that can be much different from web and other, non-C2 traffic -- and makes it relatively easy to detect. This is the case of Metasploit¹¹1https://github.com/rapid7/metasploit-framework/, one of the best known pentesting tools. Armed with traffic captures of C2 traffic from a specific tool like Metasploit and of non-C2 traffic from their local networks, security operations are able to train a machine-learning based detector of C2 traffic for their networks. In section IV we show results confirming that for a specific dataset with Metasploit traffic it is possible to train a detector with extremely high performance.

Knowing that its C2 traffic is regular and may be easily detected, the pentester may feel the need to change the traffic pattern to evade a detector. In section V we describe a set of traffic pattern changes to C2 traffic and show how the Metasploit Framework can be modified in order to generate such traffic and evade a machine learning-based detector. We then consider a second threat model in section VI, where the target’s network detection system is aware of the modifications made to the C2 traffic and the pentester employs adversarial learning techniques [8] in order to evade the detector. We present detector evasion results and discuss the overhead and performance impacts associated with the framework modifications.

The communication patterns of open-source C2 frameworks have been studied before. For example, [9] highlights common practices and communication behaviours present in some of the most popular pentesting frameworks, and shows how a machine learning model could be trained based on these behaviours to distinguish each framework’s traffic. Additionally, and specifically focusing on Metasploit, [14] studied the entire behaviour of a Metasploit payload inside a victim’s host, focusing on C2 communication patterns and on the presence of the payload in the victim’s host memory. Although these studies are important for improving the performance of intrusion detection systems (IDS’s), they fail to inform a legitimate pentester on how to overcome such identifiable characteristics and evade detection systems. Additionally, due to the active and open-source development of such frameworks, these studies have quickly become outdated and no longer accurately describe the current implementation of these tools.

Evading detection systems has been a concern for the Metasploit’s development team, as defenders more quickly react to new threats by automatically analyzing and updating detection rules [15]. In 2018, the Metasploit team incorporated evasion techniques like code obfuscation, code stub injection and encryption in the Metasploit Framework modules[2]. Casey et al. [1] studied the performance of these modules in evading commonly used anti-virus software and showed that most anti-viruses are successful at detecting them, likely due to the public availability of the documentation of these modules. The techniques used in these evasion modules are targeted at evading static signature-based antivirus checks like binary file analysis and they don’t change the C2 patterns that can give away the presence of pentesting tool traffic on the network.

Other studies have focused on the use of adversarial learning techniques against machine learning-based detection systems, specially targeting malware’s traffic characteristics. For example, [12] showed how a generative adversarial network (GAN) could be used to adapt the inter-packet time and packet length variance of botnet attacks, in order to bypass an IDS model. Based on the same type of traffic features, Yang et al. [16] showed the performance of different adversarial algorithms against an IDS, in a black-box scenario and the authors of [17] have proposed multiple defense methods against adversarial attacks targeting intrusion detection systems. In a more C2-specific work, Rigaki et al. [11] showed how by adapting a Remote Access Trojan (RAT) C2 communication scheme, according to a GAN, it was possible to mimic the traffic of a legitimate application, thus evading a detector. Although these studies contribute to highlighting the weakness of IDSs against adversarial examples, they all focus on incorporating adversarial learning in malware samples, not on pentesting tools. Specifically, these studies don’t focus on adapting source code such that an IDS that focuses on encrypted traffic can be evaded.

Another conceptually similar topic is the one of censorship circumvention, where an actor masks traffic features by mimicking allowed traffic in an attempt to bypass the censor’s detector. The authors of [5] have used a GAN for automatic traffic generation and censor circumvention, and advancements made in this research field may generally be used by pentesters and vice versa.

During a normal Metasploit exploit process the deployed payload and the Metasploit framework have to communicate. When using a stageless payload this communication is bootstrapped as follows:

1. The exploit occurs and the payload starts on the victim’s host;

2. The payload’s dispatch loop starts and the payload reaches out to the framework on a specific host and HTTP URL;

3. The Metasploit framework on the pentester host recognizes this request as a new session and negotiates TLV C2 encryption keys. Afterwards, any communication for this session between the payload and the Metasploit Framework consists of GET or POST requests with encrypted data.

In our setup we configure the Mettle payload (Mettle is the C-based Metasploit payload²²2https://github.com/rapid7/mettle) to use HTTPS (HTTP over TLS), which additionally secures the bootstrapping and prevents direct eavesdropping of e.g. the type and headers of the HTTP request that the payload issues. When using this type of payload, the Metasploit framework communicates using packets that follow the structure presented in Figure 1, with the encrypted data transmitted between the Metasploit Framework and the payload encapsulated in the TLV layer of each packet. As the Metasploit framework does not internally differentiate between HTTP and HTTPS traffic, its communication workflow is the same whether using HTTP or HTTPS.

Figure 2 shows the payload’s communication workflow after a secure communication session has been established. The payload’s dispatch loop repeatedly contacts the framework in a pooling manner, using empty HTTP GET requests on a new URL generated by the framework. The framework responds to each of these GET requests by sending any queued commands back to the payload. These commands are then individually processed and their results returned using POST requests back to the framework. If no commands are returned to the payload, the interval between the pooling requests doubles up to a maximum of 10 seconds.

This pooling pattern generates very consistent and periodic traffic not commonly present in regular web traffic. Mettle uses the libcurl library to execute its HTTP requests. curl configures requests including custom options, headers, and payload through the handle programming construct. Every time a requests is made and its response is received, Mettle terminates the corresponding handle. This automatically causes a new TCP connection to be initiated and terminated whenever the payload needs to communicate with the framework. This can be seen in Figures 3 and 4.

As a consequence of this behaviour, when using an HTTPS payload, the traffic flow between Metasploit and the payload rarely exceeds more than two TLS Application Data records (type 23, AppData). This stands out when compared to non-C2, web traffic. Table I highlights this characteristic by grouping all TLS records belonging to the same TCP connection and then filtering them by their TLS record type. C2 traffic only shows 1 HTTP request per connection, which produces 2 TLS AppData records – one in each direction. Web traffic shows several TLS AppData records exchanged during the same TCP connection.

The communication workflow we describe in this section is for the standard Metasploit and Mettle versions available online. In sections V and VI we show how to modify Mettle and Metasploit implementations to change traffic patterns while keeping the same workflow and evading a detector. Before that, in section IV, we show how the standard communication pattern is easily detectable from non-C2 traffic without these modifications.

The model we use to detect C2 traffic takes as input a sequence with the sizes of the first 20 TLS AppData records in both directions of a TCP connection. These sequences of sizes are extracted from traffic captures using Cisco’s Joy³³3 https://github.com/cisco/joy tool. These features are then filtered by their TLS content type and the length of the AppData records is fed to the model. We pad flows with fewer than 20 TLS Appdata records using the value -1 and truncate flows with more than 20 TLS Appdata records.

Internally, the model consists of a multi-layer neural network with an input layer of 20 nodes (for the first 20 TLS AppData records), 3 “hidden layers" of 2048, 1024 and 512 nodes respectively, all with a relu activation function, and a final output layer with 2 nodes for categorical classification with a softmax activation function. In each layer, we add a 20% dropout layer to prevent overfitting. The softmax function used in the output layer returns a 2-dimensional probability distribution vector on whether the input sequence is considered a C2 traffic flow or not. The Adam optimizer was used for updating weights during training and we use categorical cross-entropy as the loss function.

The model was trained and evaluated using a dataset of locally generated Metasploit C2 traffic together with a dataset of non-C2 traffic. Our locally generated Metasploit C2 traffic consists of a series of Metasploit commands typically used during a pentest, such as sysinfo, ps, ipconfig, route, download /etc/shadow, ls, that are invoked automatically once the payload contacts Metasploit. We repeatedly spawn payloads on a virtual machine and capture the traffic the payloads generate towards the Metasploit host. Our non-C2 traffic was generated using BrowserTime⁴⁴4 https://github.com/sitespeedio/browsertime and consists of 10 visits to each of the top 1k Alexa web sites⁵⁵5 http://s3.amazonaws.com/alexa-static/top-1m.csv.zip .

We achieved a detection accuracy of 99% on 111k balanced C2 and non-C2 samples. This high accuracy confirms our intuition that Metasploit’s C2 traffic is highly identifiable and that a pentester could be easily detected when using this framework.

The detector model developed in section IV is tested with Metasploit C2 samples generated from the standard Metasploit framework. Our first new threat model considers that a pentester is smart enough to attempt to evade such a detector by modifying its C2 traffic.

Threat model #1: A C2 traffic detector, aware of the traffic profiles generated by regular web traffic and the standard Metasploit framework, is able to consistently detect the presence C2 traffic. Knowing about this, and to remain undetected, a pentester is able to modify the communication scheme of the Metasploit framework in two ways: 1) increase the size of TLS records (section V-A), and 2) change the number of HTTP requests used within the same TCP connection (section V-B). We describe both approaches and their evasion results next.

In order to further analyse the threat model presented in section V, a more robust model, aware of the previous changes made to the Metasploit’s communication scheme, was trained and evaluated. This model’s layers and input features are the same as the one presented in section IV, however the training data now includes samples from the dataset “Random # HTTP requests per TCP Connection" discussed in section V-B. As a result of this addition, the detector is now able to detect Metasploit’s C2 traffic with multiple HTTP requests per TCP connection with an accuracy of 98.4%. With this model in place, we consider a second threat model, as follows.

Threat model #2: A new C2 detector is trained with Metasploit traffic samples containing a random number of HTTP requests per TCP connection, as described in the beginning of this section. Knowing about this, and to remain undetected, the pentester is able to additionally modify the communication pattern of the Metasploit framework from section V.B by adding stuffing bytes to the C2 traffic that are specifically chosen to mislead the detector through adversarial machine learning techniques.

Adversarial machine learning is a technique that tries to trick machine learning models into wrongly classifying specially generated inputs. By taking advantage of the model’s properties, these inputs only need to slightly differ from normal ones in a specific way in order to be incorrectly classified. In this paper, we use the Fast Gradient Sign Method [3], an adversarial type of attack that changes the value of each input feature by a fixed $ϵ$ in the direction of the detector’s loss gradient, $x^{\ast }=x+ϵsign\left({\nabla }_{x}J\right(\theta ,x,y\left)\right)$, thus attempting to achieve a wrong classification. This attack is implemented using the CleverHans [7] library.

In this paper we validated what we suspect is the widely perceived notion that Metasploit C2 traffic can be easily detected even if it is wrapped under TLS encryption. To do so we trained a machine learning detector to distinguish between Metasploit TCP connections and web browsing TCP connections and validated this detector against Metasploit C2 traffic and web browsing traffic that we captured. This yielded 99% accuracy on a balanced dataset. We then modified the Metasploit and Mettle source code so that its C2 traffic can evade the detector and showed that with two different modifications to the traffic – 1) adding bytes, 2) grouping two or more Metasploit HTTP requests into a single TCP connection – a pentester can evade the detector in almost 100% of the Metasploit’s TCP connections. We then retrained the detector with samples from the modified Metasploit C2 traffic, which again yielded a high (98.4%) accuracy, and devised an approach to evade the new detector. This approach uses adversarial learning to choose how many bytes and TLS records a Metasploit C2 TLS connection should have in order to evade the improved detector. We conclude that the evasion rate drops slightly to 91% when compared to the evasion rate of the initial detector and that if the modifications to the traffic are done only on the payload side then the evasion rate drops significantly to 50%. We then look at the overhead of implementing the adversarial learning approach and find that although the size of the TLS payloads increases three fold due to our adding of bytes, the overall number of bytes sent between the Metasploit framework and the Mettle payload reduces by an average of 25% due to a smaller overhead in the total number of TLS handshakes. We also observe that the runtime of Metasploit commands in the payload with our modifications does not increase when compared to the original Metasploit.

In the future we intend to improve our Metasploit and Mettle modifications to split TLS records in two or more, thus considering the case where adversarial learning suggests a smaller TLS record size value than the one that needs to be sent. We also intend to choose adversarial samples according to the command that the Metasploit framework is about to issue to the payload rather than randomly choosing from a set of Metasploit samples. Regarding the adversarial learning approach, we expect to further study the cycle of retraining and adversarial learning; in this paper we did a single iteration of adversarial learning, but the detector could easily apply adversarial learning to its own model and retrain the model with the adversarial samples, which would lead to a cycle. We would like to understand the properties of such a cycle and whether after some point the detector or the pentester could prevail over the other. Finally, we expect to be able to study an alternative to adversarial learning that is closer to mimicry and attempts to squeeze Metasploit traffic into sequences of TLS record sizes obtained from non-Metasploit traffic, namely web.

We would not like to conclude this paper without providing some considerations about how the Metasploit modifications we study here could be used improperly – and by improperly we mean outside of the context of whitehat pentesting such as those targeting third-party systems and which can be detected by honeypot studies [10]. These modifications are relatively straightforward to implement given modest know-how in programming, networking, and the Metasploit framework, and we believe any modest threat actor could develop them. This is one reason for publishing this work – so network defenders can better understand what happens when a modified Metasploit payload is deployed in their networks. Less mature cybercriminals – whose actions likely generate the bulk of attacks these days – and that have only user-level experience of Metasploit, may find it harder to develop these modifications. These users would likely resort to downloading the code from a repository. Because of that, we decided not to publish our Metasploit and Mettle source code.