Исследователи SOCRadar и Ctrl-Alt-Intel нашли в сети незащищённый сервер хак-группы WP-SHELLSTORM. На нём лежало около 800 Мбайт данных: 434 файла с веб-шеллами, скриптами, настройками инфраструктуры, логами и результатами сканирований.

В открытом доступе оказались и списки целей — примерно 1,4 млн доменов. По этим материалам видно, как группа искала уязвимые сайты, закреплялась на них и, судя по всему, затем продавала доступ другим преступникам.

История инцидента

Сервер хакеров обнаружили по адресу 137.175.93[.]126. Он не требовал пароля, а утечка случилась из-за банальной ошибки: один из участников группы поднял простой HTTP-сервер на Python для передачи файлов и не выключал его 22 дня.

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

По данным исследователей, WP-SHELLSTORM действовала как брокер доступов. Схема простая: найти слабый сайт, установить веб-шелл, закрепиться и передать доступ дальше. Именно такие цепочки потом приводят к утечкам, вымогательству и продаже инфраструктуры на подпольных площадках.

Что пошло не так в защите

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

По материалам сервера видно и другое слабое место атак. Автоматизированные сканеры проверяли цели на 27 известных уязвимостей, а самым эффективным оказался баг CVE-2026-3844 в кеширующем плагине Breeze. Эксплоит применили против более чем 45 000 сайтов, а веб-шелл, судя по логам, поставили более чем на 17 000 из них.

В такой ситуации особенно важна скорость реакции владельцев сайтов. Если обновления затягиваются, а плагины стоят без контроля, злоумышленники быстро находят слабое место. Похожая логика уже встречалась и в других инцидентах, например в разборе Zimbra-уязвимость помогла шпионской группе красть почту и коды 2FA.

Отдельный сигнал для компаний — утечки через чужую ошибку не отменяют собственных рисков. На сервере WP-SHELLSTORM нашли следы другой кампании: в начале мая 2026 года атакующие скомпрометировали 11 Java-систем девяти компаний и похитили 613 конфигурационных файлов с ключами облачных сервисов, паролями от баз данных и приватными RSA-ключами.

Уроки для читателя

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

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

Для компаний урок ещё жёстче: одного антивируса мало. Нужны контроль обновлений, инвентаризация плагинов, проверка внешних сервисов, журналирование и отдельный мониторинг веб-серверов. А если сотрудники работают вне офиса, в аэропорту или кафе, им полезно помнить о рисках открытых сетей и пользоваться дополнительной защитой канала связи, например защитой трафика для публичного Wi‑Fi там, где это уместно и законно.

Практические выводы и чек-лист

  • Обновите WordPress, Joomla и все плагины, особенно те, что отвечают за кэш, формы и загрузку файлов.
  • Удалите неиспользуемые расширения и старые модули — лишний код часто становится точкой входа.
  • Проверьте административные панели и внешние сервисы: всё, что не должно быть в открытом доступе, должно быть закрыто паролем и журналироваться.
  • Настройте мониторинг файлов на сервере: веб-шелл часто маскируется под обычный PHP-файл.
  • Ограничьте права пользователей и сервисных учётных записей, чтобы одна ошибка не открыла всю инфраструктуру.
  • Для сотрудников в поездках и на выездной работе используйте дополнительную защиту соединения в дороге только как вспомогательный инструмент, а не замену обновлениям и проверкам.
  • Внедрите регулярную проверку логов: странные скрипты, массовые запросы и неизвестные IP-соединения — повод реагировать сразу.
  • Периодически тестируйте резервные копии и план восстановления, чтобы атака на сайт не превратилась в остановку бизнеса.
Поделиться: