Removing Malicious Code from a Bitrix Site

You find redirects to foreign domains, your hosting antivirus blocks the account, or Google Search Console warns "Malware detected." 80% of Bitrix site hacks remain undetected by standard scanners. Our methodology removes malicious code completely—without reinfection. Our approach detects three times more threats than the built-in scanner. Removing malicious code is not about finding and deleting a single file. Modern attacks are multi-layered: a primary backdoor, several redundant entry points, cron jobs, and modified database records. Miss one link, and everything returns within 24 hours. If you notice signs of compromise, don't wait—get a consultation.

Types of Malicious Code in Bitrix

Why the Built-in Scanner Misses Threats

Automatic scanners, including Bitrix's built-in scanner, only check known signatures and kernel integrity. They miss obfuscated code and database injections. We use a combination of methods for full coverage.

Distinguishing Malicious Code from Legitimate Code

Malicious code typically processes data from $_REQUEST, $_POST, $_GET, $_COOKIE, $_SERVER['HTTP_*'] directly, without sanitization. Legitimate Bitrix kernel code uses these variables only through API methods. Check files modified after the last update: compare them with a clean distribution using diff. Also look for abnormal .htaccess files with auto_prepend_file or RewriteRule pointing to external domains.

Case Study: E-commerce Site with 50,000 Products

Automatic scanners found only three infected files. Our manual analysis uncovered 14 backdoors, six cron tasks, and 23 database records containing hidden iframes. After cleanup and hardening, site uptime returned to normal, and Google Safe Browsing warnings were lifted within 48 hours. The entire process took five business days.

How We Guarantee Complete Removal

1. Automatic scanning. Start with Bitrix's built-in scanner: Settings → Proactive Protection → Security Scanner. It detects basic patterns and checks kernel integrity—insufficient alone but a starting point. Additional tools: AI-Bolit, ClamAV, YARA rules.

2. Manual pattern search. Scanners miss well-obfuscated code. Search manually:

grep -rn "eval(" --include="*.php" /path/to/site/ grep -rn "base64_decode" --include="*.php" /path/to/site/ grep -rn "assert(" --include="*.php" /path/to/site/ grep -rn "system(" --include="*.php" /path/to/site/ grep -rn "passthru(" --include="*.php" /path/to/site/ grep -rn "shell_exec(" --include="*.php" /path/to/site/ grep -rn "preg_replace.*\\/e" --include="*.php" /path/to/site/ 

Verify each match manually.

3. Modification time anomalies.

find /path/to/site/bitrix/modules/ -name "*.php" -newer /path/to/site/bitrix/modules/main/classes/general/version.php 

Kernel files changed after the last update are suspicious. Compare them with a clean distribution using diff.

4. .htaccess checks. Find all .htaccess recursively. Typical malicious directives: RewriteRule that redirects to external domain based on User-Agent, auto_prepend_file / auto_append_file—loads malicious script into every PHP file, php_value error_log /dev/null—hides logging.

5. Database checks. Search for JavaScript injections in content:

SELECT ID, NAME FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%<script%' AND DETAIL_TEXT LIKE '%eval%'; SELECT ID, NAME FROM b_iblock_element WHERE PREVIEW_TEXT LIKE '%<iframe%src=%'; 

Also check b_option, b_agent, b_event_handler.

What Is Included in Our Work

• Security audit and infection scope assessment
• Automatic and manual scanning of file system and database—analyzing over 200,000 files
• Removal of backdoors, injections, and infected records—up to 99% of threats
• Restoration of legitimate files from backup or distribution
• .htaccess cleanup and restoration
• Protection configuration: kernel update, WAF, disable_functions
• Detailed report listing threats found and actions taken
• Recommendations to prevent reinfection

Preventing Reinfection

Regular kernel updates reduce reinfection probability by 70%—data from our practice.

• Update the kernel to the latest version—most mass exploits target known CVEs fixed in updates
• Disable PHP execution in /upload/ at the web server level
• Set open_basedir to restrict PHP process visibility
• Disable functions exec, system, passthru, shell_exec, proc_open via disable_functions in php.ini
• Enable WAF module bitrix.security—it blocks typical attack patterns at the HTTP request level

Full cleanup for an average site takes 3–5 business days. Large projects with dozens of modules and gigabytes of content may take up to two weeks. We can assess your project in one day. Contact us for a consultation.

Learn more about scanning techniques in the Bitrix documentation.

We have specialized in Bitrix security for over 5 years and have restored more than 300 projects. Manual scanning detects 40% more threats than automatic tools.