Dynamic Analysis of a Windows Malicious Self-Propagating Binary

[Nytro]

Dynamic Analysis of a Windows Malicious Self-Propagating Binary

SHARE:

 FACEBOOK TWITTER LINKEDIN

May 29, 2019 by Adrian Hada

Dynamic analysis (execution of malware in a controlled, supervised environment) is one of the most powerful tools in the arsenal of a malware analyst. However, it does come with its challenges. Attackers are aware that they might be watched, so we must take steps to ensure that the analysis machine (aka: sandbox) is invisible to the binary under analysis. Also, since we are granting a piece of malware CPU time, it can use it to further the threat actor’s intent.

In this blog post, I will walk you through the analysis of one such binary. The malware at hand infects a computer, steals some local information and then proceeds to identify vulnerable targets on the local network and in the greater internet. Once a target has been found, it attempts to deliver malware on that machine. Such self-propagating malware has been in the news a lot in the past couple of years because of WannaCry, Mirai and other threats exhibiting this behavior. However, this technique is not limited to these families of malware – self-propagation has been around since the Morris worm of the late ‘80s – and we expect it to be used more and more. This raises a dilemma for those analyzing malware – by not limiting the things malware does, we’re granting them useful CPU cycles. By limiting them, we are unable to completely analyze the malware to determine all of its capabilities. 

AN INTERESTING TARGET

The sample at hand is a Windows binary with SHA256 54a1d78c1734fa791c4ca2f8c62a4f0677cb764ed8b21e198e0934888a735ef8 that we detected in May.

Figure 1 - Basic information for binary

The first things that stand out are its large size – 2.6MB – and the fact that it was compressed using PECompact2. PECompact is an application that is able to reduce the size of a given binary and, with the correct plugins, can also offer reverse-engineering protection. This is probably an attempt on the attacker’s part to make the binary smaller (faster and less conspicuous delivery) and cause trouble for antivirus products to detect. 

A quick search on VirusTotal shows that this is not the case – 49 out of the 71 detection engines detect it as malicious. Some of the detection names point to The Shadow Brokers, Equation Groupand WannaCry. Community information also points to mimikatz, a tool used to steal interesting security tokens from Windows memory after an attacker has established a foothold.

Figure 2 - Detections pointing to known threats and leaks

LOCAL EXECUTION

When executed, the malicious binary drops multiple files on the Windows system. One of these is a version of mimikatz, as mentioned above, dropped under the name “C:\Users\All Users\mmkt.exe”. This file is executed and drops a series of files to the local file system containing interesting system tokens:

• C:\ProgramData\uname
• C:\Users\All users\uname
• C:\ProgramData\upass
• C:\Users\All users\upass

Other dropped files include some necessary DLL files as well as six other interesting files: two executables, two XML files and two files with the extension “.fb”, all to the folder C:\ProgramData:

• Blue.exe
• Blue.xml
• Blue.fb
• Star.exe
• Star.xml
• Star.fb

The 6 files belong to the exploitation toolkit known as FuzzBunch, part of the ShadowBrokers dump, and are required to execute the exploit known as ETERNALBLUE and the DOUBLEPULSAR backdoor that could be deployed using the exploit. The pair has been used in attacks extensively since the dump and WannaCry came out – see the ATI team blogpost on WannaCry as well as another blogpost on other threats exploiting this in the wild after the leak came out. Although the exploits in the ShadowBrokers dump have been around for quite some time, our 2019 Security Report clearly points out that exploitation attempts for vulnerable targets are alive and kicking.

Figure 3 - EternalBlue files from original dump

The XML and .fb files are identical to the ones from the original ShadowBrokers leak.

Figure 4 - EternalBlue-2.2.0.fb from ShadowBrokers dump

Figure 5 - blue.fb from the sample analysis

It becomes clear that this sample is intent upon spreading as far as possible. It’s time to look at the network traffic involved to identify what it is doing.

NETWORK TRAFFIC

Analyzing the network capture with Wireshark, we see a lot of different contacted endpoints:

Figure 6 - Extract from the list of IP addresses contacted by the sample

The first two servers belong to Microsoft and Akamai and are clean traffic, Windows-related. Then comes the malware traffic itself – one to an IP address in Malaysia, probably command and control (C&C) traffic, the rest targeting consecutive IP addresses in China, part of the worming behavior. Up next, a long list of private IP addresses with little traffic – failed scans since these hosts did not exist in our local network. Note that our sandbox isn’t configured with the 192.168.0.0 network address, so it seems that the sample doesn’t rely solely on the existing interfaces but also on a hard-coded network range to be scanned.

The sample scans for an impressive number of open ports on the hosts in both the local network and in the greater Internet. The ports attempted seem to be the same for both types of hosts.

Figure 7 - Extract from the ports scanned for one LAN IP

Interesting ports that seem to be targeted include SSH, RDP, SMB, HTTP and many others.

Figure 8 - Unsuccessful attempts to connect to RDP and SMB on hosts

COMMAND AND CONTROL TRAFFIC

The sample connects to an IP address in Malaysia for C&C, first sending a login request.

Figure 9 - C&C check-in

The request comes with a “hash” and a “url” parameter, both of which are hex strings. The “hash” parameter is likely used to identify the host. The “url” parameter is a string that was Base64 encoded and then hex-encoded. Decoding it reveals that the malware is checking in the Administrator credentials that were stolen using Mimikatz.

Figure 10 - Decoding checked in data – URL parameter

Then comes another request that returns the beginning of an internet IP address range to try to spread to:

Figure 11 - Receiving a target IP range to exploit from C&C

From this point on, the malware starts scanning said network address. It periodically checks in interesting information to the C&C server – for example, after it’s identified a server that is up, it checks in the location data – where to find the web server and what the title page is.

Figure 12 - Sending data on discovering network host up

Figure 13 - Decoding URL parameter, letting the C&C server know of discovered web server

Figure 14 - Decoding Title parameter, which sends the page title of the web server response

EXPLOITATION AND POST-EXPLOITATION

The binary attempts different exploit methods depending on open ports. For HTTP, for example, it attempts to access different pages – most to check if a vulnerability exists, but some of them with overt RCE attempts. One such example, an exploit against ThinkPHP that Sucuri previously reported as being used in-the-wild.

Figure 15 - ThinkPHP Exploit Attempt

There is a minor difference in the payload than what Sucuri has reported – this attacker attempts to execute “netstat -an” on the machine to get network info, in the Sucuri report “uname” is used as an RCE test instead. Our honeypots have detected the Sucuri payload every day, so it seems that the attempts come from different attackers targeting the same exploit.

Another complete exploit comes for the Apache Tomcat platform, CVE-2017-12615. The attacker attempts to upload a snippet of piece of JSP code that they can then execute via GET request:

Figure 16 - CVE-2017-12615 attempt to upload JSP code to server

The name “satan.jsp” is a good hint of who this malware really is. In December of 2018, NSFocus blogged about the actors behind Satan ransomware using a self-replicating worm component that would then download ransomware or a cryptocoin miner onto the exploited machines. The reported exploitation methods include a list of web application vulnerabilities that are very similar to the sample at hand – the two ThinkPHP vulnerabilities seeming to be the only ones missing from the original report. The behavior they reported also include SSH bruteforcing, ETERNALBLUE and DOUBLEPULSAR against SMB-capable hosts. It seems that we have identified our threat actor.

Figure 17 - JSP shell code that downloads a binary from a web server depending on platform

The JSP code downloads an executable from the remote server, fast.exe, on Windows platforms, as well as a bash script on Linux platforms. It then executes the payload. The names involved in the script and JSP shell, “fast.exe”, “ft32”, “ft64”, “.loop” are similar to what NSFocus reported.

Similar to the NSFocus report, the “ft*” and “fast.exe” are simple downloaders for the rest of the modules. “ft” contains a list of C&C servers to contact, in this case all of them in the same network range:

Figure 18 - String view of the "ft32" source code, which shows hints of persistence using Cron as well as C&C IP addresses

Paths towards all the different malware components to be downloaded are available – conn32 and conn64, cry32, cry64 and so on. Linux binaries are UPX-compressed and Windows ones us PECompact2. In short, on successful exploitation, the downloader module is installed on the machine and it, subsequently, tries to contact a C&C server, pull the different components on the box and then start spreading, encrypting, mining or a combination of them, depending upon the malware author’s will. For a more detailed analysis, check out the NSFocus report mentioned above.

RESOLVING THE ETHICAL DILEMMA

The execution of this malware in our sandbox was mostly unrestricted. As a result, we were able to observe C&C communications and create a good signature. However, this is just what the threat actor desires – people executing his malware to spread it further. As a result, we’ve taken some precautions to limit the maximum amount of damage that sandboxing such samples can do – for example, not using any URLs accessed by these samples for our web crawler since that might lead us to re-executing exploits against innocent websites. Unfortunately, these steps are not perfect as we’ll always have to find balance between how much we allow and limit.

CONCLUSION

This is an example of the work that goes about when identifying an interesting binary. The work is not limited to simply classifying the malicious behavior but comprises other things as well – identifying ways of detecting the malware via local or network means, correlating information with known sources to validate our research as well as improve the current public knowledge of threat actors and their tools, improving our crawling ability to discover threats as quickly as possible as well as, in this case, making sure that our products are able to use all of this intelligence. 

Analysis of this binary also revealed a few gaps in our honeypot tracking and exploit traffic simulation capabilities which we are actively working on – deploying honeypot improvements and creating new strikes. BreakingPoint customers already have access to most of the exploits identified during the analysis of this binary – strikes for ETERNALBLUE, Struts S2-045 and S2-047 and other vulnerabilities. ThreatARMOR and visibility customers with an ATI subscription benefit from these detections as well with C&C addresses now being identified and most of the exploits having been tracked by our honeypots for a good amount of time now. 

LEVERAGE SUBSCRIPTION SERVICE TO STAY AHEAD OF ATTACKS

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.

 

Sursa: https://www.ixiacom.com/company/blog/dynamic-analysis-windows-malicious-self-propagating-binary