Злоумышленники начали взламывать серверы Nginx в рамках кампании, которая перехватывает пользовательский трафик и перенаправляет его.

Nginx — это программное обеспечение с открытым исходным кодом для управления веб-трафиком. Оно выступает посредником между пользователями и серверами и используется для веб-серверов, балансировки нагрузки, кэширования и обратного проксирования.

Вредоносная кампания, обнаруженная исследователями из DataDog Security Labs, нацелена на установки Nginx и панели управления хостингом Baota, используемые сайтами с азиатскими доменами верхнего уровня (.in, .id, .pe, .bd и .th), а также правительственными и образовательными сайтами (.edu и .gov).

Злоумышленники изменяют существующие конфигурационные файлы Nginx, внедряя вредоносные блоки «location», которые перехватывают входящие запросы по выбранным URL-адресам. Затем они переписывают их, чтобы включить полный исходный URL, и перенаправляют трафик через директиву «proxy_pass» на контролируемые домены. Используемая директива обычно применяется для балансировки нагрузки, позволяя Nginx перенаправлять запросы через альтернативные группы бэкенд-серверов для повышения производительности или надёжности; следовательно, её использование не вызывает никаких предупреждений безопасности.

Заголовки запроса, такие как «Host», «X-Real-IP», «User-Agent» и «Referer», сохраняются, чтобы трафик выглядел легитимным.

Атака использует скриптовый многоэтапный инструментарий для внедрения конфигурации Nginx. Инструментарий работает в пять этапов:

  • этап 1 – zx.sh: действует как начальный скрипт контроллера, отвечающий за загрузку и выполнение остальных шагов. Он включает механизм резервного копирования, который отправляет необработанные HTTP-запросы по TCP, если curl или wget недоступны;

  • этап 2 – bt.sh: нацеливается на файлы конфигурации Nginx, управляемые панелью Baota. Он динамически выбирает шаблоны внедрения на основе значения server_name, безопасно перезаписывает конфигурацию и перезагружает Nginx, чтобы избежать простоя сервиса;

  • этап 3 – 4zdh.sh: перечисляет распространённые места расположения конфигураций Nginx, такие как sites-enabled, conf.d и sites-available. Он использует инструменты анализа, такие как csplit и awk, для предотвращения повреждения конфигурации, обнаруживает предыдущие внедрения с помощью хеширования и глобального файла сопоставления, а также проверяет изменения с помощью nginx -t перед перезагрузкой;

  • этап 4 – zdh.sh: использует более узкий подход к нацеливанию, ориентированный в основном на /etc/nginx/sites-enabled, с акцентом на домены .in и .id. Он следует тому же процессу тестирования конфигурации и перезагрузки, с принудительным перезапуском (pkill) в качестве резервного варианта;

  • этап 5 – ok.sh: сканирует скомпрометированные конфигурации Nginx для построения карты захваченных доменов, шаблонов внедрения и целей прокси. Собранные данные затем передаются на сервер управления и контроля (C2) по адресу 158.94.210[.]227.

Эти атаки трудно обнаружить, поскольку они не используют уязвимость Nginx, а скрывают вредоносные инструкции в его конфигурационных файлах, которые редко подвергаются тщательному анализу. Кроме того, пользовательский трафик по-прежнему достигает места назначения, часто напрямую, поэтому прохождение через инфраструктуру злоумышленника вряд ли будет замечено, если не будет проводиться специальный мониторинг.

UPD: уже сформирован выпуск основной ветки nginx 1.29.5. В неё внесли изменения, связанные с устранением уязвимостей, в том числе CVE-2026-1642, позволяющей атакующему через канал связи между nginx и upstream-сервером подставить отправляемые клиенту ответы. Проблема затрагивает конфигурации, проксирующие запросы (HTTP 1.x, HTTP/2, gRPC или uWSGI) к вышестоящему серверу с использованием TLS-шифрования.

Кроме того, выявлена автоматизированная атака, которая после успешного взлома серверов ограничивается изменением конфигурации nginx через неисправленную уязвимость React2Shell в серверных компонентах React на системах с панелями управления хостингом, такими как Baota (BT). Вносимые в конфигурацию nginx изменения перенаправляли запросы к обслуживаемым сайтам на сервер атакующих.

Ранее разработчик представил простой пример стратегии защиты в Nginx своего экземпляра открытой платформы совместной разработки Forgejo от веб-краулеров с ИИ. При этом обеспечивается должный уровень обслуживания платформы Forgejo для обычных пользователей.