Operations
TYPO3 Compromised: The First Hours Decide
An incident is unpleasant but manageable. What makes it expensive are the first few moves: restoring a backup right away erases the traces and brings back the very hole the attacker came through.
How an incident becomes visible
Very few attacks announce themselves with a ransom note. The typical signals are quieter: the host reports outgoing spam, the site suddenly appears in search results with foreign text, the browser warns visitors, or accounts show up in the backend that nobody created.
Technical traces give it away too. Files ending in .php inside the upload directory have no business being there. A log file that grew overnight, or database records with embedded script code, point in the same direction.
Timing matters here. The moment of the first odd behaviour is rarely the moment of the break-in. Weeks of undetected access often lie between the two.
The order that limits the damage
Preserve the state before changing anything. A full copy of files and database, plus server and access logs while they still exist. That copy is the only basis for finding the cause, and for your insurer if it comes to that.
Take the site out of circulation. A static maintenance page is enough. The installation itself stays untouched.
Lock the accounts. All backend accounts, FTP and database credentials, API keys and hosting panel logins. Passwords reused elsewhere have to be changed everywhere, not only here.
Narrow down the timeframe. File modification timestamps and access log entries together usually produce a usable window. Only with that window can you judge which backup is still clean.
Find the point of entry. Clean-up comes after that. Skipping this step means rebuilding the installation and waiting for the repeat performance.
Where the cause usually sits
Three routes lead inside in practice. An outdated extension with a known, published vulnerability is the most common. A compromised account is the second, often through password reuse or an infected workstation. The third is the server environment itself, an outdated PHP version or a neighbouring project on the same account.
The TYPO3 core is rarely the entry point. That is down to the work of the Security Team, and to attacks going where things are easier. How to keep the inventory small in the first place is covered in evaluating extensions.
Getting back into operation
An installation is clean once core and extensions come from a trustworthy source, content comes from a verified database, and the hole that allowed access is closed. Comparing against an untouched state from version control makes this step considerably faster.
Then comes the unglamorous part: reissue credentials, set up a second factor for administrator accounts, move the installation to a version that still receives support. The version overview shows which ones those are.
Finally, check your visibility. Search engines and browser warning lists do not take a site off their lists by themselves; they do it after a renewed review. Forget this and you have a clean site that nobody visits.
What makes the next incident unlikely
After the clean-up is the best moment for the questions nobody wanted to ask before. Who receives security advisories, and how quickly do they get applied? How often is a backup actually restored as a test? Who has access, and who no longer needs it?
The preventive side of those questions is covered in securing TYPO3. How ongoing care handles this day to day is described under TYPO3 maintenance.