Аналитики DataDog Security Labs зафиксировали масштабную вредоносную кампанию, в рамках которой злоумышленники получают доступ к серверам Nginx и незаметно перенаправляют трафик пользователей через собственную инфраструктуру. Особая опасность этой техники в том, что она маскируется под нормальную работу балансировщика нагрузки и практически не вызывает подозрений у классических систем мониторинга и защиты.
Цели атак: Nginx и панель управления хостингом Baota
По данным исследователей, кампания связывается с эксплуатацией уязвимости, обозначаемой как React2Shell, которая, предположительно, используется для первоначального компрометационного доступа к серверам. После успешной эксплуатации атакующие фокусируются на установках Nginx и панели управления хостингом Baota, широко применяемой в среде виртуального и выделенного хостинга.
Под удар попадают сайты с доменами, популярными в азиатском регионе: .in, .id, .pe, .bd, .th. Отдельно отмечается интерес злоумышленников к ресурсам с доменными зонами .edu и .gov, что говорит о целевой атаке на образовательные и государственные организации. Такие площадки обладают высоким уровнем доверия у пользователей и поисковых систем, поэтому компрометация их трафика особенно привлекательна с точки зрения фишинга, финансового мошенничества и дальнейшего распространения вредоносного ПО.
Механика атаки: злоупотребление возможностями конфигурации Nginx
Вредоносные блоки location и перехват запросов
После получения доступа к серверу злоумышленники не эксплуатируют уязвимости самого Nginx. Вместо этого они модифицируют существующие конфигурационные файлы, добавляя скрытые блоки location. Эти блоки настроены таким образом, чтобы перехватывать запросы к определённым URL-адресам и перенаправлять их через директиву proxy_pass на контролируемые хакерами серверы.
Ключевой момент — при проксировании перенаправленный запрос сохраняет исходную информацию о том, куда изначально пытался попасть пользователь. Заголовки Host, X-Real-IP, User-Agent, Referer и другие остаются нетронутыми. Внешне такой трафик выглядит как легитимный запрос к целевому сайту, проходящий через обычный балансировщик нагрузки или обратный прокси. Для большинства систем безопасности это типичный сценарий использования Nginx, а не признак атаки.
Автоматизированное изменение конфигурации
Исследователи отмечают, что злоумышленники используют автоматизированный инструментарий для внедрения вредоносных изменений. Описывается пятиэтапный процесс, включающий поиск уязвимых систем, модификацию конфигурационных файлов, прописывание необходимых блоков location и proxy_pass, а также перезапуск или перезагрузку Nginx для применения новых настроек.
Подобный подход позволяет атакующим быстро масштабировать кампанию, настраивая одинаковые схемы перенаправления на большом количестве серверов. При этом вредоносные директивы прячутся в уже существующих конфигурационных файлах, которые во многих организациях проверяются эпизодически и редко проходят формальный аудит целостности.
Почему такие атаки трудно обнаружить
Одной из причин высокой эффективности кампании является то, что пользовательский трафик в итоге все равно достигает целевого сайта. Пользователь видит привычный интерфейс ресурса, взаимодействует с ним как обычно, а факт прохождения его запросов через инфраструктуру злоумышленника остаётся скрытым. Дополнительно ситуацию усложняет то, что:
Во‑первых, атака основана на штатной функциональности Nginx (обратное проксирование и балансировка нагрузки). Для систем мониторинга это выглядит как корректная конфигурация высоконагруженного веб-сервера.
Во‑вторых, злоумышленники не вносят заметных изменений в код приложений и не модифицируют бинарные файлы Nginx. Файлы конфигурации традиционно оказываются «слепой зоной», если не внедрены механизмы контроля целостности и регулярного сравнения с эталонными версиями.
В‑третьих, без специализированного сетевого мониторинга и анализа маршрутов трафика администраторы могут даже не заметить, что часть запросов проходит через сторонние IP-адреса и домены. Логи на стороне Nginx будут выглядеть вполне привычно, а подозрительная активность останется на инфраструктуре атакующих.
Рекомендации по защите Nginx и хостинг-панелей
Эксперты по кибербезопасности подчёркивают, что подобные атаки демонстрируют необходимость комплексного подхода к защите веб-инфраструктуры. Для снижения рисков целесообразно:
1. Внедрить контроль целостности конфигураций. Регулярно сравнивать файлы конфигурации Nginx и панелей управления (включая Baota) с эталонными копиями, использовать системы контроля версий и уведомления о любых изменениях.
2. Ограничить и сегментировать доступ. Минимизировать число учетных записей с правами на изменение конфигурации, использовать многофакторную аутентификацию, разделять административные интерфейсы и фронтенд-сервисы по различным сетевым сегментам.
3. Оперативно устранять уязвимости. Мониторить актуальные сведения об уязвимостях, в том числе связанных с React2Shell и используемыми панелями управления, своевременно устанавливать обновления и патчи.
4. Настроить углублённый сетевой мониторинг. Анализировать маршруты трафика, сопоставлять ожидаемые и фактические направления проксирования, обращать внимание на неожиданные внешние IP-адреса и домены в цепочке обработки запросов.
5. Использовать специализированные средства защиты. Внедрять веб‑экраны (WAF), системы обнаружения вторжений (IDS/IPS) и решения для анализа поведения трафика, способные выявлять аномальные паттерны, даже если они маскируются под легитимную нагрузку.
Рассматриваемая кампания наглядно показывает, что для атакующих достаточно один раз получить доступ к серверу, чтобы превратить Nginx в мощный инструмент скрытого контроля над трафиком. Регулярный аудит конфигураций, строгая модель доступа, своевременное устранение уязвимостей и внедрение продвинутых средств мониторинга позволяют существенно усложнить подобные атаки и снизить потенциальный ущерб как для владельцев ресурсов, так и для их пользователей.
