TrendLabs JS_VIRTOOL Adaptations

The TrendLabs blog has an interesting take on a new variant of JS_VIRTOOL they've spotted in the wild. This variant is designed to make it difficult/impossible to analyze shared samples or dissect if the site context is lost.

How does this deobfuscator thwart security researchers? From Trends blog...

1. It retrieves the URL where the malicious script is located.
2. It retrieves its own function and adds the string of the URL.
3. It computes the CRC of the function plus the URL.
4. It decrypts an encrypted code in the script body using the CRC that was computed.
5. It executes the decrypted code using the eval() function.

It's not precisely rocket science, but it's more that sufficient to bypass static analysis investigation and network-based detection systems.

The particular technique of tying the decryption key to the URL of the source has been discussed for several years - and has been tried in the past (legitimately) by various Web sites that endeavor to protect their content from plagiarism. It's neither elegant nor a robust protection mechanism against host-based manipulation. - but from a network perspective it's "good enough".

Threat Naming
One point to note. Trend's the only folks using the name "JS_VIRTOOL" for this vector - so don't be worried if your preferred security vendor has no idea what you're talking about if you're wanting to check to see if you already have protection against this particular threat. Just ask them about obfuscated malicious JavaScript and JavaScript payload protection.

Something else to note... While it's a difficult threat to counter at the network level (and to not false-positive on legitimate sites that use similar techniques to protect their site's content) - there are a number of interesting in-the-browser technologies that will protect your host from anything malicious within the JavaScript payload - and they don't care about the obfuscation (since that's not the 'dangerous' part).