Microsoft Foundry Keys or Connection Secrets Accessed by New Principal


Description

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.

Query · kuery

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"

Investigation fields

Pivot points the source recommends for triage.

  • @timestamp
  • azure.activitylogs.operation_name
  • azure.activitylogs.identity.authorization.evidence.principal_id
  • azure.activitylogs.identity.authorization.evidence.principal_type
  • azure.activitylogs.identity.authorization.evidence.role
  • user.name
  • source.ip
  • source.geo.country_name
  • azure.resource.name
  • azure.resource.group
  • azure.subscription_id

Implementation guide

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.

Known false positives

  • Administrators with Owner or Contributor roles opening the Keys and Endpoint blade in the Azure portal or Foundry portal, which issues a listKeys call. Confirm the activity with the principal and prefer Entra ID authentication over key-based access.
  • Infrastructure-as-code pipelines and deployment scripts that read keys to configure applications. Prefer managed identities, or add exceptions for the service principals that run these pipelines.

Analyst notes

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.
Raw source Microsoft Foundry Keys or Connection Secrets Accessed by New Principal · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified.
[metadata]
creation_date = "2026/10/23"
integration = ["azure"]
maturity = "production"
updated_date = "2026/10/23"

[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
    """
    Administrators with Owner or Contributor roles opening the Keys and Endpoint blade in the Azure portal or Foundry
    portal, which issues a listKeys call. Confirm the activity with the principal and prefer Entra ID authentication
    over key-based access.
    """,
    """
    Infrastructure-as-code pipelines and deployment scripts that read keys to configure applications. Prefer managed
    identities, or add exceptions for the service principals that run these pipelines.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Microsoft Foundry Keys or Connection Secrets Accessed by New Principal"
note = """## 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.
"""
references = [
    "https://learn.microsoft.com/en-us/azure/ai-services/authentication",
    "https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/connections-add",
    "https://www.elastic.co/docs/reference/integrations/azure/activitylogs",
]
risk_score = 47
rule_id = "49796406-78a2-4c11-aa5b-6f1a3ca730de"
setup = """## 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.
"""
severity = "medium"
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",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
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"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[rule.threat.technique.subtechnique]]
id = "T1555.006"
name = "Cloud Secrets Management Stores"
reference = "https://attack.mitre.org/techniques/T1555/006/"



[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat_mappings]]
framework = "MITRE ATLAS"
version = "2026.09"
[[rule.threat_mappings.threat]]
framework = "MITRE ATLAS"
[[rule.threat_mappings.threat.technique]]
id = "AML.T0055"
name = "Unsecured Credentials"
reference = "https://atlas.mitre.org/techniques/AML.T0055/"


[rule.threat_mappings.threat.tactic]
id = "AML.TA0013"
name = "Credential Access"
reference = "https://atlas.mitre.org/tactics/AML.TA0013/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "azure.activitylogs.operation_name",
    "azure.activitylogs.identity.authorization.evidence.principal_id",
    "azure.activitylogs.identity.authorization.evidence.principal_type",
    "azure.activitylogs.identity.authorization.evidence.role",
    "user.name",
    "source.ip",
    "source.geo.country_name",
    "azure.resource.name",
    "azure.resource.group",
    "azure.subscription_id",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.activitylogs.identity.authorization.evidence.principal_id", "azure.resource.name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.