Microsoft Foundry Keys or Connection Secrets Accessed by New Principal

edit

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Microsoft Foundry Keys or Connection Secrets Accessed by New Principal

edit

Identifies the first time in seven days that a high-privilege Azure principal lists or regenerates the API keys of a Microsoft Foundry (Azure AI Services) account, or reads the stored secrets of a Foundry account or project connection. Account keys grant direct inference access to every model deployment on the account and bypass Entra ID conditional access, and connection secrets hold credentials for downstream services such as Azure OpenAI, storage, and search. A compromised identity retrieving these keys is a common first step in LLMjacking and in pivoting from a Foundry project to the data it is connected to.

Rule type: new_terms

Rule indices:

logs-azure.activitylogs-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Domain: GenAI
Data Source: Azure
Data Source: Azure Activity Logs
Data Source: Microsoft Foundry
Platform: Azure
Use Case: Threat Detection
Tactic: Credential Access
Tactic: Initial Access
Threat: LLMjacking
Threat: Unauthorized AI Usage
Mitre Atlas: AML.T0055
Resources: Investigation Guide
Rule Type: New Terms

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Microsoft Foundry Keys or Connection Secrets Accessed by New Principal

Microsoft Foundry accounts (Microsoft.CognitiveServices/accounts) expose two API keys that authorize inference against every model deployment on the account. Foundry accounts and projects also store connection secrets for linked resources. This rule fires when a high-privilege principal that has not done so for that resource in the last seven days lists or regenerates account keys, or reads account or project connection secrets.

Possible investigation steps

Identify the caller from azure.activitylogs.identity.authorization.evidence.principal_id, user.name, and azure.activitylogs.identity.authorization.evidence.principal_type, and confirm the role in azure.activitylogs.identity.authorization.evidence.role.
Review azure.resource.name, azure.resource.group, and azure.subscription_id to determine which Foundry account or project was affected and what model deployments or connections it holds.
Check source.ip and source.geo.country_name against the principal’s normal sign-in locations, and review Entra ID sign-in logs for the same principal around the event.
For REGENERATEKEY, determine whether a legitimate key rotation was scheduled. An unplanned regeneration can also be used to lock out legitimate applications.
Look for follow-on activity from the same principal, such as deployment or content filter changes, diagnostic setting deletion, or new role assignments on the account.

False positive analysis

Portal users with privileged roles viewing keys during setup or troubleshooting. Confirm with the user and their change records.
Deployment automation that reads keys on every release. Exclude those service principals by ID.

Response and remediation

If the access is not authorized, regenerate both account keys, rotate any connection secrets that were read, and review recent inference usage and cost on the account.
Revoke the principal’s sessions, reset its credentials, and review its role assignments.
Set disableLocalAuth on the account to require Entra ID authentication instead of keys where possible.

Setup

edit

Setup

This rule requires Azure Activity Logs ingested via the Azure integration (azure.activitylogs data stream). Key listing, key regeneration, and connection secret reads are Administrative control-plane events and are logged by default.

Rule query

edit

data_stream.dataset: "azure.activitylogs" and
azure.activitylogs.operation_name: (
    "MICROSOFT.COGNITIVESERVICES/ACCOUNTS/LISTKEYS/ACTION" or
    "MICROSOFT.COGNITIVESERVICES/ACCOUNTS/REGENERATEKEY/ACTION" or
    "MICROSOFT.COGNITIVESERVICES/ACCOUNTS/CONNECTIONS/LISTSECRETS/ACTION" or
    "MICROSOFT.COGNITIVESERVICES/ACCOUNTS/PROJECTS/CONNECTIONS/LISTSECRETS/ACTION"
) and
azure.activitylogs.identity.authorization.evidence.role: (
    "Owner" or
    "Contributor" or
    "Cognitive Services Contributor" or
    "Cognitive Services OpenAI Contributor" or
    "User Access Administrator"
) and event.outcome: "success"

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Credentials from Password Stores
- ID: T1555
- Reference URL: https://attack.mitre.org/techniques/T1555/
Sub-technique:
- Name: Cloud Secrets Management Stores
- ID: T1555.006
- Reference URL: https://attack.mitre.org/techniques/T1555/006/
Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
Sub-technique:
- Name: Cloud Accounts
- ID: T1078.004
- Reference URL: https://attack.mitre.org/techniques/T1078/004/

« AWS STS GetCallerIdentity Bulk Account Enumeration Azure Key Vault Multi-Vault Secret Retrieval Burst by Application »