Joomla Website Hacked: What To Do, Step by Step

2. The First Hour: Contain the Damage

2.1 Take the Site Offline

As long as the site is reachable, it keeps harming visitors, keeps sending spam, and keeps collecting search-engine penalties. Switch it off.

The best method depends on how bad it is:

Joomla's own offline mode is the weakest of the three. It stops normal visitors, but a backdoor placed in a PHP file is reached directly by URL and never asks Joomla whether the site is offline. If you suspect a webshell, block at the server level.

If you have shell access, the fourth option is the one I reach for, and the one I used on my own hacked site (section 4.6), because it is the only method that contains the incident and protects the evidence in the same move:

mv public_html public_html.hacked
chmod 700 public_html.hacked
mkdir public_html
printf '<h1>Temporarily unavailable</h1>' > public_html/index.html

The compromised site is now unreachable from the web, including every webshell in it, because the web server user can no longer enter the folder. Nothing has been deleted, so every file and every timestamp survives for phase 2. Visitors get a plain static page that involves no PHP at all, which means no Joomla, no extensions, and nothing left for an attacker to call.

Check afterwards which user your PHP actually runs as. If PHP runs as the same account that owns the files, 700 still permits access; in that case move the folder outside the web root entirely, or take the site down at the hosting level.

2.2 Preserve the Evidence Before You Change Anything

Before you touch a single file, make a complete copy of the compromised state: all files and a full database dump. Label it clearly as infected and store it outside the web root, ideally off the server entirely.

This copy is not a backup you will ever restore. It is your evidence. You need it because:

• File timestamps and log entries disappear as soon as you start cleaning.
• You will want to compare the infected files with clean ones to find every injection.
• If personal data was involved, you may have to explain later what happened and when.
• If you clean too aggressively and break something, you can still look up how it was.

Copy the files with a method that keeps modification times intact. On the command line, rsync -a or tar preserve them; a drag-and-drop through some FTP clients does not.

2.3 Tell Your Host

Contact your hosting provider early, even if you plan to fix everything yourself. Two reasons: their server logs usually go back further than what you can see in your own account, and a compromise sometimes starts outside your site - in a neighbour account, in a stolen control-panel password, or in a server-level vulnerability. Your host is the only party who can check that.

Ask them specifically for the raw access logs of the last few months, the FTP and SSH login history for your account, and whether they see the same infection pattern on other accounts.

Sometimes the conversation runs the other way, and the first you hear of the hack is an email from someone else. Security organisations scan for defaced and malicious pages and report them to the hosting provider and to the domain registry. For .nl domains, for example, Netcraft reports findings to SIDN, the registry that manages the zone. Your host may forward such a report, or send their own.

Treat those messages as urgent, because they usually carry a deadline and real consequences: hosting providers suspend accounts, and a registry can suspend the domain name itself if nobody responds. Reply straight away to say you are working on it, even before you have fixed anything. A reported site that answers is treated very differently from a reported site that stays silent, and you will need to report back once it is clean (section 9.6).

2.4 Do Not Restore a Backup Yet

Restoring last night's backup feels like the fastest fix, and it is the most common early mistake. Two things usually go wrong:

• If the site was compromised weeks ago, last night's backup contains the backdoor too. You restore the hack.
• Even a genuinely clean backup goes straight back to the vulnerable state that let the attacker in. Without the update or the password change, you are reinfected in days.

A backup restore is part of phase 4, after you know when the break-in happened and what caused it. Not before.

2.5 Stop the Site From Sending Mail

If the site is being used to send spam, every extra hour damages your domain reputation and pushes you further onto blocklists. Getting a domain delisted takes far longer than the hack does.

Joomla has a single switch for this: set Send Mail (mailonline) to No under System → Global Configuration → Server → Mail Settings. It is on by default, and turning it off stops Joomla from sending anything at all - including your own contact forms, so this is a deliberate temporary measure.

Be aware of the limit, which is the same limit as the offline mode: this stops Joomla from sending mail. Malware that calls PHP's mail() directly, or talks to an SMTP server itself, does not go through Joomla and ignores this setting completely. If the spam continues after you flip it, the sender is a file, not Joomla, and you need the server-level block from section 2.1 plus your host's help with the mail queue.

2.6 Assume the Neighbours Are Affected Too

If several websites live in the same hosting account, treat all of them as compromised from the start, not just the one where you noticed something. Where all sites run as the same Unix user, code running in one of them can usually read and write the files of the others, so the infection spreads sideways without any second break-in.

That changes your first hour: take stock of every site in the account, check each one for the signals in section 1.2, and plan the clean-up for the whole account at once. Cleaning them one at a time, while the others stay infected, means the first site you finish gets reinfected while you work on the second.

4. Find Out How They Got In

4.1 The Joomla Action Log

The User Actions Log (com_actionlogs, fed by the System - User Actions Log plugin) is the first place to look. Open Users → User Actions Log. It records logins, extension installs, article and module changes, and configuration saves, with a user name and a timestamp. You can export the whole list to CSV from the toolbar, which is much easier to work through in a spreadsheet.

Two defaults are worth knowing before you rely on this log:

• IP logging is off by default (ip_logging in the component options). If nobody switched it on, your log tells you who and when, but not from where.
• API actions are not logged by default (loggable_api). Activity through the Web Services API leaves no trace in this log unless that option was enabled.

Both are switches to turn on today, while you are looking at the screen anyway. They cost nothing and they are exactly what you will wish you had next time.

There is one pattern in this log that people consistently overlook, because it does not look like an attack at all: a successful login by your own account, at a moment when you were not working. Everyone scans the list for unfamiliar user names. Nobody questions their own.

So check your own line. Compare every recent login of every administrator against where those people actually were, and confirm it against something independent - your browser history, your calendar, your phone. A login you cannot account for is one of the strongest signals in this entire article, and it says something specific: the attacker did not need your password. If your password still works and was never reset, they arrived with a stolen session, a leaked token, or a flaw that let them authenticate as you. Changing that password alone will not remove them, which is why section 3.2 and section 3.3 exist.

4.2 The Failed-Login Log

The System - Log plugin listens to the onUserLoginFailure event and writes every failed login attempt to a log file. By default that is error.php in your log folder (administrator/logs/ unless you moved it in the Global Configuration).

Read it for two patterns. Thousands of failures from many addresses is ordinary background noise from bots. A short burst of failures on one existing user name, followed by silence, is the interesting one: silence after failures often means they finally succeeded.

The plugin has a log_username option that adds the attempted user name to each line. Without it you only see that a login failed, not which account was targeted. Switch it on.

4.3 Server Access Logs

The web server log is where the actual break-in is usually visible, because it records requests that never reached the Joomla application layer. Ask your host for the raw logs, then look for:

• POST requests to files that should never receive a POST, especially anything under images/, tmp/, or media/.
• Requests to file names you do not recognise, particularly short random names ending in .php.
• Long, encoded query strings full of % escapes or base64-looking text.
• Requests to a known vulnerable component URL, for example index.php?option=com_something&task=... for an extension you have installed.
• The very first request from the IP address that later uploads files. That request is usually the exploit.

A practical trick: once you know the timestamp of the oldest malicious file, grep the access log for that exact minute. The request that created the file is almost always right there.

Expect to find more than one visitor. Once a site is broken into, the address often gets shared, and opportunists arrive to use the webshell somebody else installed. A second IP address appearing hours later, coming in from a social network and going straight to a file it could not possibly have guessed, is a familiar sight. It does not mean two separate break-ins; it means the first one was advertised. It does raise the urgency, because each newcomer does their own damage.

If you have root on your own server, check the authentication log as well, to establish whether the attacker ever got beyond the web application:

grep Accepted /var/log/auth.log     # successful SSH and SFTP logins
grep Failed   /var/log/auth.log     # brute-force attempts

Seeing only your own logins here is genuinely good news: it suggests the compromise stayed inside the web account and never reached the server itself. Note the limit, though, and be honest with yourself about it: if the attacker gained write access outside the web root, they could have edited this log. It is evidence, not proof, and on shared hosting you will not have it at all - ask your host instead.

4.4 File Timestamps

Modification times are the cheapest forensic tool you have. On a shell, list everything changed in the last two weeks:

find . -type f -name "*.php" -mtime -14 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

On a site that was not updated recently, this list should be almost empty. Cluster the results by time: file changes usually arrive in bursts of a few seconds, and the oldest burst marks the break-in.

Be aware that a careful attacker resets timestamps with touch to blend in. If the dates look suspiciously uniform, or a file's modification time is older than its inode change time (ls -lc versus ls -l), treat the timestamps as unreliable and lean on file comparison instead (section 5.1).

4.5 Build a Timeline

Write the findings down in one simple list, sorted by time: the first suspicious request, the first modified file, the new user account, the first spam page indexed. You are looking for the earliest event that has no innocent explanation. That is your break-in moment, and it answers two questions at once: which backup generation is still clean, and which vulnerability was open on that date.

Also check what your Joomla version and extension versions were on that date. Very often the answer is already there: an extension that had a known security release two weeks earlier and was never updated.

Then ask a second question, and ask it about yourself rather than about the software: what did I change shortly before that date and never change back? A surprising share of real incidents begins with a temporary measure taken while troubleshooting something entirely unrelated. Debug mode switched on to chase a mail problem. Error reporting set to maximum. A folder made writable "just for a moment". A test file uploaded to check something. Each is harmless for the ten minutes it was meant to last, and each is a real opening for the months it actually lasts, because the thing that ends the ten minutes is usually an interruption rather than a decision. Walk back through your own notes, your ticket history, and your mail from the weeks before the break-in.

The same reasoning explains how attackers find a site in the first place. Nobody targeted your small Joomla site by name; they searched for what it was leaking. Debug output, verbose error messages, and directory listings all contain distinctive text, and once a search engine indexes a page carrying it, that page becomes findable by anyone who knows what to search for. A referrer of https://www.google.com/ on the very first request from the attacker's IP address is the tell-tale here: they did not guess your domain, they were handed it by a search engine. Search your own domain for the strings your mistakes produce, and you will see roughly what an attacker sees.

4.6 A Worked Example: How This Played Out on My Own Site

The method above is not theory for me. In October 2022 the website of my own Joomla User Group, Arnhem-Nijmegen, was hacked, and my investigation ran exactly along these steps. It is worth walking through, because the site was three months old, ran only a handful of extensions, and was fully up to date. Being patched is necessary, and it was not sufficient.

The First Hour

I found out at a quarter past midnight, from an email. Netcraft, which reports findings to SIDN for the .nl zone, had discovered a defacement file on the domain and asked me to fix it or see the domain taken down. My VPS provider had been told as well, and warned me the whole VPS could be taken offline. That is the notification path from section 2.3, with the deadline attached.

Over FTP I found two files that we had never put there: Ox.php, the defacement, and sec.php, a backdoor with access to the filesystem and the database. I contained the site the way section 2.1 describes, moved it aside with restrictive permissions and served a static maintenance page. Then I archived the files, the database, and the logs and pulled them down to my own machine before touching anything. Then I went to bed, because an analysis needs a clear head and I had safequarded the evidence.

What the Logs Showed

The next day the database gave me the moment. #__action_logs showed a successful login for my own account on 12 October at 15:46. However, I had been nowhere near a computer at that moment; my browser history confirmed it. My password still worked and had never been changed. That is the pattern from section 4.1, and it told me straight away that this was not a guessed password.

With that timestamp I went into the access log. The attacker's IP address first appeared two minutes earlier, on an ordinary article page, with a referrer of https://www.google.com/. Searching Google for that page showed why: it was indexed with Joomla's debug output visible on it. They had not gone looking for my user group. They had gone looking for sites leaking debug data, and Google handed them mine.

The root cause was mine and it was mundane. A JUG meeting had been cancelled, the newsletter about the cancellation failed halfway through with SMTP authentication errors, and I switched debug mode on to investigate. The real fault turned out to be DNS: two mail. records with different IP addresses, one of them wrong. I fixed it, sent the newsletter, posted the cancellation, and forgot to switch debug back off. Exactly the never-reverted temporary change described above.

The log also showed a second, unrelated visitor arriving later that evening from a Facebook link, who used the existing sec.php to read configuration.php and walk off with the database and SMTP credentials. One break-in, two attackers, and the reason section 3.1 insists you assume everything in that file is public.

What Came Out of It

Because core Joomla looked involved, I sent everything to the Joomla Security Strike Team. They confirmed a real issue, and it became CVE-2022-27912, advisory [20221001] Core - Disclosure of critical information in debug mode, affecting Joomla 4.0.0 to 4.2.3 and fixed in Joomla 4.2.4 on 25 October 2022. Only then did I rotate every credential and restore a clean backup. A German colleague whose Joomla 4 site had been hacked months earlier turned out to have had debug mode on too.

The CVE record is assigned by the Joomla project and lists me as the finder. I mention that for one reason only, and it is the point of section 9.5 rather than a credential: I do not hunt for vulnerabilities and I did not find this one on purpose. I got hacked, kept the evidence, wrote down what I saw, and handed it to people who could analyse it. That was enough. If your own investigation ever points at core, your notes are worth more than you think.

Two things are worth carrying forward. That specific hole is closed: in current Joomla the debug AJAX handler checks both the user's authorisation and a valid session token, so it cannot be called the way it was in 2022. But the habit that exposed me is still available to everyone, because the debug plugin's Allowed Groups option ships empty, which means that with debug enabled the output is shown to whoever is looking. If you must debug on a live site, restrict that option to Super Users first, and switch debug off when you are done.

I wrote the full account up at the time in the Joomla Community Magazine, with the log lines and the timings: How my new Joomla 4 website got hacked. The Joomla User Group meeting that set the whole thing off, the one we cancelled because exactly one person besides the presenter had signed up, was rescheduled to 2 November. That one drew a full room. Alongside a Joomla migration talk, there was a short presentation by yours truly called "How the JUG website was hacked".

6. Clean or Rebuild?

Now you decide how to get to a trustworthy site. There are three routes, and the honest ranking is not the one most people hope for.

6.1 Restore a Clean Backup - Fastest

If your timeline (section 4.5) says the break-in was on the 14th and you have a full backup from the 10th, restoring that backup is the fastest and most reliable route. You get a known state, with no guessing about what you missed.

The cost is the content created between the 10th and today, which you have to re-enter by hand. That is a real cost, but usually a smaller one than an incomplete clean-up.

Never restore the backup on top of the infected files. Delete everything in the web root first, then restore. Otherwise the webshell that is not part of your backup simply stays where it is.

6.2 Rebuild on Fresh Files - Most Reliable

When no backup is old enough, rebuild the file side from scratch and keep only the database and your own content. It takes a few hours and it leaves nothing behind, because you never copy an unknown file forward. Section 7 describes the procedure step by step.

This is the route I recommend for any site where the timeline is unclear, and the only sensible route when the compromise is older than every backup you own.

6.3 Clean In Place - Last Resort

Removing malicious code from the existing installation is the most attractive option and the one that fails most often. It only works if you can enumerate every change the attacker made, and you can never be quite sure that you did.

Reserve it for small, obvious, freshly discovered infections where the timeline is short and complete. Even then, follow it with a full comparison against clean sources.

6.4 The Database Is the Hard Part

Whichever route you take, the database usually cannot be replaced, because it holds the content you want to keep. It has to be reviewed rather than rebuilt: the injected content of section 5.3, the accounts of section 3.4, the extension rows of section 5.4, and the scheduled tasks of section 5.5.

One structural check is easy to forget. Go to System → Manage → Database, where Joomla verifies that your table structure matches the schema of your installed version, and fix anything it reports. It will not detect malicious rows, but it does tell you whether the structure itself was tampered with or left half-updated.

8. Bring the Site Back Online

8.1 Block PHP Where It Does Not Belong

Almost every webshell in section 5.2 depends on one assumption: that a PHP file dropped into an upload folder will actually be executed when someone requests it. You can take that assumption away, and it is the single most valuable thing you can add while rebuilding.

Joomla does not do this for you. The shipped htaccess.txt blocks directory listings, sets nosniff, and stops scripts inside uploaded SVG files, but it contains no rule against running PHP in images/. You add that yourself, in an .htaccess file inside the upload folder:

<FilesMatch "\.(?i:php|phtml|php[0-9]|phar|inc)$">
  Require all denied
</FilesMatch>

On nginx the equivalent lives in the server block, because nginx does not read .htaccess files:

location ^~ /images/ {
    location ~ \.php$ { return 403; }
}

Apply it to every folder that receives uploads and never needs to run code: images/, your media folders, and any upload target of a form extension. Test afterwards that your site still works and that a test file is genuinely refused, then delete the test file.

This does not make uploads safe on its own - the attacker can still store the file - but it turns a working backdoor into an inert file sitting on disk, which is a very large difference.

Put the Rule Where the Attacker Cannot Reach It

There is a hole in the advice above, and it is better to say it out loud than to discover it twice. The rule sits in an .htaccess file, inside a folder the attacker can already write to. They can overwrite your file, or drop their own in a subfolder, which Apache reads last and therefore lets win. Section 5.8 shows the version used in the wild, where the attacker's block re-enables PHP for .json files.

The repair is to move the decision out of the document root, into the server configuration, where nothing an upload form touches can override it. In an Apache virtual host:

<Directory /var/www/example.test/images>
    AllowOverride None
    Options -Includes -ExecCGI
    <FilesMatch "\.(?i:php|phtml|php[0-9]|phar|inc|shtml)$">
        Require all denied
    </FilesMatch>
</Directory>

Options -Includes switches off Server Side Includes, which is the second route described in section 5.8: an .shtml file that Apache parses and acts on without PHP being involved. Joomla never uses SSI, so you lose nothing by turning it off.

AllowOverride None is the line that does the real work, and it is worth knowing why. SetHandler, AddHandler, and AddType all belong to Apache's FileInfo override class, so an .htaccess file can only change which handler runs a file when AllowOverride includes FileInfo. Shared hosting almost always ships AllowOverride All, which includes it. Switch it off for the folders that exist only to hold uploads, and the attacker's block becomes a comment. Because the setting is inherited, it covers the subfolders as well.

Note that AllowOverride None also disables your own .htaccess in that folder, which is why the FilesMatch rule moves into the same <Directory> block. Keep the folder-level .htaccess in place anyway as a second layer, for the day the site moves to a host that has not applied this.

If you cannot edit the server configuration yourself, ask your host for it. It is a small change on their side, and it is the difference between a defence you control and a defence your attacker can edit.

8.2 Test Before You Flip the Switch

Go through a short checklist before the site is public again:

• The homepage and the main templates render correctly, logged out.
• Test with a search-engine referrer and a mobile user agent (section 5.7). No unexpected redirect.
• View the page source of a few pages and search for script and iframe tags you do not recognise.
• Forms work, and outgoing mail arrives. Check the mail queue too: a queue full of messages you did not send means something is still sending.
• Scan the site with an external malware scanner, and let a second one confirm it. Treat both as detection tools, not as proof: signature scanners routinely miss custom or freshly modified malware, so a clean report is encouraging, not conclusive.
• No unknown Super Users, no unknown plugins, no unknown scheduled tasks.
• A test PHP file in images/ returns 403 and does not execute (section 8.1).

8.3 Reopen and Watch

Take the site out of offline mode and then keep watching for at least a month. Reinfection almost always happens quickly, because the attacker has automated scripts that check their old victims.

Set up the watch so it does not depend on you remembering:

• Enable the User Actions Log, now with ip_logging and API logging switched on.
• Enable the System - Log plugin with log_username, and read error.php weekly.
• Enable the Task - Update Notification plugin with the Task Scheduler, so you hear about updates by email.
• Connect Google Search Console and turn on its email alerts.
• Add an external uptime and content monitor that alerts you when the homepage changes unexpectedly.
• Take a fresh backup now - this one is your new clean reference point - and keep multiple generations from here on.

8.4 If It Comes Back

Reinfection within days means one of three things, in order of likelihood: you missed a backdoor, the original vulnerability is still open, or the compromise is not in your site at all but in the server, the control panel, or the computer you administer the site from.

Do not simply repeat the same clean-up. Go back to the timeline, and this time include the layers outside Joomla: scan the administrator's own workstation for information stealers, check for unknown SSH keys, and ask your host to look at the account from their side.

10. Under the Hood (Developer View)

10.1 Where an Attacker Hides in the Database

That last row is worth a second look. If #__update_sites points somewhere that is not the official Joomla or developer URL, every future "update" you install comes from the attacker.

10.2 A Practical Triage Toolkit

Four commands that answer most first questions:

# 1. What changed recently?
find . -type f -newermt "2026-07-01" ! -path "./cache/*" ! -path "./tmp/*"

# 2. PHP where PHP does not belong
find images tmp cache media -type f -name "*.ph*"

# 3. Obfuscation markers
grep -rn --include="*.php" -E "eval\s*\(|base64_decode|gzinflate|\\\$GLOBALS\[" . | head -50

# 4. Files that are writable by everyone
find . -type f -perm -o+w

A compromised site does not only receive traffic, it also makes connections: sending spam, fetching extra payloads, reporting to a command-and-control host, or mining. If you have shell access while the incident is live, look at what the server is doing right now:

ss -plant          # listening sockets and active connections
ps auxf            # process tree, including anything spawned by PHP
lsof -nP           # open files and sockets per process
mailq              # queued mail waiting to go out

Collect the output before you kill anything. A running process is evidence that disappears the moment you stop it, and the connection it holds open often identifies the infrastructure behind the attack faster than any file on disk.

If the site is in version control, you have a far better tool than any of these:

git status --porcelain
git diff --stat

Every unexpected line is a modified or added file, with no guessing involved. This is the strongest practical argument for keeping even small Joomla sites in Git: after an incident, "what changed" becomes a one-second question instead of a two-hour investigation.

10.3 Why the Site Secret Matters, Precisely

Joomla builds the session cookie name with md5($secret . $session_name), where $session_name falls back to the application class name. The API token plugins verify tokens with hash_hmac($algorithm, $rawToken, $siteSecret). So a single change to $secret ends all sessions and invalidates all API tokens at once, which is exactly what you want in the first minutes of an incident.

It is worth being precise about the limits, so nobody relies on it too much: passwords are bcrypt hashes and are unaffected, enrolled MFA methods in #__user_mfa keep working, and remember-me tokens in #__user_keys are stored per user agent and need their own clean-up.

10.4 Verifying a Cleaned Site

Do not trust your own eyes on this. Build a checksum list from a clean Joomla of the same version and compare:

cd /path/to/clean-joomla && find . -type f -name "*.php" \
  -exec sha256sum {} \; | sort -k2 > /tmp/clean.sha256

cd /path/to/site && find . -type f -name "*.php" \
  -exec sha256sum {} \; | sort -k2 > /tmp/site.sha256

diff /tmp/clean.sha256 /tmp/site.sha256

Everything that differs is either a legitimate customisation you can name, or something to explain. "I do not know what that file is" is not a passing result.

Two limits are worth knowing if you turn this into ongoing monitoring. A hash list only catches changed files, and most malware simply adds new ones, so compare the file lists as well as the hashes. And keep the reference data somewhere the web account cannot write - another server, or storage your PHP user has no access to. A checksum file that sits next to the site is a checksum file the attacker can regenerate.

12. SEO and Metadata

A hack is a search-engine problem as much as a technical one, and the damage often outlives the infection by months.

What typically happens: the attacker publishes hundreds of spam pages that get indexed under your domain, injects hidden links into existing articles, and serves different content to the Googlebot than to you. Google detects it, flags the site in Search Console, and may show a warning in the results. Rankings that took years to build drop within days.

The recovery order matters:

1. Clean the site properly first. A review request on a site that is still infected fails and costs you another waiting period.
2. Make the spam URLs return 404 or, better, 410 Gone. Do not redirect them to your homepage; that just tells Google the spam page moved.
3. Request a review under Security Issues in Search Console.
4. Check whether your domain landed on any mail or malware blocklists, and follow each delisting procedure.
5. Watch the indexed page count for a few weeks until the spam URLs are gone.

There is a preventive angle here as well. Search Console alerts are free and often reach you before your visitors do. A site that nobody monitors can serve spam for months before anyone notices, and the longer that lasts, the longer the recovery takes.

14. Best Practices

If you remember only a few things from this article, remember these:

• Contain first, investigate second, clean third. Never reverse that order.
• Copy the infected site and database before you change anything. It is your evidence and your safety net.
• Find the entry point. A clean-up without it is a delay, not a repair. Ask what you switched on while troubleshooting and never switched off.
• Check your own account's login times, not just the list of unfamiliar users. A login you cannot account for means they did not need your password.
• Change every credential, and change the $secret in configuration.php to end all sessions and API tokens at once.
• Empty the web root before restoring or rebuilding. Never clean around unknown files.
• Reinstall extensions and templates from their original sources, never from the hacked site.
• Review the database as carefully as the files. Custom modules and template parameters hide injections well.
• Look for the second and third backdoor: plugins, scheduled tasks, server cron, .htaccess, auto_prepend_file.
• Block PHP execution in upload folders, and block it from the server configuration with AllowOverride None, not only from an .htaccess file the attacker can rewrite. Joomla does not do this for you, and it disables most webshells.
• Block PHP execution in upload folders. Joomla does not do this for you, and it disables most webshells.
• Enforce MFA and update everything before the site goes public again.
• Rotate the credentials a second time once the clean site exists. The first round happened while the backdoor was watching.
• Watch the site closely for a month, and take a fresh backup as your new clean reference.
• Report a personal data breach within 72 hours. Tell your users plainly.
• If Joomla core was the way in, report it to the JSST instead of posting it publicly.
• Close the loop with your host and whoever reported the hack. An open abuse report can still cost you the account.
• Afterwards, fix the cause: the missing update, the weak password, the extension nobody maintains.

16. Summary

A hacked Joomla site is a bad day, not a lost site, provided you work in the right order:

• Contain before you clean. Block at the server level, and copy the infected state before you change a byte.
• Find the entry point. The action log, the failed-login log, the server access log, and file timestamps together give you a timeline, and the timeline tells you which backup is still clean.
• Lock the attacker out. Rotate every credential, change the site secret, and empty #__session and #__user_keys.
• Look for everything they left. Modified core files, webshells in upload folders, injected articles and custom modules, rogue plugins, scheduled tasks, .htaccess redirects, and auto_prepend_file.
• Prefer a rebuild over a clean-up when the timeline is unclear. Empty web root, fresh Joomla, fresh extensions, reviewed database.
• Come back carefully. Update everything, enforce MFA, test as a stranger would, and watch the logs for a month.
• Report what the law and decency require. Users, the supervisory authority within 72 hours if personal data was involved, the JSST if Joomla core was the way in, and a review request to the search engines once you are genuinely clean. Then close the loop with your host and whoever reported it.

The most useful thing to take away is that almost none of this is exotic work. It is patient, ordered checking: one list of accounts, one list of files, one list of database tables, and the discipline not to skip the investigation because the clean-up feels more productive.

If you are in the middle of an incident right now and the timeline will not come together (the logs are gone, the backups are all too recent, or the site keeps coming back) that is the point where a second pair of experienced eyes usually saves more time than it costs. Recovering a compromised Joomla site methodically, and finding the door that everyone else walked past, is exactly the kind of work a Joomla specialist does often enough to recognise the patterns quickly.