Monday, April 20, 2020

Detecting Malicious Activity in Network Traffic

 During my usual scour of any.run for interesting samples, I came across a .bat batch file which included both Koadic and Cobalt Strike infections. Not being sure how common it is to see both frameworks used almost simultaneously, I wanted to take a further look with a focus on the network traffic.

I have not been able to find similar campaigns or come across other samples to suggest this attack is being seen elsewhere. The focus of this post will be on conducting a quick "hunt" through the traffic in the PCAP of the infection. Zeek will be heavily utilized, with Wireshark making an appearance a few times.



Sample: https://app.any.run/tasks/21989a13-02c5-46c3-a584-83c5bf1c117f/

Great info to get started:  https://www.activecountermeasures.com/how-to-threat-hunt-your-network/

 Command and Control

Identifying persistent communication channels in your network may be difficult as a number of legitimate services "call home" regularly. If the adversary plans on maintaining and later on moving laterally, they must constantly check in with the victim system. This constant communication is a great way for defenders to identify long connections out of the ordinary.

A number of frameworks provide options to introduce jitter into the C2 communications. This allows the adversary to randomize how often their malware reports back to the C2 server.

Many programs exist to identify long connections, however that is not in the scope of this post. Let's read our PCAP into Zeek, and get this hunt started!


Figure 1

The downside about analyzing a PCAP from an automated sandbox is that we may not get the entire picture of infection as their is a time limit for the sample being run. From what we can see above in Figure 1, nothing stands out immediately, and we can keep digging.

Protocol Discovery 

Analyzing the protocols used to communicate between two devices could allow an analyst to identify anomalous activity. As you may not expect regsvr32 to make connections from your endpoint, knowing what is "normal" on your network and how protocols are utilized can lead to interesting findings.

Again using Zeek, we can get an idea of the protocols seen from the connections log.

Figure 2
The traffic from our compromised system at 192/168.100.87 to 142/93.252.95 over port 9999 is definitely interesting and will require us to keep pivoting from what we find.

We saw the suspicious communications to the above IPv4 address, let's check the DNS logs for any funny looking domains.

Figure 3
Other than the DNS lookup for the bot-framework.azureedge.net, nothing else looks to out of the ordinary. However we don't see a domain name for the 142/93.252.95 address from Figure 2. Any IP to IP communications should be considered suspicious. The bot-framework allows users to create chat bot on services like Skype. More on that in a few!

Internal Host Connections

As stated above, any internal IP to external IP addresses are probably suspicious, but should be verified depending on your environment. With a tad bit more information to work with than what we started, lets continue by identifying any unique HTTP user agents and URI paths.

Figure 4
This may be a little hard to read, but there are more than a few indicators that should ring alarm bells. Analyzing the user agents would be an exercise for the analyst to identify anything unique to their environment.

As we identified earlier, the traffic to IP address ending in .95 contains some suspicious URI paths with the most interesting being "./mshtml, RunHTMLApplication".  Additionally, traffic to IP address 209/97.190.80 resembles known Cobalt Strike user agent as well as the "/g.pixel" URI that is randomly chosen by the malleable C2 profile.

The http log from Zeek gives us a clearer view of the URI's requested.

Figure 5
Analysis of Destination Server(s)

We have identified what appear to be at least two servers of interest.  We will continue our hunt and drill down on what exactly is being served up.

Figure 6
We know from the sample that this infection kicks off from a batch file which is unfortunately not available. We see the same Zeek output from earlier, in addition to a protocol warning about the traffic we have lightly attributed to Cobalt Strike.

Let's start our analysis with the suspected Cobalt Strike system.

Figure 6
This system has quite a few ports open, the most interesting of them being port 50050. By default, the Cobalt Strike client utilizes this port to connect to the team server. Ports are soft indicators and can be changed easily. The well-known "HTTP 1.1/ 404 Not Found" message was found on ports 443 and 8080.

Figure 7

Figure 8

Figure 9
 With a few lines of Python and some Cyber Chef, the final payload of the suspected Cobalt Strike script reveals the system ending in .80 as well as the user agent we saw earlier with Zeek.

Let's move to our second suspect system.

Figure 10

Figure 11

I'm not sure whereabouts Some-State is located, but the server utilizes a self-signed certificate from Internet Widgits Pty Ltd. It should go without saying that you should be suspicious of any server utilizing a self-signed certificate.

Figure 12

Figure 13 


The final two graphics above depict behavior consistent with the Koadic C2 framework. It should be noted that the service listening on port 9998, was identified as an Apache server with a banner of HTTP 1.0/ 404 Not Found. No other identifying information about this server was found at this time.

Defenses 

The following Mitre Att&ck tactics were utilized in this sample:

TA0002 - Execution
TA0003 - Persistence
TA0005 - Defense Evasion
TA0007 - Discovery
TA0011 - Command and Control

If you are more of the killchain type, defenders need to concern themselves with the following:

Exploitation
Installation
Command and Control

Applying a few techniques, most native to Windows allows defenders to protect themselves and identify how their current environment would hold up.

The exploitation that allowed this adversary to be successful was not due to a cool zero day or software backdoor. The issue stems from a lack of filtering out the benign information and monitoring only what may be abnormal network behavior.

 Process monitoring would have alerted that a .bat batch file was responsible for PowerShell making network connections. A batch file making a connection may not be unusual in your environment, but encoded PowerShell most certainly is. If possible, script block logging would be a great addition to your defense practices.

Windows Defender Application Control (WDAC), Attack Surface Reduction, and Applocker are all free tools that can trip up attackers in the beginning stages of the attack.  These tools would prevent the application whitelisting bypasses of regsvr32 and rundll32.

Summary

 While it would have been great to have had a PCAP with more traffic, I think this post shows just how much info can be gleaned without a GUI. The hunting process from Active Countermeasures provides a quick and decisive approach to identify activity, whether it be malicious or benign.

Other than the use of Digital Ocean for adversary infrastructure, there was not much else to make a strong attribution of the threat actor responsible. The use of Koadic and Cobalt Strike is indeed interesting, and a technique I will keep an eye out for in the future.

I leave it to the reader to take a look at the sample run, and find out why the bot-framework connections and Skype was an interesting find earlier in the post.

Dual Lingo: Japanese and English Titled LNK Files Targeting Businesses

 27 Nov 2020  *The files discussed below were discovered around ~10 days ago. Domains and IP addresses have likely been changed/abandoned. W...