Остання модифікація ботнета Chaos демонструє помітний зсув у тактиці кіберзлочинців: замість домашніх роутерів та IoT‑пристроїв основною ціллю стають неправильно налаштовані хмарні розгортання. Це підтверджує стійкий тренд, коли ботнети використовують хмарні ресурси як потужну, масштабовану та відносно анонімну інфраструктуру для атак.
Атака Chaos на вразливий Hadoop: як працює компрометація хмари
Фахівці Darktrace зафіксували новий варіант malware Chaos під час атаки на свій honeypot — навмисно уразливий кластер Hadoop із можливістю віддаленого виконання коду. Такі «пастки» моделюють типові помилки конфігурації у хмарі й дозволяють відстежити реальну тактику зловмисників.
Ланцюжок атаки стартував з HTTP‑запиту до сервісу Hadoop, який ініціював створення нового застосунку. Усередину цієї операції було вбудовано послідовність оболонкових команд: завантаження бінарного агента Chaos з домену pan.tenire[.]com, надання йому максимальних прав через «chmod 777», запуск виконання та подальше видалення файла з диска для мінімізації цифрових артефактів.
Такий підхід типовий для атак на хмарну інфраструктуру: зловмисники знаходять сервіс із надмірними правами або помилковою конфігурацією (Hadoop, Docker, Kubernetes тощо), використовують його як точку входу, закріплюють шкідливий код і включають сервер до складу ботнета.
Походження Chaos: еволюція Kaiji та зв’язок із кібергрупами з Китаю
Шкідливе ПЗ Chaos вперше детально описали аналітики Black Lotus Labs у 2022 році як кросплатформену малварь для Windows і Linux. Базовий функціонал включав віддалене виконання команд, завантаження додаткових модулів, перебір SSH‑ключів для поширення, майнінг криптовалют та проведення DDoS‑атак по HTTP, TLS, TCP, UDP і WebSocket.
Chaos вважають подальшим розвитком сімейства Kaiji, яке раніше активно експлуатувало погано захищені Docker‑інстанси. Наявність серверів на території Китаю та китайських рядків у коді дала підстави припускати участь операторів з КНР, хоча остаточна атрибуція поки що відсутня.
Інфраструктура нинішніх атак пов’язана з діяльністю групи Silver Fox, що раніше використовувала домен pan.tenire[.]com у фішингових кампаніях для доставки документів‑приманок і малварі ValleyRAT. Дослідники Seqrite Labs відносили цю активність до операції Operation Silk Lure, що ілюструє типову для кіберзлочинців практику багаторазового використання вже «обкатаних» доменів і серверів.
Новий технічний профіль Chaos: ELF‑бінарник та вбудований SOCKS‑проксі
На скомпрометованих вузлах розгортається 64‑бітний ELF‑файл — оновлена збірка Chaos. За спостереженнями Darktrace, ключові можливості збережено, однак архітектуру суттєво перероблено, а фрагменти коду, пов’язані з Kaiji, переписані або глибоко відрефакторені.
Найважливіша зміна — повна відмова від функцій самопоширення, зокрема брутфорсу SSH та експлуатації вразливих роутерів. Натомість у новій версії з’явилася вбудована підтримка SOCKS‑проксі, що перетворює заражений хмарний сервер на транзитний вузол для трафіку зловмисників.
SOCKS‑проксі дозволяє прокидати майже будь‑який мережевий трафік через скомпрометовану машину, маскуючи реальне походження з’єднань. Для служб безпеки це означає, що атаки виглядають як такі, що виходять із легітимних IP‑адрес хмарних провайдерів, тоді як справжні оператори знаходяться на кілька «стрибків» глибше в ланцюгу проксі.
Монетизація Chaos: від DDoS і майнінгу до проксі‑сервісів
Додавання SOCKS‑функціоналу вказує на зміну моделі заробітку. Якщо раніше Chaos приносив прибуток через майнінг криптовалют та послуги DDoS‑for‑hire, то тепер оператори можуть продавати анонімні проксі‑канали на підпільних майданчиках. Схожий зсув спостерігається й в інших ботнетах, наприклад, AISURU, де проксі‑можливості стають головним «товаром».
Для організацій це означає, що захоплений хмарний сервер здатен використовуватися не лише для DDoS‑атак, а й як анонімний шлюз для фішингу, зломів, маскування командно‑контрольних (C2) серверів і обходу гео‑ та IP‑блокувань. У результаті компанія ризикує зіткнутися з блокуванням власних IP‑адрес, репутаційними втратами й юридичними претензіями, навіть якщо безпосереднього витоку даних не відбулося.
Як захистити хмарну інфраструктуру від Chaos та подібних ботнетів
Жорстке налаштування сервісів і контроль доступу
Успішні атаки Chaos базуються насамперед на помилках конфігурації. Варто обмежити або вимкнути віддалене виконання коду в Hadoop, Docker, Kubernetes та інших платформах, запровадити принцип найменших привілеїв і виключити анонімний доступ. Адміністративні панелі слід розміщувати в ізольованих сегментах мережі, захищати VPN‑доступом і багатофакторною автентифікацією.
Моніторинг аномальної активності та мережевого трафіку
Системи NDR/EDR і засоби моніторингу мають виявляти аномальні мережеві патерни: нестандартні вихідні з’єднання до рідкісних доменів, різкі стрибки TCP/UDP‑трафіку, нетипові сплески HTTP‑запитів. Важливі індикатори компрометації — запуск wget/curl із зовнішніми URL, масове застосування «chmod 777», поява невідомих ELF‑файлів у тимчасових або нестандартних каталогах.
Керування вразливостями та готовність до інцидентів
Регулярне оновлення ОС і middleware, аудит конфігурацій за еталонами безпеки (наприклад, CIS Benchmarks), періодичні пентести й відпрацювання планів реагування на інциденти суттєво знижують шанси ботнета Chaos закріпитися в інфраструктурі. Критично важливо мати актуальні резервні копії та налагоджені процедури швидкої ізоляції скомпрометованих хмарних вузлів.
Еволюція ботнета Chaos наочно показує, як швидко кіберзлочинці адаптуються до хмарної екосистеми та попиту на анонімізацію трафіку. DDoS‑атаки вже не є єдиною чи головною загрозою: заражений сервер може стати частиною розподіленої проксі‑мережі, що обслуговує широкий спектр незаконних операцій. Саме зараз доцільно переглянути конфігурації хмарних сервісів, посилити моніторинг та підготовку персоналу, щоб не дозволити власній інфраструктурі перетворитися на інструмент чужих атак.
