Идентификация уже давно стала основным вектором атак в облаке. Вредоносное ПО класса «инфостилер», распространяемое через индустриализированную экономику киберпреступности, является ведущим вектором первоначального доступа для компрометации корпоративных облачных сред, сред разработки и ИИ. Нацеливаясь на незащищенные конечные точки разработчиков с помощью социальной инженерии и атак на цепочку поставок, злоумышленники крадут учетные данные, ключи API и активные токены сеансов, тем самым обходя более надежные средства защиты, которые ограждают большинство облачных сред от прямых атак.
Краденые учетные данные широко признаны одним из самых распространенных векторов первоначального заражения — Microsoft, Recorded Future и DBIR от Verizon указывают на инфостилеры как на причину серьезной озабоченности. Эти атаки начинаются с простой заражения вредоносным ПО на личным устройстве, а заканчиваются тем, что злоумышленники получают привилегированный доступ к вашей инфраструктуре AWS, Azure или GCP, а в последнее время — и к платформам для работы с кодом, используемым вашей организацией, таким как GitHub или GitLab.
Понимание того, как это происходит, — первый шаг к созданию устойчивой защиты. Поэтому мы решили составить карту различных облачных ключей, на которые нацелено вредоносное ПО для кражи информации, и определить ценность, которую злоумышленники могут из них извлечь.
Что такое инфостилеры и какие секреты они крадут?
Современные атаки с использованием инфостилеров являются результатом зрелой, многоуровневой цепочки поставок, обслуживающей злоумышленников. Все начинается с платформ «вредоносное ПО как услуга» (MaaS), где мощные инфостилеры, такие как Lumma и RedLine, сдаются в аренду всего за несколько сотен долларов в месяц. Эти инструменты созданы для одной цели: быстрого и скрытного сбора данных. Они выполняются, собирают учетные данные и эксфильтрируют данные за считанные секунды, часто с устройств, на которых установлено актуальное антивирусное ПО.
Затем украденные журналы данных продаются на подпольных торговых площадках, часто через брокеров первоначального доступа (IAB). Эти брокеры курируют логи, проверяют ценные учетные данные и продают подтвержденный доступ высокоуровневым злоумышленникам, таким как картели вирусов-вымогателей. Такая система означает, что время от ошибочного клика сотрудника по фишинговой ссылке до продажи его корпоративных облачных учетных данных может составлять от нескольких часов до многих недель или месяцев.
Тем не менее, вредоносное ПО крадет не только пароли, оно также нацелено на несколько методов аутентификации и ключи API, чтобы извлечь максимум выгоды из жертвы, в том числе:
- Ключи API и секретные ключи: часто встречаются в конфигурационных файлах разработчиков.
Ключи API и секретные ключи: часто встречаются в конфигурационных файлах разработчиков.
- Активные файлы cookie сеансов и токены: позволяют обходить многофакторную аутентификацию (MFA) путем перехвата уже аутентифицированного сеанса.
Активные файлы cookie сеансов и токены: позволяют обходить многофакторную аутентификацию (MFA) путем перехвата уже аутентифицированного сеанса.
Наш анализ секретов, обнаруженных на зараженных машинах с помощью интеграции Wiz с NordStellar, выявляет концентрированный ландшафт угроз, в котором доминирует небольшое число плодовитых семейств инфостилеров: Lumma C2, RedLine и Vidar составляют 85,7% всех обнаруженных инцидентов, подчеркивая комодитизацию экосистемы инфостилеров, где горстка предложений вредоносного ПО как услуги, по-видимому, доминирует на подпольном рынке.
В частности, NordStellar identifies более 400 различных типов секретов, не являющихся учетными данными, что демонстрируют, что злоумышленники забрасывают широкие сети, чтобы монетизировать любой доступ, который они могут получить.
Украденные учетные данные облачных сервисов являются основной добычей инфостилеров: на AWS и GCP приходится 46% и 13% всех скомпрометированных секретов соответственно. Следующей крупной целью является GitHub, где токены приложений, токены OAuth и персональные токены доступа (PAT) составляют примерно 10% от общего числа. Платформы искусственного интеллекта также занимают значительную долю (5% украденных секретов), среди которых лидируют ключи API OpenAI. Эти учетные данные ИИ являются весьма прибыльными; они позволяют злоумышленникам свободно запускать свои собственные рабочие нагрузки или перепродавать доступ в рамках незаконного рынка перепродажи LLM. Кроме того, эти ключи потенциально могут предоставить доступ к историческим журналам чатов, которые могут содержать конфиденциальные корпоративные данные, однако нам не известно о публичных случаях возникновения такого сценария.
Наш анализ данных также показывает, что традиционные методы распространения вредоносного ПО по-прежнему играют важную роль: легитимные исполняемые файлы Windows, такие как vbc.exe (компилятор Visual Basic), часто используются злоумышленниками для выполнения, в то время как файлы, замаскированные под игры (например, Roblox.exe, Valorant SkinChanger.exe), указывают на нацеленность на персональные компьютеры разработчиков, которые часто защищены хуже, чем корпоративные конечные точки.
Совсем недавно вредоносное ПО, похожее на инфостилеры, такое как Miasma, нацелилось на CI/CD-пайплайны, серверы разработки и процессы сборки. В этих случаях фишинг не является применимым вектором первоначального доступа; вместо этого злоумышленники нацеливаются на часто используемую программную зависимость и перехватывают ее последнюю версию для внедрения вредоносного кода, который будет выполнен в средах жертв. Эти инфостилеры CI/CD нацелены на ключи API, облачные учетные данные, токены CI и артефакты развертывания, в конечном итоге злоупотребляя ими для деятельности после компрометации против корпоративных организаций.
От конечной точки до облака
Путь к компрометации облака начинается с устройства конечного пользователя, которое уже вошло в целевой сервис и недавно было заражено инфостилером. Вместо того чтобы пытаться взломать MFA, злоумышленники крадут токен сеанса, созданный после успешной аутентификации пользователя. Впоследствии используя этот украденный токен в собственном браузере, они получают доступ от имени легитимного пользователя, полностью обходя запросы MFA. Один-единственный действительный токен сеанса для корпоративной системы, особенно если у пользователя есть высокие привилегии или доступ к конфиденциальной информации, может открыть доступ ко многим ресурсам в облачной среде целевой организации. В качестве примера см. наше недавно опубликованное расследование в отношении JINX-0164.
Помимо перехвата сеансов, злоумышленники также могут использовать долгосрочные ключи и учетные данные, собранные инфостилерами, но их ценность различается в зависимости от целевой облачной среды, как подробно описано ниже.
Amazon Web Services (AWS)
В AWS злоумышленники концентрируются на двух основных типах секретов. Первые — это долгосрочные ключи доступа IAM, которые часто хранятся в виде обычного текста в конфигурационных файлах или исходном коде на рабочих станциях разработчиков. Второй целью является активный файл cookie сеанса для AWS Management Console. Кража этого файла cookie позволяет злоумышленнику по сути обойти требование MFA и получить прямой интерактивный доступ к облачным ресурсам жертвы, как описано выше.
Файлы cookie сеансов обычно извлекаются из дискового кэша каждого браузера. В современных браузерах их также можно извлечь непосредственно из памяти — либо путем внедрения кода в процесс браузера, либо путем подключения отладчика для чтения памяти с помощью API отладки.
При атаке на AWS основные файлы, представляющие интерес для злоумышленников, находятся в следующих местах (такие же файлы существуют в Windows в папке %USERPROFILE%).
- ~/.aws/config — хранит несекретные параметры конфигурации для AWS CLI и SDK, такие как регионы по умолчанию, форматы вывода и именованные профили.
~/.aws/config — хранит несекретные параметры конфигурации для AWS CLI и SDK, такие как регионы по умолчанию, форматы вывода и именованные профили.
- ~/.aws/credentials — содержит конфиденциальные ключи аутентификации, в частности AWS Access Key ID и Secret Access Key, разделенные по профилям.
~/.aws/credentials — содержит конфиденциальные ключи аутентификации, в частности AWS Access Key ID и Secret Access Key, разделенные по профилям.
- ~/.aws/cli/cache/ — временно хранит кэшированные ответы API и данные внутренних команд для повышения производительности AWS CLI и сокращения числа повторяющихся вызовов API.
~/.aws/cli/cache/ — временно хранит кэшированные ответы API и данные внутренних команд для повышения производительности AWS CLI и сокращения числа повторяющихся вызовов API.
- ~/.aws/sso/cache/ — содержит временные краткосрочные токены доступа и данные сеансов, создаваемые при аутентификации с помощью AWS IAM Identity Center (ранее AWS SSO).
~/.aws/sso/cache/ — содержит временные краткосрочные токены доступа и данные сеансов, создаваемые при аутентификации с помощью AWS IAM Identity Center (ранее AWS SSO).
Хотя файл конфигурации AWS (.aws/config) не содержит секретных данных, он точно указывает злоумышленнику, к каким профилям, ролям и учетным записям жертва имеет доступ. Злоумышленники комбинируют эти сведения с секретами, хранящимися в других каталогах.
Если файл учетных данных (.aws/credentials) настроен с помощью aws config, он включает фактические долгосрочные секреты, используемые для входа в AWS, а именно Access Key IDs и Secret Access Keys. По умолчанию временные токены SSO здесь не записываются; однако многие используемые разработчиками сторонние инструменты (например, gimme-aws-creds) могут внедрять временные токены в этот файл для совместимости со старыми SDK. Более безопасной альтернативой является использование таких инструментов, как Granted, которые задействуют связку ключей операционной системы.
Когда пользователь проходит аутентификацию через SSO с помощью aws sso login, полученные временные токены STS (Access Key, Secret Key и Session Token) кэшируются на уровне системы в папке кэша CLI (.aws/cli/cache/). Срок действия этих токенов составляет от 1 до 12 часов в зависимости от конфигурации организации. Это означает существование активного окна, в течение которого токен уязвим для немедленной эксфильтрации и использования. Из-за этого токены STS представляют меньшую ценность для операторов инфостилеров и их клиентов, если только они не смогут продать их немедленно.
Еще более критичной является папка кэша SSO (.aws/sso/cache/), которая содержит долгоживущие токены OIDC, создаваемые во время первоначального входа через SSO. Срок действия таких токенов обычно составляет до 90 дней. Если пользователь явно не выполнит команду aws sso logout или сеанс не будет аннулирован администратором, это многократно увеличивает окно уязвимости, позволяя операторам инфостилеров и их клиентам похитить токен и в дальнейшем непрерывно генерировать свежие учетные данные AWS.
Microsoft Azure
Глубокая интеграция Azure с корпоративной идентификацией посредством Azure Active Directory (Entra ID) предоставляет возможности для получения первоначального доступа к средам Azure с помощью инфостилеров. Единая скомпрометированная учетная запись синхронизированного пользователя может послужить мостом для перемещения злоумышленников в латеральном направлении между локальной сетью и облачной средой. Главной целью зачастую является компрометация учетной записи с привилегиями в Azure AD, например роли «Глобальный администратор», которая обеспечивает контроль над всей облачным клиентом (тенантом) и связанными с ним службами M365.
Группировки угроз вроде LAPSUS$ исторически специализируются на использовании украденных учетных данных для проникновения в Azure AD, порой даже регистрируя собственную машину в качестве «доверенного» устройства для обхода политик условного доступа. Другим, более свежим примером является Miasma, которая целенаправленно targets следующие файлы:
- .azure/accessTokens.json — хранит необработанные токены доступа в виде обычного текста, используемые главным образом старыми версиями Azure CLI для аутентификации запросов API.
.azure/accessTokens.json — хранит необработанные токены доступа в виде обычного текста, используемые главным образом старыми версиями Azure CLI для аутентификации запросов API.
- .azure/msal_token_cache.* — служит современным кэшем токенов для Azure CLI, надежно сохраняя данные сеансов и токены доступа с помощью библиотеки Microsoft Authentication Library (MSAL).
.azure/msal_token_cache.* — служит современным кэшем токенов для Azure CLI, надежно сохраняя данные сеансов и токены доступа с помощью библиотеки Microsoft Authentication Library (MSAL).
Современные инфостилеры нацелены непосредственно на критические каталоги, связанные с разработкой в облаке Azure, с целью компрометации учетных данных. Их главная задача — папка кэша аутентификации Azure CLI (%USERPROFILE%\.azure), которая содержит файлы конфигурации в открытом тексте с высокой степенью конфиденциальности.
Наиболее ценной целью в этой экосистеме является accessTokens.json. Этот файл содержит необработанные токены доступа Azure, долгоживущие токены обновления (refresh tokens), идентификаторы тенантов, идентификаторы ресурсов и метки времени истечения срока действия. Его кража обеспечивает немедленный программный доступ к API Azure Resource Manager (ARM), полностью исключая необходимость использования веб-порталов. Вторичной, но по-прежнему жизненно важной целью является azureProfile.json. Хотя в нем нет прямых секретов, он раскрывает ключевые данные разведки, такие как идентификаторы подписок, тенанты по умолчанию и имя участника-пользователя (UPN), позволяя злоумышленникам создавать скрипты для автоматизированного латерального перемещения при полном понимании облачной среды жертвы.
Кроме того, приложения, использующие библиотеку Microsoft Authentication Library (MSAL), генерируют локальные кэши удостоверений, которые обычно находятся в %localappdata%\.IdentityService\msal.cache или msalv2.cache. В этих кэшах хранятся полные токены доступа и обновления Entra ID, идентификаторы учетных записей и конкретные области разрешений для основных служб Microsoft (Graph, Outlook, SharePoint и облачных вычислений Azure). Крайне важно и то, что они содержат идентификаторы клиентов приложений (Application Client IDs), позволяя злоумышленникам перехватывать активные сеансы, выдавать себя за доверенные корпоративные приложения и тем самым обходить обнаружение аномалий.
Ярким примером такого целенаправленного воздействия является вредоносное ПО Vidar 2.0, обладающее специальной логикой для перечисления содержимого %USERPROFILE%\.azure directory, с помощью которого оно извлекает учетные данные Azure и эксфильтрирует эти данные злоумышленникам.
Google Cloud Platform (GCP)
Основной риск в GCP связан с долгоживущими переносимыми ключами сервисных аккаунтов. Эти файлы JSON с ключами, которые предоставляют программный доступ, являются главной целью инфостилеров, сканирующих машины разработчиков. Украденный ключ, связанный с привилегированным сервисным аккаунтом, может предоставить злоумышленнику немедленный и полный контроль над проектом GCP.
При атаке на GCP наибольшую ценность для злоумышленников представляют следующие файлы и переменные среды:
- credentials.db — база данных SQLite, содержащая долгоживущие токены обновления OAuth 2.0, используемые gcloud CLI.
credentials.db — база данных SQLite, содержащая долгоживущие токены обновления OAuth 2.0, используемые gcloud CLI.
- access_tokens.db — база данных SQLite, в которой хранятся активные токены доступа, используемые gcloud CLI для взаимодействия с API Google.
access_tokens.db — база данных SQLite, в которой хранятся активные токены доступа, используемые gcloud CLI для взаимодействия с API Google.
- application_default_credentials.json — JSON-документ, используемый фреймворком Google Application Default Credentials (ADC) для предоставления аутентификации клиентским библиотекам Google Cloud.
application_default_credentials.json — JSON-документ, используемый фреймворком Google Application Default Credentials (ADC) для предоставления аутентификации клиентским библиотекам Google Cloud.
- $GOOGLE_APPLICATION_CREDENTIALS — переменная среды, которая указывает на точный путь к файлу с высокопривилегированными JSON-ключами сервисных аккаунтов, используемым в производственных или тестовых средах.
$GOOGLE_APPLICATION_CREDENTIALS — переменная среды, которая указывает на точный путь к файлу с высокопривилегированными JSON-ключами сервисных аккаунтов, используемым в производственных или тестовых средах.
Основной инструмент командной строки Google Cloud, gcloud, хранит состояние аутентификации, метаданные проектов и данные конфигурации сеансов в предсказуемых локальных каталогах. В системах Linux и macOS эти критически важные данные обычно находятся в директории ~/.config/gcloud/, в то время как операционные системы Windows используют каталог %appdata%\gcloud\. Стиллеры используют точные, зашитые в код алгоритмы поиска, предназначенные для сбора следующих ценных артефактов GCP:
Прежде всего, это файлы credentials.db и access_tokens.db. Эти базы данных SQLite содержат крайне конфиденциальные токены обновления (refresh tokens) OAuth 2.0 и активные токены доступа, используемые интерфейсом командной строки gcloud для взаимодействия с API Google. Кража этих конкретных баз данных представляет особую ценность, поскольку токены обновления Google Cloud обычно не истекают автоматически, если они явно не отозваны администратором или не подпадают под действие чрезвычайно строгих политик безопасности организации. Следовательно, их кража дает злоумышленникам постоянный долгосрочный программный доступ ко всей среде GCP.
Во-вторых, стиллеры нацелены на файл application_default_credentials.json. Этот JSON-документ является важнейшим базовым компонентом фреймворка Google Application Default Credentials (ADC), который используется клиентскими библиотеками Google Cloud для автоматического обнаружения и использования учетных данных аутентификации во время разработки приложений. Примером недавнего вредоносного ПО, нацеленного на эти файлы, является стиллер цепочки поставок TeamPCP LiteLLM, в списке целей для эксфильтрации которого были указаны именно эти пути.
Наконец, изощренные варианты вредоносного ПО, особенно те, которые осуществляют автоматизированные атаки на цепочку поставок, целенаправленно атакуют переменные среды, уделяя особое внимание $GOOGLE_APPLICATION_CREDENTIALS. В производственных и тестовых средах эта переменная указывает на точное расположение файлов JSON-ключей сервисных аккаунтов в файловой системе. Злоумышленники анализируют переменные среды, извлекают целевой путь, а затем эксфильтруют соответствующий файл JSON-ключа, что предоставляет им немедленный программный доступ к вычислительным службам и службам хранения GCP в качестве высокопривилегированной нечеловеческой учетной записи (сервисного аккаунта) опубликовано Google Cloud.
GitHub
Учетные данные GitHub представляют собой высокоприоритетную цель для стиллеров из-за центральной роли платформы в разработке программного обеспечения и конфиденциальной интеллектуальной собственности, хранящейся в частных репозиториях. Украденный сеанс GitHub или персональный токен доступа (PAT) предоставляет злоумышленникам доступ не только к исходному коду, но и к секретам CI/CD, конвейерам развертывания, а также потенциально к возможности внедрения вредоносного кода непосредственно в цепочки поставок программного обеспечения. Подтверждая свой статус главной цели, наш анализ показывает, что около 50% семейств вредоносного ПО-стиллеров в настоящее время активно собирают учетные данные GitHub, что делает его четвертым по популярности секретом среди всех вредоносных штаммов.
При атаке на GitHub злоумышленники концентрируются на следующих файлах и артефактах:
- ~/.config/gh/hosts.yml (или %APPDATA%\GitHub CLI\hosts.yml) — хранит токены OAuth и параметры конфигурации, используемые интерфейсом командной строки GitHub (gh) для авторизации доступа к вашим учетным записям GitHub.
~/.config/gh/hosts.yml (или %APPDATA%\GitHub CLI\hosts.yml) — хранит токены OAuth и параметры конфигурации, используемые интерфейсом командной строки GitHub (gh) для авторизации доступа к вашим учетным записям GitHub.
- ~/.git-credentials (или $XDG_CONFIG_HOME/git/credentials) — содержит имена пользователей в виде обычного текста, пароли или персональные токены доступа (PAT), используемые Git для аутентификации HTTPS-соединений с удаленными репозиториями.
~/.git-credentials (or $XDG_CONFIG_HOME/git/credentials) — содержит имена пользователей в виде обычного текста, пароли или персональные токены доступа (PAT), используемые Git для аутентификации HTTPS-соединений с удаленными репозиториями.
- ~/.ssh/id_rsa, ~/.ssh/id_ed25519 — содержат закрытые ключи SSH, используемые для установления безопасного соединения, обычно применяемого для аутентификации без ввода пароля на удаленных серверах Git.
~/.ssh/id_rsa, ~/.ssh/id_ed25519 — содержат закрытые ключи SSH, используемые для установления безопасного соединения, обычно применяемого для аутентификации без ввода пароля на удаленных серверах Git.
- GITHUB_TOKEN, GH_TOKEN — переменные среды, часто используемые в рабочих процессах CI/CD и локальной разработке для предоставления активных токенов доступа с целью программной аутентификации в API и CLI GitHub.
GITHUB_TOKEN, GH_TOKEN — переменные среды, часто используемые в рабочих процессах CI/CD и локальной разработке для предоставления активных токенов доступа с целью программной аутентификации в API и CLI GitHub.
Интерфейс командной строки GitHub (gh) хранит токены OAuth в файле hosts.yml, который содержит токены в виде обычного текста (с префиксом gho_), если системное хранилище ключей недоступно. Аналогичным образом, пользователи, выполняющие аутентификацию по протоколу HTTPS, часто полагаются на вспомогательную утилиту git-credential-store, которая записывает учетные данные в виде обычного текста в файл ~/.git-credentials в формате https://username:token@github.com.
Ключи SSH также остаются постоянной целью. Стиллеры вроде Ghost Loader целенаправленно извлекают ~/.ssh/id_rsa для получения долгосрочного доступа к GitHub. Для перехвата сеансов злоумышленники нацеливаются на файлы cookie браузера, включая user_session, __Host-user_session_same_site и _gh_sess. Кража этих файлов cookie позволяет полностью обойти многофакторную аутентификацию (MFA). Основные семейства стиллеров, включая Lumma и RedLine, систематически собирают файлы cookie браузера и хранилища учетных данных, которые включают сеансы GitHub.
GitLab
GitLab представляет собой поверхность атаки, аналогичную GitHub, поскольку компрометация учетных данных GitLab может предоставить доступ к исходному коду, переменным CI/CD, содержащим секреты развертывания, и реестрам контейнеров.
При атаке на GitLab злоумышленники концентрируются на следующих файлах и переменных:
- ~/.config/glab-cli/config.yml (или %USERPROFILE%\.config\glab-cli\config.yml) — хранит параметры конфигурации и персональные токены доступа, используемые официальным интерфейсом командной строки GitLab (glab) для аутентификации и взаимодействия с экземплярами GitLab.
~/.config/glab-cli/config.yml (или %USERPROFILE%\.config\glab-cli\config.yml) — хранит параметры конфигурации и персональные токены доступа, используемые официальным интерфейсом командной строки GitLab (glab) для аутентификации и взаимодействия с экземплярами GitLab.
- /etc/gitlab-runner/config.toml (или ~/.gitlab-runner/config.toml) — содержит параметры конфигурации и конфиденциальные токены регистрации для GitLab Runners, отвечающих за выполнение задач CI/CD.
/etc/gitlab-runner/config.toml (или ~/.gitlab-runner/config.toml) — Содержит настройки конфигурации и конфиденциальные токены регистрации для GitLab Runner, отвечающих за выполнение CI/CD-задач.
- GITLAB_TOKEN, GITLAB_ACCESS_TOKEN, CI_JOB_TOKEN — Переменные среды, которые часто используются в сценариях автоматизации и пайплайнах CI/CD для программной аутентификации на основе токенов в API и репозиториях GitLab.
GITLAB_TOKEN, GITLAB_ACCESS_TOKEN, CI_JOB_TOKEN — Переменные среды, которые часто используются в сценариях автоматизации и пайплайнах CI/CD для программной аутентификации на основе токенов в API и репозиториях GitLab.
Интерфейс командной строки GitLab (glab) хранит токены аутентификации в файле config.yml, который содержит токены в виде открытого текста, если во время аутентификации явно не использовался флаг --use-keyring. Многие разработчики также хранят персональные токены доступа (PAT) GitLab в файлах ~/.netrc в формате machine gitlab.com login oauth2 password <token>.
Файлы конфигурации GitLab Runner (config.toml) представляют собой особо ценные цели. Эти файлы содержат токены аутентификации бегунов (с префиксом glrt-), которые позволяют злоумышленникам регистрировать поддельные бегуны, перехватывать CI/CD-задачи или получать доступ к секретам, раскрываемым во время выполнения пайплайна.
Для перехвата сеансов основной целью является файл cookie _gitlab_session: путем внедрения украденного файла cookie в свой собственный веб-браузер злоумышленник полностью принимает на себя личность жертвы в веб-интерфейсе GitLab.
В ходе кампаний эксплуатировались уязвимости в размещаемых самостоятельно экземплярах GitLab (такие как CVE-2023-7028) для распространения инфостилеров, таких как StealC, через загрузчик Amadey. После развертывания эти стилеры собирают учетные данные браузера и файлы cookie, которые часто включают токены сеанса GitLab среди более чем 17 миллиардов файлов cookie браузеров, похищаемых ежегодно.
OpenAI API и ChatGPT
Чтобы обойти аутентификацию на веб-платформе ChatGPT, инфостилеры нацелены конкретно на файл cookie __Secure-next-auth.session-token. Когда пользователь входит в ChatGPT, этот токен генерируется и сохраняется в локальной базе данных файлов cookie браузера для поддержания сеанса. Извлекая значение __Secure-next-auth.session-token, злоумышленники могут использовать его в своем собственном браузере и полностью перехватить сеанс. Это дает злоумышленнику доступ к истории чатов жертвы, которая часто содержит конфиденциальные корпоративные данные, проприетарный исходный код и внутренние бизнес-стратегии.
Помимо файлов cookie веб-сеансов, разработчики и автономные ИИ-агенты представляют собой огромную поверхность атаки для компрометации инфраструктуры OpenAI. Инфостилеры систематически сканируют среды разработчиков на наличие таких файлов, как credentials.json или файлы .env, в которых активные ключи API OpenAI (OPENAI_API_KEY) хранятся в виде открытого текста.
Anthropic Claude Code
Поскольку помощники по программированию на базе ИИ, такие как Claude Code и Codex, становятся неотъемлемой частью рабочих процессов разработчиков, они превратились в новую категорию целей для кражи учетных данных. Эти инструменты хранят токены аутентификации и конфигурацию, которые злоумышленники могут использовать для злоупотребления API, доступа к конфиденциальной истории разговоров и горизонтального перемещения в подключенную облачную инфраструктуру.
В качестве примера Claude Code злоумышленники часто концентрируются на следующих файлах:
- ~/.claude/.credentials.json (Linux) — Хранит OAuth-токены в открытом тексте.
