Malicious Pastebin Replacement for jQuery

Website hackers are always changing tactics and borrowing ideas from each other. One of the challenges of website security is staying on top of those threats as they evolve. We wrote in the past about fake jQuery scripts and how hackers use Pastebin.com to host malware. This time, we will show you an attack that combines both of these techniques to spread malware using a fake jQuery Pastebin file.

Reversed URL Detected by SiteCheck

A couple of weeks ago SiteCheck began detecting WordPress sites with reversed JavaScript code in /wp-includes/js/jquery/jquery.js and /wp-includes/js/jquery/jquery-migrate.min.js files. As you can see, the URL is written backwards inside the payload.

Infected jQuery detected by SiteCheck
Infected jQuery detected by SiteCheck

When the code is reversed (e.g. war/moc.nibetsap//:ptth – is – http://pastebin.com/raw – written backwards), it injects external scripts that load code directly from Pastebin. Previously, we saw this trick used on infected Magento sites. There are strong signs that these two attacks are related, but this WordPress infection is interesting on its own, so let’s look closer at these Pastebin links.

Pairs of Pastes

Both jquery.js and jquery-migrate.min.js are core WordPress files. Hackers gain access to the website and replace the content of these files with their own short code.

In the case of jquery.js the attackers inject scripts from:

  • hxxp://pastebin .com/raw/HC90NJsp
  • hxxp://pastebin .com/raw/dWe3gcb5 (or hxxp://pastebin .com/sE8cX1Pi)

… and in the case of jquery-migrate.min.js they inject:

  • hxxp://pastebin .com/raw/WMMc4sS8
  • hxxp://pastebin .com/raw/rDiH4Bjy

Now we have some interesting questions about these pairs of Pastebin links.

… Why do they inject two scripts?

… Why do they remove the legitimate code from WordPress core files?

… Wouldn’t it break the infected sites?

We get answers to all these questions when we check the referenced pastes.

Referenced Pastebin Content

Let’s first break down the content of each pair of Pastebin links.

  • The paste HC90NJsp is actually the real source code of jQuery (v1.11.3)
  • Its pair, dWe3gcb5 is an obfuscated malicious script that redirects visitors to hxxps://goo .gl/54Miz5
  • The paste WMMc4sS8 is the real code of the jQuery Migrate (v1.2.1) library
  • Its pair rDiH4Bjy is an obfuscated malicious script that redirects visitors to either hxxps://goo .gl/54Miz5 or hxxp://get .adobe.com .flashplayer .frogsland .com/flashplayer_20ga/

Now we know that in each infected WordPress jQuery file, the first injected Pastebin script compensates removal of the original jQuery code (by loading the same code from pastebin.com) and the second script injects the malware.

It’s not clear why the attackers decided to remove existing code and then load it from Pastebin. Most likely it makes infection and reinfection easier. Instead of checking whether a .js file is already infected or not, they just replace its whole content with code that is guaranteed to be correct. Since the jQuery code is quite long to be embedded in their attack scripts, they replaced it with a short external call to the same jQuery library saved on Pastebin. Why not? It works.

Pastebin User Info

The malicious pastes are not anonymous. There are two user accounts associated with them

Both users have only two pastes. Emonostin’s pastes are the ones injected into jquery-migrate.min.js and Jstoolshope‘s are the ones from the infected jquery.js.

Why create malicious pastes under some user account if anonymous pastes can be equally good for script injections? The answer is flexibility. Users can modify their own pasted content whenever they want. Anonymous pastes can’t be modified. If the hackers need to change the URL they redirect traffic to, they can just change the code of their paste and the URL will remain the same. As we can see in the screenshot below, these guys actually use this feature (the last modification was made on Dec 25th, 2015).

Malware modification date on Pastebin.com
Malware modification date on Pastebin.com

Pastebin also provides information about the number of views to each paste. Pastes from jquery.js have 20,000+ views, and pastes from jquery-migrate.min.js have around 40,000 views. At the first glance this statistics look plausible since both pastes in the pairs have similar numbers of views — the infected .js scripts loads both at the same time. However, the Pastebin FAQ says that they do NOT include “hits which came from the RAW version of pastes” and we know that infected sites load RAW versions of the paste, so the Pastebin counter may not represent real statistics for this attack. For more reliable statistics, we look later at the goo.gl redirect.

Malicious Code

Now let’s get back to the malicious code. It checks for presence of the “tmid_no_session” (in one version) or “tmid_no_check” (in another version) cookie. If this cookie is set to “1“, nothing happens (returning visitor). Otherwise the script sets this cookie for 3 days and redirects the visitor to third party sites.

At this point the script from  jquery-migrate.min.js redirects Windows users to hxxp://get .adobe .com .flashplayer .frogsland .com/flashplayer_20ga/ and the rest of users go to hxxps://goo .gl/54Miz5. The script from jquery.js redirects both Windows and non-Windows users to hxxps://goo .gl/54Miz5.

The Windows redirect URL is self explanatory. You can see that it pretends to be a Flash player update page. It is already blacklisted by Google as phishing

Fake Flash player update page
Fake Flash player update page

Here’s the VirusTotal analysis of the file this site pushes under disguise of a flash update: Detection ratio: 18 / 53

HFA (Hacked for Advertising)

The alternative redirect goes to “hxxps://goo .gl/54Miz5” which points to “hxxps://go .padsdel .com/afu.php?id=473791“. This is an affiliate link of some ad network.

Redirecting traffic from hacked sites to ad network links was one of the prominent trends of 2015. We see more and more attacks that monetize compromised sites by pushing unwanted ads. The ad networks used in such attacks, in turn, usually get money from advertisers. These advertisers pay to drive traffic to pure scam sites or sites that trick visitors into installing malicious and potentially unwanted software (UwS). This unwanted software hijacks their browsers and shows even more low quality scammy ads (do you see a recursion here?).

Ads and malware come hand in hand. In case of this “jquery pastebin” attack, they have two execution branches: one for unwanted ads and one for malware. The Magento variant of this attack also can redirect a browser either to an exploit page or to some ad page — ads basically help monetize “unexploitable” traffic.

You might know the MFA (“Made for Advertising” or “Made for AdSense”) term, which is a blackhat marketing term that describes low quality spam sites created with the sole purpose of tricking people into visiting and clicking their ads. Now hackers adopted a somewhat similar approach that can be called HFA – Hacked for Advertising.

Goo.gl Link Statistics

Goo.gl links have a nice feature – you can see usage statistics of any shortened link. For example, here’s the usage data for the redirect link during December https://goo.gl/#analytics/goo.gl/54Miz5/month.

Malware campaign statistics provided by goo.gl
Malware campaign statistics provided by goo.gl

We can see that hackers began using the”hxxps://goo .gl/54Miz5” redirection on December 15th. The average number of redirects is more than 10 thousand per day with a peak on December 29 with over 30 thousand redirects. These numbers represent mostly unique redirected visitors since we know that malware sets a cookie that prevents redirection of known visitors.

Mitigation

In terms of mitigation, this attack has both upsides and downsides. The downside is if you simply remove the malicious code from the .js files your site may stop properly working as the jQuery library file will be empty now, so be careful. The upside is that those are core WordPress file so you have multiple easy remediation options:

  1. Restore your site from the latest clean backup copy.
  2. Update or re-install WordPress.
  3. Restore only infected .js files. You can get canonical versions here (links for WordPress 4.4)

As always, removing the malicious code is never enough. You should also scan your server for backdoors and close the security holes that hackers used to break into your site in the first place. Make sure you have a website security detection system in place so you can be alerted if your website is targeted by such an attack.

4 comments
  1. I’m still having issues with the first jQuery round from the last post – I can’t seem to locate the infection. I’ve checked both my core jquery.js and jquery-migrate.min.js files against known clean copies and they are identical. I can remove the code from header.php but it always comes back within a couple of days — any ideas of what I’m missing?

    1. Hey Chris,

      These two infections are different. You need to find and remove backdoors and open security holes to prevent reinfections.
      https://blog.sucuri.net/2011/05/ask-sucuri-why-does-my-site-keep-getting-reinfected.html

      Unlike the visitor-facing part of the infection, vulnerability and backdoor part may be different on different sites so it is hard to tell where exactly you should be looking for them.
      Here’s some general steps you should take to keep your site clean:
      https://kb.sucuri.net/remediation/After+Clean+Up/steps-to-stay-clean

  2. Thanks for the report, the reverse code was interesting! That’s a varied mixture of techniques.

  3. i was recently hired to update a website that was affected by this attack. i was able to remove the malicious code quite easily (many thanks to you folks for writing this article). so far my fixes have not been overwritten. the cms and plugins were dramatically out of date, so i have everything updated and i have also installed securi plugin, which is also very helpful. interestingly, it has reported 65 failed login attempts to my wordpress back-end. somewhat unnerving but very good to know. i have locked down the accout in question that they are trying to access. i am also considering password protecting the wp-admin dirctory with a htaccess password… do you guys have any recommendations for how to deal with these login attempts? i guess they aren’t so frequent that they would qualify as “brute force” but is this something similar? 65 password guesses in 8 hours or so? thanks!

Comments are closed.

You May Also Like