Support

Admin Tools

#43118 Summary of Our Cleanup and Recovery Process After a Joomla Compromise for all SPpagebuilder Users

Posted in ‘Admin Tools for Joomla!’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
6.1.1
PHP version
8.3
Admin Tools version
n/a

Latest post by nicholas on Sunday, 05 July 2026 15:22 CDT

fw611
For all of u guys that had a hard time because of this it might be helpfull to spread this information here aswell:


After recovering several compromised Joomla websites, I wanted to share the steps we took to successfully clean the systems. Hopefully this may help others facing a similar incident.

>>> Assume the attacker had full administrative access

Do not assume that removing a single malicious file is sufficient.

Perform a complete review of:

Joomla administrator accounts User groups and permissions Access control entries Installed extensions Database integrity 2. Remove all unauthorized administrator accounts

In our case, several unauthorized Super Users had been created.

Verify:

all administrator accounts user groups creation dates last login information

Remove every account you cannot positively identify.

Inspect the database

Besides users, also inspect permission-related tables.

Look for:

orphaned permission records suspicious assets unexpected ACL entries

Attackers may leave persistence mechanisms inside the database.

Restore Joomla core files

Do not rely on individual file cleaning.

Replace Joomla core files with fresh copies from the official Joomla release matching your installed version.

This ensures no modified core files remain.

Inspect uploaded files

Search your web space for:

unexpected PHP files alternative PHP extensions executable scripts in upload locations suspicious configuration files

Do not only search by filename—inspect file contents where necessary.

Remove malicious uploads completely

If an extension-specific upload directory was abused, remove all suspicious content.

If possible, rebuild that directory from a clean installation instead of trying to identify every malicious file individually.

Prevent code execution in upload directories

Where appropriate, configure your web server so uploaded files cannot be executed as PHP.

This significantly limits the impact of future upload vulnerabilities.

Rotate secrets and credentials

After any compromise:

change Joomla secrets change administrator passwords change hosting passwords rotate database credentials if appropriate review SSH keys and API tokens

Assume all credentials may have been exposed.

Review web server logs

Analyze access logs for:

exploitation attempts suspicious POST requests newly created users administrator logins unusual client IPs

This often reveals how the compromise occurred.

Verify the vulnerability has been patched

Cleaning a hacked site without fixing the original vulnerability only leads to reinfection.

Update:

Joomla all extensions all templates

Remove extensions you no longer use.

Create a clean backup only after verification

Do not restore from an unknown backup.

Only create a new backup after:

all malicious files are removed database has been verified administrator accounts have been checked logs no longer show successful exploitation 12. Continue monitoring

Even after cleanup:

monitor web server logs monitor new administrator accounts monitor file changes monitor extension updates

Most internet-facing Joomla sites continue to receive automated scans every day.

Final assessment

In our case, the original compromise was successfully removed.

Subsequent log analysis showed only:

automated vulnerability scanners bot traffic spam account registrations search engine crawlers AI crawlers

There was no evidence of a second successful compromise after the cleanup.

Search scripts used to track this mess can be requested via PN

nicholas
Akeeba Staff
Manager

I have written my own advice in https://www.akeeba.com/news/1784-what-to-do-after-and-before-your-site-got-hacked.html which is really just me rehashing the same advice I have been giving people for years.

A few things you mentioned and why they are not in mine:

  • Credential rotation. I consider that standard procedure after any suspected intrusion, long before you start doing any work. Maybe not obvious to everyone?
  • Web server log analysis. I agree it's the right way to do it. However, it requires some skill to do it that not all Joomla site owners have.
  • Database ACL / asset table inspection. Largely irrelevant if you restore a backup and work on it to clean up the site. Moreover, just the assets table is not enough. You can hide misconfiguration in the extensions table, or extension-specific tables. Unless you have intimate knowledge of both Joomla and every 3PD extension you are using, you're trying to complete a task with no defined limits.

Some important things in mine you're not doing:

  • Taking the site offline during cleanup. You don't want the attacker's bot to hack your site as you're cleaning it up.
  • Kicking out active sessions. Same as above.
  • Taking incremental backups during cleanup. My experience is that people tend to go very enthusiastic during cleanup, oftentimes reaping legitimate files in their panic to clean the site up.
  • Clearing cache and temp directories. Every hack we have seen tries to persist files in there.
  • PHP File Change Scanner. Makes it easier spotting the files you need to focus on instead of drowning into an ocean of 10,000+ files.
  • Clean restore path via backup. Your life is incredibly easier if you can restore a backup from before the time the site was hacked. It nullifies the need to go into the database.

I think that if you adapt your process to take into account the key steps I outlined above –especially considering restoring a backup first, taking the site offline, killing active sessions, and clearing the cache and temp directories– you have a very sound SOP for cleaning hacked sites. It just about describes what people doing that for a living will do on a site when you ask them to clean it up after a hack.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

fw611
Hi Nicholas,

i did a LOT more then that. But as u said: it requires some skill

i wrote scanner scripts, that also inspect the files itself , webshell checks and so on.

a full forensic of all Websites that got hit by the Pagebuilder "Zero Day".

Maybe a new set of RewriteRule s would make sense for those people who got hit.



nicholas
Akeeba Staff
Manager

If you are already hit you need to clean up. No RewriteRule will help you there.

You seem to have a basic misunderstanding, though. My instructions are not partial. They are complete. You do not need separate scripts to detect web shells; the PHP File Change Scanner already does. However, it excludes your site's log and temporary directory, the frontend and backend cache directories, as well as folders named tmp, log or logs in the frontend or backend of your site. That's why I tell you to empty those directories in my instructions and put the site off-line to ensure no new files will be added while you're scanning your site. You get to the same point you did, but with fewer steps and much less effort on your part because I already did the hard work for you.

If you are not hit yet, but can't update either there's a temporary solution I have described in https://www.akeeba.com/news/1785-protecting-old-sites-against-joomla-extensions-zero-days.html. Again, this looks deceptively simple. I had predicted this class of attack would come to bite us nearly 20 years ago. That's the reason I wrote UploadShield (and contributed it to Joomla), the .htaccess Maker's Frontend and Backend protection, and the WAF Deny Lists features.

Arbitrary file upload vulnerabilities are not new. They are a garden variety vulnerability. The reason we saw a wave of those exploits within a few weeks is that about ten days before that new AI models were released which excelled at ferreting out basic vulnerabilities like that. From there to exploitation it's minimal effort and skill – and even that can be outsourced to AI code assistants with a locally executed "jailbroken" model which doesn't complain when it's asked to write exploitation code. A used RTX 3090 with 24 GB VRAM is about 600 Euro and can do all of that analysis and exploit code generation in under a day, consuming around 5 kWh. In the past it would take someone with at least 5 years of very specialized experience a few days to weeks to do that. The bar to vulnerability discovery and exploitation has been reduced to practically nothing. You can expect a wave of security issues, many of which will have the form of a zero day, in the coming months. Software just got infinite eyeballs watching over it, and not all of them are benign.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!