От фишинга к LLMjacking: злоумышленники атакуют облачные биллинговые аккаунты ради использования LLM

Источник: wiz.io•

От фишинга к LLMjacking: злоумышленники атакуют облачные биллинговые аккаунты ради использования LLM

Как один клик по рекламе в Google Search приводит к краже учетных данных, взлому облачного биллингового аккаунта и сотням тысяч долларов убытков из-за несанкционированного использования AI API

Команда реагирования на инциденты Wiz (CIRT) исследовала растущую тенденцию угроз в облачных средах: злоумышленники взламывают облачные биллинговые аккаунты для финансирования несанкционированного использования ИИ. Злоумышленники не просто используют ИИ как инструмент для проведения атак — они также компрометируют среды жертв исключительно ради злоупотребления их финансами для масштабного запуска больших языковых моделей (LLM), что влечет за собой расходы на AI API в сотки тысяч долларов.

Wiz CIRT расследовала несколько вторжений, демонстрирующих этот паттерн, причем данный пост в блоге посвящен конкретно кампаниям, нацеленным на инфраструктуру Google Cloud Platform (GCP). В ходе этих атак злоумышленники скомпрометировали привилегированные учетные записи пользователей GCP и связали внешние, управляемые злоумышленниками проекты GCP напрямую с внутренними биллинговыми аккаунтами жертвы. Поскольку рабочие нагрузки ИИ обрабатывались во внешних проектах, содержимое промптов и выходы моделей оставались полностью скрытыми от организации-жертвы, из-за чего масштабное использование ИИ оставалось неизвестным.

В этом посте подробно описывается полный жизненный цикл атак, наблюдавшийся во время этих вторжений — от первичного фишинга и манипуляций с политиками до межтенантной связки проектов, а также приводятся практические рекомендации по охоте за угрозами, которые помогут организациям обнаружить LLMjacking в своих средах.

Первичный доступ: фишинг через спонсируемую поисковую рекламу

Атака началась с классической, но эффективной фишинговой тактики. Злоумышленник купил рекламу в Google Search по популярным административным поисковым запросам, таким как «google cloud» и «gcp». Когда пользователь нажимал на вредоносную рекламу, его перенаправляли через редирект Google Sites на поддельную веб-страницу входа в Google. Пользователи-жертвы, имеющие законный доступ к Google Console, вводили учетные данные своей учетной записи и коды многофакторной аутентификации (MFA) на фишинговой странице. Вредоносный сайт перехватывал предоставленные пользователем учетные данные и одновременно плавно перенаправлял пользователя обратно на легитимный запрос аутентификации Google. Вынужденный проходить аутентификацию во второй раз, пользователь, вероятно, предполагал, что первая попытка была незначительным сбоем. На самом деле автоматизированный фишинговый набор сразу же использовал собранные учетные данные для выполнения первого вредоносного входа в среду GCP жертвы с IP-адреса 212.73.134[.]136, который являлся исходным IP-адресом фишингового набора. Затем через несколько минут злоумышленник повторно прошел аутентификацию со второго IP-адреса, который позже использовался для всей остальной активности в GCP. После сообщений об этой активности Google Ads приняла меры по удалению вредоносной рекламной кампании.

Google автоматически пометил аномальную попытку входа как подозрительную и отправил электронные письма с предупреждениями безопасности во входящие сообщения пользователя. Однако для раннего выявления таких вторжений организациям не следует полагаться только на осведомленность пользователей — необходимо собирать и отслеживать события входа пользователей в Google Workspace (User Log Events) на предмет флагов подозрительного входа и аномальных триггеров повторной аутентификации.

Закрепление в системе и эскалация привилегий: отключение защитных механизмов и вынос биллинга наружу

Оказавшись внутри среды, злоумышленник использовал избыточные привилегии скомпрометированной учетной записи, чтобы закрепить свой доступ, обойти организационные средства контроля безопасности и подготовить биллинговую архитектуру к внешней эксплуатации.

Включение API и создание учетных записей служб (Service Account)

Вместо создания новой инфраструктуры с нуля злоумышленник нацелился на существующие проекты GCP с низким уровнем использования, чтобы:

  • Включить продукт Gemini API

Включить продукт Gemini API

  • Создать учетные записи служб с ключами Gemini API

Создать учетные записи служб с ключами Gemini API

  • Добавить созданные учетные записи служб в роли с высоким уровнем привилегий, такие как roles/ml.admin и roles/mcp.toolUser

Добавить созданные учетные записи служб в роли с высоким уровнем привилегий, такие как roles/ml.admin и roles/mcp.toolUser

Демонтаж элементов управления организационной политики

Чтобы расширить свое присутствие без поднятия тревоги в рамках внутреннего управления доменами, злоумышленник удалил политики безопасности на уровне организации, такие как iam.allowedPolicyMemberDomains. Это действие устранило защитный барьер, который ограничивает членство в управлении доступом и идентификацией (IAM) проверенными доменами компании, позволяя предоставлять доступ внешним личным учетным записям, а также правам с высоким уровнем привилегий.

Приглашение учетных записей внешних злоумышленников и повышение привилегий

После снятия ограничений домена скомпрометированная учетная запись пользователя была использована для добавления контролируемых внешним злоумышленником учетных записей Gmail непосредственно в биллинговый аккаунт организации.

Злоумышленник также назначил административные роли скомпрометированным пользователям или внешним учетным записям, таким как:

  • roles/recommender.billingAccountCudAdmin для проектов GCP

roles/recommender.billingAccountCudAdmin для проектов GCP

  • roles/billing.admin для биллинговых аккаунтов GCP

roles/billing.admin для биллинговых аккаунтов GCP

Роль roles/billing.admin предоставила полный контроль над биллинговым аккаунтом, включая возможность управлять разрешениями, подключать внешние проекты и изменять настройки платежей.

Связывание внешних проектов для масштабной эксплуатации

Злоумышленник связал внешние проекты GCP напрямую с внутренним биллинговым аккаунтом жертвы. Этот шаг установил межтенантный доступ, позволяя автоматически списывать средства по всем запросам API, выполненным во внешних проектах злоумышленников, на биллинговый аккаунт жертвы, сохраняя при этом полезные нагрузки промптов невидимыми для мониторинга внутренних журналов.

Обход средств защиты: географическое смещение и блокировка администраторов

После обеспечения первоначального доступа злоумышленники применили методы обхода защиты, призванные избежать срабатывания предупреждений безопасности на основе местоположения и не позволить группам безопасности вернуть контроль.

Во всех расследованных случаях вторжения команда Wiz CIRT отметила, что после первоначального входа последующая активность злоумышленников исходила с IP-адресов, геолокация которых соответствовала стране штаб-квартиры каждой организации-жертвы, даже если это не совпадало с фактическим физическим местоположением скомпрометированного пользователя.

Кроме того, после обеспечения административного контроля злоумышленники понизили роли существовавших ранее внутренних администраторов биллинга с административных до уровня пользователей с правами только на чтение (billing viewers). Эта модификация лишила легитимных администраторов возможности отзывать разрешения или отсоединять посторонние проекты непосредственно из консоли.

Влияние: злоупотребление ресурсами ИИ

Основной целью этих вторжений была неразрушающая финансовая эксплуатация — использование взломанной облачной инфраструктуры для перекладывания расходов на высокообъемный инференс LLM. Во всех наблюдавшихся случаях последствия проявлялись в виде резких скачков расходов на выставление счетов, вызванных автоматизированным крупномасштабным использованием Gemini API.

В течение 24–48 часов после получения первоначального доступа организации-жертвы столкнулись с неожиданными расходами, достигшими от десятков до сотен тысяч долларов за несанкционированное использование Gemini API. Эта активность представляла собой резкий всплеск по сравнению с установленными базовыми расходами организаций на вычисления.

Поскольку злоумышленники связали внешние, управляемые ими проекты GCP напрямую с платежными аккаунтами жертвы, вся генерация API-ключей, запросы промптов и вывод моделей происходили полностью внутри сторонних тенантов. В результате, хотя финансовая ответственность за использование API легла на пострадавшую организацию, внутренние журналы безопасности и аудита не давали никакого представления о характере, содержимом или контексте выполняемых задач ИИ.

Индикаторы обнаружения и охоты за угрозами

Для обнаружения потенциального LLMjacking и несанкционированного изменения платежных аккаунтов в вашей среде Google Cloud команды безопасности должны искать индикаторы в журналах аудита Google Workspace, GCP Admin Activity и Cloud Billing. Клиенты Wiz могут ознакомиться с рекомендациями в Центре аналитики угроз (Threat Intel Center), которые включают следующие индикаторы:

  • Проверьте журналы аудита Google Workspace и GCP на предмет активности по индикаторам компрометации из приведенного ниже раздела. Клиенты Wiz могут использовать этот запрос Cloud Events.

Проверьте журналы аудита Google Workspace и GCP на предмет активности по индикаторам компрометации из приведенного ниже раздела. Клиенты Wiz могут использовать этот запрос Cloud Events.

  • Проверьте GCP IAM на наличие пользователей с внешними доменами, особенно сторонних почтовых провайдеров, таких как @gmail.com. Клиенты Wiz могут использовать этот запрос Cloud Events, заменив domain.com на собственный домен организации.

Проверьте GCP IAM на наличие пользователей с внешними доменами, особенно сторонних почтовых провайдеров, таких как @gmail.com. Клиенты Wiz могут использовать этот запрос Cloud Events, заменив domain.com на собственный домен организации.

  • Проверьте журналы аудита GCP на предмет изменений в элементах управления политикой организации, особенно allowedPolicyMemberDomains, и изменений политик IAM, связанных с администраторами платежных аккаунтов. Клиенты Wiz могут использовать этот запрос Cloud Events.

Проверьте журналы аудита GCP на предмет изменений в элементах управления политикой организации, особенно allowedPolicyMemberDomains, и изменений политик IAM, связанных с администраторами платежных аккаунтов. Клиенты Wiz могут использовать этот запрос Cloud Events.

  • Проверьте журналы аудита GCP на предмет неожиданного включения Gemini API, создания сервисных аккаунтов и создания API-ключей сервисных аккаунтов в старых проектах. Клиенты Wiz могут использовать этот запрос Cloud Events.

Проверьте журналы аудита GCP на предмет неожиданного включения Gemini API, создания сервисных аккаунтов и создания API-ключей сервисных аккаунтов в старых проектах. Клиенты Wiz могут использовать этот запрос Cloud Events.

  • Следите за аномальным ростом затрат на использование API и при необходимости устанавливайте бюджетные лимиты расходов. Клиенты Wiz Cloud Cost могут обнаруживать аномальное использование ИИ в разрезе моделей и облачных провайдеров, отслеживая результаты мониторинга затрат (Cost Monitor Findings) на предмет ресурсных аномалий.

Следите за аномальным ростом затрат на использование API и при необходимости устанавливайте бюджетные лимиты расходов. Клиенты Wiz Cloud Cost могут обнаруживать аномальное использование ИИ в разрезе моделей и облачных провайдеров, отслеживая результаты мониторинга затрат (Cost Monitor Findings) на предмет ресурсных аномалий.

Клиенты Wiz Defend, получающие облачные логи, такие как Google Workspace, будут получать предупреждения Wiz Threats о начальных входах в систему. Клиенты, получающие журналы аудита GCP, будут получать предупреждения Threats об описанной активности.

Если вы столкнулись с взломом или любым инцидентом облачной безопасности, обратитесь в Wiz CIRT за поддержкой по реагированию на инциденты.

Индикаторы компрометации

О чём эта статья

Ещё в разделе «Кибербезопасность»

Все →

Ещё от Wiz