Az - AI Foundry, AI Hubs, Azure OpenAI & AI Search

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Pourquoi ces services sont importants

Azure AI Foundry est la plateforme de Microsoft pour construire des applications GenAI. Un hub agrège des AI projects, des Azure ML workspaces, du compute, des data stores, des registries, des prompt flow assets, et des connexions vers des services en aval tels que Azure OpenAI et Azure AI Search. Chaque composant expose communément :

  • Clés API à longue durée de vie (OpenAI, Search, data connectors) répliquées dans Azure Key Vault ou dans des workspace connection objects.
  • Managed Identities (MI) qui contrôlent les déploiements, les jobs d’indexation vectorielle, les pipelines d’évaluation de modèles, et les opérations Git/GitHub Enterprise.
  • Cross-service links (storage accounts, container registries, Application Insights, Log Analytics) qui héritent des permissions du hub/projet.
  • Multi-tenant connectors (Hugging Face, Azure Data Lake, Event Hubs) qui peuvent leak des identifiants ou des tokens en amont.

La compromission d’un seul hub/projet peut donc impliquer le contrôle des managed identities en aval, des clusters compute, des online endpoints, et de tous les search indexes ou OpenAI deployments référencés par les prompt flows.

Composants principaux et surface d’attaque

  • AI Hub (Microsoft.MachineLearningServices/hubs): Objet de niveau supérieur qui définit la région, le managed network, les system datastores, le Key Vault par défaut, le Container Registry, Log Analytics, et les hub-level identities. Un hub compromis permet à un attaquant d’injecter de nouveaux projects, registries, ou user-assigned identities.
  • AI Projects (Microsoft.MachineLearningServices/workspaces): Hébergent les prompt flows, data assets, environments, component pipelines, et les online/batch endpoints. Les projects héritent des ressources du hub et peuvent aussi les surcharger avec leur propre storage, kv, et MI. Chaque workspace stocke des secrets sous /connections et /datastores.
  • Managed Compute & Endpoints: Inclut les managed online endpoints, batch endpoints, serverless endpoints, déploiements AKS/ACI, et des on-demand inference servers. Les tokens récupérés depuis Azure Instance Metadata Service (IMDS) à l’intérieur de ces runtimes portent généralement les role assignments MI du workspace/projet (souvent Contributor ou Owner).
  • AI Registries & Model Catalog: Permettent le partage régional de modèles, environments, composants, données, et résultats d’évaluation. Les registries peuvent automatiquement se synchroniser avec GitHub/Azure DevOps, ce qui signifie que des PATs peuvent être intégrés dans les connection definitions.
  • Azure OpenAI (Microsoft.CognitiveServices/accounts with kind=OpenAI): Fournit les modèles de la famille GPT. L’accès est contrôlé via des role assignments + admin/query keys. Beaucoup de Foundry prompt flows conservent les clés générées comme secrets ou variables d’environnement accessibles depuis les compute jobs.
  • Azure AI Search (Microsoft.Search/searchServices): Le stockage vectoriel/index est typiquement connecté via une Search admin key stockée dans une project connection. Les données d’index peuvent contenir des embeddings sensibles, des documents récupérés, ou des corpus d’entraînement bruts.

Architecture pertinente pour la sécurité

Managed Identities & Role Assignments

  • Les AI hubs/projects peuvent activer des identities system-assigned ou user-assigned. Ces identities détiennent généralement des rôles sur des storage accounts, Key Vaults, container registries, ressources Azure OpenAI, services Azure AI Search, Event Hubs, Cosmos DB, ou des APIs personnalisées.
  • Les online endpoints héritent du MI du projet ou peuvent être configurés avec un MI user-assigned dédié par déploiement.
  • Les prompt flow connections et les Automated Agents peuvent demander des tokens via DefaultAzureCredential ; capturer l’endpoint metadata depuis le compute fournit des tokens pour le mouvement latéral.

Network Boundaries

  • Les hubs/projects supportent publicNetworkAccess, private endpoints, Managed VNet et **managedOutbound** rules. Une mauvaise configuration de allowInternetOutbound` ou des scoring endpoints ouverts permet une exfiltration directe.
  • Azure OpenAI et AI Search supportent firewall rules, Private Endpoint Connections (PEC), shared private link resources, et trustedClientCertificates. Quand l’accès public est activé, ces services acceptent des requêtes depuis n’importe quelle IP source qui connaît la clé.

Data & Secret Stores

  • Les déploiements par défaut de hub/projet créent un storage account, un Azure Container Registry, un Key Vault, un Application Insights, et un Log Analytics workspace à l’intérieur d’un managed resource group caché (pattern: mlw-<workspace>-rg).
  • Les workspace datastores référencent des blob/data lake containers et peuvent embarquer des SAS tokens, des secrets de service principal, ou des storage access keys.
  • Les workspace connections (pour Azure OpenAI, AI Search, Cognitive Services, Git, Hugging Face, etc.) conservent les credentials dans le Key Vault du workspace et les exposent via le management plane lors de l’affichage de la connection (les valeurs sont du JSON encodé en base64).
  • AI Search admin keys fournissent un accès complet en lecture/écriture aux indexes, skillsets, data sources, et peuvent récupérer des documents qui alimentent les systèmes RAG.

Monitoring & Supply Chain

  • AI Foundry prend en charge l’intégration GitHub/Azure DevOps pour le code et les prompt flow assets. Les OAuth tokens ou PATs résident dans le Key Vault + la connection metadata.
  • Le Model Catalog peut refléter des artifacts Hugging Face. Si trust_remote_code=true, du code Python arbitraire s’exécute pendant le déploiement.
  • Les data/feature pipelines loggent vers Application Insights ou Log Analytics, exposant des connection strings.

Énumération avec az

# Install the Azure ML / AI CLI extension (if missing)
az extension add --name ml

# Enumerate AI Hubs (workspaces with kind=hub) and inspect properties
az ml workspace list --filtered-kinds hub --resource-group <RG> --query "[].{name:name, location:location, rg:resourceGroup}" -o table
az resource show --name <HUB> --resource-group <RG> \
--resource-type Microsoft.MachineLearningServices/workspaces \
--query "{location:location, publicNetworkAccess:properties.publicNetworkAccess, identity:identity, managedResourceGroup:properties.managedResourceGroup}" -o jsonc

# Enumerate AI Projects (kind=project) under a hub or RG
az resource list --resource-type Microsoft.MachineLearningServices/workspaces --query "[].{name:name, rg:resourceGroup, location:location}" -o table
az ml workspace list --filtered-kinds project --resource-group <RG> \
--query "[?contains(properties.hubArmId, '/workspaces/<HUB>')].{name:name, rg:resourceGroup, location:location}"

# Show workspace level settings (managed identity, storage, key vault, container registry)
az ml workspace show --name <WS> --resource-group <RG> \
--query "{managedNetwork:properties.managedNetwork, storageAccount:properties.storageAccount, containerRegistry:properties.containerRegistry, keyVault:properties.keyVault, identity:identity}"

# List workspace connections (OpenAI, AI Search, Git, data sources)
az ml connection list --workspace-name <WS> --resource-group <RG> --populate-secrets -o table
az ml connection show --workspace-name <WS> --resource-group <RG> --name <CONNECTION>
# For REST (returns base64 encoded secrets)
az rest --method GET \
--url "https://management.azure.com/subscriptions/<SUB>/resourceGroups/<RG>/providers/Microsoft.MachineLearningServices/workspaces/<WS>/connections/<CONN>?api-version=2024-04-01"

# Enumerate datastores and extract credentials/SAS
az ml datastore list --workspace-name <WS> --resource-group <RG>
az ml datastore show --name <DATASTORE> --workspace-name <WS> --resource-group <RG>

# List managed online/batch endpoints and deployments (capture identity per deployment)
az ml online-endpoint list --workspace-name <WS> --resource-group <RG>
az ml online-endpoint show --name <ENDPOINT> --workspace-name <WS> --resource-group <RG>
az ml online-deployment show --name <DEPLOYMENT> --endpoint-name <ENDPOINT> --workspace-name <WS> --resource-group <RG> \
--query "{identity:identity, environment:properties.environmentId, codeConfiguration:properties.codeConfiguration}"

# Discover prompt flows, components, environments, data assets
az ml component list --workspace-name <WS> --resource-group <RG>
az ml data list --workspace-name <WS> --resource-group <RG> --type uri_folder
az ml environment list --workspace-name <WS> --resource-group <RG>
az ml job list --workspace-name <WS> --resource-group <RG> --type pipeline

# List hub/project managed identities and their role assignments
az identity list --resource-group <RG>
az role assignment list --assignee <MI-PRINCIPAL-ID> --all

# Azure OpenAI resources (filter kind==OpenAI)
az resource list --resource-type Microsoft.CognitiveServices/accounts \
--query "[?kind=='OpenAI'].{name:name, rg:resourceGroup, location:location}" -o table
az cognitiveservices account list --resource-group <RG> \
--query "[?kind=='OpenAI'].{name:name, location:location}" -o table
az cognitiveservices account show --name <AOAI-NAME> --resource-group <RG>
az cognitiveservices account keys list --name <AOAI-NAME> --resource-group <RG>
az cognitiveservices account deployment list --name <AOAI-NAME> --resource-group <RG>
az cognitiveservices account network-rule list --name <AOAI-NAME> --resource-group <RG>

# Azure AI Search services
az search service list --resource-group <RG>
az search service show --name <SEARCH-NAME> --resource-group <RG> \
--query "{sku:sku.name, publicNetworkAccess:properties.publicNetworkAccess, privateEndpoints:properties.privateEndpointConnections}"
az search admin-key show --service-name <SEARCH-NAME> --resource-group <RG>
az search query-key list --service-name <SEARCH-NAME> --resource-group <RG>
az search shared-private-link-resource list --service-name <SEARCH-NAME> --resource-group <RG>

# AI Search data-plane (requires admin key in header)
az rest --method GET \
--url "https://<SEARCH-NAME>.search.windows.net/indexes?api-version=2024-07-01" \
--headers "api-key=<ADMIN-KEY>"
az rest --method GET \
--url "https://<SEARCH-NAME>.search.windows.net/datasources?api-version=2024-07-01" \
--headers "api-key=<ADMIN-KEY>"
az rest --method GET \
--url "https://<SEARCH-NAME>.search.windows.net/indexers?api-version=2024-07-01" \
--headers "api-key=<ADMIN-KEY>"

# Linkage between workspaces and search / openAI (REST helper)
az rest --method GET \
--url "https://management.azure.com/subscriptions/<SUB>/resourceGroups/<RG>/providers/Microsoft.MachineLearningServices/workspaces/<WS>/connections?api-version=2024-04-01" \
--query "value[?properties.target=='AzureAiSearch' || properties.target=='AzureOpenAI']"

Ce qu’il faut rechercher lors de l’évaluation

  • Portée d’identité : Les projets réutilisent souvent une identité assignée par l’utilisateur puissante attachée à plusieurs services. Capturer des IMDS tokens depuis n’importe quel compute géré hérite de ces privilèges.
  • Objets de connexion : La payload Base64 inclut le secret plus les métadonnées (endpoint URL, API version). Beaucoup d’équipes laissent les clés admin OpenAI + Search ici plutôt que de les faire tourner fréquemment.
  • Connecteurs Git et sources externes : Les PATs ou les OAuth refresh tokens peuvent permettre un accès en push au code qui définit les pipelines / prompt flows.
  • Datastores et assets de données : Fournissent des SAS tokens valables pendant des mois ; les assets de données peuvent pointer vers des PII clients, des embeddings ou des corpus d’entraînement.
  • Remplacements du Managed Network : allowInternetOutbound=true ou publicNetworkAccess=Enabled rend trivial l’exfiltration de secrets depuis les jobs/endpoints.
  • Groupe de ressources géré par le Hub : Contient le storage account (<workspace>storage), le container registry, KV, et Log Analytics. L’accès à ce RG signifie souvent une prise de contrôle complète même si le portail le cache.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks