Detect, Analyze and Repair a Hacked Site¶

Most websites do not get hacked. If yours did, there is something wrong with it, or with the server, or with the hosting environment, or with the security on your desktop computer, your editors' computers, etc. You have to figure out how this happened so you can prevent it from happening again. It is not enough to simply restore a hacked site – it will most likely be hacked again, sooner or later.

In case your server or TYPO3 website has been hacked, a number of steps should be taken to restore the system and to prevent further attacks. Some recommended actions are described in this chapter but always keep in mind: if you are already in the situation that you have to restore a hacked site, focus on the limitation of damage and do not react over-hastily.

Detect a hacked website¶

Typical signs which could indicate that a website or the server was hacked are listed below. Please note that these are common situations and examples only, others have been seen. Even if you are the victim of one of them only, it does not mean that the attacker has not gained more access or further damage (e.g. stolen user details) has been done.

Manipulated frontpage¶

One of the most obvious "hacks" are manipulated landing or home page or other pages. Someone who has compromised a system and just wants to be honored for his/her achievement, often replaces a page (typically the home page as it is usually the first entry point for most of the visitors) with other content, e.g. stating his/her nickname or similar.

Less obvious is manipulated page content that is only visible to specific IP addresses, browsers (or other user agents), at specific date times, etc. It depends on the nature and purpose of the hack but in this case usually an attacker tries either to target specific users or to palm keywords/content off on search engines (to manipulate a ranking for example). In addition, this might obscure the hack and makes it less obvious, because not everybody actually sees it. Therefore, it is not sufficient to just check the generated output because it is possible that the malicious code is not visible at a quick glance.

Malicious code in the HTML source¶

Malicious code (e.g. JavaScript, iframes, etc.) placed in the HTML source code (the code that the system sends to the clients) may lead to XSS attacks, display dubious content or redirect visitors to other websites. Latter could steal user data if the site which the user was redirected to convinces users to enter their access details (e.g. if it looks the same as or similar to your site).

See alse the explanations below Search engines warn about your site.

Embedded elements in the site's content¶

Unknown embedded elements (e.g. binary files) in the content of the website, which are offered to website visitors to download (and maybe execute), and do not come from you or your editors, are more than suspicious. A hacker possibly has placed harmful files (e.g. virus- infected software) on your site, hoping your visitors trust you and download/execute these files.

See also the explanations below Reports from visitors or users.

Unusual traffic increase or decrease¶

A significant unusual, unexpected increase of traffic may be an indication that the website was compromised and large files have been placed on the server, which are linked from forums or other sites to distribute illegal downloads. Increased traffic of outgoing mail could indicate that the system is used for sending "spam" mail.

The other extreme, a dramatic and sudden decrease of traffic, could also be a sign of a hacked website. In the case where search engines or browsers warn users that "this site may harm your computer", they stay away.

In a nutshell, it is recommended that you monitor your website and server traffic in general. Significant changes in this traffic behavior should definitely make you investigating the cause.

Reports from visitors or users¶

If visitors or users report that they get viruses from browsing through your site, or that their anti-virus software raises an alarm when accessing it, you should immediately check this incident. Keep in mind that under certain circumstances the manipulated content might not be visible to you if you just check the generated output - see explanations above.

Search engines or browsers warn about your site¶

Google, Yahoo and other search engines have implemented a warning system showing if a website content has been detected as containing harmful code and/or malicious software (so called "malware" that includes computer viruses, worms, trojan horses, spyware, dishonest adware, scareware, crimeware, rootkits, and other malicious and unwanted software).

One example for such a warning system is Google's "Safe Browsing Database". This database is also used by various browsers.

Leaked credentials¶

One of the "hacks" most difficult to detect is the case where a hacker gained access to a perfectly configured and secured TYPO3 site. In previous chapters we discussed how important it is to use secure passwords, not to use unencrypted connections, not to store backups (e.g. MySQL database "dumpfiles") in a publicly accessible directory, etc. All these examples could lead to the result that access details fall into the hands of an attacker, who possibly uses them, simply logs into your system and edits some pages as a usual editor.

Depending on how sophisticated, tricky, small and frequently the changes are and how large the TYPO3 system is (e.g. how many editors and pages are active), it may take a long time to realize that this is actually a hack and possibly takes much longer to find the cause, simply because there is no technical issue but maybe an organizational vulnerability.

The combination of some of the recommendations in this document reduces the risk (e.g. locking backend users to specific IP addresses, store your backup files outside the web server's document root, etc.).

Take the website offline¶

Assuming you have detected that your site has been hacked, you should take it offline for the duration of the analysis and restoration process (the explanations below). This can be done in various ways and it may be necessary to perform more than one of the following tasks:

route the domain(s) to a different server
deactivate the web host and show a "maintenance" note
disable the web server such as Apache (keep in mind that shutting down a web server on a system that serves virtual hosts will make all sites inaccessible)
disconnect the server from the Internet or block access from and to the server (firewall rules)

There are many reasons why it is important to take the whole site or server offline: In the case where the hacked site is used for distributing malicious software, a visitor who gets attacked by a virus from your site, will most likely lose the trust in your site and your services. A visitor who simply finds your site offline (or in "maintenance mode") for a while will (or at least might) come back later.

Another reason is that as long as the security vulnerability exists in your website or server, the system remains vulnerable, meaning that the attacker could continue harming the system, possibly causing more damage, while you're trying to repair it. Sometimes the "attacker" is an automated script or program, not a human.

After the website or server is not accessible from outside, you should consider to make a full backup of the server, including all available log files (Apache log, FTP log, SSH log, MySQL log, system log). This will preserve data for a detailed analysis of the attack and allows you (and/or maybe others) to investigate the system separated from the "live" environment.

Today, more and more servers are virtual machines, not physical hardware. This often makes creating a full backup of a virtual server very easy because system administrators or hosting providers can simply copy the image file.

Analyze¶

In most cases, attackers are adding malicious code to the files on your server. All files that have code injected need to be cleaned or restored from the original files. Sometimes it is obvious if an attacker manipulated a file and placed harmful code in it. The date and time of the last modification of the file could indicate that an unusual change has been made and the purpose of the new or changed code is clear.

In many cases, attackers insert code in files such as index.php or index.html that are found in the root of your website. Doing so, the attacker makes sure that his code will be executed every time the website is loaded. The code is often found at the beginning or end of the file. If you find such code, you may want to do a full search of the content of all files on your hard disk(s) for similar patterns.

However, attackers often try to obscure their actions or the malicious code. An example could look like the following line:

eval(base64_decode('dW5saW5rKCd0ZXN0LnBocCcpOw=='));

Where the hieroglyphic string "dW5saW5rKCd0ZXN0LnBocCcpOw==" contains the PHP command unlink('test.php'); (base64 encoded), which deletes the file test.php when executed by the PHP function eval()`. This is a simple example only and more sophisticated obscurity strategies are imaginable.

Other scenarios also show that PHP or JavaScript Code has been injected in normal CSS files. In order that the code in those files will be executed on the server (rather than just being sent to the browser), modifications of the server configuration are made. This could be done through settings in an .htaccess file or in the configuration files (such as httpd.conf) of the server. Therefore these files need to be checked for modifications, too.

As described above, fixing these manipulated files is not sufficient. It is absolutely necessary that you learn which vulnerability the attacker exploited and to fix it. Check log files and other components on your system which could be affected, too.

If you have any proof or a reasonable ground for suspecting that TYPO3 or an extension could be the cause, and no security-bulletin lists this specific version, please contact the TYPO3 Security Team. The policy dictates not to disclose the issue in public (mailing lists, forums, Twitter or any other 3rd party website).

Repair/restore¶

When you know what the problem was and how the attacker gained access to your system, double check if there are no other security vulnerabilities. Then, you may want to either repair the infected/modified/deleted files or choose to make a full restore from a backup (you need to make sure that you are using a backup that has been made before the attack). Using a full restore from backup has the advantage, that the website is returned to a state where the data has been intact. Fixing only individual files bears the risk that some malicious code may be overlooked.

Again: it is not enough to fix the files or restore the website from a backup. You need to locate the entry point that the attacker has used to gain access to your system. If this is not found (and fixed!), it will be only a matter of time, until the website is hacked again.

So called "backdoors" are another important thing you should keep in mind: if an attacker had access to your site, it is possible and common practise that it implemented a way to gain unauthorized access to the system at a later time (again). Even if the original security vulnerability has been fixed (entry point secured), all passwords changed, etc., such a backdoor could be as simple as a new backend user account with an unsuspicious user name (and maybe administrator privileges) or a PHP file hidden somewhere deep in the file system, which contains some cryptic code to obscure its malicious purpose.

Assuming all "infected" files have been cleaned and the vulnerability has been fixed, make sure to take corrective actions to prevent further attacks. This could be a combination of software updates, changes in access rights, firewall settings, policies for log file analysis, the implementation of an intrusion detection system, etc. A system that has been compromised once should be carefully monitored in the following months for any signs of new attacks.

Further actions¶

Given the fact that the TYPO3 site is now working again, is clean and that the security hole has been identified and fixed, you can switch the website back online. However, there are some further things to do or to consider:

change (all) passwords and other access details
review situation: determine impact of the attack and degree of damage
possibly notify your hosting provider
possibly notify users (maybe clients), business partners, etc.
possibly take further legal steps (or ask for legal advice from professionals)

Depending on the nature of the hack, the consequences can be as minimal as a beautifully "decorated" home page or as extensive as stolen email addresses, passwords, names, addresses and credit card details of users. In most cases, you should definitely not trifle with your reputation and you should not conceal the fact that your site has been hacked.