« Authorization Plugin Modification Azure Automation Account Created »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Azure Arc Cluster Credential Access by Identity from Unusual Source

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

Azure Arc Cluster Credential Access by Identity from Unusual Source

edit

Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not previously associated with that identity. The listClusterUserCredential action retrieves credentials for the Arc Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines that rotate IPs but maintain consistent identity-to-IP patterns over time.

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
  • Data Source: Azure
  • Data Source: Azure Arc
  • Data Source: Azure Activity Logs
  • Use Case: Threat Detection
  • Tactic: Initial Access
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Azure Arc Cluster Credential Access by Identity from Unusual Source

The listClusterUserCredential operation on an Azure Arc-connected cluster returns credentials that allow the caller to establish a proxy tunnel via az connectedk8s proxy. This proxy routes kubectl commands through the Azure ARM API, enabling Kubernetes access without direct network connectivity to the cluster API server.

Possible investigation steps

  • Identify the caller service principal using azure.activitylogs.identity.claims.appid and cross-reference with Azure AD to determine if this is a known application.
  • Check the source IP and geolocation — is this from a country or ASN where your organization operates?
  • Correlate with Azure Sign-In Logs around the same time to see the full authentication chain (SP login followed by credential listing).
  • Verify the Azure role used — the Azure Arc Enabled Kubernetes Cluster User Role is required for this operation. Was this role recently assigned?
  • Check if subsequent Arc-proxied operations (secret/configmap CRUD) occurred after the credential access.
  • Review the service principal creation date in Azure AD — recently created SPs are more suspicious.

Response and remediation

  • If the source IP is from an unexpected country or the service principal is not recognized, treat as potential credential compromise.
  • Revoke the service principal credentials and remove Arc RBAC role assignments.
  • Review Kubernetes audit logs for any operations performed through the Arc proxy after credential access.
  • Rotate any Kubernetes secrets that may have been accessed.

Rule query

edit
event.dataset: "azure.activitylogs"
    and azure.activitylogs.operation_name: "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION"
    and event.outcome: (Success or success)

Framework: MITRE ATT&CKTM

« Authorization Plugin Modification Azure Automation Account Created »