The website hack you'd never find (old, probably outdated)

Warning: This page is pretty old and was imported from another website. Take any content here with a grain of salt.

Warning: do not try the URLs here unless your system is locked down properly. I suggest using a “virual machine” (I use VMware) to test things like this. The hack itself is complicated, the system is simple - skip the complicated part if you’re in a hurry.

It all started with a posting ( like this:

When I do a google search for [Jonathan Wentworth Associates] the first result is:

_Jonathan Wentworth Associates, LTD
Welcome to Jonathan Wentworth Associates, a respected resource for 
world-class orchestral soloists, conductors, opera, chamber music, 
chamber orchestras, ... - 19k - Cached - Similar pages - Note this_

The: "Jonathan Wentworth Associates, LTD" is highlighted and is a link 
to the web site.  If you place the mouse over the link, it shows  However, if you click the link it immeately 
attempts to download the trojan.  My McAfee immediatly blocked it.

Looking at the page in question, it doesn’t appear to be hacked, it doesn’t appear to have any kind of scripts injected, etc. However, using LiveHTTPHeaders with Firefox, while doing the same steps (search, click on the top result) you see the following:

GET / HTTP/1.1
HTTP/1.x 302 Found
GET /ind.htm?src=324&surl;;=80&suri;=%2F HTTP/1.1
HTTP/1.x 302 Found

Without going through Google, the page is returned right away, just like it should. Search engine crawlers also get it like that. After the step through Google however, the site does a 302 redirect to some IP-Address and then returns to the original site. The average browser won’t see that, but if you’re quick you might spot it in the status-bar. A search engine crawler or any user who knew the address would get there without a redirect and not notice a thing.


That’s something that deserves to be looked at more closely. What’s on that server? How could I be able to see it?

I had seen something similar a few months back which redirected me to an affiliate site the first time I went to that site through a Google referrer (in my case, the referrer was enough). It would only trigger once per IP-Address. This looks like a similar hack.

When I was able to download the files, I had a nice collection of:

  • an encrypted javascript file that downloaded exploits based on browser and operating system
  • an exploit from
  • an affiliate sales page for an antivirus software. Oh the irony. “We just infected you, buy our antivirus to get clean.” That is, if that software isn’t infected with something else.
  • an affiliate signup link on that page

A search engine crawler will never see these things. A user, coming in from Google, will get redirected and if the IP address is not known, it will trigger a few exploits based on the system the user has and then display an affiliate ad page. The next time the user comes, the redirect will happen but the normal page will be shown.

Spotting the hack on your site

It would be good to know how you could spot a hack like this on your site. In general, you wouldn’t be able to. You can check for this particular hack, but it might not trigger every time … not to mention that there are likely way too many hacks that you would need to check for.

A simple way to check for it would be to use wget to access the page, and check for strange redirects, eg:

$ wget --user-agent Firefox --save-headers \
    --referer "" \

However, as mentioned, that might not work every time.

The technical details

(skip this part, if you are lost already :-) )

The original spotting of the anomaly was using LiveHTTPHeaders with Firefox, while doing the steps: search, click on the top result. You see the following:

GET / HTTP/1.1

HTTP/1.x 302 Found
Date: Thu, 23 Aug 2007 06:38:04 GMT
Server: Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/
1.2 mod_bwlimited/1.4 PHP/4.4.6 FrontPage/ mod_ssl/
2.8.28 OpenSSL/0.9.7a
(... added space to prevent linking ...)

GET /ind.htm?src=324&surl;;=80&suri;=%2F HTTP/1.1
HTTP/1.x 302 Found
Date: Thu, 23 Aug 2007 06:38:05 GMT

A strange redirect like that is a really bad sign. How can we check the URL that is given to see what they are sending? Apparently it can only be triggered once per IP-address and I had already used that chance earlier. In order to view the initial page, I had to find an IP address that was not yet registered with the remote server (at least that’s my explanation). I used a proxy server from one of the lists online. Using the proxy server and wget, I was able to access the page:

$ set http_proxy=

$ wget --user-agent "Firefox" --save-headers \

Connecting to connected.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
20:43:23 (79.20 KB/s) - `ind.htm@src=324&surl;;=80&suri;=%
2Findex.html.2' saved [414]

The page that was returned was a normal frameset:

<frameset framespacing="0" border="0" rows="*,1" frameborder="0">
<frame name="m" src="/site.htm?lng=1&trg=cln&oip=0&trk=zszuyhbinthnpzt" scrolling="no" noresize marginwidth="0" marginheight="0">
<frame name="b" src="about:blank" marginwidth="0" marginheight="0" scrolling="auto">
<noframes><BODY>Frames not supported by your browser.</BODY></noframes>

The second frame was kind of funny, “about:blank”? The first one was a bit more interesting though: Notice the “trk” parameter.

Accessing that page with Opera within a VMware virtual machine running Windows 2000 (heh, paranoid is good), I was able to access that page. I saved it for analysis (and had Ethereal running on the side just to be sure). I tried to refresh and it returned 404. You could only view the page once.


Looking at the files you see some interesting things:

  • an encrypted javascript file
  • an exploit from
  • an affiliate sales page for the antivirus software
  • an affiliate signup link on that page

The ZIP-File contains a full copy of the files as downloaded by the Opera browser. Check the files at your own risk, they contain the full exploit.

The encrypted javascript file looks like this (pulled apart and reformatted; called “__cntr000.htm” in the ZIP file):

<script language=JavaScript>
function dc(sed) {
  var b=1024,i,j,r,p=0,s=0,w=0,t=Array(63,56,60,51,15,9,10,13,36 (...) 52,16);
  for(j=Math.ceil(l/b);j>0;j--) {
     for(i=Math.min(l,b);i>0;l--,i--) {
dc("AVbFxuGqAk7s5OpH (...) G2ovPVoP9dATq_")

The contents of the file are encrypted with some variation of Base64 encoding. You can decode the javascript by replacing: eval(dd1+"."+dd2) with document.write("<xmp>" + r + "</xmp>");

Doing that will display the full contents of the encrypted data (called “__cntr000-decoded.htm” in the ZIP file).

var WinOS=Get_Win_Version(IEversion);
PatchList = clientInformation.appMinorVersion;
switch (WinOS) {
    case wXPw:
        for (var i=0; i < PatchList.length; i++) { 
            if (PatchList[i]=="SP2") { XP_SP2_patched=1; } 
        if (XP_SP2_patched==1) { 
location.href="cnte-eshdvvw.htm?trk=zszuyhbinthnpzt"; (...)

It is yet another javascript that triggers an exploit based on the operating system (it even test for XP service pack 2) and browser that the user is using. The exploit is also tagged with the “trk” parameter and couldn’t be downloaded separately. You can bet that’s it’s not a picture of your favorite celebrity, however.

Next steps

You could follow these up with:

  • Checking the whois of the payload-server ( and notifying the hoster (in this case probable fruitless)
  • Checking the sales page, search for the affiliate ID and the setups running and complain to the affiliate networks about this webmaster
  • Mirror a copy of the original server for analysis
  • Obviously move to a different server, perhaps even a different hoster


The hacker had managed to patch the server side code (most likely the Apache server) so that

  • search engines see the normal page
  • new users from search engines are hacked with several exploits and shown an ad for anti-virus software

Spotting something like this on your own sites is close to impossible. The search engine crawlers would not notice anything.

Recognizing something like this algorithmically on Google’s side would be possible with the Googlebar-data. Assuming all shown URLs are recorded, they could compare the URL clicked in the search results with the URL finally shown on the user’s browser (within the frames). At the same time, the setup could be used to detect almost any kind of cloaking.

Scary stuff.

Warning: This page is pretty old and was imported from another website. Take any content here with a grain of salt.

Comments / questions

There's currently no commenting functionality here. If you'd like to comment, please use Twitter and @me there. Thanks!

Tweet about this - and/or - search for latest comments / top comments

Related pages