Getting Started with WordPress Incident Response

In previous episodes, we have extensively covered one of the key aspects of security: the proactive approach (or safeguards). This includes all the measures related to good security hygiene and posture to minimize the risk of being hacked.

But what happens when the worst-case scenario comes true? What are the next steps once you get hacked? Because it will happen—one of the axioms of security is that there is no 100% efficient security, and there never will be. Former Cisco Chairman John Chambers famously said, “There are two types of companies: those that have been hacked, and those who don’t know they have been hacked.”

So, being prepared for the possibility of discovering that your site has been compromised—such as noticing that the main page has been completely redesigned with messages you didn’t create—is essential. This is where Incident Response (IR) comes into play. According to VMware, IR is “the effort to quickly identify an attack, minimize its effects, contain damage, and remediate the cause to reduce the risk of future incidents”. It falls under the reactive approach to cybersecurity (AKA countermeasures).

The IR Plan

The Incident Response plan, adapted to WordPress security event scenarios, is formed by these five phases, assuming the detection phase has already happened:

• Triage: Gathering information about the attack.
• Action: Implementing cleanup strategies to remove malware.
• Mitigation: Removing vulnerabilities to prevent future incidents. This phase digs on the proactive measures topic we have developed through previous posts, so we will ignore it in this topic.
• Recovery: Restoring functionality and reputation.
• Lessons Learned: Analyzing the incident to improve future responses.

Since this topic can be extensive, I’ll cover some concepts and focus on the triage phase in this post. We will address the remaining phases in subsequent posts.

Some Facts

Not All Hacks Are Visible or Easy to Detect

Discovering a completely altered homepage is actually one of the best-case scenarios. Not all hacks are as obvious. Some are incredibly sneaky and even difficult for a tier 3 Incident Responder to detect. So, don’t feel bad if you haven’t noticed it earlier, or if others spot issues you missed. Some attacks target specific audiences or display randomly to users.

Also, don’t take a green mark from a scanner as absolute. Remember this rule: A green mark from a scanner might be true, but a red one IS true. Although there are false positives, this approach generally holds. So, are scanners reliable? They are useful tools for gathering information, but hacks are designed by people who know how to avoid detection. Also, consider that scanners are based on current knowledge, so new procedures or vulnerabilities might not trigger any warnings.

Site Hacking is Almost Never Client-Oriented

Attackers typically do not focus on a specific site, content, or owner. Instead, they aim to exploit vulnerabilities massively for malicious purposes using automated tools. If your site is on their list and it is vulnerable, bad luck. Their focus is on what they can gain from the hack, so the more massive, the better. I have cleaned countless animal adoption sites, NGOs helping Alzheimer-affected elders, child care initiatives, and similar sites. Do malicious hackers lack empathy? They simply don’t care. So, even if it is our first impulse, don’t assume this is personal or targeting you specifically.

In fact, almost always, hacking occurs due to deficient monitoring and maintenance.

Patches and Security Updates Almost Always Come After an Exploit is Identified

That’s why updating as soon as possible is essential. We will later discuss how updating is also a crucial tool for Incident Response.

Triage Phase

There are a huge number of attacks that can be solved directly by you without the intervention of a security expert. The chain of agents involved in a security incident starts from your site’s responsible (you, your admins, etc.) and ends with an external security expert, passing through the hosting provider’s support department. Here is a list of things you can do by yourself before handing the case over to others.

Step 0: Block Access

As a first measure, if you already know that your site has been hacked, limit access to the site just to your IP, so you can explore around minimizing the harm. You can do it manually by modifying your .htaccess file if you are using Apache, or configuration files if you are using other web server applications like Nginx, redirecting the rest of the traffic to a simple maintenance HTML file.

Some hosting providers allow you to do this from their hosting panel.

You might need to re-enable access to some scanners as they need to access your site, but at least you can control “when” using this technique.

Part of this step should also be to change all passwords around: (S)FTP, SSH, WordPress administrator, hosting panel user password, database password, etc. Doing this, we can at least block any attack leveraging leaked credentials.

Step 1: Scan Your Site

It might sound obvious, but as said before, we need to gather more information. There are lots of types of attacks, some of which have been covered in previous episodes, but let’s simplify them into three categories:

• Those affecting the frontend; visible to users when they are normally browsing the site.
• Those related to the backend; not visible through browsing and more related to files and backdoors.
• Those affecting your database; not file-based. We will cover this in a following episode.

Frontend Techniques

For the frontend, there are four main ways of gathering more information about a possible hack:

• Frontend Scanner: Pass it through a frontend scanner like sitecheck.sucuri.net. If you are lucky, this kind of scanner will spot the issue and provide essential information for effective cleanup.
• Blocklists: Check your site URL against a blocklist aggregator like virustotal.com. Various blocklist authorities might detect malware on your site and add it to their lists. Checking individually any positive match from the VirusTotal scanner can help get contextual information about the issue. Some vendors are not willing to give much information, but others do.
• Expert Tools: If you are an expert web developer, you can try webpagetest.org, where you can test your site from different configurations and get detailed information about scripts loaded, redirections, performance scores, etc. Having a trained eye is essential here, as you can spot anomalies in the waterfall trace graph it generates.
• Users: Enabling proper channels to give voice to your site users can save you lots of hours, as they can get in touch with you and share information about what they observe.

Backend Scanners

For the backend, there are two main techniques:

• Server-Side Scanner: Several open-source tools perform server-side scanning, and some hosting providers offer them in their hosting panels. These scanners will go through your files and compare their content against community-driven signature databases, so you might be lucky enough that it resolves the issue and cleans the malware. A classic one is ClamAV.

One important aspect of these scanners worth mentioning is that they should be external to the WordPress site. It is common for malware to tamper with scanners executed from within the WordPress instance, so I wouldn’t recommend using any malware scanner from a plugin. You can read more about this here.

• File Integrity Monitor: This monitor compares the digital signature of each file on your site with a previously saved signature, making it easy to spot modified or added files.

This is very useful in a WordPress environment: WordPress core files are fixed and shouldn’t be modified, so the “wp-admin” folder and “wp-includes” folder, along with all core files in the site root folder, except “wp-config.php,” shouldn’t change. If there is a change in any of the files in those folders or files, it is clearly suspicious. They should only change when we update the site.

However, this kind of monitor can be noisy, and you might find yourself reviewing lots of false positives. Even so, it is an essential tool, and although you can easily build your own monitor from scratch or install plugins with this feature, the easiest way would be to use the WP-CLI command for that.

Conclusion

In conclusion, being prepared for potential security breaches on your WordPress site is crucial. While proactive security measures are essential to minimize risks, understanding and executing an effective Incident Response (IR) plan is equally important. Hacks can be subtle and difficult to detect, but by blocking access, changing passwords, and conducting thorough scans, you can mitigate damage and gather information about what happened.

In the next post, I’ll dig into the action points for cleaning up and recovering a site. Remember, constant monitoring, timely updates, and leveraging the right tools are key components in maintaining your site’s security and quickly addressing any incidents that arise.