Сучасні атаки на веб‑інфраструктуру дедалі рідше ґрунтуються на грубих зламах і дедалі частіше маскуються під легітимну роботу сервісів. Одна з таких кампаній, проаналізована фахівцями DataDog Security Labs, демонструє, як зловмисники перетворюють Nginx на інструмент непомітного контролю над користувацьким трафіком, не торкаючись ні бінарних файлів, ні коду застосунків.
Масштабна кампанія з компрометації Nginx і Baota
За даними дослідників, атаки пов’язують з експлуатацією уразливості, позначеної як React2Shell, яка використовується для первинного доступу до серверів. Після закріплення в системі зловмисники переключаються на компоненти веб‑інфраструктури — насамперед на Nginx та популярну в хостинг‑середовищах панель керування Baota.
Основний інтерес становлять ресурси з доменними зонами, поширеними в азійському регіоні: .in, .id, .pe, .bd, .th. Окремо фіксується цілеспрямована активність проти доменів .edu та .gov. Такі сайти мають високий рівень довіри з боку користувачів і пошукових систем, а отже їхній трафік є привабливою ціллю для фішингу, фінансового шахрайства та розповсюдження шкідливого ПЗ.
Як працює атака: приховане проксування та модифікація Nginx
Шкідливі location‑блоки та збереження оригінальних заголовків
Отримавши доступ до сервера, зловмисники не використовують уразливості самого Nginx. Замість цього вони обережно змінюють наявні конфігураційні файли, додаючи приховані блоки location. Ці блоки налаштовані так, щоб перехоплювати запити до певних URL‑адрес і перенаправляти їх через proxy_pass на підконтрольні хакерам хости.
Ключовий нюанс — при такому проксуванні зберігаються вихідні HTTP‑заголовки: Host, X-Real-IP, User-Agent, Referer тощо. Для цільового сайту запит виглядає як звичайний звернений до нього трафік, що пройшов крізь типовий балансувальник навантаження або зворотний проксі. Більшість систем моніторингу сприймають це як нормальний сценарій роботи Nginx, а не як ознаку атаки.
Автоматизація інфікування конфігурацій
Дослідники відзначають використання автоматизованих інструментів, які уніфікують процес компрометації. Типовий ланцюжок включає пошук вразливих систем, внесення змін у конфігурацію, додавання необхідних location і proxy_pass, а також перезапуск Nginx для застосування оновлень.
Завдяки автоматизації зловмисники здатні розгорнути однакові схеми перенаправлення на десятках і сотнях серверів за короткий час. Шкідливі директиви ховаються в уже існуючих файлах, які в багатьох організаціях перевіряються епізодично та рідко підпадають під формальний контроль цілісності.
Чому атаки через конфігурацію Nginx так важко виявити
Однією з причин високої ефективності цієї кампанії є те, що користувач у підсумку все одно потрапляє на справжній сайт. Інтерфейс ресурсу виглядає звично, функціонал працює, сертифікат TLS коректний — а ланцюжок проходження запиту через інфраструктуру зловмисника залишається непоміченим.
По‑перше, атака ґрунтується на штатних можливостях Nginx — зворотному проксуванні й балансуванні навантаження. З погляду стандартного моніторингу це коректно налаштований веб‑сервер з високим трафіком, а не компрометований вузол.
По‑друге, не змінюються бінарні файли та код застосунків; модифікуються лише конфігурації. У багатьох середовищах саме файли налаштувань залишаються «сірою зоною», якщо немає автоматизованого порівняння з еталоном і журналювання всіх змін.
По‑третє, без поглибленого мережевого моніторингу адміністратори можуть не помітити, що частина HTTP‑запитів проходить через сторонні IP‑адреси й домени. Журнали Nginx виглядають звично, тоді як підозріла активність фіксується вже на інфраструктурі нападників і залишається недоступною для аналізу.
Як захистити Nginx, панель Baota та веб‑інфраструктуру
Описана кампанія наочно демонструє, що одноразовий доступ до сервера достатній, щоб перетворити Nginx на потужний інструмент прихованого контролю над трафіком. Знизити ризики допоможе комплексний підхід до захисту:
1. Контроль цілісності конфігурацій. Регулярно порівнюйте конфігураційні файли Nginx і хостинг‑панелей (зокрема Baota) з еталонними копіями. Використовуйте системи контролю версій, журналювання змін і сповіщення про будь‑які модифікації налаштувань.
2. Мінімізація та сегментація доступу. Обмежте кількість облікових записів із правами на зміну конфігурації, застосовуйте багатофакторну автентифікацію, відокремлюйте адміністративні інтерфейси від фронтенд‑сервісів у різні мережеві сегменти та VLAN.
3. Оперативне закриття уразливостей. Постійно відстежуйте інформацію про уразливості, пов’язані з React2Shell, Nginx, панеллю Baota та іншими компонентами стеку, своєчасно встановлюйте оновлення та патчі, автоматизуйте керування оновленнями там, де це можливо.
4. Поглиблений мережевий моніторинг. Аналізуйте маршрути трафіку та фактичні напрямки проксування, корелюйте їх з очікуваною архітектурою. Звертайте увагу на незнайомі зовнішні IP‑адреси й домени в ланцюжках обробки HTTP‑запитів.
5. Використання спеціалізованих засобів захисту. Впроваджуйте веб‑фаєрволи (WAF), системи виявлення та запобігання вторгненням (IDS/IPS), рішення для аналізу поведінки трафіку. Такі інструменти здатні виявляти аномальні шаблони звернень, навіть якщо вони маскуються під легітимну роботу балансувальників.
Посилення контролю за конфігураціями, жорстка модель доступу, своєчасне усунення уразливостей і глибокий мережевий моніторинг суттєво ускладнюють для зловмисників перетворення Nginx на канал прихованого перенаправлення трафіку. Власникам веб‑ресурсів варто вже зараз переглянути свої підходи до захисту інфраструктури, аби не стати частиною подібних кампаній і не допустити непомітної компрометації довіри користувачів.
