Evolution of the Nuclear Exploit Kit

Thursday, October 9, 2014 05:54

This post is co-authored by Alex Chiu, Martin Lee, Emmanuel Tacheau, and Angel Villegas.

Exploit kits remain an efficient mechanism for cyber criminals to distribute malware. Such kits include exploits for multiple vulnerabilities within a single malicious webpage. Criminals can check operating systems, web browsers and browser plugins for anything that is not fully patched and launch an exploit specific to the out of date software. Using this technique criminals can maximise their chances of infecting visitors but reduce their exposure to only infect those who are vulnerable; presumably in order to remain inconspicuous.

We have previously written about the Rig, Angler and Styx exploit kits and and how they are a serious threat if machines with vulnerable third-party software are left unpatched. We have also previously discussed how attackers have turned to malvertising as a viable means of redirecting users to exploit kit landing pages. The Nuclear exploit kit is no different from the other exploit kits we have talked about in that it gets distributed in the same fashion and presents the same threat as the others exploit kits. Users who wind up compromised by an exploit kit put themselves at a greater risk of having sensitive information stolen or having their computer used for other malicious activity. In recent weeks, the Nuclear exploit kit has shown a marked increase in activity. Exploring their traces within our security telemetry demonstrates how the attack evolved.

Looking at the number of blocks recorded by Cisco’s Cloud Web Security service attributable to the Nuclear exploit kit shows that the campaign started during mid-August, reached a peak on September 18, then rapidly tailed off.

During this time, we observed the malware being hosted on 47 distinct IP addresses hosted by 11 different network providers.

Plotting the cumulative number of IP addresses (in blue) against time over the length of campaign shows that IP addresses were used at a steady rate. IP addresses were typically used to host malware for no more than one day before being discarded. The small number of IP addresses used, and the fact that the network addresses were typically reserved for static allocation rather than for dynamic home broadband use suggests that the malware was not being hosted on a botnet, but rather on dedicated servers.

The first nine days of the campaign saw the attackers use IP addresses provided by nine different hosting providers. However, only three providers were used for the remainder of the campaign, and one of these was only used on one occasion, demonstrating a strong preference for two hosting providers for hosting the malware.

We have no evidence to suggests that the attackers used bullet proof hosting providers. The rapid change of providers at the beginning of the campaign coupled with settling on two providers for the remainder suggests that the earlier providers may have rapidly withdrawn services to the gang, whereas the later two providers were not as pro-active in identifying and resolving malware hosting on their networks.

The attackers also abused the free domain provider uni.me to provide URLs for their malware. Before August 27, the domain pattern used consisted of 10-14 random letters and numbers, followed by a pseudo-word, followed by uni.me

e.g. 63569f0dhrhq6e.orlikineston.uni.me

After August 27, the initial random letters and numbers was dropped and the domains took the form pseudo-word dot uni.me.

e.g. lithformedhors.uni.me

Additionally, we identified 59 apparently legitimate domains with nameservers hosted by afraid.org, a Free DNS and Dynamic DNS hosting service, that the attackers utilized to create similar pseduo-word subdomains pointing at malware serving websites. This different pattern of domains may indicate the activity of a different gang or a separate affiliate, however in many cases the same malware was used for both activities suggesting that there was, at least, a common link.

The malware used in the campaign consisted of a heavily obfuscated Javascript landing page which identified the visitor’s browser, its version, operating system, and checked for the presence and version of various plugins. Depending on these values, the script would select the exact malware to serve to the visitor based on one exploiting one of the vulnerabilities from this list:

At least some of the exposure to the malware originated from malvertising where criminals have placed Javascript to redirect visitors to malicious pages within web adverts served on legitimate web sites. We have previously written about this activity which remains an effective method for criminals to distribute malware.

A Closer Look
In our investigation into this malware campaign, we took a closer look at a couple key elements that caught our attention. We’d like to discuss a couple of these elements we noted in our investigation of the evolution of the Nuclear exploit kit.

As we previously mentioned, this malware campaign utilized obfuscated JavaScript to conceal which plugins were being detected and what browser was being used.  Attackers typically introduce several layers of complexity to conceal the detection code by encoding the actual detection logic, utilizing indirect function calls, and layering these indirect function calls to obfuscate the execution flow.

In the above segment taken from part of the exploit kit landing page, one thing we notice is the declaration of the “nK5” variable and its assigned value, a unique, random looking string containing special characters.  This string is actually a transposition of all printable ASCII characters which is used as a key table to decode the actual plugin detection logic.  To see how, you’ll need to look at the encoded detection logic.  Below is a small snippet of the plugin detection logic encoded.

The plugin detection logic is encoded as a long string of numerical digits which can be broken down into successive two-character strings.  These two-character strings are then evaluated as integers with the integer being used as an index to retrieve the original intended character from the declared transposition string.  There is a small caveat in that if the integer evaluated is greater than or equal to 10, 2 is subtracted from the value of the integer. Otherwise, the integer is left as-is.  The result is that the detection logic is decoded with a simple substitution cipher and using a transposed string of all ASCII characters as a key table.  The following diagram is an illustration of the algorithm using the first 11 decoded characters as an example.

Examining the Java Exploit in More Detail
We noted earlier that the exploit kit utilizes Java vulnerability CVE-2012-0507 if the plugin detection code finds a vulnerable version of Java on the system.  We took a closer look at this, starting from the plugin detection code.  Below is a part of the Java detection code on the landing page.

In our analysis, we observed that the actual code that exploits CVE-2012-0507 is contained within a serialized object.

In this instance, the exploit proceeded to download a payload from hxxp://tulmenifica[.]cube-gg[.]com/f/2/1410177840/3680688730/2 and save the payload as “1palitra.exe” in the temp folder.  The payload is then executed as either "cmd.exe /C start" or "regsvr32.exe /s,” depending on the t or tt parameter passed to it by the detection code.  The “t” parameter set to 1 would tell the exploit to download the payload and execute it immediately while the “tt” parameter would signal the exploit to download the payload (a DLL) and register it as a service.

Indicators of Compromise (IOCs)
You can view all the domain names we've observed serving the Nuclear exploit kit here.

Additionally, here is a list hashes of all the exploits and executables we've seen.

Conclusion
This campaign is an example of the continuing activity of malware distribution gangs on the internet and the continued evolution of exploit kits. Organisations need to remain against these threats. Maintaining systems fully patched and scanning web content for the presence of malware remain vital in order to protect users from infection.

Additionally, organisations need to make sure that their domain names have not been compromised to allow miscreants to create malicious subdomains, and that servers are not being abused to host malicious content.

Protecting Users Against These Threats

Advanced Malware Protection (AMP) is well suited to detect and block this type of attack.

CWS or WSA web scanning will prevent access to malicious websites and detect the malware used in this attack.

The Network Security protection of IPS and NGFW have up-to-date signatures and will block this threat.

ESA is not applicable for this attack, because the threat is not using email.