Как я отследил скрытую инъекцию и укрепил защиту окружения
Вы запускаете сканирование на вредоносное ПО. Вы заменяете основные файлы. Вы обновляете плагины и меняете пароли. Сайт выглядит чистым.
Через два дня звонит клиент. Снова появились новые учетные записи администраторов. Посетителей перенаправляет на вредоносные сайты.
Это кошмар закрепления в системе.
Стандартные плагины безопасности часто не справляются. Искушенные злоумышленники не просто оставляют одну полезную нагрузку. Они создают вложенные бэкдоры, которые прячутся внутри легитимных файлов.
Недавно я разбирал случай, когда три попытки очистки провалились. Симптомы были специфическими:
• «Админы-призраки»: новые учетные записи со случайными именами появлялись каждые 48 часов. • Условные редиректы: вредоносный сайт видели только новые посетители из поисковых систем. Разработчики ничего не замечали.
Команда уже перезаписала ядро WordPress и обновила плагины. Сканеры ничего не показывали. Вредоносное ПО возрождалось, как гидра.
У злоумышленника был механизм закрепления в базе данных или через cron-задачу. Автоматизированные сканеры пропустили его, так как код был самописным.
Чтобы найти истину, я использовал командную строку.
Сначала я проверил основные файлы с помощью контрольных сумм: wp core verify-checksums
Ядро было чистым. Бэкдор находился в wp-content или в базе данных.
Я поискал файлы, измененные за последние 7 дней: find . -type f -mtime -7 -name "*.php"
Затем я поискал подозрительные функции, такие как eval() или base64_decode(): grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('
Я нашел скрытый файл в устаревшем премиум-плагине. Но удаление плагина не остановило заражение.
Злоумышленник оставил триггер в таблице wp_options в параметре cron. Каждый раз, когда запускался WordPress cron, он подтягивал новую полезную нагрузку. Это приводило к повторному заражению основных файлов спустя считанные минуты после очистки.
Чтобы исправить это, необходимо строго соблюдать порядок действий:
- Очистка базы данных
- Проверьте wp_options на наличие вредоносных данных в autoload.
- Проверьте wp_cron на наличие неизвестных URL.
- Используйте SQL для прямого удаления неавторизованных пользователей.
- Очистка файловой системы
- Удалите всё, кроме wp-config.php и wp-content/uploads/.
- Замените всё свежими файлами из официального репозитория.
- Удалите любые PHP-файлы внутри папки uploads.
- Ротация учетных данных
- Перегенерируйте все соли аутентификации в wp-config.php.
- Сбросьте все пароли от базы данных, SSH и хостинга.
Я также внедрил три защитных механизма, чтобы предотвратить повторение ситуации:
• Защита периметра: Я использовал Cloudflare WAF для блокировки подозрительных POST-запросов к чувствительным директориям.
• Права доступа к файлам: Я заблокировал структуру директорий. Для директорий установил права 755, а для файлов — 644. Я перевел wp-config.php в режим «только для чтения».
• Отключение редактирования: Я добавил DISALLOW_FILE_EDIT и DISALLOW_FILE_MODS в wp-config.php. Это предотвращает любое изменение кода через панель управления.
Не доверяйте зеленой галочке в плагине. Исходите из того, что взлом уже произошел. Защищайте свой сайт изнутри.
Источник: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm