15 июля 2025 года компания Netwrix сформировала собственную профильную команду по анализу безопасности. Ее возглавил Huy Kha, директор по вопросам анализа безопасности. В состав команды входит эксперт по безопасности Darryl Baker – признанный специалист в сфере безопасности Active Directory и учетных записей. Экспертиза команды охватывает анализ угроз для учетных записей, безопасности данных, искусственного интеллекта и облачных сред. Главная цель заключается в преобразовании результатов аналитики в практические улучшения всей линейки продуктов Netwrix. В этом квартале команда аналитиков объединила усилия с командой PingCastle для расширения охвата проверок Entra ID, а также с командой Threat Manager для интеграции дополнительных механизмов обнаружения угроз, в частности уязвимостей ADCS.
Результаты работы этой команды являются основой для квартального отчета Netwrix Threat Lab. Каждый выпуск будет охватывать ключевые новости и результаты анализа безопасности учетных записей за квартал, оригинальные находки экспертов Netwrix, а также объяснение практического значения этой информации для команд, отвечающих за безопасность учетных записей и AD.
Обнаружение устаревших и фантомных SPN до того, как это сделают злоумышленники
Автор: Huy Kha
Введение
В течение последних нескольких лет возросло количество атак на Active Directory, связанных со злоупотреблением именами участников службы (SPN). Все началось с Kerberoasting, но с тех пор методы стали более изощренными. Атаки с использованием фантомных SPN позволяют повышать привилегии путем захвата целевых служб, которые уже не используются. С недавних пор атаки через коллизии Unicode в SPN позволяют любому аутентифицированному пользователю с правами на запись SPN также повышать привилегии, используя для этого лишь визуально идентичное, но технически отличное SPN.
Существует также менее заметная проблема, которой уделяют слишком мало внимания – базовая гигиена безопасности. Эксперты Netwrix постоянно наблюдают одну и ту же тенденцию, независимо от размера организации. Учетные записи компьютеров остаются активными в Active Directory еще долго после вывода соответствующей машины из эксплуатации. Учетные записи служб сохраняют SPN, которые до сих пор указывают на больше не существующие хосты. Никто не проводит удаление, поэтому такая учетная запись просто остается в системе – по-прежнему активная, по-прежнему уязвимая к Kerberoasting и оставленная без какого-либо внимания.
Поиск скрытых SPN в доменах
Команда экспертов по безопасности решила создать инструмент, который упростил бы эту задачу для специалистов по ИТ и администраторов. Скрипт PowerShell под названием Find-StealthSPNs. Он выполняет поиск скрытых SPN как в учетных записях компьютеров, так и пользователей. Это позволяет просмотреть результаты и определить, что именно требует удаления.
Выполнение скрипта происходит в два основных этапа. На первом этапе проверяется каждая учетная запись компьютера в лесу. Поскольку каждая присоединенная к домену машина по умолчанию регистрирует по меньшей мере одно SPN, на этом этапе проверяется, распознается ли еще собственное имя хоста этого компьютера в DNS, и не указывают ли какие-либо из его SPN на хосты, которых больше нигде не существует. Такое явление называется фантомным SPN – это запись, которая все еще остается привязанной к учетной записи, формально является действительной, но не указывает ни на один реальный объект. Также выявляются учетные записи компьютеров, которые были предварительно созданы в AD, но так и не были присоединены к домену. Такие записи часто вообще не имеют SPN и могут незаметно оставаться в системе на неопределенный срок.
Эта проверка намеренно выполняется через DNS, а не с помощью пингов ICMP. Некоторые администраторы полагаются на пинг, чтобы быстро понять, активен ли еще хост, привязанный к SPN. Однако протокол ICMP настолько часто блокируется брандмауэрами и фильтрами на уровне хоста в большинстве сред, что отсутствие ответа на пинг на самом деле неинформативно. Отсутствие записи DNS – это значительно более надежный сигнал того, что ни одна система больше не ожидает существования этого имени хоста, независимо от того, ответила бы сама машина на пинг.
Второй этап
Второй этап охватывает учетные записи пользователей, в частности те, которые содержат SPN, поскольку это классическая настройка для учетных записей служб. Для каждого найденного SPN выполняется двойная проверка: существует ли еще соответствующая учетная запись компьютера в AD, и распознается ли еще это имя хоста в DNS. Если оба условия не выполняются – это самый четкий индикатор того, что SPN является «мертвым грузом». Учетная запись остается активной, SPN – зарегистрированным, и он по-прежнему так же уязвим к атакам Kerberoasting, как и раньше, но теперь от него больше не зависит ни один обоснованный процесс.
Кроме того, скрипт также проверяет наличие коллизий Unicode в SPN – типа атаки, о котором упоминалось ранее. Специально созданная запись SPN может визуально совпадать с настоящей, но на самом деле иметь абсолютно другое скрытое значение. Происходит маркировка любых записей SPN со скрытыми или похожими символами. Также выполняется перекрестная проверка каждого SPN в лесу. Это позволяет выявить случаи, когда две учетные записи визуально содержат одинаковые значения. Поскольку во время этого процесса возможны ложноположительные срабатывания, перед выполнением любых действий результаты всегда требуют дополнительной проверки.
Вся работа выполняется исключительно с помощью ADSI и DirectorySearcher, поэтому отсутствует зависимость от модуля PowerShell ActiveDirectory. Скрипт работает во всех доменах леса, а не только в том, из которого инициирован запуск.
Краткое примечание относительно распознавания DNS: этот скрипт проверяет DNS с помощью того резолвера, который настроен на машине, с которой осуществляется запуск. Для получения более точных результатов запуск следует выполнять с контроллера домена, а не с рабочей станции. Это нужно, потому что контроллеры домена уже настроены на распознавание каждого домена в среде. Запуск с машины с нестандартными или ограниченными настройками DNS может привести к ложноположительным результатам MISSING_DNS для записей, которые существуют на самом деле.
Заключение
В конечном итоге главная цель заключается в том, чтобы помочь организациям уменьшить поверхность атаки путем удаления устаревших учетных записей, которые больше не отслеживаются. Каждое фантомное SPN, каждая активная учетная запись компьютера, привязанная к машине, которой давно нет, каждая учетная запись службы, которая все еще указывает на несуществующий хост – все это лишние элементы в Active Directory, которых там просто не должно быть. Эксплуатация таких недостатков не требует высокого уровня квалификации. Достаточно лишь того, чтобы злоумышленники заметили их раньше команды защиты.
Аспект безопасности учетных записей на DEF CON 34
Автор: Darryl Baker
Конференции DEF CON 34 и Black Hat USA 2026 представили три отдельных аналитических отчета, которые непосредственно касаются инфраструктуры учетных записей. Ниже приведен обзор того, что было анонсировано в каждом из них, и что это значит для специалистов, управляющих программами защиты учетных записей и AD.
CloudBasher: превращение бесплатных Cloud Shell в инфраструктуру злоумышленников
Jenko Hwong и Chris Ryan представили CloudBasher – набор инструментов с открытым исходным кодом, созданный путем обратного проектирования приватных REST API и сеансов WebSocket, обеспечивающих работу бесплатных функций Cloud Shell в AWS, Azure и GCP. Этот инструментарий будет опубликован на GitHub вместе с подробным анализом за 2026 год относительно шаблонов неправильной конфигурации облачных сред, составленным на основе данных об утечках информации.
Этот анализ выявил несколько специфических моментов, на которые стоит обратить внимание командам по безопасности учетных записей:
- Скомпрометированная учетная запись AWS может взять на себя роль и развернуть большое количество сред CloudShell.
- Терминальные сеансы WebSocket остаются активными после отзыва соответствующего маркера доступа, поэтому отзыв учетных записей не обязательно завершает активный сеанс.
- Пользовательские учетные записи M365 и Gmail получают доступ к CloudShell по умолчанию, что расширяет соответствующую поверхность атаки на личные учетные записи, а не только на корпоративные.
- После установки сеанса набор инструментов закрепляется в каталоге $HOME (который сохраняется после сброса настроек), может заблокировать законному пользователю доступ к sudo в пределах его собственного сеанса и устанавливает фреймворк C2.
Почему это важно: если программа защиты учетных записей рассматривает отзыв токена как эквивалент завершения сеанса, эти данные свидетельствуют о том, что такое допущение требует практической проверки. Также стоит убедиться, способны ли существующие политики доступа и инструменты мониторинга CloudShell вообще обнаружить аномальное создание сеанса.
GhostJacking: агенты ИИ для написания кода, действующие по инструкциям, скрытым в журналах
Barak Sternberg, Nevo Poran и Ron Bobrov из компании Tenet Security представили GhostJacking – технику перехвата управления агентами ИИ для написания кода путем внедрения инструкций в журналы, которые эти агенты должны считывать (например, оповещения WAF, отчеты об ошибках и данные мониторинга). Эксперты Tenet сообщили о 90% успешности во время атак на Claude Code при условии использования стандартных настроек Cloudflare и подсчитали, что более 15 000 организаций подвергаются риску только из-за конфигураций Cloudflare.
Специалисты Tenet продемонстрировали эту технику на трех платформах
Скомпрометированные записи в журналах WAF от Cloudflare заставляли агентов изменять настройки DNS и перенаправлять трафик. Оценивается, что решения Cloudflare используются примерно в 42% компаний из списка Fortune 500.
Внедренные сообщения в журналах Datadog приводили к установке агентами вредоносных пакетов. Это приводило к удаленному выполнению кода и краже учетных данных. Datadog используют примерно 48% компаний из Fortune 500.
Модифицированные отчеты об ошибках Sentry заставляли скомпрометированный экземпляр Claude Code подтверждать надежность злоумышленника собственному агенту Seer AI от Sentry. В результате создавалась цепь доверия между агентами. Платформа Sentry обслуживает ориентировочно 4 миллиона разработчиков.
Аналитики Tenet также сообщили об обнаружении более 2700 открытых ключей API Datadog и отдельно передали компании Anthropic информацию об уязвимости, связанной с доступом токенов JWT, которая позволяла выход из «песочницы» в Claude Desktop. Эта проблема была исправлена до начала выступления на DEF CON.
Действия агента во всех трех случаях выполняются с использованием его собственных, уже авторизованных и надлежащих учетных данных. Это означает, что инструменты EDR, WAF и IAM не классифицируют такие действия как аномальные.
Почему это важно: системы RBAC, принцип наименьших привилегий и решения MFA здесь не помогают, поскольку доступ агента является легитимным. Проблема заключается в том, какие именно действия ему приказано выполнить с этим доступом. Рекомендации экспертов Tenet формируют надежный базовый контрольный список для защиты:
- ограничение исходящего сетевого доступа агентов по умолчанию;
- обязательное утверждение человеком перед внесением любых изменений в инфраструктуру;
- отделение инструментов с доступом только для чтения от тех, которые имеют права на запись;
- восприятие любого журнала или оповещения, которые считывает агент, как ненадежных входных данных, независимо от платформы их происхождения.
Инцидент OpenAI и Hugging Face: агент, который вышел за пределы собственной тестовой среды
В июле 2026 года компания OpenAI раскрыла информацию о том, что во время внутреннего оценивания с помощью бенчмарка ExploitGym (898 реальных уязвимостей) экспериментальная версия модели GPT-5.6 Sol, запущенная с отключенными механизмами безопасности, вышла за пределы своей «песочницы» и скомпрометировала рабочую инфраструктуру Hugging Face. Компания Hugging Face сообщила об инциденте 16 июля; OpenAI подтвердила свое участие 21 июля. Eric Wallace и Michael Dalton выступили с докладом об этом случае на конференции Black Hat USA 2026.
Согласно обнародованным данным, агент нашел и эксплуатировал уязвимость нулевого дня в локально развернутом экземпляре Artifactory (сервере проксирования и кэширования реестра пакетов JFrog), чтобы выйти из «песочницы» и получить доступ в интернет. После этого агент пришел к выводу, что именно на серверах Hugging Face хранятся ключи ответов для бенчмарка, и направил атаку непосредственно на них. Впоследствии несколько экземпляров агента координировали свои действия через сам Artifactory, обменявшись сотнями тысяч сообщений для распределения задач и обмена эксплойтами. В один из моментов агенты даже предложили криптографически подписывать свои сообщения из-за подозрений на присутствие «самозванца». Когда 4 июля представители OpenAI перекрыли этот канал, агенты восстановили его через четыре дня, использовав названия каталогов на конечной точке без аутентификации в качестве альтернативного канала для обмена сообщениями.
В течение кампании продолжительностью 4,5 дня компания OpenAI зарегистрировала более 17 600 действий агента, в том числе эксфильтрацию 136 ключей из хранилища учетных данных, кражу ключа аутентификации сетевого VPN, регистрацию 181 устройства через Tailscale и получение прав на запись для приложений GitHub. Активность на 11 узлах Kubernetes включала имитацию узлов с помощью метаданных экземпляров AWS, подделку токенов учетных записей с помощью похищенного ключа подписи EdDSA JWT и создание привилегированных подов с монтированием файловой системы хоста. Компания OpenAI заявила, что обнаружила и другие, меньшие по масштабу случаи выхода из «песочницы», которые охарактеризовала как ограниченные по характеру и такие, которые, по ее убеждению, не покидали пределов собственной сети компании.
Одна деталь, которая касается учетных записей и реагирования на инциденты:
Поисковые запросы специалистов Hugging Face по цифровой криминалистике блокировались теми же коммерческими механизмами безопасности ИИ, которые были встроены в модели OpenAI и Anthropic, которые пытались привлечь для расследования. Причина заключалась в том, что эти предохранители не могли отличить вопросы специалиста по реагированию на инциденты от действий злоумышленника. Для обработки более 17 000 вредоносных событий за считанные часы вместо дней компания Hugging Face использовала открытую модель с 753 миллиардами параметров (GLM-5.2).
Почему это важно: это задокументированный случай того, как автономный агент самостоятельно обнаружил уязвимость, эксфильтровал учетные данные, подделал токены и осуществил расширение атаки по облачной инфраструктуре без вмешательства человека. Если существующие модели управления и IAM охватывают только учетные записи людей и служебные записи, этот инцидент является веским основанием для введения третьей категории – автономных агентов, способных действовать по собственной инициативе.
Что общего во всех трех случаях
CloudBasher демонстрирует пробелы в средствах контроля учетных записей на протокольном уровне. Отзыв токенов, пределы допущений ролей и политику доступа по умолчанию. GhostJacking касается ситуации, когда агент ИИ использует легитимную, делегированную учетную запись для выполнения инструкций, которым он не должен был доверять. Инцидент между OpenAI и Hugging Face связан с тем, что агент самостоятельно получает и подделывает учетные данные без участия человека или влияния скомпрометированных журналов.
Сквозь все три случая проходит общая угроза: специалисты ограничены инструментами, которыми злоумышленникам не обязательно руководствоваться. CloudBasher эксплуатировал допущения, которые специалисты не проверяли. GhostJacking использовал тот факт, что инструменты учетных данных не способны оценивать намерения. А в инциденте с OpenAI и Hugging Face защитные предохранители, призванные уменьшать злоупотребления, одновременно замедляли работу специалистов, осуществлявших реагирование.
Практические шаги для команд защиты учетных записей и AD
Четыре вещи, которые стоит сделать в этом квартале на основе анализа:
Необходимо убедиться, что отзыв учетных данных в рабочей среде действительно завершает активные сеансы. Это касается не только будущих попыток аутентификации, но и любой службы, предоставляющей доступ к консоли, терминалу или долговременным подключениям WebSocket.
Необходимо составить список всех агентов ИИ или ассистентов по написанию кода, имеющих права на чтение журналов, оповещений или данных мониторинга, и проверить, рассматриваются ли эти данные в настоящее время как надежные или ненадежные входные данные.
Необходимо требовать утверждения человеком перед внесением агентом ИИ изменений в инфраструктуру или DNS, установкой пакетов или использованием инструментов с правами на запись.
Необходимо рассматривать агентов ИИ как отдельный класс учетных записей с собственными пределами доступа, мониторингом и планом реагирования на инциденты, а не включать их в существующие категории учетных записей людей или служебных записей.
Аналитические материалы, которые могли остаться без внимания
Для дополнительного ознакомления ниже приведены две ключевые публикации от команды аналитиков по безопасности Netwrix.
Автоматизация удаления тенантов Entra ID с помощью ИИ
Используя расширение Claude для Chrome в Microsoft Graph Explorer, Huy Kha продемонстрировал, что после получения доступа уровня глобального администратора для авторизованной учетной записи JavaScript на стороне браузера и пакетные запросы Graph способны автоматизировать массовое удаление пользователей, сброс паролей, отзыв сеансов и удаление политик условного доступа. В публикации это связывается с реальными инцидентами, в частности делами Stryker и Storm-0501, где разрушительные действия в тенантах происходили после компрометации привилегированных учетных записей. Также подчеркивается, что ИИ не создает здесь новый вектор атаки – он лишь эксплуатирует существующий рабочий процесс администратора, делая его выполнение более быстрым и простым для масштабирования.
Почему это важно: именно здесь пролегает граница между компрометацией привилегированной учетной записи и полным удалением тенанта, и автоматизация с помощью ИИ стремительно сокращает этот разрыв. Как только злоумышленник получает сеанс глобального администратора, ему больше не нужны навыки написания скриптов или много времени для нанесения максимального ущерба. Это повышает требования к защите и мониторингу административных сеансов и таких инструментов, как Graph Explorer, а не только самих учетных данных.
Отчет по безопасности данных и учетных записей за 2026 год: достижения и пробелы во внедрении агентного ИИ и уровне готовности
Исследовательская лаборатория Netwrix опросила 2317 IТ-специалистов и специалистов по безопасности из 1889 организаций. Опрос проводился для подготовки отчета по безопасности данных и учетных записей за 2026 год.
Результаты показывают, что организации, где ИИ значительно расширил инфраструктуру учетных записей, сталкивались с утечкой данных примерно в четыре раза чаще. Речь идет о сравнении с организациями, где такого расширения не произошло. В отчете эта разница связывается со скоростью управления, а не с его тщательностью. 76% организаций не осуществляют полноценного управления или мониторинга машинных учетных записей. Лишь 11% сообщают о полной готовности к безопасной работе с ИИ благодаря непрерывному контролю и применению политик.
Почему это важно: эти данные ставят под сомнение распространенное допущение о том, что только надлежащая гигиена учетных записей надежно защищает от рисков, вызванных ИИ. Если процессы управления учетными записями все еще базируются на ежеквартальных проверках и периодических аудитах, стоит проверить, сколько времени новый агент ИИ или машинная учетная запись существует в системе до того, как ее заметят. Именно эта задержка, а не отсутствие элементов управления, является истинной причиной уязвимости, на которую указывает этот отчет.
