Зловмисник використовував агента для програмування, щоб збирати доступ до чужих сервісів ШІ та будувати на ньому власний сервіс. Аж поки агент не обрав дослідницьку пастку як безкоштовний бекенд ШІ. Разом із запитами він передав приблизно 43 КБ власного робочого контексту зловмисника: інструкції, зібрані API-ключі, скрипти розвідки, нотатки про інфраструктуру, попередні цілі та частину історії роботи.
У звіті від 11 вересня дослідник SANS Internet Storm Center Ренато Маріньйо відтворив операцію за серією перехоплених запитів. Тут цікаві обидві сторони обміну: як зловмисник зібрав працездатний пул доступу до ШІ та як вибір бекенду розкрив досліднику роботу за лаштунками.
1. Агент обрав безкоштовний бекенд — і надіслав робочий контекст
Пастка Маріньйо імітувала сумісну з OpenAI точку доступу до моделей: API, що приймає запити у звичному для клієнтів ШІ форматі. Агент неодноразово обирав її як безкоштовний бекенд. Сумісність дозволяла надсилати запити, але нічого не говорила про власника сервісу.
Саме цей клієнт додавав до запитів моделі робочі інструкції та контекст сеансу. Приблизно 43 КБ містили великий файл інструкцій AGENTS.md, план атак і матеріали поточної операції. Отже, дослідник отримав значно більше, ніж запитання до моделі: що робить агент, як йому наказано діяти, які облікові дані та цілі він уже зібрав.
Проблема виникла в момент надсилання контексту. У публічному описі клієнт передає його у звичайних запитах. Дослідник не описує попереднього злому комп’ютера зловмисника чи виманювання даних через ін’єкцію промпту. Сервіс може дізнатися конфіденційні відомості просто тому, що клієнт довірив йому обробити запит.
2. Навіть інструкція перевірки проксі дещо розкрила
План наказував агенту перед атакою перевірити, чи працює проксі. Для порівняння в ньому була записана пряма вихідна IP-адреса оператора — без проксі. Сама ця інструкція потрапила до пастки.
Показова помилка: запобіжний захід для перевірки прихованого мережевого маршруту містив інформацію, яку мав допомогти приховати. Навіть якщо з’єднання надходить через проксі, сервіс-одержувач читає адресу, записану всередині запиту. HTTPS також захищає дані дорогою до сервісу, але не приховує вміст запиту від його оператора.
3. Доступ шукали через звичайні слабкі місця шлюзів
Зафіксований робочий процес використовував FOFA — пошуковик інтернет-ресурсів — для пошуку шлюзів LLM та пов’язаної інфраструктури підписок. Запити орієнтувалися на характерні заголовки сторінок і HTTP-заголовки підписок. Так агент знаходив кандидатів для перевірки; сама поява ресурсу в пошуку ще не доводила його компрометації.
План отримання доступу містив кілька шляхів:
- Безкоштовні стартові баланси та пробні акаунти. Відкрита реєстрація давала початковий кредит. Тимчасова пошта та сервіси розв’язання CAPTCHA допомагали автоматизувати створення пробних облікових записів.
- Стандартні облікові дані. Відомі початкові логін і пароль, які залишили без змін, відкривали шлях до акаунта або панелі.
- Слабка перевірка прав. План шукав проблеми авторизації, пов’язані з переданим клієнтом полем
group_id, та відкриті точки керування обліковими даними, зокрема/api/auth-files.
Ці шляхи відрізняються. Масове отримання пробних кредитів зловживає умовами пропозиції; викрадені ключі або помилка авторизації порушують іншу межу доступу. Спільною метою були придатні до використання обчислювальні ресурси ШІ. Звіт не встановлює, що кожен перелічений спосіб спрацював на кожному зібраному підключенні.
Деталь із правами важлива: ідентифікатор від клієнта має вказувати, який ресурс він просить, а не доводити його право на цей ресурс. У цій операції агент шукав сервіси, де ця межа або базовий захист акаунтів були достатньо слабкими, щоб отримати доступ.
4. Робочий ключ був лише початком перевірки
Агент тестував зібрані ключі на сервісах перепродажу доступу. Частина точок рекламувала преміальні моделі, деякі показували надзвичайно високі стандартні платіжні ліміти, а ще одна віддавала повний каталог моделей без автентифікації. Жодна з цих ознак окремо не доводила доступності чи справжності заявленої моделі.
Згодом у робочому процесі з’явилося просте обчислення факторіала — тест логіки коду, покликаний відрізнити придатну до роботи модель від заготовлених відповідей. Для зловмисника це був практичний фільтр: сервіс, який лише приймає ключ, мало корисний, якщо не може виконати просте завдання.
Успішний тест усе одно не підтверджував назву моделі. Посередник може прив’язати відому назву до іншого бекенду. Докази підтверджують робочі відповіді під заявленими назвами, а не незалежно перевірений доступ саме до цих моделей. Високий показаний платіжний ліміт також не встановлює фактичних витрат чи збитків потерпілого.
5. Приблизно 379 підключень звели до одного робочого API
Пізніший запис показав побудову сервісу-агрегатора. Оператор розгорнув власний шлюз New-API — легітимний проєкт із відкритим кодом — і завантажив до нього приблизно 379 зовнішніх точок доступу як канали, використовуючи зібрані облікові дані.
Після тестування процес вимкнув 341 канал, що виявився фальшивим або непрацездатним. На решту каналів призначили п’ять стандартних назв моделей, налаштували почергове спрямування запитів з урахуванням пріоритетів та автоматичне перемикання в разі відмови. Завершальна перевірка отримала придатні відповіді під усіма п’ятьма налаштованими назвами через один шлюз.
Так операція вийшла за межі колекції ключів. Шлюз міг обирати серед робочих підключень і пробувати інше в разі відмови, подаючи весь пул клієнтам як єдиний сервіс. Облікові дані були вхідним матеріалом; результатом стала доступна через спільний API обчислювальна потужність ШІ.
Цифри означають різні речі: 379 — імпортовані канали, 341 — вимкнені канали, п’ять — налаштовані назви моделей. Це не кількість зламаних компаній, потерпілих або незалежно підтверджених моделей. Звіт також не показує, що дослідницька пастка була серед каналів, які залишилися працювати.
Маріньйо спостерігав цикл під керуванням людини: агент допомагав знаходити доступ, перевіряти його та збирати потужності для подальшої роботи. Повністю автономного самовідтворення він не продемонстрував. Споріднена проблема викрадення API-ключів ШІ стає для зловмисника кориснішою, коли нестабільні підключення можна об’єднати в один робочий сервіс.
6. Коли завадила власна панель, агент змінив базу даних
Ліміти частоти запитів у власному шлюзі заблокували частину автоматизації. Агент відповів прямим редагуванням бази SQLite: очистив записи сеансів і вставив токен адміністратора.
Це сталося на шлюзі самого оператора. Епізод показує, який контроль агент мав над цим середовищем, а не доводить обхід захисту чужого хостингового сервісу. Обмеження вебпанелі не є дієвою межею для того, хто може переписати базу даних, на якій ця панель працює.
Що насправді показує цей випадок
Найвиразніший урок — у самому розвороті подій. Поки зловмисник перевіряв працездатність чужого доступу до ШІ, його агент надіслав власний робочий контекст неперевіреному одержувачу. Бекенду не довелося викрадати ці дані з комп’ютера. Клієнт доставив їх сам.
Джерело
- Ренато Маріньйо, SANS Internet Storm Center, 11 вересня 2026 року: Дослідження збирання та повторного надання чужого доступу до моделей ШІ. Дата публікації звіту не встановлює дат самих перехоплень.
