Base 64 code injection in a lot of sites

A lot of websites seem to suffer from injected files. It also happened to a few of my own sites. Apparently “they” use holes in code to do this. It is a tactic that has at least being going on for a year, if not longer.

1. How can you check it if you are infected?

1) A good “trick” (although reactive and dependent on Google) is use Google Chrome to surf to one of your websites, there is a good change you will get the following notice but you have to set under your privacy settings the “protection against phishing and malware”


it means that Google has found the injected code. In the webmaster tools you will find then a list of files it found that has been affected. Handy to immediately go and check for that file. (in my case a php file has been uploaded in one of my image upload directories).

2) you see strange behavior on your site e.g. a footer that gives an error message. You should check your footer.php or the code that generates the footer for javascript includes. You might need to scroll your window to the right to see it.

3) Use an active virus scanner that scans for these injections and go through your websites

4) Run a script to check for php files with base 64 encodings (see below)

5) If you run an intrusion detection system, a light one like the wordpress monitor plugin that mails you if file have changed or heavier intrusion detection systems well… it will notice you (sometimes).

6) you can schedule security audits to be performed on your installation, that might also help to inform you about security issues.

2. What is actually done on your server?

2.1 additional php files are placed

On the first place .php files will have been placed in random places throughout your directory structure, these contain the actual malicious code that calls to the outside.

They carry random names to not be detectable that way. A few names I encountered out of a long list:

  • coven.php (6k)
  • fileNice.php (4k)
  • poofy.php (6k)
  • tc_general.php (6k)
  • utilities.php (3k)
  • aviso.php (6k)
  • etape.php (15k)
  • input.php (4k)
  • jquery-bgiframe-min.php (4k)
  • order.php (8k)
  • backgroundImage.php (4k)
  • dumky.php (14k)
  • frond.php (7k)
  • jquery.lavalamp.php (4k)
  • markt.php (4k)
  • expand.php (3k)
  • func2.php (4k)
  • haugh.php (7k)
  • ja.catslwi.php (7k)
  • vault.php (6k)
  • etc… etc…

They are all 644 in terms of permission so they can not be detected by inspecting the permissions UNLESS your other files are not 644. If that is the case it makes detecting them very easy but then your files were not secure in the first place (I assume).

They all have the date and time of the other files in that specific directory, so you can not identify them based on their date time, the algorithm behind it probably does a date-time set according to the other files in the directory structure. (maybe you could run a script that gives each file an increasing date to detect strange additions better the next time).

In most cases the code that is executed in these files is garbled. In most cases base 64 encoding has taken place.

Some examples of more simple base 64 encoded evaluated strings as seen in these files:

[ccN_php] eval(gzuncompress(base64_decode(‘
[/cc] [ccN_php] $fr = strrev(“sserpmocnuzg”); $df = strrev(“edoced_46esab”); eval($fr($df(‘
[/cc] [ccN_php] $v1 = strrev(“edoced_46esab”); $v2 = strrev(“sserpmocnuzg”); eval($v2($v1(‘
[/cc] [ccN_php] $cares = strrev(“edoced_46esab”); eval(gzuncompress($cares(‘
[/cc] [ccN_php] $sa = array(‘4_decode’,’base6′); $sb = array(‘gzunco’,’mpress’) ;$t1 = $sb[0].$sb[1]; $t2 = $sa[1].$sa[0]; $tfi = array(‘
[/cc] [ccN_php] $a1 = array(“edoced_”,”46esab”); $a2 = array(“sser”,”pmocnuzg”) ; $a3 = array(‘

Some examples of more advanced calls using function calls and more obfuscated code using functions and a lot of “innovative” garbling:

[ccN_php] function authcode($i){$a=Array(‘
[/cc] [ccN_php] function fuck($i){$a=Array(”,’Xw==’,’Xw==’,’XFxcIg==’,’XCI=’,’XFwn’,’Jw==’,’XFxcXA==’,’XFw=’,’XA==’,’Lw==’,’Ly8=’,’Lg==’,
function fuck($i){$a=Array(”,’Xw==’,’Xw==’,’XFxcIg==’,’XCI=’,’XFwn’,’Jw==’,’XFxcXA==’,’XFw=’,’XA==’,’Lw==’,’Ly8=’,’Lg==’,
[/cc] [ccN_php] $GLOBALS[‘_figu_’]=Array(” .’f’ .’uncti’ .’on_exi’ .’sts’,’fun’ .’ction_exists’,’cu’ .’rl_init’,’c’ .’url_set’ .’opt’,” .’curl_’ .’se’ .’t’ .’opt’,” .’cu’ .’r’ .’l_seto’ .’pt’,’curl_set’ .’o’ .’pt’,’cu’ .’rl_’ .’setopt’,’c’ .’u’ .’rl’ .’_setopt’,’curl_setopt’,’cur’ .’l_exec’,’c’ .’ur’ .’l_cl’ .’ose’,’i’ .’n’ .’i_g’ .’et’,’fil’ .’e_get_’ .’co’ .’n’ .’ten’ .’ts’,’fun’ .’ction_exists’,’p’ .’reg_’ .’re’ .’p’ .’lace’,’e’ .’re’ .’gi’,’ere’ .’gi’,’eregi’,’strlen’,’set_’ .’time_limit’,” .’i’ .’ni_s’ .’et’,’erro’ .’r_re’ .’p’ .’o’ .’r’ .’tin’ .’g’,’header’,’header’,’gmda’ .’te’,’he’ .’ade’ .’r’,’header’,’h’ .’e’ .’ad’ .’er’,” .’date’,’system’,’date’,’fil’ .’e’ .’_e’ .’xists’,’f’ .’o’ .’pen’,’f’ .’close’,’fi’ .’le’ .’_’ .’exists’,’rand’,’fopen’,’f’ .’wr’ .’ite’,” .’f’ .’c’ .’lose’,” .’bas’ .’e64_de’ .’code’,” .’f’ .’ile_get_’ .’c’ .’onten’ .’ts’,’file’,’t’ .’rim’,’fo’ .’pe’ .’n’,’f’ .’write’,” .’fclose’); ?> [/cc]

So as you can see they are difficult to detect by scanning the files. Someone has written a script to detect base64 encodings (see below) but I have not tried that one yet. I don’t know if that will detect all possible obfuscations.

2.2 calls to these php files are inserted in your php code

Next, javascript based calls are placed inside (random):

  • your existing php files
  • your existing javascript (includes)

For WordPress I have seen inclusions in both core code e.g. jquery library files or your custom code e.g. in the footers of themes but also on many other places.

2.3 your .htaccess rules have been adjusted

Check your .htaccess file for any changes

2.4 images disguised as jpg files are uploaded

You not only need to look for .php and .js files but also for images. Since code could have been hidden in there. The tip found here is to check the the option tables in the database for these kind of images.

2.5 additional ADMINistrators have been added

This scares the shit out of you but it happened on one of my WordPress installations: I saw an extra admin …

2.6 code may have been injected in your content e.g. pages and posts
Search for patterns in your content like iframes, scripts, display: A lot of variations are used here.

3. How to clean them?

Currently I am cleaning them one by one since I own my own servers and pretty easily can run through the directory structure. I also have found a script that can check for base64 encodings I have not tried that one yet.

Ofcourse it is needed to know WHAT code is vulnerable, possibly some plugins or maybe even some core code due to the wide spread infection. I have not figured that out yet. It happens to a lot of platforms so including platforms that do not run WordPress but totally different software. So my guess it uses a library of possible zero-day security holes.

4. More references

I am including a list of websites that have written about base64 encoded js injections:


5. Helpful WordPress Tools


(this post is being updated)