Discovering your website has been hacked easily ranks as one of the least enjoyable experiences associated with running a website. Depending on the type and extent of the hack, the cleanup process can be quite lengthy and costly, but many sites can be cleaned up very quickly. Of all the questions that arise when this happens, users are often left asking:
1) How did my site get hacked?
2) Why did my site get hacked?
3) What can we do to prevent it happening again?
These three questions are often intrinsically linked and the answer depends significantly on the site’s setup and the type of attack. In this three-part guide, each of these questions will be looked at in turn. The following assumes that the site is running on WordPress, but the principles are the same for most other popular CMSs.
How did my site get hacked?
Hackers use many different methods in their attempts to gain unauthorised access to websites, but the most common methods of entry fall under two categories: a vulnerability in software or weak username/password combinations. Weak credentials should be a no-brainer despite remaining surprisingly common, however the wider and more subtle threat lies in sites that run on vulnerable software for weeks, months or even years.
WordPress sites need to be regularly updated to remain secure. This requires updating everything: the Wordpress core, plugins and theme files that make up the public-facing aspect of the site all need to be kept on top of. If these are not maintained for whatever reason, the site will likely become vulnerable.
Another way that hackers can gain access to a site is through other sites on the same server. Most sites tend to be hosted on shared servers which allow hosts to sell server space cheaply by dividing the server resources by hundreds, sometimes thousands, of sites. This works for many users, but in some cases this can make sites vulnerable to being exploited through other user’s unpatched sites. In a worst case scenario, this can allow hackers access to other sites on the same server, so it’s important to choose website hosts carefully and not on price alone.
An often overlooked vulnerability is the existence of outdated versions of a site existing in a publicly accessible folder. A common scenario is for users to setup development/staging/test versions of their site in a subdomain that actually resides in the /public_html/ folder (e.g. /public_html/dev/). This is perfectly normal and secure as long as the development site doesn’t lag behind the production site in terms of software updates. Should be left to gather dust, the unpatched software on this site can allow hackers access to your entire account.
That just about covers the common reasons your site may have been hacked, the next post looks at why a hacker might target your site in the first place.