ScanBox framework – who’s affected, and who’s using it?

Earlier this year the Japanese language website of one of the world’s largest suppliers of industrial equipment was compromised by a sophisticated threat actor. Usually in such cases an attacker will use their access to place an exploit kit on the compromised website, delivering malware to visitors - a technique commonly referred to as setting up a ‘watering hole’ or ‘strategic web compromise’. In this case however, rather than relying on malware, the exploit kit was a self-contained key logger that recorded all keystrokes the user performed while on the website. AlienVault[1] produced an excellent write-up on this framework, which the developers named ScanBox.

ScanBox is particularly dangerous as it doesn't require malware to be successfully deployed to disk in order to steal information - the keylogging functionality simply requires the JavaScript code to be executed by a web browser. The framework also facilitates reconnaissance, enabling attackers to exploit vulnerabilities in visitors systems in a more traditional fashion, by pushing & executing malware.

Since the initial post made by AlienVault, we have been actively scouring the web for new instances of the framework. In this blog, we’re going to discuss four other watering holes which use ScanBox:

Month Identified

Country

Sector / type

ScanBox domain

August 2014

JP

Industrial sector

js.webmailgoogle[.]com

September 2014

CN

Uyghur

code.googlecaches[.]com

October 2014

US

Think tank

news.foundationssl[.]com

October 2014

KR

Hospitality

qoog1e[.]com

Table 1 – Selected ScanBox compromises

Looking at who was being targeted, we noticed a reasonable variation, including targeting of the Uyghur population in China, US Think Tanks, the Japanese Industrial sector & Korean hospitality. This variation was our first clue that more than one actor may be using the framework (although on its own this would not be enough - some actors do target a wide range of organisations, some also focus on specific geographies or sectors).

To check if this was the case, we took a deeper dive into each version of the code.

The Framework

Whilst all four implementations share the same codebase, there are some minor differences in their implementations. These differences may show that different attackers are using the ScanBox framework. We’ve outlined a few key differences we identified below:

Malicious code was delivered in a single block of JavaScript on both webmailgoogle[.]com and foundationssl[.]com. The domains qoog1e[.]com and googlecaches[.]com selectively loaded extra plugins from separate files:

Figure 1 – The JavaScript function to load additional plugins

We can see how these differ by comparing two exploit kits side by side:

Figure 2 – foundationssl[.]com on the left loads JavaScript inline. qoog1e.com on the right loads JavaScript from separate files

A motivation for selectively loading plugins is likely to be to prevent crashes or any errors appearing (which may alert the compromised site’s owner) when the page is loaded – as some of the plugins are only compatible with specific browsers. Selectively loading plugins has the added bonus of slightly reducing access to the attacker’s code to researchers. Browsers the attackers are not interested in will be served the following placeholder instead of the malicious function:

Figure 3 – The empty JavaScript function that the exploit kit delivers when a browser doesn’t match a targeted browser

The following ScanBox plugins are deployed on code.googlecaches[.]com, dependent upon the user's browser:

From a developer’s perspective, I know it’s always a good idea to check the details of any exceptions that occur when writing code in order to create more stable applications. It’s pleasing to see the ScanBox developers using good coding practices, though only if they’re in the office!

When identifying the security software, only the implementation found on foundationssl[.]com employs the full version of some publicly available code[5] (the section of code with informational messages such as “"Folder was found!"”). In all other versions only a subsection of the same code is used.

At this point we’ve established that there are subtle variations between the ScanBox code deployed on different websites, however this could be due to differences in the expected environment of the targets the attackers wish to infect in each case, or upgrades to the framework.

Analysis of associated attacker infrastructure

In order to potentially group the activity observed together, we analysed network infrastructure associated with the domains used by the attacker(s) deploying the ScanBox framework. Our analysis showed that there was little overlap both in terms of associated infrastructure and in terms of the malware families associated with that infrastructure.

Summaries of each cluster are given below, whilst full details of the components which made up each are available in the Appendix.

Cluster

Starting point

Malware families

Domain Registrars used

Nameservers used

1

*.googlecaches[.]com

Briba, Zegost

PublicDomainRegistry.com

*.cloudns.net

2

*.foundationssl[.]com

Unknown

GoDaddy

*.cloudflare.com

3

*.qoog1e[.]com

Unknown

HiChina

*.hichina.com

4

*.webmailgoogle[.]com

Jolob

GoDaddy

*.domaincontrol.com

We have been unable to identify any direct overlaps between the clusters, i.e. shared domains or IP addresses, neither have we been able to determine any softer linkages beyond the reuse of the GoDaddy registrar.

Of course this could be due to lack of data points available to us – we welcome any additional data points the community are available to provide which show linkages between the clusters shown below.

Visualisations of each cluster can be seen in the Maltego graphs below:

Cluster 1

Cluster 2

Cluster 3

Cluster 4

Conclusions

In this post we’ve identified four affected websites, each of which would draw distinct audiences who would be valuable to different actors. We’ve also taken a look at the variations in how the framework was implemented, and found a few subtle differences in the implementations. Finally, we analysed the associated infrastructure with the attacker domains used in each case, and found no overlap between the clusters of activity.

In a similar fashion to our previous blog entry on potential overlap between APT1 and Putter Panda[6] , we can attempt to explain these differences with several hypotheses:

The framework is used by a single group that target widely and upgrade or adapt their code for different targets, and are careful to avoid any overlap in infrastructure or in services used.

Selections of actors share some resources, as per previous observations with similar kits by some security vendors[7].

The exploit kits have been used by one group, and taken from public watering holes for their own use by other unrelated persons

In our experience, very few attackers have the patience to maintain completely distinct infrastructure with multiple registrars, name servers and hosting providers at the same time, therefore we have a low confidence in hypothesis 1. In our view, the hypothesis with the highest probability is that groups of attackers share resources leading to overlaps – this appears to be an ever more common feature – with malware families, builders, and even sometimes hosting infrastructure being shared between disparate actors with a common goal. Sharing frameworks like ScanBox or other exploit kits allows less sophisticated actors (who were themselves unable to develop a tool like ScanBox) to conduct better attacks.

[2] This appears to be a misconfiguration, as the attackers are looking for Chrome plugins on Firefox

[3] This employs code from “The Browser Hackers handbook” The plugins deployed on “qoogle.com” are the same, though they utilise different plugin IDs – this may indicate that the framework allows you to select which plugins you wish to deploy, and then the entire framework is ‘built’ by a builder.

[4] This is the key logger described by AlienVault, and using code previously published on sites such as CSDN

I don't know much about cybersecurity within Japan, though I'd be happy to put you in contact with some of our Japanese team who would have more insight. Others with more knowledge than myself have commented that Japan may be a little behind countries such as the UK,US and Australia as they have more embedded government support.

JPCERT do a fantastic job responding to incidents, though perhaps they could use extra funding given how busy they are.

I suppose really it comes down to co-operation - I am lucky I do get to talk to my Japanese colleagues, and I hope we will talk more and share more knowledge in the future.
The same could be said for the wider industry- more co-operation and information sharing against threats should start to give give defenders the advantage.

Hi Chris,
Thank you for your insight into this issue. I was wondering if you had any thoughts on gaps in the cybersecurity market that you think UK companies in particular might be able to fill? Japan just passed its new Cybersecurity Strategy in Sept of this year and with little understanding on how implementation is going to follow through, I thought I'd seek your expertise on whether you think UK companies or other international cybersecurity companies might be able to help Japan.