Новый администратор в CMS, которого никто не создавал

MAATRIX

Открываете список пользователей WordPress или другой CMS ради рутинной проверки — и видите администратора, которого никто в команде не заводил. Дата регистрации сегодняшняя, почта не из корпоративного домена, логин вроде wp_support или system_adm. Это не баг и не забытая учётка стажёра — это почти всегда прямое доказательство того, что сайт уже скомпрометирован, а лишний администратор — просто самый заметный след атаки.

Почему новый администратор — это тревога номер один

Из всех признаков взлома сайта учётка с правами администратора — самая опасная именно потому, что она не эксплойт и не временная дыра, а готовый постоянный доступ. Через уязвимость в плагине атакующий заходит один раз, а через созданного администратора — заходит когда угодно, легально, через штатную форму входа, и делает с сайтом что угодно: меняет контент, ставит редиректы, заливает файлы, читает базу с данными клиентов. Пока такая учётка жива, ваш сайт находится под чужим полным контролем, даже если внешне всё работает нормально.

Хуже того, лишний администратор обычно появляется не первым шагом атаки, а одним из последних: сначала находят точку входа (уязвимый плагин, слабый пароль, скомпрометированный доступ к серверу), а уже потом закрепляются через нового пользователя как более удобный и незаметный канал, чем повторная эксплуатация той же дыры. Поэтому находка лишнего админа — это сигнал, что где-то уже произошёл первый этап взлома, и его нужно найти, а не просто удалить симптом.

Как регулярно проверять список администраторов

Проверку стоит превратить в привычку, а не разовое действие после инцидента. Для WordPress это делается через WP-CLI прямо на сервере — быстрее и надёжнее, чем через веб-интерфейс, который сам может быть скомпрометирован:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Для прямой проверки базы, в обход возможно подделанного вывода админки:

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

Для других CMS логика та же, меняется только источник. В Bitrix — раздел «Пользователи» с фильтром по группе «Администраторы», в самописных системах — таблица пользователей с флагом роли в базе. Главное правило одинаково для любой платформы: список администраторов должен быть коротким, известным наизусть, и любое отклонение от этого списка — повод для проверки в тот же день, а не «как-нибудь на неделе».

Разумный минимум — сверять список раз в неделю, а после любого крупного изменения на сайте (обновление плагинов, миграция, работа подрядчика) — сразу. Автоматизировать легко: cron-задача раз в сутки выгружает список в файл и сравнивает с эталоном, при расхождении шлёт уведомление:

#!/bin/bash
CURRENT=$(wp user list --role=administrator --field=user_login --path=/var/www/site)
BASELINE="/root/scripts/admins-baseline.txt"
diff <(echo "$CURRENT") "$BASELINE" || mail -s "Изменился список админов $(hostname)" admin@example.com <<< "$CURRENT"

Это не заменяет ручную проверку, но ловит проблему до того, как вы вспомните заглянуть в админку сами.

На что смотреть в каждой учётке

Просто список пользователей мало о чём говорит — важно уметь быстро отличить легитимную учётку от подделанной. Вот на что смотреть в первую очередь.

Дата регистрации. Сверьте её с датой, когда вы действительно нанимали нового человека с админ-доступом. Если админ появился в выходной, ночью или в день, который ничем не примечателен для вашей команды, — это подозрительно. Атакующие часто действуют в нерабочее время, чтобы созданная учётка не бросилась в глаза сразу.

Email. Легитимные администраторы регистрируются на корпоративную почту или как минимум на адрес, который знает вся команда. Почта на бесплатных доменах (особенно с случайным набором символов в имени), домен, не похожий ни на что знакомое, или адрес, совпадающий по шаблону с типичными автоматическими регистрациями — явный красный флаг.

Логин и отображаемое имя. Здесь атакующие делают две противоположные ошибки, обе заметны: либо берут максимально нейтральное техническое имя (support, wp_admin, system, backup_user), маскируясь под системную учётку, либо копируют логин существующего сотрудника с минимальной опечаткой. Сверяйте логины буква в букву, не по памяти.

Права и метаданные. Проверьте, каким способом создана учётка — через штатную форму регистрации (если она вообще открыта для публики — это отдельная проблема), через админку кем-то залогиненным, или напрямую записью в базу в обход интерфейса. Прямая запись в базу без следов в логе действий CMS — верный признак, что доступ уже был не через штатный вход, а через уязвимость или прямой доступ к серверу.

Активность. Проверьте, логинилась ли учётка уже, и если да — что делала: последние правки контента, установленные плагины, изменённые файлы темы. Таблица wp_usermeta хранит session_tokens, по которым видно, есть ли у учётки активная сессия прямо сейчас:

SELECT user_id, meta_value FROM wp_usermeta
WHERE meta_key = 'session_tokens' AND user_id = <ID подозрительной учётки>;

Если сессия активна — злоумышленник может быть залогинен в эту секунду, и следующий шаг требует особой аккуратности.

Почему нельзя просто удалить учётку

Первый инстинкт — стереть лишнего администратора и выдохнуть. Это ошибка, которая почти гарантированно приведёт к повторному взлому в течение нескольких дней. Удаление учётки убирает симптом, но не причину: если точка входа, через которую её создали, всё ещё открыта, атакующий заведёт нового администратора за минуту, просто под другим именем.

Прежде чем удалять, зафиксируйте состояние — так же, как при любом инциденте: сохраните ID учётки, точное время регистрации, email, IP-адрес последнего входа (если есть в логах), список правок, которые она успела сделать. Это не бюрократия ради галочки — без этих данных вы не сможете понять, как её создали, и будете гадать вместо того, чтобы закрыть конкретную дыру.

Только после того, как вы поняли путь проникновения и закрыли его — устаревший плагин обновлён или удалён, скомпрометированный пароль сменён, дыра в коде закрыта, — можно безопасно удалять учётку и все связанные с ней артефакты. Удаление раньше времени не решает проблему, а просто откладывает следующий инцидент на несколько дней и заставляет расследовать всё заново.

Как найти путь проникновения

Найти лишнего администратора — это половина работы, вторая половина — понять, откуда он взялся. Начните с логов создания пользователя. У большинства CMS есть журнал активности (в WordPress — через плагин активности или напрямую по meta-записям с user_registered), у веб-сервера — access-лог, который покажет, какой запрос предшествовал появлению учётки:

grep -E "wp-admin/user-new.php|wp-login.php|xmlrpc.php" /var/log/nginx/access.log | grep -B5 "<время создания учётки>"

Обратите внимание на несколько типичных сценариев:

• Через уязвимый плагин или тему. Самый частый путь — плагин с известной проблемой позволяет создать пользователя напрямую, в обход обычной формы регистрации. Проверьте wp plugin list --fields=name,version,update и сверьте с тем, что реально обновлялось в последние месяцы.
• Через скомпрометированный пароль администратора. Если в логе входа виден успешный логин с незнакомого IP непосредственно перед созданием нового пользователя — это не эксплойт, а вход по украденным или подобранным по перебору данным существующей учётки.
• Через прямой доступ к серверу или базе. Если запись появилась без единого HTTP-запроса к панели — значит, у атакующего уже был доступ к серверу или базе данных напрямую, и проблема не в CMS, а на уровне сервера: SSH, панель хостинга, утечка бэкапа с паролями.
• Через XML-RPC или REST API. Некоторые сценарии автоматизированного взлома используют xmlrpc.php или REST API CMS для действий, которые обычно требуют формы в браузере — если вы не используете эти интерфейсы, их стоит закрыть вовсе.

Найденный путь определяет дальнейшие действия: обновление или удаление плагина, смена всех паролей (не только скомпрометированного, а вообще всех — если пароль подобрали для одной учётки, он мог утечь и для других), проверка правил доступа к серверу, отключение неиспользуемых интерфейсов вроде XML-RPC.

Ищите связанные изменения в файлах и базе

Лишний администратор редко приходит один — обычно это часть более широкого закрепления в системе, и его находка должна запускать полную проверку, а не точечное удаление одной строки в базе. Проверьте несколько мест параллельно.

Файлы, изменённые примерно в то же время, что и создание учётки:

find /var/www/site -type f -newermt "2026-08-25" -mtime -14 -name "*.php" | xargs ls -la

Каталог uploads и другие директории с загрузками — там не должно быть исполняемых PHP-файлов вообще:

find /var/www/site/wp-content/uploads -name "*.php"

Задачи планировщика — как встроенного (wp-cron), так и системного (crontab пользователя, от которого работает веб-сервер), которые могли быть добавлены для повторного создания учётки после чистки:

wp cron event list
crontab -u www-data -l

Список плагинов и тем — на предмет установленного, но незнакомого никому в команде расширения: часто именно через него и был получен изначальный доступ, а фейковый администратор — лишь следствие.

Таблицу wp_options — на подозрительные автозагружаемые записи с обфусцированным кодом, которые могут быть частью бэкдора, независимого от учётки пользователя.

Если находите одновременно новую учётку, незнакомый плагин и изменённые файлы темы — это не совпадение, а полная картина одной атаки, и чистить нужно всё сразу. Подробный порядок действий при обнаружении постороннего кода в файлах разбирается в статье про то, как искать заброшенные закладки в CMS, когда сайт вроде не менялся, а последовательность действий при уже подтверждённом взломе — в материале про план реагирования на инцидент.

Как закрыть дыру и не допустить повтора

После того как источник понятен и вредоносные артефакты найдены, порядок действий такой: сначала закрываете точку входа, потом чистите следы, потом меняете все доступы.

Смена ключей безопасности в WordPress выполняется одной командой и сразу обрывает все активные сессии, включая сессию атакующего, если он в этот момент залогинен:

wp config shuffle-salts

Для защиты от повторного создания подобных учёток двухфакторная аутентификация для панелей управления закрывает даже случай, когда пароль администратора снова окажется скомпрометирован — без второго фактора войти всё равно не получится. Настройка описана в статье про двухфакторную аутентификацию для панелей управления.

Отдельно стоит ограничить, кто вообще может создавать пользователей с правами администратора — на уровне логики приложения или хотя бы файрвола веб-сервера, если запросы на создание пользователя идут не из панели, а напрямую к обработчику. И — банально, но часто забывается — держите свежий бэкап, снятый до момента взлома: если чистка пойдёт не по плану, откат к чистой версии сайта быстрее, чем ручной разбор каждого файла.

Частые вопросы