Хакнат WordPress сайт – как да разберете и какво да направите веднага

Признаци, че WordPress сайтът е компрометиран

Повечето собственици на WordPress сайтове разбират за хакване едва когато Google покаже червено предупреждение или хостинг компанията изпрати имейл за спиране на акаунта.

Проблемът е, че между момента на пробива и видимите симптоми могат да минат седмици. През това време атакуващият инжектира backdoor файлове, създава скрити admin акаунти и добавя spam линкове, които се виждат само от Googlebot. Ранното откриване спестява часове работа по възстановяването и предпазва от трайна SEO щета.

Ето конкретните индикатори, подредени по това колко лесно се забелязват.

Непознати файлове в wp-content директорията

Стартирайте SSH сесия и проверете кога са модифицирани файловете в uploads папката:

find wp-content/uploads -name "*.php" -mtime -30

PHP файлове в uploads нямат работа там – WordPress качва само медийни файлове. Всеки .php файл в тази директория е почти гарантирано malware. Типичните имена изглеждат безобидно: social-icons.php, class-widget.php, wp-tmp.php. Разликата спрямо легитимните файлове се вижда при отваряне – съдържат base64_decode() извиквания или eval() конструкции.

grep -r "eval(base64_decode" wp-content/ --include="*.php" -l

Тази команда връща списък на всички заразени файлове.

Странни акаунти с администраторски права

Директна проверка в базата данни е по-надеждна от wp-admin панела, защото някои backdoor-и крият акаунтите от интерфейса:

SELECT user_login, user_email, user_registered
FROM wp_users
JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id
WHERE wp_usermeta.meta_key = 'wp_capabilities'
AND wp_usermeta.meta_value LIKE '%administrator%';

Ако видите потребител с имейл от безплатен домейн, регистриран в 3 сутринта – изтрийте го. Преди това проверете дали не е създал публикации или страници с злонамерени пренасочвания към външни сайтове.

Google Search Console сигнали

Влезте в Search Console и проверете секция Security & Manual Actions. Google маркира три типа проблеми: malware, phishing и spam content. Разделът URL Inspection показва какво вижда Googlebot – понякога ботът получава различно съдържание от реалните посетители чрез техника, наречена cloaking.

Проверете и Coverage report за внезапен скок в индексирани страници. Хакнатите сайтове често генерират хиляди spam URL-и с японски или кирилски символи, насочени към фармацевтични продукти.

Първите 60 минути след откриването

Скоростта на реакция определя мащаба на щетите.

Изключете сайта от публичен достъп незабавно. Най-бързият метод е .htaccess правило, което допуска само конкретно IP:

order deny,allow
deny from all
allow from 123.456.789.0

Направете пълен backup на текущото състояние – да, включително заразените файлове. Те са доказателство и помагат за анализ на вектора на атака. Сменете паролата на базата данни от хостинг панела и актуализирайте wp-config.php с новата стойност. Генерирайте нови WordPress salt ключове от api.wordpress.org/secret-key – това инвалидира всички активни сесии, включително на атакуващия.

// Генериране на нови ключове - заменете блока в wp-config.php
define('AUTH_KEY',         'нова-случайна-стойност');
define('SECURE_AUTH_KEY',  'нова-случайна-стойност');
define('LOGGED_IN_KEY',    'нова-случайна-стойност');
define('NONCE_KEY',        'нова-случайна-стойност');

Промяната на salt ключовете анулира всички бисквитки за автентикация моментално.

Проверка на core файловете с WP-CLI

WP-CLI предлага вградена команда за сравняване на инсталацията с оригиналните файлове от WordPress.org:

wp core verify-checksums

Командата маркира всеки файл, чийто хеш не съвпада с официалния за текущата версия. Ако видите промени в wp-includes/ или wp-admin/, заменете цялата папка с чисто копие от wordpress.org/latest.tar.gz. Не копирайте файлове поотделно – изтрийте директорията и разархивирайте наново.

Плъгините изискват отделен подход:

wp plugin verify-checksums --all

Всеки плъгин с променени файлове се преинсталира от wordpress.org хранилището. За premium плъгини, които не са в официалното repo, изтеглете свежо копие от доставчика. Файловете на темата проверете ръчно – functions.php е любимото място за инжектиране на зловреден код.

Почистване на базата данни от инжектиран код

Malware в базата данни е по-коварен от файловия, защото оцелява при пълна реинсталация на WordPress.

Търсете в wp_options за подозрителни стойности:

SELECT option_name, LEFT(option_value, 200)
FROM wp_options
WHERE option_value LIKE '%eval(%'
OR option_value LIKE '%base64_decode(%'
OR option_value LIKE '%<script%'
OR option_name LIKE 'wp_check_%';

Таблицата wp_posts е другата цел. Инжектираният JavaScript обикновено стои в post_content полето на стари публикации, които никой не преглежда. Автоматизирайте проверката:

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
AND post_content NOT LIKE '%googletagmanager%'
AND post_content NOT LIKE '%analytics%';

Филтрирането на Google Tag Manager и Analytics предотвратява фалшиви положителни резултати.

Укрепване след почистването

Чистият сайт без допълнителна защита от хакерски атаки ще бъде компрометиран отново в рамките на дни.

Забранете редактирането на файлове от wp-admin:

define('DISALLOW_FILE_EDIT', true);

Ограничете wp-login.php до конкретни IP адреси или добавете HTTP Basic Authentication пред него. Rate limiting на ниво сървър (fail2ban или mod_evasive) спира brute force опитите преди да достигнат PHP. Двуфакторната автентикация чрез TOTP плъгин елиминира риска от компрометирани пароли напълно.

Файловите права имат значение – wp-config.php трябва да е 400 или 440, а директориите 755. Права 777 са покана за проблеми.

Ролята на хостинга в сигурността

Не всеки хостинг план предлага еднакво ниво на защита.

Shared hosting без изолация между акаунтите позволява атака от съседен компрометиран сайт на същия сървър. Managed WordPress хостинг с правилно конфигуриран домейн и сървърна среда включва WAF (Web Application Firewall), автоматично сканиране за malware и изолирани контейнери. Цената е по-висока, но спестява десетки часове ръчна работа при инциденти.

Проверете дали хостингът поддържа поне PHP 8.1 с актуални security patch-ове. Остарялата PHP версия е вектор за атака сама по себе си.

Възстановяване от backup – кога и как

Backup-ът е спасение само ако е от преди компрометацията.

Проверете датата на най-стария backdoor файл чрез stat командата – тя показва кога файлът е създаден. Ако имате backup от преди тази дата, възстановяването е по-бързо от ръчното почистване. След restore задължително сменете всички пароли (wp-admin, FTP, база данни, хостинг панел) и актуализирайте WordPress core, плъгини и тема до последните версии. Ако планирате да преместите сайта на друг сървър след почистването, процесът по смяна на домейн включва допълнителни стъпки за запазване на SEO стойността.

Мониторинг след инцидента

Следващите 30 дни са критични.

Настройте file integrity monitoring – Wordfence или OSSEC следят за промени в core файловете и изпращат имейл при всяка модификация. Проверявайте ежедневно Security & Manual Actions в Google Search Console. Конфигурирайте правилен caching слой, който едновременно подобрява производителността и намалява повърхността за атака чрез по-малко директни PHP заявки. Следете server log файловете за повтарящи се POST заявки към wp-admin/admin-ajax.php от непознати IP адреси.

Ако сайтът е бил маркиран от Google, подайте заявка за преразглеждане едва след като сте сигурни, че всичко е чисто. Повторно маркиране след прибързана заявка удължава периода на предупреждението.

Често задавани въпроси