How We Recovered a Hacked WordPress E-Commerce Website

A WordPress e-commerce website faced a recurring and frustrating problem. The website would suddenly stop working and display a 403 Forbidden error.

Restoring a previous backup brought the website back online. However, the fix only lasted for several hours or days. The same error returned even though nobody had made any visible changes.

At first, the problem looked like a hosting or server configuration issue. After a deeper investigation, we traced it to an active malware infection inside the WordPress installation.

In this case study, we explain how we investigated the incident, identified suspicious files, removed confirmed malware, and started securing the website against reinfection.

Project Overview

The affected website was an active WordPress and WooCommerce store.

It depended on several important components, including:

• WooCommerce
• Elementor
• LiteSpeed Cache
• Shipping integrations
• SEO plugins
• Security plugins
• A commercial WordPress theme

Because the website processed real customer activity, every period of downtime could affect customer trust, orders, and revenue.

The Main Problem

The website repeatedly displayed the following message:

403 Forbidden — Access to this resource on the server is denied.

Initially, we considered several possible causes:

• Incorrect file permissions
• A corrupted .htaccess file
• ModSecurity restrictions
• A blocked IP address
• A security plugin conflict
• A caching problem
• A hosting configuration issue

However, one detail changed the direction of the investigation.

Restoring a backup fixed the website temporarily, but the problem returned later without any manual changes. Therefore, we suspected that something inside the website was automatically modifying or recreating files.

Initial WordPress Health Check

First, we reviewed the WordPress Site Health report.

The website passed checks related to:

• PHP version
• HTTPS
• REST API
• Scheduled events
• Background updates
• Page caching
• Database connectivity
• PHP modules
• File uploads
• Communication with WordPress.org

These results confirmed that WordPress generally worked correctly while the website remained accessible.

However, Site Health could not explain the recurring 403 error. The problem did not come from a standard WordPress configuration warning.

Malware Scanner Findings

Next, we reviewed the hosting malware scanner.

The scanner detected 25 affected files.

According to the report:

• It removed 24 malicious files.
• It cleaned one compromised file.
• Some malicious files appeared more than once.
• Malware repeatedly infected the main index.php file.
• Attackers had modified the .htaccess file.
• Suspicious PHP files appeared inside WordPress core directories.
• Hidden folders contained malicious files.
• Some folders used names that resembled legitimate plugins.

These findings confirmed that the website did not have a simple configuration error. It had an active WordPress malware infection.

Why the Website Kept Returning a 403 Error

A server may return a 403 error when access rules deny visitors permission to open specific files or directories.

During our investigation, we found that compromised files and malicious access rules could modify the website configuration.

The infection targeted important areas such as:

• index.php
• .htaccess
• WordPress administration files
• WordPress core folders
• Upload directories
• Cache directories
• Language directories

In addition, the automatic malware scanner sometimes removed an infected index.php file. Because WordPress needs this file to load the website, removing it could make the website inaccessible.

As a result, the website sometimes stopped working immediately after an automated malware scan.

Backup Investigation

The malware history showed detections going back several weeks.

Therefore, we could not assume that recent backups were clean.

A backup may restore the website successfully while still containing:

• Hidden backdoors
• Obfuscated PHP files
• Malicious scheduled tasks
• Compromised plugins
• Modified WordPress core files
• Unauthorized database entries

We identified the latest backup created before the first visible malware detection as the safest available option.

However, we still needed to inspect the backup manually before trusting it.

Manual File Inspection

After reviewing the backup history, we manually inspected files inside the website’s root directory.

We reviewed each file to determine whether it was:

• A legitimate WordPress file
• A hosting-related file
• A security plugin file
• An unnecessary file
• A suspicious file
• A confirmed malicious file

Legitimate Files

We reviewed several important files and found no obvious malicious code in:

• The current WordPress index.php
• The current wp-config.php
• The active .htaccess rules
• The security plugin bootstrap file
• The hosting configuration file inside a protected directory

These files did not contain obvious obfuscation, suspicious execution functions, or unreadable code.

Unnecessary Files

We also found files that were not malicious but were unnecessary inside the public website directory.

These included:

• An old Hostinger default page
• A PHP file used only to reset OPcache
• An old .htaccess backup

Removing unnecessary public files reduces confusion and limits the number of files that attackers may abuse.

Confirmed Malicious Files

One compressed file contained heavily obfuscated PHP code.

The code used:

• Multiple goto statements
• Encoded character sequences
• Extremely long hidden strings
• Unreadable execution logic

Attackers commonly use these techniques in WordPress backdoors and web shells.

We also found a text file that contained encoded information referencing a suspicious PHP file inside a misleading plugin path.

We removed both files immediately.

Hidden Directory Inspection

We also reviewed hidden directories because the malware report showed infections inside them.

Some hidden folders belonged to the hosting provider and were legitimate. However, other folders contained structures designed to hide malicious index.php files.

For example, one suspicious .htaccess file denied access to most PHP files while allowing access to one specific index.php file.

This configuration could help an attacker hide a backdoor while keeping the malicious entry file accessible.

After verification, we removed directories directly connected to confirmed malware detections.

Plugin Review

Next, we inspected the WordPress plugin directory.

We looked for:

• Unknown plugins
• Fake plugin folders
• Misspelled plugin names
• Duplicate plugins
• Abandoned plugins
• Plugins installed from unofficial sources

The visible folders appeared to belong to known WordPress plugins.

However, a legitimate folder name does not prove that every file inside it is clean.

Therefore, after confirming a malware infection, the safer approach is to remove and reinstall plugins from trusted or licensed sources instead of relying only on folder names.

Security Actions Taken

The recovery and hardening process included several actions.

Removing Malicious Files

We removed confirmed malicious archives, encoded text files, hidden backdoors, and suspicious directories.

Verifying WordPress Core Files

We reviewed important WordPress files and prepared to replace the core directories with files from a clean official WordPress package.

Reviewing Plugins and Themes

We reviewed the installed plugins and themes and planned clean reinstalls from official or licensed sources.

Reviewing the Security Configuration

The website continued using All In One WP Security as its main WordPress security plugin.

We reviewed its configuration carefully because enabling several aggressive firewall rules at the same time can create conflicts and cause additional 403 errors.

Rotating Passwords

We recommended replacing the following credentials:

• Hosting account password
• WordPress administrator passwords
• FTP or SFTP passwords
• Database user password
• Administrative email password

Replacing WordPress Security Keys

We replaced the WordPress authentication salts and security keys.

This action invalidated existing login sessions and forced users to authenticate again.

Reviewing User Accounts

We checked all WordPress administrator accounts for unknown or unauthorized users.

Disabling Dashboard File Editing

We disabled file editing from the WordPress dashboard to reduce the risk of unauthorized changes to plugin and theme files.

Enabling Activity Monitoring

We recommended using an activity log to monitor:

• Administrator logins
• Plugin installations
• Plugin activations
• User creation
• Settings changes
• Theme modifications

Tools Used During the Investigation

We used a combination of automated and manual tools:

• Hostinger Malware Scanner
• Hostinger File Manager
• WordPress Site Health
• All In One WP Security
• Manual PHP file inspection
• WordPress user and plugin review
• Backup history comparison
• Hosting access logs
• Server error logs

Automated scanners helped us locate infected files quickly. However, manual review remained necessary because scanners cannot always identify the original entry point or distinguish every legitimate custom file from malicious code.

Important Lessons From This Case

Restoring a Backup Is Not Always a Permanent Fix

A backup may restore the website and the malware at the same time.

Therefore, you must compare backups with the infection timeline before treating them as safe.

Removing Detected Files Does Not Close the Vulnerability

Deleting malware removes the visible files, but it does not necessarily remove the original vulnerability.

If the entry point remains open, attackers may reinfect the website.

Hidden Folders Require Inspection

Attackers often hide malicious files inside:

• Upload directories
• Cache directories
• Language folders
• Fake plugin folders
• Hidden directories
• WordPress core subdirectories

File Names Can Be Misleading

Malicious files may use names related to:

• Elementor
• LiteSpeed
• WPForms
• Envato
• WooCommerce
• WordPress core files

Therefore, a familiar file or folder name does not guarantee that it is legitimate.

Too Many Security Plugins Can Create New Problems

Using several firewall plugins at the same time may cause:

• Conflicting .htaccess rules
• False-positive blocking
• Repeated 403 errors
• Higher server load
• Difficult troubleshooting

In most cases, one properly configured security plugin works better than several overlapping systems.

Current Status

We identified and removed the known malicious files.

In addition, the main WordPress configuration files reviewed so far appeared clean.

However, the website still requires monitoring to confirm that:

• Malicious files do not return
• The .htaccess file remains unchanged
• Malware does not modify index.php again
• No unknown administrator accounts appear
• Malware scans continue to return clean results
• The website remains stable
• The 403 error does not return

We should only consider the website fully recovered after a monitoring period with no signs of reinfection.

Final Conclusion

This case shows that recurring WordPress downtime does not always result from poor hosting performance or a server configuration problem.

When a website works after restoring a backup but fails again later, it may contain an active backdoor, a compromised plugin, or malicious files that automatically recreate themselves.

Therefore, proper WordPress recovery requires more than restoring a backup.

It requires:

• Reviewing the malware timeline
• Inspecting files manually
• Removing hidden backdoors
• Replacing WordPress core files
• Reinstalling plugins and themes
• Changing all credentials
• Reviewing administrator accounts
• Monitoring the website after cleanup

At Digital Squid, we approach WordPress recovery by identifying the cause of the problem instead of only restoring temporary access.

A stable website is not simply a website that works today. It is a website that remains secure, monitored, and maintainable over time.