Imagine for a moment, you have a suspicion that you have somehow been hacked. You see that something is off, but you feel as if you are missing something. This is the emotionally draining world that many live in, with a paranoia and concern that grips you once you see and recognize that something is not right. As humans we need closure, we need the ability to say… “Gotcha!!” Often though, especially when it comes to hacks, we are left only with our imagination and that can be concerning for many.
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 using kept reporting nothing was amiss. As a website owner, that’s perhaps the most frustrating feeling, when you can feel it in your bones 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 have been hacked yet you are unable to see the infection?
Anatomy of Attacks
Before I dive into my thoughts, I always like to 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 compromised of five basic elements.
These elements span across almost all attacks, regardless of size, and to some degree:
– Reconnaissance
– Identification
– Exploitation
– Action
– Sustainment
In the most simple and pure forms, this is what a normal attack sequence looks like. There can be variants from this and some have extended beyond to 6/7 steps, but this is 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, this does not mean that they 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 time 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 of time, 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 had also detected a random image 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 be able to say for certain that there wasn’t an infection was impossible. This process though, does speak to very good administration/maintenance on the part of the website owner. Previously, I also wrote about tips to secure your wordpress site and this simple steps are really useful.
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).
10 Actions To Take After a Suspected Hack
Once you’ve identified a hack has occurred, whether it be via an IoC similar to above, or a system that flags an issue, there are definitely a number of actions you should take:
1. Presume you entire environment is compromised.This might sound a bit dire, but it is true. 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 it 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 you are using, 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 and means you can build a timeline of events and know exactly 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 technical minded, this might be a fun challenge, but for the everyday website owner like most of you it will be a nightmare.
