Один заголовок — и вся компания как на ладони. Microsoft выдала способ деанона через Entra ID
NewsMakerВас вычислили через ошибку 401. Добро пожаловать в новую реальность Azure.
Исследователи из NetSPI провели годичное исследование и выяснили, что для некоторых облачных сервисов Microsoft Azure можно определить реального владельца ресурса, используя особенности аутентификации через Entra ID . Раньше любая попытка привязать найденный поддомен к конкретной компании была скорее догадкой: даже если имя ресурса выглядело «говорящим», это ничего не доказывало. Например, хранилище с названием AWS в Azure вовсе не обязано принадлежать Amazon. Без кастомного домена или уникального сертификата установить владельца было практически невозможно. Новая методика меняет ситуацию: определённые сервисы, работающие с Entra ID, при обращении могут непреднамеренно раскрывать идентификатор арендатора (tenant ID), по которому затем удаётся узнать домен организации.
Azure широко использует поддомены для адресации . Если создать хранилище с именем $StorageName, автоматически будут зарезервированы адреса $StorageName.blob.core.windows.net, $StorageName.file.core.windows.net, $StorageName.table.core.windows.net и $StorageName.queue.core.windows.net. Если в Blob-хранилище включено статическое веб-хостинг, добавляется ещё один поддомен, например $StorageName.z4.web.core.windows.net. Похожий принцип применяется и для других сервисов, часто с добавлением региональных и «ёмкостных» префиксов вроде westus-01, canadaeast, z1, z2. Это значительно расширяет поверхность для DNS-сканирования , и уже существующие подходы активно используют такие имена в сочетании с открытыми DNS-источниками, базами сертификатов и перебором вариантов.
Но до недавнего времени даже обнаруженный активный поддомен нельзя было уверенно связать с конкретной организацией. Исследователи показали , что теперь это возможно. В примере они взяли приватный Storage Account без общедоступных контейнеров и с доступом только через private endpoint. При запросе через PowerShell try { Invoke-RestMethod -Uri " https://0752a779955f4cbda44468.blob.core.windows.net/?comp=blobs" ; -Method Get -Headers @{"x-ms-version"="2019-12-12"} } catch { $_.Exception.Response.Headers } сервер вернул ошибку 401 с заголовком WWW-Authenticate. В нём содержалась ссылка на login.microsoftonline.com с tenant ID (например, 977e0660-d4d3-4752-a79d-3ac9c4dbcf19). Этот идентификатор можно передать в Graph API через метод /v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='$tid') и получить домен владельца.
Метод работает даже для ресурсов за private endpoint, так как DNS-имя остаётся доступным, а API продолжает отвечать. Помимо хранилищ, аналогичным образом можно идентифицировать владельцев Key Vault, SharePoint, App Services, DataBricks, Azure Machine Learning, DevOps и ресурсов, доступных через Azure management API. В некоторых случаях нужная информация передаётся в других заголовках — например, "Report-To" у SharePoint или "Location" при редиректе в App Services и DataBricks. Иногда запрос приводит к перенаправлению на "common" tenant, но при обращении с активной сессией Entra ID (cookie ESTSAUTHPERSISTENT) удаётся получить реальный tenant ID.
Исследователи также обращают внимание на идентификаторы подписок в URL вроде https://management.azure.com/subscriptions/155c4768-b71c-4e4b-a990-97407f43edda?api-version=2022-12-... — их стоит скрывать в коде и скриншотах, чтобы не раскрывать лишнюю информацию.
Чтобы автоматизировать процесс, NetSPI разработала инструмент ATEAM (Azure Tenant Enumeration and Attribution Module). Он массово сканирует поддомены, получает tenant ID от уязвимых сервисов и через Graph API определяет домен владельца. Все найденные результаты сохраняются в базе SQLite azure_tenants.db с отметкой времени и могут выводиться в CSV, JSON или HTML. Инструмент умеет проверять отдельные имена (-r "myapp"), список ключевых слов или файл со списком, а также генерировать варианты имён с префиксами и суффиксами (-p) по словарю permutations.txt. Для ускорения можно увеличить число потоков (-w 10). Для каждого найденного ресурса выполняются два HTTP-запроса — первый для получения tenant ID, второй для названия компании.
В ходе работы команда собрала около миллиона ключевых слов из разных поддоменов Azure и выполнила DNS-поиск по ним. Это позволило построить карту активных ресурсов, которые можно привязать к конкретным организациям.
Все найденные особенности были переданы в Microsoft Security Response Center . Первые отдельные отчёты по хранилищам, Key Vault и App Services в 2024 году закрыли как "by design" или "working as intended". В феврале 2025 года после объединения кейсов и демонстрации масштабов проблема получила статус "valid, but does not pose an immediate threat", и Microsoft начала искать способы снижения риска. Для Storage Account отчёт отправлен 27 марта 2024, закрыт 23 апреля; для Key Vault — отчёт 27 марта, закрыт 28 мая; для App Service — отчёт 27 марта, закрыт 22 мая. Комбинированный отчёт по Azure Tenant Enumeration подан 14 февраля 2025, закрыт 26 февраля; 28 февраля началось координированное раскрытие, а в июле 2025 шли консультации с продуктовой командой. В итоге Microsoft подтвердила, что пересмотрела изначальную оценку и рассматривает меры против подобных методов разведки.
Авторы отмечают, что метод применим не ко всем сервисам Azure, но для тех, что раскрывают tenant ID в ходе аутентификации, он даёт возможность массовой привязки инфраструктуры к конкретным владельцам. ATEAM доступен на GitHub NetSPI и может использоваться как исследователями, так и специалистами по защите для проверки публичной видимости своих ресурсов.
Исследователи из NetSPI провели годичное исследование и выяснили, что для некоторых облачных сервисов Microsoft Azure можно определить реального владельца ресурса, используя особенности аутентификации через Entra ID . Раньше любая попытка привязать найденный поддомен к конкретной компании была скорее догадкой: даже если имя ресурса выглядело «говорящим», это ничего не доказывало. Например, хранилище с названием AWS в Azure вовсе не обязано принадлежать Amazon. Без кастомного домена или уникального сертификата установить владельца было практически невозможно. Новая методика меняет ситуацию: определённые сервисы, работающие с Entra ID, при обращении могут непреднамеренно раскрывать идентификатор арендатора (tenant ID), по которому затем удаётся узнать домен организации.
Azure широко использует поддомены для адресации . Если создать хранилище с именем $StorageName, автоматически будут зарезервированы адреса $StorageName.blob.core.windows.net, $StorageName.file.core.windows.net, $StorageName.table.core.windows.net и $StorageName.queue.core.windows.net. Если в Blob-хранилище включено статическое веб-хостинг, добавляется ещё один поддомен, например $StorageName.z4.web.core.windows.net. Похожий принцип применяется и для других сервисов, часто с добавлением региональных и «ёмкостных» префиксов вроде westus-01, canadaeast, z1, z2. Это значительно расширяет поверхность для DNS-сканирования , и уже существующие подходы активно используют такие имена в сочетании с открытыми DNS-источниками, базами сертификатов и перебором вариантов.
Но до недавнего времени даже обнаруженный активный поддомен нельзя было уверенно связать с конкретной организацией. Исследователи показали , что теперь это возможно. В примере они взяли приватный Storage Account без общедоступных контейнеров и с доступом только через private endpoint. При запросе через PowerShell try { Invoke-RestMethod -Uri " https://0752a779955f4cbda44468.blob.core.windows.net/?comp=blobs" ; -Method Get -Headers @{"x-ms-version"="2019-12-12"} } catch { $_.Exception.Response.Headers } сервер вернул ошибку 401 с заголовком WWW-Authenticate. В нём содержалась ссылка на login.microsoftonline.com с tenant ID (например, 977e0660-d4d3-4752-a79d-3ac9c4dbcf19). Этот идентификатор можно передать в Graph API через метод /v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='$tid') и получить домен владельца.
Метод работает даже для ресурсов за private endpoint, так как DNS-имя остаётся доступным, а API продолжает отвечать. Помимо хранилищ, аналогичным образом можно идентифицировать владельцев Key Vault, SharePoint, App Services, DataBricks, Azure Machine Learning, DevOps и ресурсов, доступных через Azure management API. В некоторых случаях нужная информация передаётся в других заголовках — например, "Report-To" у SharePoint или "Location" при редиректе в App Services и DataBricks. Иногда запрос приводит к перенаправлению на "common" tenant, но при обращении с активной сессией Entra ID (cookie ESTSAUTHPERSISTENT) удаётся получить реальный tenant ID.
Исследователи также обращают внимание на идентификаторы подписок в URL вроде https://management.azure.com/subscriptions/155c4768-b71c-4e4b-a990-97407f43edda?api-version=2022-12-... — их стоит скрывать в коде и скриншотах, чтобы не раскрывать лишнюю информацию.
Чтобы автоматизировать процесс, NetSPI разработала инструмент ATEAM (Azure Tenant Enumeration and Attribution Module). Он массово сканирует поддомены, получает tenant ID от уязвимых сервисов и через Graph API определяет домен владельца. Все найденные результаты сохраняются в базе SQLite azure_tenants.db с отметкой времени и могут выводиться в CSV, JSON или HTML. Инструмент умеет проверять отдельные имена (-r "myapp"), список ключевых слов или файл со списком, а также генерировать варианты имён с префиксами и суффиксами (-p) по словарю permutations.txt. Для ускорения можно увеличить число потоков (-w 10). Для каждого найденного ресурса выполняются два HTTP-запроса — первый для получения tenant ID, второй для названия компании.
В ходе работы команда собрала около миллиона ключевых слов из разных поддоменов Azure и выполнила DNS-поиск по ним. Это позволило построить карту активных ресурсов, которые можно привязать к конкретным организациям.
Все найденные особенности были переданы в Microsoft Security Response Center . Первые отдельные отчёты по хранилищам, Key Vault и App Services в 2024 году закрыли как "by design" или "working as intended". В феврале 2025 года после объединения кейсов и демонстрации масштабов проблема получила статус "valid, but does not pose an immediate threat", и Microsoft начала искать способы снижения риска. Для Storage Account отчёт отправлен 27 марта 2024, закрыт 23 апреля; для Key Vault — отчёт 27 марта, закрыт 28 мая; для App Service — отчёт 27 марта, закрыт 22 мая. Комбинированный отчёт по Azure Tenant Enumeration подан 14 февраля 2025, закрыт 26 февраля; 28 февраля началось координированное раскрытие, а в июле 2025 шли консультации с продуктовой командой. В итоге Microsoft подтвердила, что пересмотрела изначальную оценку и рассматривает меры против подобных методов разведки.
Авторы отмечают, что метод применим не ко всем сервисам Azure, но для тех, что раскрывают tenant ID в ходе аутентификации, он даёт возможность массовой привязки инфраструктуры к конкретным владельцам. ATEAM доступен на GitHub NetSPI и может использоваться как исследователями, так и специалистами по защите для проверки публичной видимости своих ресурсов.