Service

Technical WordPress audit, Website recovery after a hack

Project

A corporate WordPress website of an international company in the hand protection products niche

Objective

– Remove malicious code, spam posts, hidden links, and backdoors, close vulnerabilities, and restore the website’s normal operation

Region

UK, Europe, USA

Challenges of the project

A corporate website is not just an “online business card.” For a B2B company, it often serves as an entry point for partners, distributors, customers, and potential employees. That means it needs not only to function properly, but also to be secure and fully under control. When a website starts living a life of its own, publishing casino content in different languages and hiding suspicious links in the code, it is no longer a “small technical issue.” It is a full-scale digital takeover that puts both the business and its reputation at risk.

This is exactly the kind of problem the RegisTeam team faced when this WordPress website came to us for a technical audit. In this case study, we explain what critical consequences of the hack we uncovered, how we removed the malicious code and closed the vulnerabilities, restored the admin panel to normal operation, and helped the client regain control over the website.

Our client is a leading international company specializing in hand protection products. The company sells its products both retail and wholesale and supplies them through a distributor network across multiple industries, including:

  • automotive
  • agriculture
  • manufacturing
  • cleaning
  • food production, and more

The company operates in the UK, the EU, and the US. In other words, the website is an important part of its presence across several markets.

The client came to us with a request for a technical review. Their corporate WordPress website was showing clear issues, and the goal was to understand what was going on and provide recommendations.

At first, it sounded like a standard technical audit. But we quickly realized this was not just a case of outdated plugins or “something broke after an update.”

The website had been hacked.

Project analytics

The main problem was obvious: the website was being used by attackers to publish third-party content.

In the Blog section, dozens and even hundreds of posts had appeared in different languages promoting online casinos. And these were not one-off publications — they were being posted with the kind of persistence usually reserved for someone trying to win a “Spam of the Year” award.

On top of that, the site contained hidden and spammy links pointing to external resources. This is a typical Black Hat SEO scheme: attackers exploit the authority of someone else’s website to promote unrelated third-party projects.

Simply put, the client’s website had been turned into a donor for someone else’s SEO game. Only the client never asked for that, never agreed to it, and definitely did not plan to turn their corporate blog into an international casino fan club.

Critical issues that had to be addressed first

After the initial analysis, we identified several critical areas that required immediate attention.

1. The website had been hacked and was being used to publish spam

The blog was flooded with casino-related posts. This was damaging not only the appearance of the website, but also the reputation of the domain.

For search engines, this kind of activity is a clear red flag. If a website publishes junk content, contains suspicious links, and points to questionable resources, it can affect trust in the domain, indexation, and organic visibility.

2. The website contained spammy links

We found links pointing to third-party resources, including casino websites and other suspicious domains. They had been hidden in widgets, page content, and serialized JSON data inside Elementor meta fields.

A particularly unpleasant detail is that links like these are often invisible to a regular user. On the surface, the page may look completely normal, while in the code the website is already functioning as free advertising space for attackers.

3. There were signs of hidden hacker access

The initial analysis showed the presence of a hidden administrator account with the username wpadminyu.

We also found an AdminConcealer script that was hiding this account from the admin panel. In other words, a user with full administrator rights existed, but could not be seen through normal means.

It was like having someone in the office with keys to every room, but no trace of them on the employee list. Convenient — just not for the business owner.

4. Malicious code was blocking updates and changes

We found signs of code on the website that disabled file editing and updates from the WordPress admin panel through DISALLOW_FILE_MODS.

We also identified the following filter:

add_filter(‘site_transient_update_plugins’, ‘__return_false’)

It disabled plugin update notifications, so the site owner would not see that the plugins were outdated and would not patch the vulnerabilities.

This is one of the typical post-hack scenarios: attackers do not just gain access — they try to keep it for as long as possible.

5. The website contained suspicious directories and files

Inside the wp-content/plugins folder, we found suspicious directories:

  • pwnd
  • prewdview-domwain

The hello.php file also raised concern. It had been rewritten from the standard Hello Dolly functionality into malicious code functioning as a backdoor.

Elements like these are often signs of web shells — scripts that allow attackers to upload files, execute commands, or restore access to the website even after a partial cleanup.

Why you cannot just delete “suspicious files” and call it a day

When a WordPress website is hacked, the biggest mistake is treating the symptoms instead of the cause.

Deleting a couple of suspicious files is not enough, because malicious code and attacker access can be hidden in:

  • theme files
  • plugins
  • the database
  • cron jobs
  • widgets
  • WordPress autoload data
  • old site copies
  • cache
  • hidden users
  • SSH keys
  • modified access permissions

Sometimes a backdoor does not look like an obvious malicious file at all. It can appear as a fragment of code disguised as a normal function.

That is why the task was not simply to clean the website, but to carry out a full-scale recovery process: identify the vulnerabilities, remove malicious elements, close re-entry points, and restore the normal operation of the system.

Work plan

We built a task list across several areas. Below is a brief overview of the main directions.

Access review

We needed to check:

  • all FTP accounts
  • SSH and SFTP access
  • user roles
  • hosting-level access
  • cron jobs
  • suspicious keys and system records

Hidden admin search

We separately checked for the wpadminyu account and for any code that could be hiding it from the admin panel.

We also reviewed the database for third-party users and suspicious records.

Malicious code cleanup

We paid special attention to the following directories:

  • wp-content/plugins
  • wp-content/cache
  • wp-includes

We checked suspicious files, empty folders, old copies, and directories with names like old, bak, and _bak.

Folders like these are often used for concealment. At first glance, they may look like old backups, but in practice they are a convenient place to hide a backdoor.

Restoring the normal operation of the website

After the cleanup, it was important not just to confirm that there were no obvious signs of malware left on the site. We also needed to make sure the resource was once again stable and secure: that new pages and blog posts could be published, media files could be uploaded, plugin updates were visible, the admin panel worked properly, and the blog no longer contained spam content.

We also placed special focus on preventing a repeat hack. We did not stop at closing only the vulnerabilities that had already been exploited. We also checked for and fixed other potential risk points:

  • updated access credentials
  • protected critical files
  • removed suspicious directories
  • blocked the execution of malicious code through uploads
  • strengthened security at the file, database, and hosting levels

The goal was not just to “clean the site,” but to return control of the resource to the owner and reduce the risk of future compromise.

Team actions

The work was carried out as a full-scale recovery process – at the hosting level, across website files, in the database, inside the WordPress admin panel, and within the security system.

We removed suspicious access and updated passwords

We deleted all FTP users from the hosting account and changed the SSH/SFTP passwords.

We also identified access rights assigned to two unidentified users at the hosting level. Since we could not confirm that these were legitimate accounts, their access was revoked.

After that, we updated the credentials for all users who remained in the system.

We removed junk directories and a compromised SSH key

In the root hosting directory, we found folders that were not needed for the website to function. Elements like these are often left behind intentionally as a way to regain access later.

We also removed an SSH key from the files. Based on our initial assessment, it may have been compromised.

We cleaned the database of malicious links and records

In the database, we found a large number of infected widgets containing malicious links, for example:

  • heylink.me/officialpion138
  • pusat777official.hair
  • mez.ink/pusat777

Most of the malicious load was found in entries related to:

  • widget_block
  • sidebars_widgets[footer-1]
  • customize_changeset auto-drafts

We ran a global search and removed mentions of hacker nicknames, email addresses, and malicious links. We also cleaned suspicious records from registration logs and notification data.

We removed hidden and malicious files

The following items were removed:

  • public/wp-includes/SimplePie/library/SimplePie/york.php
  • public/wp-content/plugins/hello.php
  • wp-content/plugins/pwnd
  • wp-content/plugins/prewdview-domwain
  • public/wp-content/cache-OLD/
  • public/wp-content/cache/

We classified the york.php file as a backdoor. The pwnd and prewdview-domwain folders were also removed as traces of malicious activity.

We cleaned the infected files

The following files were cleaned:

  • public/wp-config.php
  • public/wp-content/themes/twentytwentyone-child/functions.php

This was an important step, because files like these are often used to inject malicious code. They are loaded together with the website and can perform hidden actions without any visible signs for the user.

We removed hidden spam SEO links

We found and removed a hidden HTML block with display:none that linked to replica watch websites:

  • thecomedypub.co.uk
  • tickwatchtock.co.uk
  • watchesfromme.co.uk

These links had been deeply hidden inside Elementor JSON settings in _elementor_data and in page content within the wp_posts table.

This is a good example of why a surface-level website check is not enough. Visually, the page may look completely normal, but underneath it can be running an entire underground shopping mall of spam links.

We rotated the Security Salts

We regenerated the authorization keys in wp-config.php.

This was a critically important step. After rotating the Security Salts, all active user sessions became invalid. Even if an attacker had still been logged in at the moment the password was changed, their cookies would stop working.

Without this step, changing the password alone might not have had an immediate effect.

We removed a suspicious theme and old website archives

We removed a suspicious placeholder theme called wl4r55n0, which was being used as a hidden backdoor, and also deleted the ai1wm-backups directory containing old full website archives.

This was especially important because archives like these may contain:

  • database dumps
  • configuration files
  • credentials
  • technical information
  • the site structure

If such an archive is accessible through a direct link, an attacker can compromise the website again. A simple analogy would be leaving the office keys under the doormat and then being surprised that someone is playing casino games in the meeting room again.

We carried out a large-scale cleanup of spam blog posts

We removed more than 500 casino-related posts that had been published by the attackers over time. We also identified and deleted spam blocks containing links to casino websites. After the cleanup, the blog section once again looked normal and matched the purpose of a corporate website.

We restored plugin update visibility

After the malicious code was removed, plugin updates started showing up in the admin panel again. This was an important result, because hiding updates is one of the common ways to keep a website in a vulnerable state. When the site owner cannot see that a plugin needs to be updated, potential security gaps remain open.

We fixed file permissions

On the server, we found overly permissive access rights on website files where that level of access was not needed. This allowed unrelated processes or users on the server to view the contents of critical files.

We tightened permissions for configuration files, especially wp-config.php, which contains the database connection details. Access is now configured according to the principle of least privilege, blocking one of the common vectors for reinfection.

This is a basic but very important security measure. Even a perfectly cleaned website can be hacked again if configuration files are open to “anyone who feels like it.”

We added protection against PHP execution in the uploads folder

We created an .htaccess file in the public/wp-content/uploads/ directory with the following rule:

<Files *.php>
Order Allow,Deny
Deny from all
</Files>

This protection blocks the execution of PHP files inside the uploads folder.

Why does this matter? If an attacker tries to upload a malicious PHP script disguised as an image or document, the server will not be able to execute it. The uploads folder remains a place for storing static files, not a launchpad for backdoors.

Additional issues we discovered after the cleanup

After the main malicious activity was removed, we continued auditing the website and uncovered several additional problems.

1. Publishing pages and uploading media files

The website had lost the ability to publish new pages and posts, as well as upload media files.

The first cause was related to Sucuri: the security system was blocking the WordPress REST API. We disabled the option that was interfering with the website’s normal operation and added filters that allowed the site to function correctly again.

*Sucuri is a WordPress security plugin.

2. Damaged database structure

The next issue ran deeper. The database structure had been damaged, most likely because the attackers had made aggressive changes while injecting malicious code directly into it.

We wrote and applied a custom corrective SQL script. It scanned 9 core WordPress tables, including:

  • wp_posts
  • wp_postmeta
  • wp_users
  • wp_options, and others

The script reassigned the correct Primary Key and AUTO_INCREMENT relationships. As a result, the table structure was restored to a normal WordPress state.

3. Saving products

We also fixed the issue that was preventing products from being saved. The cause turned out not to be WooCommerce itself, but the lack of free disk space on the hosting account.

And that led us to another major problem.

Why did the database grow to 55 GB?

During the work, we discovered that the website’s database had grown to 55 GB. The main reason was WooCommerce Action Scheduler — the built-in scheduler responsible for background store tasks.

Two tables were taking up almost all of that space:

  • wp_actionscheduler_logs — 46,595 MB
  • wp_actionscheduler_claims — around 800 MB

What happened?

Because the core WordPress tables had a damaged structure, the store’s background tasks kept failing with critical database errors. The scheduler kept trying to restart them again and again, logging every failure in the system records. As a result, within a relatively short period, the website accumulated around 47 GB of logs and temporary lock data.

It is important to note that these tables did not contain orders, products, or store settings. They stored only technical logs and temporary data. That is why we fully cleaned them, freed up disk space, and restored the website’s ability to function normally.

An attempted return after the backdoor was closed

During the work, we also saw in Sucuri that the attackers tried to regain access to the website through a backdoor we had already closed. Since the vulnerability had been removed, the attempt failed. In practice, they were simply knocking on doors that no longer existed.

This is an important point: after a hack, it may seem that once the malicious files are deleted, the problem is solved. But in reality, attackers often come back and test whether any working entry points are still left.

That is why comprehensive protection after cleanup is not an extra option — it is a required part of the job.

Results

As part of the full website cleanup and recovery process, our specialists:

  • removed hidden and suspicious accounts
  • closed unidentified access points at the hosting level
  • changed SSH, SFTP, and user passwords
  • removed malicious files and directories
  • cleaned infected wp-config.php and functions.php files
  • cleared the database of malicious links and records
  • removed hidden spam SEO links from Elementor and wp_posts
  • deleted more than 500 casino-related posts
  • restored the blog to its normal state
  • brought back plugin update visibility
  • fixed access permissions for critical files
  • removed old website archives that could have been used for reinfection
  • added protection against PHP execution in the uploads folder
  • restored the ability to publish pages and posts
  • restored media uploads
  • repaired the damaged database structure
  • cleaned oversized WooCommerce Action Scheduler tables
  • freed up hosting space
  • blocked an attempted return through a previously closed backdoor

As a result, the website is now running stably again and continues to serve as an effective business tool, while the client has regained full control over it.

What website owners need to understand

A hacked website does not always look like a black screen saying, “You’ve been hacked.” Sometimes the site keeps working, opens normally, accepts orders, and looks almost fine on the surface.

But underneath, things may be happening that seriously harm the business:

  • spam content is being published
  • hidden links appear
  • hidden users are created
  • updates are disabled
  • the database gets damaged
  • technical logs keep growing
  • the domain’s reputation suffers
  • attackers retain the ability to come back

That is why website maintenance is not just about “updating a plugin once a month.” It is about ongoing control over security, access, files, the database, hosting, and the overall behavior of the website.

Summary

In this project, we were dealing not with a single issue, but with a whole chain of consequences caused by the hack: a hidden administrator, malicious code, backdoors, spam posts, SEO links, a damaged database, hosting overloaded with logs, and even an attempted return after cleanup.

The RegisTeam team carried out an in-depth technical analysis, eliminated the vulnerabilities we found, cleaned the website of malicious code, and restored the normal operation of WordPress.

The main takeaway is simple: if a website starts behaving strangely, it is better not to wait until the corporate blog fully turns into a casino branch office. The earlier a technical audit is carried out, the lower the risk for the business, SEO performance, and brand reputation.

Want to make sure your website belongs only to you – and is not being used by attackers for their own shady purposes? Contact us today. We will run a full technical check and, if needed, remove the unwanted guests with no chance of a comeback.