Атаките срещу инфраструктурата на големите езикови модели могат да генерират над 100 000 долара измамни разходи дневно. Google GTIG и Mandiant идентифицират две групи заплахи, които компрометират облачни ресурси и препродават достъпа до тях.

Компрометираният ИИ достъп се превръща в бизнес

Атаките, известни като LLMjacking, позволяват на киберпрестъпници да използват чужда инфраструктура за големи езикови модели (LLM), като прехвърлят разходите за обработка на заявките към законните собственици на облачните ресурси.

Според Google Threat Intelligence Group (GTIG) и Mandiant измамните начисления при анализирани инциденти са надхвърляли 100 000 долара дневно, а в някои организации общите разходи са достигнали 1 милион долара.

Изследователите установяват два основни типа атакуващи: едните сканират за публично достъпни крайни точки на LLM услуги, а другите крадат валидни API ключове от недостатъчно защитени системи.

След компрометирането достъпът се препродава на посреднически услуги, известни като LLM mixers. Те пренасочват заявките на клиентите си към чуждите ИИ ресурси, използвайки откраднатите ключове.

Рязко увеличение на заявките и разходите

След препродажбата трафикът може да надхвърли 1000 заявки в секунда. Облачният доставчик отчита това като легитимно потребление и фактурира токените на организацията-жертва.

Посредническите услуги предлагат достъп до модели на ниски цени чрез прокси инфраструктура. Сред наблюдаваните услуги са Jet Night, рекламираща „неограничен достъп“ срещу 60 долара месечно, и newapi[.]pro.

Google описва случай с над 500 000 API заявки за по-малко от осем часа, извършени чрез откраднати ключове на трети страни. Трафикът е пренасочван през jet-night.com, която според компанията е прехвърлила почти 1 милион долара разходи за токени към жертвата.

Изследователите са идентифицирали и клъстера UNC6993, който използва шлюзови инструменти за агрегиране на откраднати ключове и разпределяне на заявките. Достъпът вероятно се продава и чрез подземни форуми.

Кражба на ключове и поддържане на достъпа

Атакуващите използват компрометирани облачни идентификационни данни, ключове на служебни акаунти, GitHub токени, активни токени за сесии и API ключове за LLM услуги.

След проникването те търсят допълнителни тайни в системни дневници, бази данни и хранилища за тайни. За запазване на достъпа могат да създават скрити акаунти или да добавят SSH ключове.

Google е наблюдавала и експлоатация на CVE-2026-40217 в LiteLLM – уязвимост, която позволява изпълнение на произволен код на сървъра чрез крайна точка за тестване на защитни механизми с персонализиран код.

В някои случаи компрометираната облачна инфраструктура се използва за хостване на неоторизирани прокси услуги и агентни работни процеси. Един от атакуващите е разположил публични обратни прокси сървъри и пакети за прокси маршрутизиране, разработени с Node.js, предоставящи достъп до множество водещи LLM модели под идентичността D1337-KAIROS.

Препоръки за защита

Google поставя управлението на идентичностите и достъпа (IAM) и сигурността на веригата за доставки сред основните приоритети.

Организациите трябва да:

• използват централизирани платформи за управление и ротация на API ключове и други тайни;
• ограничават правата за достъп до необходимите за конкретната роля;
• отказват всички разрешения, които не са изрично необходими, включително достъп до облачни LLM услуги;
• прилагат многофакторно удостоверяване (MFA), устойчиво на фишинг;
• наблюдават за неоторизирани ИИ услуги и скрито използване на ИИ (shadow AI);
• задават лимити за API потребление и разходи.

Необходимо е също да бъдат активирани и наблюдавани облачните одитни дневници и дневниците за изпълнение на заявки към моделите. Те могат да разкрият неоторизирано активиране на услуги, подозрителни проверки на идентификационни данни, необичайно потребление и опити за изключване на регистрирането на събития.

Финансовият мониторинг е част от сигурността

LLMjacking съчетава компрометиране на инфраструктурата с директен финансов риск. Атакуващите използват чуждите ресурси за собствена печалба, оставяйки сметката на жертвата.

Затова мониторингът на сигурността трябва да бъде свързан с облачните бюджети, API лимитите и автоматичните известия за необичайни разходи. Рязкото увеличение на заявките или токените може да бъде едновременно сигнал за компрометиране и предупреждение за значителни финансови загуби.