New Wave of the Test0.com/Test5.xyz Redirect Hack

Last week we described the hack that randomly redirected site visitors either to a parked test0 .com domain or to malicious sites via the default7 .com domain. This week the default7 .com domain went down but the attackers returned with a new wave of site infections and the new redirecting domain – test5 .xyz (registered just a few days ago on May 7th, 2016).

This new domain points to the same dedicated server as default7 .com – 199 .48 .227 .25 (United States Carlsbad Plankton Tech Inc) and it still redirects eligible visitors to malicious sites and the rest to a parked test0 .com domain.

Malware + Ads Combo

Here’s an example of a redirect chain that leads to a fake Flash update download with a very poor detection rate of 2/56 on VirusTotal.

  • test5 .xyz/
  • test557 .com/
  • adorableoccassion .com/d/p/test557.com?k=39b456316a2174d17f701aea39f676c5.1462908901.787.0&r=
  • www.checkournewsoft .com/?pcl=5qe5FetFrItyco5HNTadzxMu9Nwdv__MlK_dmzyotoo.&subid=102860_63d8579cd6fe93a754bb2f7385e255da
  • autoupdate.update4ever .xyz/tfdsaza?cyfrt=5qe5FetFrItyco5HNTadzxMu9Nwdv__MlK_dmzyotoo.&subid=102860_63d8579cd6fe93a754bb2f7385e255da&v_id=rpcihcNtq3qeCGZWqzeSqwvbhfhT4lBbZKLaUy096OA.
  • intva31.technologyventures .info/dl?bc=1202331&c=affl_oc&filename=adobe_flash_player.exe&p_tid=eg9HLGMRX_BnN0NOehq8zM19O6mSk8qUVpj1ECRPv0OsLJ1oMppUPgiL3WT_pAxDRnSUb7JueWZtGRRc42MYbZgOvRundJ4pn-mmg_oBLyDbmMC7PuTLWTdV_t-wwadKq9h6xbihiR6RKpD7CUbvdvoXPKG9y1l74BCxdqbZK6YAQRtKZfeD96VfEncqrlnFwHXwCnKUdEH5BDGP1RZ23YYBArnHKHKGHVbVWFEybDyyqyjlzyJ99p9Z7Cwv34MJ&productKey=ii7zxkp7ntfj6uljmsteb2irhuahtnbq&zTmp=1
  • intva31.electradev .info/dl-pure/1202331/35005458/?bc=1202331&checksum=35005458&ephemeral=1&filename=adobe_flash_player.exe&cb=631432239&hashstring=IczdojJFuj9J&usefilename=true&executableroutePath=1202485&stub=true

In the final redirect, the visitor is delivered an executable file:

Fake Flash Player Update
Fake Flash Player Update

Interestingly enough, the fake Flash update site also loaded ad scripts (adk2x is well known for malvertising). These scripts tried to open a scam site in a popup window:

  • adsrvmedia .adk2x .com/imp?p=71630944&ct=html&ap=1303&iss=0&f=0
  • www.freelotto .com/offer.asp?offer=1066295&affiliateid=71630941&tid=adkm_ExIRsa5e12OdlhukkLB7stg-9RsGhqGrjmFzgndXRhzcQZyn3sNwjSkW8wKNEKN2ie-1uOmrjUvusdhCP-kfM5nFhctHZ0UjuGbR67a8JnWTffqI40ESFrD4462B-AgMo2pz5fq1mADEdaVKv2vxSU3Razsq11sGoQzEp2oCbvvEzwy_Da0R12QJMZZERD7A4nOIdc-mRnRTUNkGyec__NGrzY9g-iCfEVbwznQ0jwoRKrvEXat9PrgGMifiwKeBOUJmrI0Q_1dfjAvh10pquxL8rFzKp-teF7zbiowHMn8L37FfbBL34ne4iytqkW6nXhhBaX_mvZW8GyRIxXxCejZ7i2C9XwUsj6V2WFpnOhY2XXnI9WGhZAPsJezeAjAE52XRSciD4z8TWrW04En2uWkDyV3FsoSzIIAUw515Di2wd0Op5hE5PBvW_WSOScQpgcmEcxwYYWpFfb09KqHpzw

Most likely they use this hybrid technique to maximize the conversion rate.

New Injected Code

The malicious code is still being injected at the top of the active theme’s header.php file but it looks and works differently.

A bit abbreviated version of the new injection
A bit abbreviated version of the new injection

This code resembles the older version of the same attack where it infected the footer.php file. While the code is not obfuscated, it is more complex to understand and uses client-side redirects instead of the server-side redirects from the previous version of the attack.

To get redirected, a visitor has to pass several levels of this malware, each of which requires a separate HTTP request. This is supposed to hinder detection by scanners that do not see the whole picture.

Step 1 – Set IP Parameter

When a visitor comes to an infected site for the first time, the malware injects the following JavaScript:

<script src='/?nnn_nnn_nnn_nnn=1'></script>

Where nnn_nnn_nnn_nnn is the server’s IP address. The dots are replaced with underscores (e.g. 10_123_123_123 instead of 10.123.123.123)

This script doesn’t reveal much about its malicious nature – just another script from the same site. The only suspicious thing about it is it requests a home page instead of a real .JS file.

Step 2 – Check Cookies

This script initiates a second request to an infected webpage. The malicious code now detects that it has the nnn_nnn_nnn_nnn parameter, which is the server’s IP address. This triggers a different part of the malware which returns a longer JavaScript code.

The goal of this code is to hide the malware from returning visitors and load the real malware from a third-party site. It checks for the same Jf8y6S2aifZVynJb6hEZ cookie to identify returning visitors.

Step 3 – Return Gateways

To get the URLs of the third-party sites, the script makes one more request to the same infected page. This time with this parameter: /?sXnj0DSOvuqJQ7SnZkS6=1

When the injected code detects this parameter, it returns the list of URLs:

3BVKIGQA0lhCLzrxTFM7_star
hxxp://22degrees .co.nz/wp/wp-content/themes/lightweight/main .php
hxxp://alf-mutschelbach .de/wp-content/themes/lightweight/track .php
hxxp://newsweetpix .com/assets/track .php
hxxp://fugitif.eu/wp-content/themes/lightweight/atom-conf .php
hxxp://morrow-technologies .com/wp-content/themes/lightweight/inc .php
3BVKIGQA0lhCLzrxTFM7_end

The script from step 2 uses these URLs to dynamically load external scripts from them. Since the URLs reside on hacked sites, the redundancy helps keep the attack alive, even if some of the gateways scripts get removed. If all the scripts are live, usually only the first one returns malware. Most likely, behind the scenes, they all communicate with the same C&C server. This ensures the malware only returns the payload once for each visitor’s IP address.

Using this scheme – where gateways communicate with a common central server – adds flexibility to the attack, as it can change the redirect URL and the malicious payload anytime without making changes on the infected sites.

Step 4 – Final Redirect

The gateway returns the BetterJsPop script. This either creates a popup, or redirects to test5 .xyz. It also sets the Jf8y6S2aifZVynJb6hEZ cookie for one year to recognize returning visitors (which it checks for in step 2).

It took 4 consecutive HTTP requests and execution of JavaScript on each step just to trigger the redirect. This may pose a problem to some scanners, however, our SiteCheck website scanner has been detecting this new version of malware from the very beginning as “malware-entry-mwjsanon7?r3.”

Cleanup and Prevention

As we showed last week, this attack commonly uses stolen WordPress credentials to log into admin interface and use the theme editor to inject malware into theme files. That’s why we suggest the following steps to clean and harden your site.

  1. Remove the malicious code from your theme files. This attack injects the malicious code at the very top of header.php (and footer.php in some older versions, or administrator/includes/help.php in the case of Joomla) so it’s easy to find and remove it. If in doubt, replace the whole theme with a clean backup version (or get a new copy from WordPress theme repository or the theme’s developer).
  2. Make sure there are no new WordPress users.
  3. Change passwords of all WordPress admin users.
  4. Most likely you don’t edit theme files every day, so it’s a good idea to prevent them being edited in WordPress admin interface. To do this, you can either revoke write permissions from theme files (change their permissions to 444) and/or disable file editing using this setting in your wp-config.php file:
    define( ‘DISALLOW_FILE_EDIT’, true);
    
  5. Hinder brute force attacks against your blog. You can use plugins that limit login attempts, and/or change the login form URL. Consider disabling XML RPC if none of your plugins use it.
  6. Restrict access to the WordPress admin interface, so that only trusted IPs can use it. Our WAF offers this option by default.
  7. Although this attack doesn’t directly use software vulnerabilities, make sure that everything is up to date and all the core files are intact.

Overall, it’s a good idea to employ a website firewall that not only will protect your site from attacks that exploit vulnerable code but also stop brute force attacks and prevent access to restricted areas of your site.

4 comments
  1. One of the biggest problems with restriction of IP addresses is that most small sites are owned and operated by people with dynamic IP addresses. They need to consider the extra cost of acquiring dedicated IP.

  2. What about if you’re just an end-user of possibly-infected websites? I see these popups all the time from various popular sites that I visit, despite having Firefox’s “block reported attack sites” and “block reported web forgeries” settings enabled. Of course I know better than to allow an exe downloaded from some random domain claiming to be a Flash update to run, but it’s still a frequent annoyance to get a malware page instead of the place I was trying to go. Seems like there ought to be a better end-user defense for this?

Comments are closed.

You May Also Like