A technical paper by Fraser Howard, SophosLabs, UK
3 Code obfuscation
The sharp rise in the volume of malicious samples over the past few years is mainly due to server-side polymorphism (SSP) functionality. This refers to the situation where the encryption engine is hosted in scripts (normally PHP) on the web server, and is used to periodically rebuild the content. As such it is perfectly suited to all web-delivered threats. The engines can be used to build polymorphic content for most file types, but the technique is most effective when applied to files that can easily be generated dynamically upon each request (e.g. HTML, JS, PDF). All exploit kits use SSP functionality in an attempt to evade detection.
In this regard Blackhole does not disappoint. In fact, the aggressive efforts put into code obfuscation make Blackhole one of the most persistent ‘threat campaigns’ experienced to date. Each day we encounter thousands of new, unique files for the various components used in the kit. Exactly how the code is obfuscated depends upon the file type in question.
One of the peculiarities with Blackhole has been the coordinated nature of the changes in code obfuscation. This is easily observed by monitoring the volume of Blackhole detections reported in the field. When code obfuscation changes are sufficient to break generic detection, we see an immediate sharp drop in reported detections. We can speculate that this arises because of the centralised control provided by the rental model of Blackhole. Updates appear to be deployed very rapidly to active Blackhole sites. This is contrary to experience with other exploit kits, where attackers purchase the kit and host/administer it themselves.
In addition to these continual ‘minor’ changes produced by the encryption engine, there have been several ‘major’ changes in the Blackhole landing page over time. These tend to correspond to structural changes in how the page is put together; something you would not expect without an update to the kit.
Table 3: Examples of some of the main changes in the structure of the Blackhole landing page as it evolved over the past year.
As shown in Table 3, the structure of the Blackhole landing page is regularly updated, in some cases reverting back to tactics used several months previously. Despite the structural changes, the functionality of the landing page has remained fairly static over time (see Appendix 1). That said, just as this paper was being finalised, the landing page was modified to load the PluginDetect library from a remote server, rather than embedding it in the page.
As noted above (Section 2.3.1), there are a few script injections that have become synonymous with Blackhole. The obfuscation used in these is modified as aggressively as that used in the landing page. Since these scripts are injected into legitimate web pages, there is no option for the attackers to modify the structure of the page. Instead they are restricted to tricks within the injected script itself. The most recent of these include the use of Math functions, presumably as an anti-emulation technique. Examples of this are shown in Figures 3 and 11.
Figure 11: Recent Mal/Iframe-W script injected into legitimate sites. Note the use of Math.log and Math.E as an anti-emulation trick.