AN1547: Analytic 1547
Detection of containerized service accounts or compromised kubeconfigs being used for cluster access from unexpected nodes or IPs.
Analyst context for executives and security teams
This analytic matters because Kubernetes or container-cluster credentials that work from unexpected nodes or IP addresses can indicate that a service account token or kubeconfig is being used outside its intended execution context. For leaders, the practical question is whether cluster access is tied to known workloads, nodes, and administration paths—or whether stolen credentials could be used without quick visibility.
Executive priority
Prioritize this as a cloud/container access-governance and SOC readiness issue. It supports decisions about whether Kubernetes authentication activity is logged, whether service-account usage has an expected baseline, and whether incident responders can quickly distinguish normal automation from suspicious access originating from unfamiliar infrastructure. It is especially relevant to resilience because unauthorized cluster access can affect workloads and operational services, even though this ATT&CK object does not specify a tactic or impact outcome.
Technical view
Validate whether container-platform telemetry can show which service account or kubeconfig identity accessed the cluster, from which node or source IP, and whether that source is expected. Because no official detection logic is provided, SOC and detection engineering teams should build baselines for normal service-account and kubeconfig access patterns, then alert on access from unexpected nodes, IP ranges, or administrative paths. Tuning should account for legitimate cluster maintenance, node scaling, CI/CD runners, and administrative jump hosts to avoid excessive false positives.
Likely telemetry
- Kubernetes or container-cluster API server authentication logs
- Audit logs showing user, service account, source IP, node, namespace, and requested resource where available
- Kubeconfig-based administrative access records
- Service account token usage evidence
- Cluster node inventory and expected node/IP mappings
Detection direction
- Confirm that cluster authentication and audit logging are enabled and retained long enough for investigation.
- Define expected source nodes, IP ranges, CI/CD systems, and administrator access paths for service accounts and kubeconfig users.
- Alert when a containerized service account or kubeconfig identity is used from an unexpected node or IP address.
- Tune detections for legitimate operational changes such as node replacement, autoscaling, maintenance windows, and approved automation.
- Correlate suspicious access with namespace, workload, and resource access to help incident responders prioritize triage.
Mitigation priorities
- Inventory service accounts, kubeconfigs, and their expected usage locations.
- Restrict cluster access paths to approved networks, nodes, and administrative workflows where feasible.
- Apply least privilege to service accounts and remove unused or overly broad credentials.
- Protect kubeconfigs and service account tokens as sensitive credentials, including rotation when compromise is suspected.
- Maintain current cluster node and automation inventories so detection logic has reliable context.
Analyst notes and limits
This is a detection analytic, not a technique object. The supplied ATT&CK fields identify the platform as Containers and describe detection of service accounts or compromised kubeconfigs used from unexpected nodes or IPs. There are no supplied relationships, tactics, or official detection implementation details, so the primary value is in validating local telemetry, baselines, and access-source context.
No official detection logic, related techniques, relationships, or tactic mappings were supplied. Any final alert thresholds, expected IP/node lists, and severity decisions require local Kubernetes/container architecture, identity model, and operational change context.
Analytic 1547
Detection of containerized service accounts or compromised kubeconfigs being used for cluster access from unexpected nodes or IPs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 0969dd222509… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1547Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.