One of the reasons we are so critical of web security companies spreading falsehoods about security is that even without running into that people whose websites have been hacked often believe things that are wrong about the situation. This makes it harder to get the hacking properly resolved because either they are trying to deal with it in ways that don’t have any impact or they want someone else to do those things for them. Often times most of time spent communicating with clients with hacked websites is trying to clear up misconceptions, whether of the clients own creation or something coming from another security company. In some cases people are so convinced with these falsehoods that they are not interested in having the websites properly cleaned up, which leaves the website vulnerable going forward.
One common issue we run into is people believing whatever was the last action they took related to the website before they noticed it was hacked was the cause of the hack. As an example of this, we recently had someone contact us that in all likelihood had been hacked due to their running an outdated version of WordPress, 4.7.1, which has a vulnerability that allowed posts to be modified by anyone. Exploitation of that vulnerability is usually easily fixed by simply updating WordPress and reverting the posts back to an older revision. At the point they had contacted us they had already done those things, so there wasn’t really anything more that likely needed to be done. When we let them know that, they responded that:
Thanks, but the hack date is the same day we installed this plugin, which is kind of weird. Anti-Malware Security and Brute-Force Firewall
What are the chances that installing a security plugin with 100,000+ active installs would cause such a hack? Probably close to none, but despite that, this person made that connection (that isn’t a knock on them as this type of thing comes up frequently).
The further problem we often find with this type of assumed correlation is that the correlation doesn’t actually exist, as the website was hacked not when the website’s owner became aware of it being hacked, but at some earlier time.
Finding the Real Source of the Hacking
The best bet for finding out how a website was hacked is probably to hire a company that does proper hack cleanups, which includes trying to determine how the website was hacked. Even when hiring someone that does that (like us) often times it cannot be determined with certainty how the website was hacked, as important evidence, usually log files, is gone by the time the website is being cleaned up. In that case someone that deals with lots of websites should still be able to make a fairly good educated guess as to how the website was hacked based on the remaining evidence, the particulars of the situation, and how that compares to other hacked websites they have dealt with where it was possible to make a more definitive determination as to the source.
Even if the source of the hack is not able to be determined we have found that doing the work needed to try to do that helps to make sure the website is fully cleaned. It can also help to make sure the source can be determined if the vulnerability stills exists and gets exploited again after the website has been cleaned up.