Catching and Preventing echo md5(“just_a_test”); exploit attempts

Have been noticing LOTS of automated explot attempts recently across my small portfolio of php sites.

The bots are replacing script.php?id=4 calls with urls like:


All these landing pages have:

<?php echo md5("just_a_test");?>

them. If you have a browse around these obviously hacked sites there is
some other interesting code. eg:

im changing a
script which gets hit a few times a day to actually see what the bot
will do when it finds the output from the echo md5() statement.


Here’s what happens when the initial just_a_test exploit attempt is successful:

fake exploitable script was hit 7 times by the robots. Each hit was
from different ip addresses and using different compromised hosts for
the initial just_a_test remote file code. Each robot was presented with
the output from echo md5(“just_a_test”);

The robots didn’t seem
to do anything straight after seeing that the site was exploitable, but
8 hours later I received 60 hits from robots trying to inject a
different bit of code: and and so on.. (all ending in /a/ )

The time lapse between initial attempts and follow up attempts leads me
to believe that the initial robots communicate back to a central server
when they find an exploitable host. More robots are then scheduled to
come back to the exploitable host and try to move to the next level.

code file they were trying to inject contains a lot of white space with
some PHP code in the middle. Here’s the formated PHP code if you want
to have a look:

click to view step 2 code

Step 2 php code creates a new file with the contents from base64_decode. The file is called namogofer.php
and if tries to create this file in every directory under the document
root. When step 2 successfully creates a file on the server it will
ouput a tab separated list of information about where the file is
loaced, and continue. The contents of the namogofer.php file which get
written to the web server are here:

click to view step 3 code

you can see Step 3 code is waiting for a special file upload. The next
round of attacks will involve uploading another php file to the server
in the form of a normal file upload. The code will be dumped in the
/tmp directory like all file uploads are, and then the code will be

I’ll update again once I catch the uploaded code.


seeing about 100 hits a day and growing on this topic. If anybody knows
the true nature of this exploit attempt or how so many websites have
been compromised tell me about it and i’ll post it here. dtbaker @
gmail. com


More compromised hosts (2008-02-06):



From Jonathan Dill

Digging through web logs, there has been a surge in this type of
activity lately, but it appears to be run of the mill index.php
attempted remote file inclusion exploit, as long as you have PHP
configured with allow_url_fopen = ‘off’ you should be OK. Newer PHP
uses a “wrapper” which allows you to restrict what can be included, or
you can recode to use cURL instead of url_fopen.

Here are some relevant articles:

Docs from PHP website:

See also:


You should disable allow_url_fopen in the php.ini file:

; Disable allow_url_fopen for security reasons
allow_url_fopen = ‘off’

The setting can also be disabled in apache’s httpd.conf file:

# Disable allow_url_fopen for security reasons
php_flag allow_url_fopen off

For remote file access, consider using the cURL functions that PHP provides.


I have made a number of scripts output echo md5(“just_a_test”); when they see these automated exploit attempts.
Hopefully I will catch one soon and will be able to see what the next step in the remote file inclusion exploit is.�


Mark: some info about WordPress and this exploit:

Mark: a .htaccess snippet that stops url’s from being passed into any scripts:
(not sure if this will affect any legit stuff – do any popular
wordpress etc.. scripts require url’s to be passed as parameters -like
referral link counters etc…)



I have received quite a few emails from people who have had their servers compromised by this attack.

Seems the overall goal of this attack is to infect .htaccess and javascript
files with as little impact on normal website functionality as
possible. When visitors navigate to the infected site via search
engines the users browsing experience is altered so the attacker can
build revenue from PPC vendors.


Our server seems to have been exploited by this code.
The payload seemed to be a redirection script that takes any search referrals
from Google, Yahoo, etc and then creates a pseudo blog page promoting some paid
advertising where the blog owner gets a commission on the clicks.

The PPC vendor is (in this instance) PeakClick They don’t appear
to be involved in this.


those who are digging around – you can find and report straight to the
PPC vendors and request for them to disabled the accounts of the user
who is exploiting this attack.

Will post some infected javascript snippets soon.

Leave a Reply

Your email address will not be published. Required fields are marked *