Your Website’s Been Hacked But No Signs of Infection

Imagine for a moment you suspect that your website has been hacked. Something is off, but you feel as if you are missing what that something is. Paranoia can grip you once you recognize that something is not right. As humans we need closure, we need the ability to say… “Ah, gotcha!” Often though, especially when it comes to hacks, we are left only with our imagination on how bad the problem is and that can be concerning.

In one of the many groups I participate in, I was reading an experience that spoke to this exact feeling. A user had noticed that a new administrator user had been added to their website, but barring a simple image file, they were unable to identify anything else out of place. To further complicate issues, the various security tools they were utilizing kept reporting nothing was amiss. As a website owner, that’s perhaps the most frustrating feeling, when you know something is wrong. Why aren’t the tools picking it up?

This isn’t the first time I’ve seen this. It’s more common than many realize, and it has more to do with how the attacks happen than with you. I want to dive into this phenomena; how is it that while you know you’ve been hacked yet, are unable to see the infection?

Anatomy of Attacks

Let me first provide context. I believe this is important as it sets us up together on the same foundation. To address this specific scenario we have to go over the basics of how attacks happen. Attacks are comprised of five basic elements.

These elements span across almost all attacks, regardless of size:

1. Reconnaissance
2. Identification
3. Exploitation
4. Action
5. Sustainment

In its simplest form, this is what a normal attack sequence looks like. There can be variants from this, some extending beyond six or seven steps. But these five are the core. What this does not help you appreciate, however, is time frame.

While it is true that a great number of attacks are automated, they don’t all occur in the same time frame. Each one of the steps can be broken into various phases (both in terms of time and actions).

A reconnaissance/identification event could occur over a period of weeks. The malicious actor configures their environment to flag all WordPress websites running a known vulnerable plugin, all Joomla! websites on any 1.x branch, or any other configuration they deem valuable at the time of the attack. They then take this information and record it in their data warehouse for use at a later time.

More important to this post however, is the exploitation/action phase. These phases don’t necessarily occur in the same time frame and there is good reason for this. There is value in the attacker waiting for the appropriate moment to initiate the nefarious act of successfully exploiting a weakness in your site. In an environment where website administrators are actively on top of their site, hackers want to reduce their footprint whenever they can. By successfully injecting a backdoor, or gaining entry via a user, it gives the attacker an opportunity to be lost in the noise before the website owner knows they have gained access. This is important for attackers in the case of forensics; when the security analysts try to locate their initial point of entry. If a hacker is able to spread out their attack over a longer period, it essentially becomes a needle in the haystack exercise for the website administrator.

Indicators of Compromise (IoC)

In the scenario I mentioned earlier, the individual described an incident in which they had identified a fake administrator user. They also detected a random image that had been uploaded and presumed it to be a backdoor of some kind. They were concerned however, because the various security systems they were using (including ours) were not detecting any infections.

I wrote to them and explained that the lack of detection was actually a good thing, but to be able to say for certain that there wasn’t an infection was impossible. This process does speak to very good administration/maintenance on the part of the website owner.

It is something I often harp on when I give talks. The importance of complementing good security posture with administration and maintenance. While it is unclear to me how they noticed the administrator user was added, they did. Depending on the platform you are using, this not something done by default and most users are happily oblivious to the fact that roles exist within their respective Content Management Systems (CMS). This action though, is a perfect example of an Indicator of Compromise (IoC).

Recently I was giving a talk where I explained how hacks do not always have the intention of displaying their payload. I described some of the various motivations for hacking that I recommend reading. These motivations include a number of other nefarious acts, like distributing malware via drive-by-download infections, abusing the environmental resources to send out spam and phishing lures, or even using the website as part of a larger bot network. Whatever the motivation, rest assured that malicious actors have various motivations for the hack.

On the flip side, this individual from my story likely stumbled onto the hack prematurely – prior to the malicious actor being able to complete their plan. If so, this would talk directly to the value of good security posture, specifically the importance of good auditing and monitoring. In this scenario, the website owner realized that a new administrator account and a new file had been added. A classic example of Indicators of Compromise (IoC) that identify the potential for a hack before the actions of the hack are made apparent.

10 Actions To Take After a Suspected Hack

Once you’ve identified a hack has occurred, whether it be via an IoC (similar to the above) or a system that flags an issue, there are definitely a number of actions you should take.

1 – Presume your entire environment is compromised. This might sound a bit dire, but it is probable. If someone has been in your environment, they have likely done things you cannot see and you must operate under that suspicion until you can prove otherwise.

2 – Clear access to all users. Some CMS applications have a tendency to retain user sessions for a very long time. Assume that the attacker might still have your administration panel open, so clear your salts / keys forcing an access reset for anyone still logged in (including yourself).

3 – Force a password reset for all users. I cannot stress the importance of this enough. Clearing your password will do you very little if the attacker is using another users’ account, even if it is a user with a lower privilege. The attacker might be exploiting some form of Access Control Bypass (ACB) vulnerability, allowing them to escalate their permissions and function as a user with a higher role.

4 – Audit remaining users. It is not enough to update their passwords. You need to look at their database configurations. Do you recognize the name and emails associated with the user? If you reset a user password, but the attacker changed the email, using the forgot password function will negate your password reset action.

5 – Replace CMS core files. Operating under the guise that everything is compromised, replace the core installs for your CMS. When working in platforms like WordPress – wp-admin and wp-includes should be safe if your developers are following best practices. If using Joomla, you are looking to stay within the includes and libraries directories. Anything beyond that could be risky without professional help.

6 – Check integrity of extensions. Regardless of the CMS, almost all are built on an extensible architecture allowing you to add and configure a series of plugins, themes, templates, extensions, modules, and components. It is important to take the time to a) reinstall if possible, or b) go through the files and directories to look for any potential integrity issues.

7 – Enable TFA / MFA authentication on access control nodes. Most CMS applications facilitate some form of Two Factor / Multi-Factor Authentication via one of their plugins, modules, or extensions. Research the ones that make the most sense that you can fit into your everyday routine painlessly.

8 – Restrict access by location. This is often the most contentious for website owners: restricting access. It throws a wrench into the idea that they can be anywhere at anytime, but in reality it’s rarely the case; it’s more the idea of being able to have that freedom than an actual need. If possible though, it’s highly recommended.

9 – Perform some level of forensics. If in a situation where an IoC has flagged a possible compromise, you are actually in a very good position. This means you know exactly when the user and file were added. This is huge when thinking about this from a forensics perspective. It means you can build a timeline of events and know where to look for things in your logs. This is not always possible, but is recommended.

10 – Employ a Website Firewall at some level. Whether employing ours, or someone else’s, it is an important step. The reason being, that all the recommended actions above will be moot if the attacker is or was able to exploit a vulnerability. The forensics would be able to identify the potential entry point, beyond the access node, but it is reactive not proactive. Therefore, how will you address the unknowns moving forward? For the more technically minded, this might be a fun challenge, but for the everyday website owner like most of you, it will be a nightmare.

Website Security Begins With Good Posture

Security has always been comprised of three important tenants – People – Process – Technology.

Too often however, we place an overemphasis on technology. The reality is that technology is only there to help complement us – the people. As we can see in the example above, it’s with the use of technology and good administration that an IoC was used to identify that a compromise had occurred. This then sets off a series of actions; the post-compromise response process, allowing you to quickly mitigate the attack and reduce the potential impact.

I’m glad I came across this scenario because it helps illustrate how interconnected the three tenants are. What I wonder, however, is how we help to convey this to the millions of website owners that believe that the last action they ever needed to take was to pay their developer / designer to deploy their website, and with that action, all further activity on their part, ceases.