Админ открывает заказ WooCommerce, чтобы проверить, что купил клиент. Вместе с заказом запускается спрятанный там скрипт - прямо в уже открытой админской сессии. О такой атаке на этой неделе сообщил Patchstack: кампанию замечают с 4 октября 2026 года. Злоумышленники прятали скрипты в заявках Ninja Forms и заказах WooCommerce, оформленных через WPC Product Bundles. Когда админ открывал такую запись, скрипт устанавливал поддельный плагин WP Smart Thumbnails. Затем создавал обычного на вид админа, второго - скрытого от экрана Users, секретную ссылку для входа и файловый менеджер.
Пароль у админа мог быть хоть идеальным. Скрипту он не нужен - тот действует через открытую сессию. Вот почему защита входа в WordPress не заканчивается на форме логина. Важно еще понимать, кто имеет права администратора, что происходит после входа и как заметить учетную запись, которую вы не создавали.
Начните с паролей и ключей доступа
Выдайте каждому сотруднику отдельную учетную запись и уникальный пароль из менеджера паролей. Если человек использует один пароль и для магазина, и для стороннего сервиса, утечка в том сервисе ударит по вашему сайту. Бот просто проверит готовую пару «логин - пароль». Угадывать ничего не придется.
Ключи доступа, или passkeys, еще надежнее там, где ваша конфигурация их поддерживает. Они привязаны к настоящему домену сайта: поддельная страница входа не выманит такой ключ так же легко, как обычный пароль. В самом WordPress встроенного входа по passkeys нет - нужен плагин. Проверьте, какие сценарии он поддерживает, испытайте вход на одной админской учетке и заранее подготовьте способ восстановить доступ. Потом уже подключайте остальных.
Пять человек со своими аккаунтами в менеджере паролей - лучше, чем один общий пароль админа, который все «точно помнят». Иначе потом еще попробуйте выяснить, кто поменял настройки заказов.
Включите 2FA для всех, у кого есть серьезные права
Двухфакторная аутентификация добавляет вторую проверку после пароля. Но способы проверки не одинаково надежны. Для тех, кто может менять сайт, я бы расставил их так:
- Ключ доступа или аппаратный ключ: лучше всего защищает от поддельных страниц входа.
- Приложение-аутентификатор (TOTP): надежный и удобный вариант. Правда, человека все еще можно обманом заставить ввести действующий код на фальшивом сайте.
- Код по почте: лучше одного пароля, но мало поможет, если взломана сама почта.
- Код по SMS: подойдет, если других рабочих вариантов нет. Первым выбором я бы его не делал.
Сделайте 2FA обязательной для каждого администратора и менеджера магазина WooCommerce. Когда ее можно включить «по желанию», без защиты обычно остается как раз забытая учетная запись. Резервные коды храните в безопасном месте, отдельно от сайта. Если настраиваете все с нуля, вот инструкция по двухфакторной аутентификации для админов - базовые шаги займут около пяти минут на человека.
И не забывайте пример в начале: даже хорошая 2FA не обезвреживает сессию, в которую админ уже вошел. Идем дальше.
Защита от брутфорса должна тормозить ботов, а не покупателей
Брутфорс - это многократные попытки подобрать пароль. Есть и другой частый сценарий: боты берут пароли из чужих утечек и проверяют их на вашем WordPress. Ограничение частоты попыток помогает против обоих подходов. Но от проверки утекших паролей по-настоящему спасают уникальные пароли и 2FA.
Ограничивайте попытки и по IP-адресу, и по имени пользователя. После ошибок увеличивайте паузу постепенно. Одной долгой блокировке я бы не доверял: злоумышленник может специально заблокировать вашего админа ровно тогда, когда пора отправлять заказы. Если хостинг дает такую возможность, отсекайте агрессивный трафик на сервере или файрволе, до запуска WordPress. Так PHP не придется обрабатывать каждую попытку, а сайт потратит меньше ресурсов.
У вас магазин на WooCommerce? Проверьте правила на /my-account/, а не только на /wp-login.php. Покупатели ошибаются в паролях, особенно с телефона. Если защита оставляет нормального клиента за бортом во время оформления заказа - это плохая защита. В услуге защиты входа WordPress можно настроить ограничения и файрвол так, чтобы забытый клиентом пароль не выглядел как атака.
А если спрятать адрес страницы входа?
Смена стандартного адреса входа уменьшит шум от ботов и сократит журналы событий. Полезный бонус. Но не замена 2FA и ограничению попыток.
Тот, кто целится именно в ваш сайт, может искать другие пути. К тому же /wp-login.php - не единственная дверь. Плагины для смены URL иногда конфликтуют с кешированием или другими плагинами. Отключите такой плагин в неудачный момент - и сами не попадете в админку. Если меняете адрес, запишите его там, где команда сможет найти, оставьте способ восстановить доступ и проверяйте вход после изменений. На это уйдет минут десять-пятнадцать.
Мой вердикт: можно сделать, если автоматические запросы забивают логи. Но тихие логи еще не означают, что вход защищен.
Проверьте другие двери: XML-RPC, пароли приложений и REST
Страница входа может быть отлично защищена, а другой путь для проверки учетных данных останется открытым. Посмотрите вот эти три места:
- XML-RPC: через
xmlrpc.phpиsystem.multicallможно проверять много паролей в одном запросе. Отключите XML-RPC, если он вам не нужен. Только сначала проверьте интеграции: Jetpack и некоторые приложения от него зависят. Разобраться поможет статья про XML-RPC в WordPress. - Пароли приложений: WordPress поддерживает их с версии 5.6 для интеграций через REST или XML-RPC. При таком входе обычная интерактивная 2FA не запрашивается - так задумано. Откройте
Users > Profileу каждого пользователя с высокими правами, посмотрите список и отзовите все пароли, назначение которых никто не может объяснить. Если подобных интеграций нет, подумайте об отключении функции. - Список пользователей через REST API: на многих сайтах имена пользователей видны по адресу
/wp-json/wp/v2/users. Откройте его без входа в аккаунт и посмотрите, что показывает ваш сайт. Если уместно, ограничьте публичную выдачу. Но не считайте скрытые логины заменой нормальным паролям.
Тут есть нюанс: пароль приложения - отдельный ключ, не тот пароль, с которым человек заходит в админку. Включенная 2FA для администратора не сделает неизвестный пароль приложения безопасным. Проверьте и то и другое. На быстрый просмотр обычно хватает десяти минут, если учеток немного.
Сократите число админов - и не верьте одному экрану Users
Права администратора нужны немногим. Тому, кто пишет описания товаров, может хватить роли редактора. Тому, кто обрабатывает заказы WooCommerce, - роли менеджера магазина. Ни одной из этих задач сами по себе не нужны полный контроль над плагинами, пользователями и настройками.
Раз в месяц устраивайте короткую проверку доступов:
- Удаляйте учетки бывших сотрудников и разработчиков, которые больше не работают с сайтом. Если нужно, передайте их материалы другому пользователю.
- Заменяйте общие админские логины личными учетками. И не делайте имена пользователей такими же, как публичные имена на сайте.
- Пересчитайте админов. Для каждого должен быть понятный ответ: зачем ему эти права сейчас?
- Включите уведомления о создании нового администратора и проверяйте журнал действий, когда приходит такое уведомление.
История в начале статьи напоминает: экран Users может показать не все. Скрытый админ там не появится. Если пришло уведомление о новом администраторе, а найти его не получается, не списывайте это на ошибку оповещения. Попросите специалиста по WordPress проверить базу данных и журналы, а затем выяснить, что создало учетку. Удалять строки из базы наугад - плохая затея.
Не оставляйте открытые админские сессии
Вышли из-за общего компьютера - выйдите и из админки. Не передавайте коллеге браузер с уже открытой сессией «на минутку». Если устройство пропало или вы подозреваете чужой вход, смените пароль учетки и через управление сессиями в ее профиле завершите остальные сеансы. Заодно проверьте недавние действия и список админов.
Это не удалит плагин, который злоумышленник уже успел поставить. Нашли незнакомого админа, неожиданный плагин или файловый менеджер непонятного происхождения? Считайте это возможным взломом, а не задачей «поменять пароль и забыть». Нужно найти точку входа и убрать все, чем атакующий закрепился на сайте, включая то, чего не видно в обычной админке.
Что мы проверяем на сайтах с обслуживанием
На сайтах, которые мы ведем, защита входа - не один плагин, поставленный навсегда. К этим пунктам приходится возвращаться:
- 2FA обязательна для каждого администратора и менеджера магазина, резервные коды сохранены отдельно.
- Ограничение попыток входа и правила файрвола настроены и проверены на входе покупателей.
- XML-RPC отключен, если известной интеграции он не нужен.
- Пароли приложений проверены, ненужные отозваны.
- Число админов сверяют регулярно, о новых учетках приходят уведомления.
- Обновления WordPress, плагинов и тем проверяются и ставятся, чтобы известная XSS-уязвимость, использующая админскую сессию, не висела на сайте месяцами.
Сами по себе обновления не гарантируют защиту от кампании вроде той, о которой сообщили на этой неделе. Но держать уязвимый плагин и при этом старательно прятать адрес логина - странный выбор приоритетов. Если пока не настроена даже обязательная 2FA, можно начать с бесплатной двухфакторной аутентификации WordPress, а затем пройтись по остальным пунктам. Часть проверок занимает минуты, но возвращаться к ним нужно регулярно.
Что проверить сегодня за десять минут
Откройте Users и пересчитайте админов. Вы можете назвать каждого и объяснить, зачем ему эта роль? Затем загляните в профили пользователей с высокими правами: нет ли паролей приложений, которые никто не узнает. Напоследок проверьте, что 2FA включена и обязательна для всех админов и менеджеров магазина. Если нет - начните подключать ее сегодня.
А если нашлась учетка, происхождение которой никто не может объяснить, отложите обычную проверрку настроек. Сначала разберитесь с этой учеткой.