How are Java attacks getting through?

Were you aware that Java is increasingly being viewed as a security risk? Of course you were recent high-profile attacks have firmly established the trend, so we’re not going to do yet another roundup here.


Instead, let’s drill in and try to understand the core problem. With so many vulnerabilities, it’s hard to keep browsers up to date with the latest patched versions especially because Java is updated independently from the browser. How hard is it? We decided to check.


We recently added Java version detection to our Advanced Classification Engine (ACE™) and pumped it into the Websense ThreatSeeker® Intelligence Cloud to get real-time telemetry about which versions of Java are actively being used across tens of millions of endpoints. Here’s what we found (you may need to click on the graph to see all the detail):


Figure 1: Global distribution of Java Runtime Environment versions based on active browser usage


As you can see, Java versions are all over the map. At the time of this writing, the latest Java Runtime Environment is 1.7.17, but only about five percent of the overall mix are using it. Most versions are months and even years out of date. How does this translate into the attack space?  


Exploit kits are a very common tool for distribution of many Java-based threats. From the billions of daily web requests being classified through our network, here is the breakdown of the active browser requests that are exploitable and which exploit kits have incorporated attacks for them.



Java Vulnerability  Vulnerable Versions**  Vulnerable   Exploit Kits With Live Exploits

CVE-2013-1493            1.7.15, 1.6.41                  93.77%         Cool 

CVE-2013-0431            1.7.11, 1.6.38                  83.87%         Cool

CVE-2012-5076            1.7.07, 1.6.35                  74.06%         Cool, Gong Da, MiniDuke

CVE-2012-4681            1.7.06, 1.6.34                  71.54%         Blackhole 2.0, RedKit, CritXPack, Gong Da

CVE-2012-1723            1.7.04, 1.6.32                  67.72%         Blackhole 2.0, RedKit, CritXPack, Gong Da

CVE-2012-0507            1.7.02, 1.6.30                  59.51%         Cool, Blackhole 2.0, RedKit, CritXPack, Gong Da

** All prior JRE versions below those listed are also vulnerable


It is probably no surprise that the largest single exploited vulnerability is the most recent one, with a vulnerable population of browsers at 93.77%. That’s what the bad guys do examine your security controls and find the easiest way to bypass them. Grabbing a copy of the latest version of Cool and using a pre-packaged exploit is a pretty low bar to go after such a large population of vulnerable browsers. Most browsers are vulnerable to a much broader array of well-known Java holes, with over 75% using versions that are at least six months old, nearly two-thirds being more than a year out of date, and more than 50% of browsers are greater than two years behind the times with respect to Java vulnerabilities. And don’t forget that if you’re not on version 7 (which is 78.86% of you), Oracle won’t be sending you any more updates even if new vulnerabilities are uncovered.


How do you stop the onslaught if the patches aren’t keeping up? Given the complexity and dynamism of exploit kits and their updates, exploit signatures do not suffice. Our protection model against new Java exploits is to use our analytics and real-time telemetry to proactively intercept new instances at every step of their attack strategy. Most prominently, ACE covers the exploit kit/exploit phase with a fine-grained knowledge of the expressible threats from all of the major kits, including not just the vulnerabilities, but also the obfuscation techniques, redirection techniques, and re-packaging of their dropper files. Here are just a few other ways we interrupt the malware kill chain to make it harder for the bad guys to drive right through this sizable hole in current IT infrastructure:


  • Real-time intelligence to block lures, phishing, and other forms of social engineering coming across web, email, and mobile platforms
  • Real-time inbound intelligence to identify known or suspicious malware destinations and compromised sites 
  • Real-time outbound intelligence to identify command and control communication, bot networks, dynamic DNS requests, and fingerprinted data headed to the wrong people or places
  • Identifying malicious droppers both statically and behaviorally (via Websense ThreatScope™



It’s clearly not just the zero-day attacks that should be getting all of the attention.

Websense Security Labs at CeBIT 2013

CeBIT 2013 We returned from CeBIT, one of the largest and most influential technology conferences in the world, last week.

The lead theme at this year’s conference was that of “Shareconomy”, finding benefit in exchanging ideas and information.  As a security lab, embrace the idea of the Shareconomy and have a tremendous amount of threat intelligence to contribute.

…(read more)

Israeli Website for “international institute for counter-Terrorism” Waterhole Attack Serving CVE-2012-4969


Websense® Security Labs™ and The Websense ThreatSeeker® Network have detected that the government-related websites and have been involved in a “waterhole” attack and are injected with malicious code that serves as an exploit for Internet Explorer vulnerability CVE-2012-4969. The first website describes itself as the “International Institute for Counter-Terrorism”. Both websites seem to be connected and governed by a leading Israeli academic institution called the IDC


The malicious code found on the websites is identical and was identified as CVE-2012-4969 – an Internet Explorer vulnerability that was verified as a zero-day at the time and was found to be exploited in the wild on September 2012. It was found by Eric Romang from Zataz.


From our initial checks, the websites still serve the malicious code on specific paths, and have been serving the malicious code from as early as the 23rd of January 2013. At the time of this writing, the malicious code on appears to be fully functional, but the malicious code on doesn’t seem to be functional (the main page that initiates the exploit seems to have been removed; although subsequent pages are still available, on their own they won’t serve a successful exploit).


The attack seems to be very similar to the spear-phishing attacks we reported on with the “Rotary Domains” (Part 1 & 2) that served CVE-2012-4792 – that’s the same zero-day that was found on The attack on IDC uses a Flash file to conduct a “heap spray” attack. The Flash file appears to have the misspelled string “heapspary”.  According to Symantec, this string may be evidence that the “Elderwoord” group is behind this attack, because there’s a similarity to the attack, which held the same string “heapspary” in a Flash file as well. We’re not completely convinced by this theory; this may indeed suggest a connection to the “Elderwoord” project, but may instead suggest the use of the same toolkit by different perpetrators. 


One of the most interesting techniques employed by this attack, which we described in detail in our previous “Rotary Domains” posts, is that the dropped malware is actually embedded as a XORed list of bytes on the page and assigned to a Javascript variable with a marker at the start of the stream.  After exploitation is successful, then on the client side the shellcode initiates a thorough search for a certain marker in memory called “KKONG”.  When this marker is found, then the stream is extracted and de-XORed to form the actual malware binary, which is then run. This is an interesting technique that is also good for Sandbox evasion and reminds us of the “Drive by cache” techniques also found to be popular with spear-phishing attacks in the last two years. The difference in this method is that it’s sort of a “Drive by marked memory object”.


Websense Security Labs™ has contacted the IDC to report the compromise; as of this writing we had not heard back yet from the IDC.


The Israeli website for the “International Institute for Counter-Terrorism” and its mission statement is shown here:






Technical details


As described, the attacks on both websites are identical. The exploit chain starting point is in an HTML file on a dedicated directory.  We’re not certain if this specific path was sent in spear-phishing emails, or if the main page of each of the websites referred to this path. If you have any more details on this, please do let us know.


Here are the exploit chains for and

hxxp:// -> Flash file loader (AceInsight report)

hxxp:// -> Flash heap-spray + exploit.html loader

hxxp:// -> Dropped file cache + Exploit Loader

hxxp:// -> Exploit CVE-2012-4969



hxxp://www.herzliyaconference. org/_modules/80.html -> Flash file loader (AceInsight report)

hxxp://herzliyaconference .org/_modules/logo4969.swf -> Flash heap-spray + exploit.html loader

hxxp://herzliyaconference. org/_modules/exploit.html -> Dropped file cache + Exploit Loader

hxxp://herzliyaconference. org/_modules/Protect.html -> Exploit CVE-2012-4969


Let’s have a look at the specific exploit chain on   The file 1.html is used just as a loader for the malicious file logo4969.swf.  Besides the loading of the malicious file, there are no malicious indicators on the page, but just the HTML Flash container/loader:



The loaded Flash file initiates a heap-spray attack, but it also acts as the caller to the Exploit Loader page exploit.html – it loads it through some Actionscript commands embedded in the Flash file, to evaluate some Javascript code to be executed on the page and load exploit.html, as seen in the next picture snippet from the file: 




exploit.html holds some Javascript code and an especially long variable. This variable starts with a marker “KKONG” that is later searched for by the shellcode that resides inside the loaded Flash file on the client side. The file is obfuscated with a simple XOR 0xBF. The page also loads the actual exploit page by calling an iframe to Protect.html:




Protect.html holds the exploit code to CVE-2012-4969. The exploit code is obfuscated with a simple obfuscation technique: 




After the exploit is triggered by Protect.html, the code will jump to the sprayed shellcode on the heap.  In return, the shellcode will scan the memory for the marker mentioned earlier: “KKONG”. After the marker is found, the shellcode strips the stream following the marker and gets it de-XORed with the value 0XBF to form a valid executable file.  That file is then written to the Windows local machine’s temporary folder and executed to infect the machine with a persistent backdoor.




The executed file dw20.exe (MD5:d2354e9ce69985c1f55dbad2837099b8) acts as a dropper and has the same name as the file dropped with Rotary domains attack. The threat stays persistent on the system by dropping another file to the Windows directory called startup.dll (MD5: 4e1e2b9cd6b5bca2b1b935ddc97f2d7a) that registers as an auto-started service called WindowsUpdata. Check out this complete report from ThreatScope™. The backdoor service is actually installed under a registry key called “RAT”, which is not very discreet, to say the least, and the backdoor connects to a C2 that is recognized by our service as suspicious hxxp:// It appears that is a web host that is located in China. Custom hosts on the site have been found to be involved in targeted attacks in the past (1 2); however, the specific host actually points to an IP address of located in Fremont, California, United States. Looking closer at this IP address, we could see that it hosts a lot of mayhem, as well as many other hosts that are associated that use host names on * that we have already classified in a security category:






One of the most interesting parts is that the IP address to which the C2 points is hosted on an IP address range that belong to Hurricane Electric, a US-based internet service provider that got some headlines lately for being the first Internet Backbone to Connect to 2,000 IPv6 Networks. An Interesting article from ‘The Droid Tech Guy’ illustrates how, although web traffic in China is very restrictive and censored, its architecture is actually one of the most advanced.  According to the article, one of its advances is that it employs a security feature known as Source Address Validation Architecture (SAVA). To quote from the article: “This feature puts security checkpoints throughout the system and then builds up a database very systematically. This database will contain trusted computers and their IP addresses. This system will then authenticate who is sending what. This way, the possibility of sending malicious data becomes a lot more difficult, nearly impossible, like many say.” 


This is a good point that makes us ponder – could it be that threats that originate from China are actually safer, from the attacker’s perspective, if hosted outside of China? That may well be the case. 


In summary, we had a look at high profile government related website that got compromised in a ‘waterhole’ attack and employed some interesting technique. It looks as if targeted attacks have now been surfacing regularly and more frequently, with more attacks that are now exposed almost on a weekly basis. Those kinds of rapid discoveries may cause the players behind state-sponsored attacks or other miscreant groups to increase their level of sophistication. However, we believe that the sophistication of such attacks directly depends on the protection level employed by the target. If defense levels are mediocre or “just enough,” then attackers will probably do just that much to get past them. The tough questions one should ask one’s self in today’s threat landscape is “what am I doing to not be the next victim?” and, even more importantly, “what am I going to do when I do become one?”.  We believe that post-infection mitigation plans should be given the same emphasis as prevention and putting adequate protection in place.


Websense Protection


Websense customers are protected from this and other threats by Websense ACE (Advanced Classification Engine).  ACE protected against this threat in real-time and against the different stages of the attack progression, also known as the “kill chain”. You can find in the next link more information about the 7 stages of advanced threats. Here is a recap how ACE protected against the different stages:


Lure stage: protection confirmed, the lure is the first stage of the attack and in this case it was those URLs that loaded a malicious flash file:

hxxp:// -> Flash file loader (AceInsight report)

hxxp:// -> Flash file loader (AceInsight report)


Dropper stage: not applicable, the dropper is the stage where a file passes through the gateway and inspected in real-time, however, this is not applicable for this attack as the file was hidden and obfuscated in memory and reconstructed on the client side – this is a typical sandbox evasion technique. 


Calling home stage: protection confirmed, the calling home stage is the destination that the malware connects to after getting successfully installed on the victim’s machine. In this attack the malware initiated connection to a destination that is already known to us hxxp:// (AceInsight report).



For participation in data analysis, special thanks to: Gianluca Giuliani

News Of Hugo Chavez’s Death Used in Malicious Email Campaigns

Following news of the death of Venezuelan President Hugo Chavez (as reported by the BBC) the Websense ThreatSeeker® Network has identified several malicious email campaigns that make reference to the President’s death.  Malware authors are increasingly using breaking global news events as a means of propagating lures that lead to malware. 

Here is a screenshot typical of the emails we have seen in these campaigns:



We have tracked the following email subjects used in the campaign. As you can see, many of these lures try to increase a user’s likelihood to click by adapting the current headlines with some fictional salacious content. 

  • CIA murdered Venezuela’s Hugo Chavez?
  • CIA “DELETED” Venezuela’s Hugo Chavez?
  • CIA killed Venezuela’s Hugo Chavez?


Upon opening the malicious email the recipient is presented with a link offering a video. Rather than displaying a video the website takes the user to page loaded with Better Business Bureau text references. 


Websense ACE proactively protected from day-0 (without update) in 2 ways: 1) Proactive detection of Blackhole Exploit Kit, for which this was an instance; 2) Proactive blocking of poor web reputation – the websites used in the campaign were already low enough to convict from day-0.  The payload websites that we have been tracking were registered little more than one week before the spam campaign was first seen.

Websense customers are protected by ACE, our Advanced Classification Engine

Lures and exploit kits are just one of many stages typical in an attack. Having protection from the early stages within the “7 Stages of an Attack” model reduces the risk of the success of an attack. If you break one link in the attack chain, you have mitigated your risk for this particular attack.

We’ve recently done a webinar on the “7 Stages of an Attack”. Check out the archived discussion to learn how to disrupt the attack chain to prevent the download of malicious payloads and inhibit the successful execution of exploit scripts against vulnerability software. 

20-20 Hindsight at the Big Top

RSA USA 2013 wrapped up last week and it had all the usual hallmarks of a modern security conference: storm troopers, casinos, free giveaways every few minutes, hawkers with headsets (much like the county fair), models in superhero costumes, attendees vying to collect the most free goodies, and of course the indispensable straight-jacketed unicycle-riding pitchmen.  The buzzwords this year included “Big Data”, “Mobile Security” and “Security Analytics”, not that there was any clear consensus about what those terms exactly meant or whether the solutions being peddled bore any resemblance to them.  For those with experience attending past conferences, it was just par for the course.


Outside of the circus tent, the high-profile hacks of major companies and web properties figured prominently in most presentations.  This wasn’t the usual FUD, either – even our conservative fellow researchers and technical presenters proclaimed that the bad guys had gained the upper hand, especially for the most sophisticated malware attacks from state-sponsored actors and financially-motivated cartels.  The technology put forth this year by the security industry in response was a little surprising, however.  Doubling down on the premise that “if the bad guys really want to get in, they will”, the emerging technology trend implied that it’s better to react quickly after you’re compromised rather than be under silent attack for months or even years like so many of the 2012-2013 examples have indicated.   There were over 11 different vendors that had created a behavioral sandbox (much like our ThreatScope) to examine the behavior of malware already in the environment.  There were at least 7 vendors that had created workflow tools to allow practitioners to record and investigate security events after the breach.  A few security vendors were touting their new-and-improved capabilities at repair and remediation.  One even declared that we now live in a “post-protection world.”  They all made for some fairly impressive demonstrations with all of those nifty post-breach attack details.


What was in short supply this year was an answer for why we were all there (in theory): “How do we stop the attacks?”  Where was the innovation around protection?   Protecting data from skilled attackers with newly crafted attacks designed to bypass existing security controls is indeed a hard enough task.  Now try adding in coverage for all the holes in emerging endpoints, mobility, and social web domains, and doing so inline, with low false positives and high performance.  Now try to figure out how to independently prove that all of this stuff works.  It’s a mammoth undertaking, and the unanimous consensus was that existing measures are not getting the job done.  Why not focus on THAT problem?


There were exceptions to this trend.  In addition to our own Chris Astacio’s standing-room-only talk on mass mobile attacks and Blackhole botnet dissection, Tomer Teller had some concrete insights into “Detecting the 1%” and Ed Skoutis presented CyberCity as a real-world model of how to pentest and ultimately protect infrastructure from physical attack.  There were other examples as well, but far too few.  


We’ve got to buck this trend and get back to basics – focus on stopping the attacks before they do harm or steal information.  True, we may never get it perfect, but we can certainly do a lot better.  It’s all well and good to put lots of 20-20 hindsight and forensics around an attack, but we would all prefer the deafening silence of a prevented attack over a decidedly louder postmortem of a successful data breach in all its glorious new detail.  


Honeyclient Evasion Techniques, Case

Hot on the heels of the hack last week, Websense® Security Labs™ researchers were alerted by SANS to another high profile website compromise on Friday: It appears that the offending code has now been removed from the website.  


At first glance, this seemed to be a run-of-the-mill “compromise, redirect, exploit” chain; however, closer analysis revealed the use of an interesting Honeyclient evasion technique. Honeyclients allow the profiling of websites in a heuristic and automated way; more often, testing a website with a Honeyclient takes longer than signature-based solutions but the results are much more accurate, especially when new zero-day code or a new emerging threat needs to be flagged up and requires scrutiny. Usually, Honeyclients run on top of virtual machine sandboxes: evasion techniques allow malicious code to become more aware of its running environment and to check if it’s in a virtual environment or likely to be an ‘analysis’ environment before actually running malicious code. 




This snippet of code is the entirety of the Honeyclient evasion attempt – as the method name suggests, the function ‘jsstatic’ will only be called once the eventhandler registers the movement of the user’s mouse over the document (page) – obviously, a primitive Honeyclient will have no mouse movement emulation, therefore the offending function that leads to exploit code will never be called and alerted on by the Honeyclient.


Let’s take a closer look at the jsstatic function (click to enlarge):



The first part of this function definition is simply a sentry variable, to stop the function being executed indefinitely with each new onmousemove event – the global variable astatf is defined as 0 in an earlier part of the script. The next part simply creates the iFrame, which is then executed as if it had just been injected into the page, as per a normal compromise.


This technique is quite primitive and showcases the infancy of this type of Honeyclient evasion technique. The plethora of event handling methods available means this technique is not going to go away anytime soon, and is likely only going to get more complex and inventive. 


In summary: the use of such techniques ultimately aids malicious code in remaining undetected for longer periods of time and thus increases its chances of bypassing security products undetected. The technique described in this blog is simple and allows redirection to exploits only if a mouse movement is detected, an action that is often associated with an actual person interacting with a website and often not used by primitive Honeyclients. Why are the attackers using this technique instead of the normal drive-by type technique we usually see? probably because they wanted to make the attack more stealthy, as attacks like this wouldn’t be picked up by automated behavioral analysis systems. That’s why multiple layers of defense are needed for web-based attacks.


This discovery ties in to Websense Security Labs predictions that Cybercriminals will become more ‘virtually aware’ and find modern bypass methods to avoid security detection – see our Websense 2013  Security Predictions.


Author: Darrel Rendell