Removing malicious code from the 1C-Bitrix website

Malicious Code Removal from 1C-Bitrix Site

The site has unexplained redirects to foreign domains, antivirus blocked the hosting account, or Google Search Console sent "Malware detected" notification. Malicious code removal — this is not finding and deleting one file. Modern Bitrix attacks are multi-layered: main backdoor, several backup entry points, cron jobs and modified DB records. Miss one link — within a day it's all back.

Types of Malicious Code in Bitrix

1. PHP backdoors (web shell). Full file manager and command line accessible via HTTP. Usually disguised as system files: settings.php, cache.php, session_handler.php. Located in directories admins rarely visit: /bitrix/tmp/, /upload/resize_cache/, /bitrix/backup/.

2. Injections in existing files. Malicious code inserted at beginning or end of legitimate PHP files. Favorite targets:

• /bitrix/php_interface/init.php — executes on every hit
• /bitrix/templates/.default/header.php and footer.php
• .htaccess — adding auto_prepend_file or php_value
• index.php in root and sections

3. Malicious code in DB. JavaScript injections in HTML content of iblocks, in properties like "HTML/text", in mailing templates (b_sender_mailing), in custom fields. Such code not detected by file system scanning.

4. Obfuscated code. Multi-layer encoding: eval(gzinflate(base64_decode(str_rot13(...)))). Goal — bypass antivirus and grep search. May use non-obvious constructs: variable variables ($$var), call_user_func(), dynamic function names.

Complete Scanning Methodology

Stage 1. Automatic scanning.

Start with built-in Bitrix scanner: Settings → Proactive Protection → Security Scanner. Detects basic patterns and checks core integrity. Not enough for complete cleanup, but gives starting point.

Additional tools:

• AI-Bolit (revisium.com) — specialized CMS scanner, knows Bitrix patterns
• ClamAV — general antivirus, detects known web shells
• YARA-rules — for advanced scanning with custom signatures

Stage 2. Manual pattern search.

Automatic 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/

Check each match manually — many of these functions legitimately used in Bitrix core. Difference of malicious code: works with $_REQUEST, $_POST, $_GET, $_COOKIE, $_SERVER['HTTP_*'] directly, without sanitation.

Stage 3. Anomaly search by modification time.

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

Core files changed after last update — suspicious. Compare them with clean distribution via diff.

Stage 4. Check .htaccess.

Find all .htaccess recursively. Bitrix creates them in specific directories — any file in non-standard place suspicious. Typical malicious directives:

• RewriteRule with redirect to external domain by User-Agent condition (Googlebot redirected, normal user — no)
• auto_prepend_file / auto_append_file — inject malicious script to all PHP files
• php_value error_log /dev/null — hide logging

Stage 5. Check DB.

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 (changed module settings), b_agent (suspicious agents), b_event_handler (new handlers connecting external code).

Removal and Verification

After compiling full list of infected objects:

1. Backdoor files — delete completely.
2. Injections in legitimate files — restore from clean backup or distribution. Don't edit manually — easy to leave tail.
3. Infected DB records — clean via SQL, dump first.
4. Modified .htaccess — replace with standard from Bitrix distribution.

Verification: after cleanup repeat full scan. Then check site works correctly — aggressive cleanup can touch legitimate code.

Prevention of Re-infection

• Update core to latest version — most mass hacks exploit known CVEs closed in updates
• Close PHP execution in /upload/ at web server level
• Configure open_basedir to limit PHP visibility scope
• Disable functions exec, system, passthru, shell_exec, proc_open in php.ini via disable_functions
• Enable WAF of bitrix.security module — blocks typical attack patterns at HTTP request level

Complete cleanup cycle for medium site takes 3-5 business days. Large projects with dozens of modules and gigabytes of content — up to two weeks.