Останніми тижнями зафіксовано активність нового ботнету під назвою NadMesh, написаного на мові програмування Go, який цілеспрямовано полює на хмарні облікові дані та токени Kubernetes через уразливі та відкриті інтерфейси систем штучного інтелекту. За інформацією дослідників безпеки, оператори цього ботнету вже отримали доступ до щонайменше 3811 унікальних ключів доступу AWS. Головна небезпека полягає в тому, що розробники та DevOps-інженери розгортають популярні інструменти для роботи з великими мовними моделями (LLM) та генеративного ШІ без належного захисту мережі та автентифікації.

Схема збору цілей для NadMesh побудована на автоматизованому скануванні мережі Інтернет. Зловмисники використовують пошукову систему Shodan для безперервного пошуку відкритих портів, на яких працюють популярні інструменти машинного навчання та автоматизації. До списку цілей входять такі сервіси, як ComfyUI, Ollama, n8n, Open WebUI, Langflow та Gradio. Ці рішення часто запускаються командами розробників у тестових режимах швидкого прототипування, без налаштування міжмережевих екранів, що робить їх легкими мішенями для автоматизованих сканерів.

Після виявлення доступного ШІ-сервісу ботнет NadMesh намагається провзаємодіяти з його API або веб-інтерфейсом. Оскільки більшість із цих інструментів у конфігурації за замовчуванням не вимагають авторизації або мають уразливості, що дозволяють віддалене виконання коду (RCE) або довільне читання файлів, атака відбувається миттєво. Отримавши доступ, шкідливе програмне забезпечення досліджує змінні оточення (environment variables) та локальні конфігураційні файли у пошуках чутливих даних. Зокрема, ботнет шукає збережені хмарні облікові дані у директорії ~/.aws/credentials, токени доступу Kubernetes у системних каталогах контейнерів, а також ключі API до інших комерційних ШІ-платформ, як-от OpenAI або Anthropic.

Захоплення ключів AWS та токенів Kubernetes дає зловмисникам повний контроль над хмарною інфраструктурою компанії. Замість банального використання серверів для майнінгу криптовалюти, зловмисники отримують доступ до конфіденційних баз даних, сирцевого коду у репозиторіях та внутрішніх мереж підприємства. Оскільки багато компаній інтегрують ШІ-сервіси безпосередньо у свої робочі процеси, компрометація одного такого інструменту стає точкою входу для масштабних атак на всю корпоративну інфраструктуру. Наявність тисяч скомпрометованих хмарних ключів на панелі керування ботнету свідчить про промислові масштаби цієї операції.

Головна передумова успіху NadMesh — це феномен «тіньового ШІ» (Shadow AI), коли інженерні команди самостійно, без погодження з відділом інформаційної безпеки, розгортають локальні моделі Ollama чи інтерфейси Gradio для швидких експериментів. Оскільки ці інструменти призначені для внутрішнього тестування, питання безпеки в них розробники часто відсувають на другий план. Коли тестовий сервер із ComfyUI чи Open WebUI випадково публікується у зовнішню мережу без обмеження доступу, він стає доступним для Shodan протягом кількох годин, після чого ботнет автоматично здійснює його експлуатацію.

Що це означає на практиці

Як пентест-команда, ми рекомендуємо негайно вжити наступних заходів для захисту вашої інфраструктури від автоматизованих сканерів на кшталт NadMesh:

  • Проведіть аудит відкритих портів: Використовуйте інструменти зовнішнього сканування (Nmap або власні запити в Shodan/Censys) для пошуку відкритих портів у ваших підмережах. Особливу увагу зверніть на стандартні порти ШІ-сервісів: 11434 (Ollama), 8188 (ComfyUI), 7860 (Gradio, Stable Diffusion WebUI), 3000 / 8080 (Open WebUI), 5678 (n8n). Жоден із цих інтерфейсів не має бути доступним з публічного Інтернету.
  • Впровадьте автентифікацію перед проксі: Якщо розробникам необхідний віддалений доступ до інтерфейсів типу ComfyUI або Gradio, ніколи не публікуйте їх напряму. Захистіть їх за допомогою зворотного проксі-сервера (наприклад, Nginx) з увімкненою автентифікацією Basic Auth, інтегруйте їх із корпоративним SSO через Cloudflare Tunnel, Authelia або налаштуйте доступ виключно через корпоративний VPN чи Tailscale.
  • Обмежте права доступу хмарних сервісних акаунтів: Дотримуйтесь принципу найменших привілеїв. Якщо контейнер із ШІ-інструментом запущено в AWS або Kubernetes, не призначайте йому ролі з широкими правами (наприклад, AdministratorAccess). Використовуйте механізми IAM Roles for Service Accounts (IRSA) в Kubernetes, щоб обмежити доступ лише до тих ресурсів (наприклад, конкретного бакета S3), які дійсно необхідні для роботи моделі.
  • Ізолюйте середовища розробки: Середовища, де розробники тестують нові ШІ-інструменти та бібліотеки, мають бути фізично або логічно ізольовані від продуктової мережі. Використовуйте мережеві політики (NetworkPolicies) у Kubernetes для заборони вихідного трафіку з ШІ-контейнерів до чутливих внутрішніх сервісів, зокрема до сервісу метаданих хмари (у хмарі AWS сервіс IMDS доступний за адресою 169.254.169.254 — доступ до нього з контейнерів розробки має бути заблоковано).