Restoring a website after a 1C-Bitrix hack

Restoring a 1C-Bitrix Website After a Hack

You have discovered that the site is redirecting visitors to a third-party resource, the search engine shows "This site may harm your computer," or the hosting provider sent a notification about spam being sent from your server. All of these are signs of compromise. Recovery is not simply deleting malicious files, but a full cycle: isolation, analysis of the attack vector, cleanup, closing the vulnerability, and monitoring. Skipping any step leads to re-infection within days.

Immediate actions

1. Isolate the site. Do not delete anything. First save the current state — it is needed for analysis. Create a full dump of files and the database. Then restrict access: put up a stub page via nginx (return 503) or .htaccess with Deny from all and Allow from your IP. This prevents further damage and prevents the attacker from establishing persistence.

2. Change all passwords. Immediately, before analysis:

• Database passwords (in .settings.php and dbconn.php)
• FTP/SSH access credentials
• Bitrix admin account passwords
• API keys of third-party services, if they were stored in configs

3. Check for added SSH keys or cron tasks. Attackers often add their public key to ~/.ssh/authorized_keys and add cron tasks for periodic backdoor downloads. Check crontab -l for all users and the contents of /etc/cron.d/.

Attack vector analysis

Without understanding exactly how the site was compromised, recovery is pointless — it will be hacked again through the same vulnerability.

Typical vectors for Bitrix:

Analyze web server access logs for the period preceding the discovery. Look for POST requests to non-standard URLs, requests to files in /upload/ with a .php extension, requests with characteristic patterns (eval, base64, system).

Full file system cleanup

Core check. Use the built-in tool /bitrix/admin/site_checker.php → "Core File Integrity Check". It compares checksums against reference values. All modified core files are suspicious. The Bitrix core should not contain your modifications; if it does — this is either a hack or a bad practice that needs to be corrected.

Backdoor search. Scan the file system for typical patterns:

• .php files in directories /upload/, /bitrix/tmp/, /bitrix/cache/
• Files with a recent modification date in /bitrix/modules/ (if you haven't updated the core)
• Contents: eval(, base64_decode(, gzinflate(, str_rot13(, assert(, preg_replace with the e modifier
• Files with names mimicking system files: wp-config.php, config.bak.php, .htaccess.php

Built-in tool: the bitrix.security module (Proactive Protection) → "Security Scanner" performs a basic search for suspicious code.

Database check. Search the b_user table for users with administrative rights that you did not create. Check b_option for modified module settings (especially main and security). Check b_file for records referencing PHP files in /upload/.

Recovery and closing the vulnerability

Option A: Clean core reinstallation. Download a fresh core distribution from 1c-bitrix.ru and replace the directories /bitrix/modules/, /bitrix/components/, /bitrix/js/. Leave /bitrix/php_interface/ (but check init.php) and /bitrix/templates/. This guarantees the absence of modified core files.

Option B: Restore from backup. Use a backup created before the compromise. Determine the date of the hack from the logs and restore files to that date. After restoration, be sure to update the core to the latest version — otherwise the same vulnerability will be exploited again.

Mandatory measures after cleanup:

• Update the Bitrix core to the latest stable version
• Remove or update all third-party modules
• Enable the bitrix.security module: WAF (proactive filter), frame protection, session IP binding
• Set proper file system permissions: directories 0755, files 0644, owner — not root
• Restrict access to /bitrix/admin/ by IP via nginx/Apache
• Block PHP execution in /upload/: in nginx — location ~* /upload/.*\.php$ { deny all; }

Monitoring after recovery

The first 2–4 weeks are a critical period. Set up:

• File monitoring (inotify / AIDE / tripwire) — tracking changes in /bitrix/modules/ and /bitrix/php_interface/
• Access log monitoring for suspicious POST requests
• Checking b_user for new administrative records (via cron + script)
• External HTTP header monitoring — detection of unauthorized redirects

Re-infection after poor-quality cleanup is a matter of "when," not "if." A single missed backdoor in a forgotten /bitrix/backup/ directory undoes all the work.