Why website reinfections happen
We all know someone who’s been in a difficult position following a security breach. They are rushing to assess the damage, while simultaneously repairing website functionality to limit the compromise. It’s a stressful situation, especially if you’ve had to deal with a compromise more than once. Unfortunately for some website owners this is a reality -- shortly after the initial security breach, the website becomes compromised again. It leaves the website owner asking why their website is being targeted and how the website re-infection is happening.
The short answer is that it’s most likely due to unresolved vulnerabilities. While it may seem like you’ve been singled out and targeted by some menacing hackers, most of the time that isn’t the case. The majority of website compromises are preceded by automated campaigns that locate websites vulnerable to a particular exploit the hacker wishes to employ. The bottom line is, you aren’t the target that the hacker is singling-out, it’s the software on your website. There are a couple main culprits for this scenario.
The Patch Problem
Take WordPress or Joomla as examples. The platforms are not inherently any more vulnerable than the next, but over time, security vulnerabilities are discovered and patches are made. This goes not only for the core installation of these platforms, but also their associated themes, plugins, and extensions. Once a vulnerability has been discovered and patched, an announcement is typically circulated to the patch stressing the urgency to resolve the security issue.
However, the platform’s users aren’t the only ones reading these patch releases. Hackers often trawl patch releases to identify an attack vector. These attack vectors are used in association with the now-patched vulnerability. In many cases, the hacker may even be able to deploy a working attack within the first day of the disclosure. These types of attacks are called zero day exploits, where there are "zero" days between the time the vulnerability is discovered and the first attack.
Those that vehemently apply patches as soon as they’re released are immediately safe from the attack vector. The problem lies with website owners who may take a few days or weeks to patch their websites. In fact, many ignore patch releases altogether, making them a ripe target. Once an attack vector has been identified for a particular platform, the hacker will attempt to identify as many of those vulnerable platform versions as possible. Believe it or not, many hackers utilize major search engines to help determine the software and version you’re running on your website. Search engines crawl and index millions of websites each day, making for a powerful database of active websites that often contain artifacts that help identify the software running on a website.
In cybersecurity, an artifact is one of many kinds of tangible by-products produced during the development of software that can help describe architecture of the software. This can serve as intelligence for adversaries.
At this point, if the hacker has leveraged the power of search engines to locate a designated artifact identifying websites using the vulnerable software, the hacker will now have a list of targets. From there it’s as simple as repeatedly launching the identified exploit against these websites until at least marginal success is achieved. The reason we see the same websites hit repeatedly, is that by this point your website has already been listed as a vulnerable target and probably isn’t going to find its way off of that list in the near future. Even after you’ve successfully cleaned the website, without resolving the initial vulnerability that allowed the attackers to compromise your website in the first place, they’re going to be able to walk right back in.
It is for this reason that we stress not only cleaning the website, but also patching all software and identifying and remediating all vulnerabilities present on the website. It is also advisable to take a more proactive approach in the future by utilizing a web application firewall (WAF) to protect your website.
On the less common end of the spectrum we see compromises due to undocumented vulnerabilities, where the bad guys were the first to the punch with discovering that a vulnerability exists. However, once the exploit has been designed, the process takes much the same shape as above, leveraging website indexes and identifying targets. The most critical difference between documented and undocumented vulnerabilities is that there won’t yet be a patch developed to mitigate the vulnerability from the vendor. In this instance, your best defense is taking a proactive approach by implementing and training a web application firewall (WAF) to block future attacks.
Logan Kipp is a Product Evangelist at SiteLock where he serves as an Ambassador to the WordPress and other open-source content management system communities. He has over eight years experience in the website hosting and security technology field, including four years as SiteLock's Lead Security Analyst where he was responsible for incident response, trend identification and analysis and security processes and implementation.