Site infection

In the last day and a half, I’ve had two of my sites infected with some sort of javascript injection into the index.php file.

The first one happened some time between 2AM and 10AM server-local time yesterday. I haven’t checked the second one.

The javascript is an obfuscated bit of code that double-decodes, then opens a 1x1 iframe with a target of ‘’.

I’m just trying to figure out how this got inserted into my index scripts. (Amusingly, the file timestamps didn’t change.)

Any thoughts?

I don’t know how it could get into my files without running as either me or another account running as a superuser.

I’m just not a big enough linux-guy to have much of a clue on how this happens.

Be sure to read this entry in the wiki:

It’s unlikely they used your password, so start looking at the third party software and scripts you’re running on your site. A search reveals that the site is hosting malware.

As expected, I am the only one who’s logged in, from this home machine, this month.

I have no third-party software (Word Press, etc) running on the site, aside from the CodeIgniter programming framework under which my site runs.

I wrote it from scratch.

What do you mean by ‘A search reveals that the site is hosting malware.’?

I searched for bronwynjamrok and found several recent references to it hosting malware.

Does your site make calls to a database or have some sort of login?

I understand what you were saying now… you were saying that was hosting malware (which I was already aware of - I found out about this when I got a burst of emails from visitors warning me about it) and I originally thought you were saying that my sites were actually hosting the malware.

I only have the hideous script injection which leads people there.

I do have a general ‘site notice’ mysql db call on both of these sites ( and, but beyond that, they use flat files for their normal operation.

I do not have any user authentication for site access for either site.

On one site, the javascript was injected at the very top of the index script, the other had it inserted just before the html end-body tag.

In neither case was the file datestamp altered, so using the method of searching for recently altered file timestamps would not help.

I suppose I should find out how to do a recursive grep on the entire directory tree to search for the double-encoded javascript, but I don’t grep grep, so to speak.

Hi Dahak,

My site was infected twice in 2 months. I cleaned up every bit of possible application code that could have given a hacker access to insert javascript into my index files. My entire site is now completely static HTML pages, yet the site was hacked again. So, just because you rid the site of malware and patched any holes, doesn’t mean it won’t happen again. That said, the only thing left for me to do is change my FTP password. If 2 months from now the site has malware again, I suspect something much bigger going on with Dreamhost. I’ve contacted them to make sure they check that out but I haven’t heard back.

If you are still using FTP at all, then that could well be the problem. Don’t use it. Set your user to only allow connection via SFTP/SSH (there is an option in the panel), and then change your password.

FTP passes your password over the net in plain text, where it could be intercepted, or even gleaned from malware on your own computer. SFTP/SSH sends your password information encrypted so it is useless for attacking your site even if it is intercepted. In short FTP is just not secure so its use should be avoided altogether.

Ah… but even if a third party gleans my FTP password, would his attempted access not be logged just as my own access is logged?

In my case, only two IPs had accessed my site via FTP, both IPs were known (home & office).

Since this incident, it’s happened to me yet again. Before killing the script, I checked the ownership and it wasn’t owned by me, root or dhapache.

Support never did give me any information on who the account belonged to, so I don’t know of the user was the intruder, or simply a compromised DH user used as the initial entry point.