We Were Hacked: Why Removing the Malware Was Not Enough

For years, we have helped companies recover compromised WordPress websites. We have removed malware, eliminated backdoors and rebuilt websites that had lost control of their installation.

This time, the attack targeted our own website.

On 1 August, our website was compromised. WordPress was up to date, Wordfence was correctly configured and the server had several layers of protection. Even so, the attacker gained access using valid credentials.

We spent approximately five hours investigating the incident, analysing logs, cleaning the installation, securing the server and applying blocks to make similar attacks more difficult.

We could have simply restored a backup. Instead, we decided to understand exactly what had happened before removing the evidence.

What happened

Log analysis allowed us to reconstruct the general sequence of the attack. For security reasons, we have omitted specific indicators and details that could facilitate a similar intrusion.

Access to the administration panel

The attacker accessed WordPress using valid credentials.

We found no evidence of a direct exploitation of WordPress core or a brute-force attack. Everything indicated that the attacker had legitimate access to an account with administrator privileges.

From WordPress’s point of view, the login appeared normal.

Installation of a malicious plugin

Once inside the dashboard, the attacker used the official plugin installer.

They did not need to upload files through FTP or initially access the server control panel. They followed the same workflow any administrator would use to install an extension.

Within seconds, the malicious code began to run.

Creation of a backdoor

The installed plugin added a mechanism that allowed actions to be executed without authenticating normally in WordPress again.

This allowed the attacker to continue working even if the original plugin disappeared. Removing the plugin without checking the rest of the installation would therefore have left the incident unresolved.

Changes and persistence

Hours later, changes appeared in other website files. The aim was to preserve access and make detection more difficult.

The modifications were not numerous or especially obvious. They were distributed across strategic locations, making them difficult to find during a superficial review.

How we investigated the hacked WordPress website

The entire investigation was carried out directly on the VPS through SSH.

Working from the command line allowed us to review both WordPress and the server, and compare the changes we found with the access timeline.

We used tools including:

• WP-CLI to check the integrity of WordPress core, users, plugins and scheduled tasks;
• grep to locate suspicious patterns in PHP files and logs;
• find to identify files modified within specific time ranges;
• stat to check modification dates;
• system tools to apply blocks;
• Nginx to restrict access to the administration area;
• Plesk to review the hosting environment and service status.

Logs allowed us to reconstruct the attack

The server logs were decisive. We were able to connect:

• the login;
• access to the administration area;
• the plugin installation;
• the first execution of the malicious code;
• subsequent modifications;
• connections made during the persistence phase.

Without this data, we would only have seen the final result: an installation with altered files. The logs allowed us to understand how the incident developed.

What we reviewed during five hours of work

The investigation and recovery included:

• WordPress core integrity;
• official and modified plugins;
• users with administrator permissions;
• active sessions;
• cron jobs;
• PHP files outside the usual locations;
• must-use plugins;
• HTTP logs;
• server-panel logs;
• firewall rules;
• IP addresses related to the attack;
• persistence mechanisms;
• file and directory permissions.

We did not only review the website. We also checked the environment hosting it and the possible routes for re-entry.

How we recovered and secured the installation

After reconstructing the incident, we applied several measures:

• reinstalled the official WordPress core;
• replaced modified plugins;
• removed the backdoors;
• reviewed administrator accounts;
• closed active sessions;
• changed credentials;
• blocked the IP addresses involved;
• restricted access to the administration panel;
• reviewed the server configuration;
• strengthened the firewall;
• checked that no modified files or persistence mechanisms remained.

The goal was not only to bring the website back online. We also wanted to close the routes used during the attack and reduce the risk of it happening again.

What we learned

The investigation confirmed something we often see when working on clients’ websites: a security incident does not necessarily end when the most visible malicious file disappears.

The difference lies in being able to answer specific questions:

• How did the attacker get in?
• What permissions did they have?
• Which files did they modify?
• Were there other backdoors?
• Did they still have access?
• Which part of the infrastructure needed strengthening?

In our case, the analysis helped us add new measures to the security protocols we apply to the websites we manage.

Every incident we resolve for a client teaches us something. This one taught us even more because the client was us.

Are we embarrassed that we were attacked?

No.

We would be much more concerned if we had suffered an attack and had not been able to understand what happened.

Absolute security does not exist. Even an updated and protected installation can be compromised if an attacker obtains valid credentials.

What matters is having a procedure to detect the incident, preserve evidence, contain it and regain control.

Our infrastructure is now stronger because this attack forced us to review every layer: authentication, WordPress, the server, firewall, access controls and internal procedures.

That is why we decided to tell the story.

Not to claim that we are immune, but to show how we respond when a real incident happens.

Do you think your WordPress website has been hacked?

If your website redirects to strange pages, displays security warnings, loads unknown code or has created users you do not recognise, do not wait for the problem to get worse.

At Ibero Studio, we investigate compromised WordPress websites, analyse server logs, remove malware, close backdoors and strengthen the installation to reduce the risk of new attacks.

We do not simply delete suspicious files: we look for how the attacker got in and what needs to be corrected to genuinely regain control of the website.

Call or write to us and we will review your case. We will help you recover your hacked WordPress website and protect it against future intrusions.

I need to recover my hacked WordPress website