Did you remove the “.old” directory created by the “one-click” upgrade (beta!) process? If you left the “.old” directory on the server, an attacker with knowledge of DH could continue to exploit any vulnerabilities that may have been present in the older version of WordPress.
You said that the “solution” was to upgrade WordPress. Did your access logs give you any indication that WordPress was the culprit? Could it have been a WordPress “plugin” that was exploited? If so, reinstalling the plugin to the “upgraded” WordPress might have “reinstalled” the vulnerability.
Not at all. My experience with numerous WordPress installations has been exactly the opposite. While any script has the potential to be exploited, WordPress has been thoroughly vetted, and is a very robust application. Again, a careful inspection of your access and error logs around the time of the corruption, close attention to your stats information (esp referrers and failure reports), and a close inspection of your files and directories should give you a clue as to the vector of attack.
Unfortunately, that provides very little additional information to help us track down the problem; it only describes the tool used to create the site and not the code that was present.
Changing the passwords is a “good thing” and since you are sure “no one has access to those” I can only assume that you have never used telnet to access your server, do not use the same password with your email account(s), have not used a wireless connection to administer your account, etc. I’m not sure what you mean by “routine precautions”, but hopefully that includes regular inspection of all your server logs, making sure no files on your server have permissions set any more loosely than absolutely necessary to provide the necessary functionality, and periodic (especially in the wake of the attacks) inspection of your files and directories looking for things like inappropriate modifed file dates/times, files you do not recognize, etc. Have you logged into your server space with SSH and stepped backwards through the command line history to see if there are commands in the history that you do not recognize? In my experience, one (or more) of those procedures has always provided a clue to the source of the “hackish” activity.
I cannot answer your question, as I do not have access to your server, logs, or code, and have not seen your site in it’s native state. I have given you several suggestions as to where to look to attempt to determine that. Should you put the site “back up” in it’s pre-hacked state and provide me with the url, I would be happy to take a look at it in hopes of spotting a potential vulnerability if you think that might be helpful. I still believe, however, that the previously described steps will provide you with a better starting point, as you can do that before you re-build the site(s) and see what tracks the attacker left.
As for “domain is on the server/software on the server/hacker on the server” question, well, yes, I suppose in some sense that could be true depending on what you mean by “on”. The whole process initiated when as user visits a site (asking for, loading, sending, and displaying a webpage) actually takes place “on” (or “over”) a whole lot of different machines and networks. There are a lot of potential “holes” in this process and lot’s of ways to “attack” a site. Most commonly, the attacker has manpulated files residing in your public webserver directory by means of a scripted exploit, compromised passwords, loose permissions, or a combination of those items in order to modify what is displayed to a visitor to your site (or send spam from your site, or other malicious activity).
The challenge is to find out how they “got in”, and only you have the tools to pursue that. We can help you interpret what you find, but we cannot do it for you,as we do not have access to the resources needed to investigate.
The answer likely lies somewhere within your directories/logs/stats and the actual files on your site.
I don’t want to sound discouraging, as the answer can almost always be determined with proper investigation. I just want you to understand that, while anything is possible, my experience in hosting dozens of sites with Dh since 1998 has proven DH to be one of the most secure providers I have encountered. Most of the idiosyncratic characteristics of the DH Debian Linux distro DH runs, “restrictions” on the use of certian modules, DH “quirks”, etc. are the result of DH’s high attention to possible security risks and their attempts to ensure a secure environment. I have not yet encountered a server based vulnerability exploited at DH; I have seen numerous “hacks” of sites on DH that were perpetrated in various other ways due to the code on the site or other previously described “routine” security exposures.
If you have any additional information re. the above mentioned items and wish to share, I’ll be happy to help you investigate further. Anecdotal statements like “Out of 6 Web sites, most hosted by others over the past ~8 years, this is the only time a security breach has ever occurred” are only helpful in helping us understand your frustration. Unfortunately, we need “hard” information to help you determine how your site was compromised.