As we have seen many times before (e.g. Mal/Iframe-Gen, Mal/Iframe-W), compromised sites are frequently injected with large, heavily obfuscated blocks of JavaScript. The primary goal of such scripts is to make it hard for scanners to detect the payload (typically an iframe or script load). However, the side effect of large, ugly, obfuscated scripts is that as far as the site administrator goes, locating the injected code should be pretty straightforward. *
Some injections make little attempt to ‘blend in’ – for example, we have recently seen a burst of sites injected with a simple iframe script (Troj/Iframe-GW, which is currently the 8th most prevalent web threat detected on Sophos endpoints over the past week).
As you can see, some HTML comments around the injected script suggest it is related to a WordPress counter. However, the use of throwaway us.to sites coupled with the specific, rude filename make the injection stand out like a sore thumb.
On the other hand, some site injections are a bit more subtle. For example, sites recently compromised with Troj/JSRedir-DY for the purpose of redirecting users to Blackhole exploit sites. (Troj/JSRedir-DY is currently the 14th most prevalent web threat detected on Sophos endpoints over the past week.)
Injected into the homepage for the site is a simple script load, referencing an innocently named local JavaScript file.
This type of script element is pretty innocuous, indistinguishable from any other local scripts that are loaded from the page.
Of course, the css.js file is also added to the compromised site. This is a large script consisting of three sections:
- PluginDetect library (legit library used to determine browser, plugin versions)
- Base64 library (legit library for B64 encoding/decoding)
- Malicious payload (the actual JavaScript that adds the iframe)
The extra effort used in Troj/JSRedir-DY attacks is almost certainly intended to make it less likely that the attack will be noticed. To some extent it achieves this – there is no giveaway footprint added to any of the web pages and even the added JavaScript looks legitimate (thanks to the bulk of it consisting of legitimate libraries).
However, in another way, this added complexity fails. The addition of a new file should be simple for a site admin to detect (tip for admins: schedule a script to recursively list the contents of your web folders, comparing to some baseline).
These two examples illustrate the diverse nature of what compromised sites can actually be injected with. The payload of the injection will typically be the same, but the actual content used to deliver that payload can vary dramatically! Furthermore, this is not simply down to the whim of the attacker. The manner in which the server/site is compromised (SQL injection versus PHP hack etc) will often dictate how they are able to inject content into pages.
* Additional tricks are sometimes used to make it harder for site admins (e.g. referer checks to only inject malicious code when user arrives via search engine).
Leave a reply
