Kubernetes Secret or ConfigMap Access via Azure Arc Proxy
Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect…
Description
Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs. This rule uses a 5-day new-terms history window keyed on the impersonated identity and alerts the first time that Azure AD principal performs this activity.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- ContainersIaaSIdentity ProviderLinuxmacOSNetwork DevicesOffice SuiteSaaSWindows
The rule states no platform. This is derived from the 4 ATT&CK techniques it maps to.
Known benign triggers
- Azure Arc system components may create or update secrets and configmaps in the azure-arc and azure-arc-release namespaces during normal cluster management. Filter by namespace to exclude these.
- Helm operations managed through Arc may create release secrets (prefixed with sh.helm.release.v1). These are normal Arc lifecycle operations.
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services | 5 |
| learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect | 3 |
| microsoft.github.io/Threat-Matrix-for-Kubernetes/ | 15 |
| www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence | 3 |
| www.wiz.io/blog/lateral-movement-risks-in-the-cloud-and-how-to-prevent-them-part-3-from-compromis | 2 |
From the source
- At source
- Open at source
- Upstream identifier
- 220d92c6-479d-4a49-9cc0-3a29756dad0c
- Tagged by the source as
- Data Source: KubernetesData Source: Kubernetes API Server Audit LogsDomain: CloudDomain: ContainersDomain: KubernetesNoise: LowPerformance: FastPlatform: KubernetesResources: Investigation GuideRule Type: ES|QLTactic: CollectionTactic: Credential AccessUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Sep 20, 2026
- Version
- 3