Когда злоумышленник проникает в админку, он не оставляет дверь открытой — в 85% случаев внедряется бэкдор, который позволяет вернуть доступ даже после смены всех паролей. Поиск следов компрометации в логах требует анализа не только факта входа, но и аномалий в поведении сервера, которые часто игнорируют стандартные сканеры безопасности.
Аномальные POST-запросы к легитимным файлам
Первый признак бэкдора — появление POST-запросов к файлам, которые в норме принимают только GET или вообще не должны обрабатывать ввод от пользователя. Если вы видите в access.log серию запросов к index.php или style.css с параметрами в теле запроса, это верный признак веб-шелла. Опытные хакеры маскируют бэкдоры под системные файлы, меняя дату модификации (timestomping), чтобы файл не выделялся в списке по дате.
Кейс: при анализе сайта на WordPress был обнаружен файл wp-includes/images/logo-cache.php. В логах фиксировались запросы с IP-адреса из Сингапура, передающие зашифрованные данные через параметр $_POST['cmd']. Итог: полный контроль над базой данных и внедрение скрытых ссылок. Экспертный вывод: любой исполняемый файл в папке с медиа-контентом — это 100% компрометация, требующая немедленного удаления и аудита прав доступа.
Несоответствие User-Agent и сессионных кук
При использовании бэкдоров или краже сессий часто возникает разрыв в идентификаторах. Если в логах один и тот же Session ID за 5 минут сменил User-Agent с Chrome/Windows на Python-requests или Curl, перед вами результат Session Hijacking. В 60% случаев автоматизированные скрипты забывают имитировать заголовок браузера, что делает их легко обнаружимыми при фильтрации логов по уникальным парам IP-UserAgent.
Пример: администратор зашел с macOS (Safari), а через 2 минуты под его сессией прилетает запрос на создание нового пользователя с правами супер-админа от User-Agent Mozilla/5.0 (compatible; Googlebot/2.1). Это классический пример обхода двухфакторной аутентификации (2FA) в 2024 году: методу Session Hijacking и SIM-swapping не нужен пароль, им нужен активный токен. Экспертный вывод: мониторинг смены User-Agent внутри одной сессии эффективнее, чем простая проверка IP-адреса.
Всплеск 404 ошибок при сканировании путей
Перед установкой бэкдора или его использованием злоумышленник часто проверяет доступность своих «закладок» или ищет уязвимые точки через фаззинг. Резкий скачок количества 404 ошибок (от 100 до 1000 за несколько минут) с одного IP, направленный на случайные комбинации имен файлов (например, /shell.php, /cmd.php, /backup.sql), сигнализирует о подготовке к атаке или проверке жизнеспособности бэкдора.
Мини-кейс: сайт зафиксировал 450 запросов 404 за 30 секунд, после чего последовал один успешный запрос 200 OK к файлу /wp-content/uploads/2023/01/db-config.php.bak. Спустя час в админке появился новый пользователь. Экспертный вывод: высокая плотность 404 ошибок — это «звонок», который должен автоматически триггерить временную блокировку IP на уровне firewall (iptables/nftables) на срок от 1 до 24 часов.
Нетипичные временные интервалы активности
Анализ временных меток (timestamps) часто выявляет активность в «мертвые часы» (обычно с 03:00 до 06:00 по местному времени владельца). Если админ работает с 9 до 19, а в 4 утра происходят массовые выгрузки таблиц базы данных или правка .htaccess — это работа бэкдора. В профессиональных атаках используется планировщик (cron), который запускает скрипт раз в сутки для обновления связи с C2-сервером.
Статистика показывает, что до 40% скрытых бэкдоров обнаруживаются именно по периодичности запросов: например, один запрос ровно каждые 3600 секунд. Это не человек, а бот. Экспертный вывод: настройте алерты на любые административные действия в ночное время. Это самый простой и дешевый способ обнаружить автоматизированный доступ.
Запросы к API с обходом стандартного интерфейса
Современные CMS используют REST API для работы админки. Хакеры часто обходят визуальный интерфейс и шлют запросы напрямую в API, чтобы не оставлять следов в логах действий пользователя внутри CMS. В системных логах сервера это выглядит как прямые обращения к /wp-json/ или /api/v1/ с параметрами модификации прав доступа, что часто пропускают администраторы, смотрящие только в панель управления.
Кейс: через инъекции в API и REST-интерфейсы новые векторы доступа к административным функциям сайта позволяют менять email администратора без ввода старого пароля. В логах это выглядит как один POST-запрос на 0.1 сек, который полностью меняет владельца сайта. Экспертный вывод: логируйте не только факт входа в админку, но и все запросы к API-эндпоинтам с правами администратора.
Вывод
Для защиты от бэкдоров недостаточно сменить пароли или обновить плагины. Начинать нужно с внедрения строгого WAF и настройки мониторинга логов по паттерну «IP + User-Agent + Time». Избегайте стандартных путей к админке и любых файлов с правами 777 в публичных папках. Мой вердикт: лучшая стратегия сегодня — это переход на беспарольный доступ через SSH-ключи для управления сервером и жесткая изоляция API-интерфейсов, так как именно через них сейчас проходит основной поток скрытых вторжений.
