Security teams can detect container and resource discovery by watching for unusual enumeration of cloud assets, metadata queries and API calls that list clusters, images, containers or related resources. Correlate discovery activity with identities, source IPs and time of day. Repeated broad listing after low-privilege access often signals reconnaissance before later compromise.
What container and resource discovery looks like in practice
Discovery is usually the earliest stage of container-focused reconnaissance, and it often looks boring in logs until you line up the context. The key signal is not one query, but a pattern: a principal that suddenly starts listing clusters, container images, registries, namespaces, pods, tasks, metadata endpoints or adjacent cloud resources it would not normally need.
Because container estates are highly API-driven, attackers and internal test tools can generate discovery through ordinary-looking calls. Security teams should pay attention to broad list, get and describe operations, especially when they expand across projects, subscriptions, accounts or clusters in a short window. That breadth is often more important than the exact command name.
Discovery is also useful as a precursor to privilege abuse. A low-privilege identity that repeatedly enumerates resources, then pivots to metadata services, registry queries or orchestration APIs, is often trying to map where secrets, workloads or control-plane permissions live before attempting deeper access. Cloud Security Guide is useful here because the same logging and posture issues that expose cloud inventory also expose container control planes.
Signals that separate routine administration from reconnaissance
The main job is to distinguish legitimate inventory activity from enumeration that is too broad, too fast or too correlated with an unusual source. A scheduled platform job may query many resources, but it will usually do so from a known identity, from expected network locations and at a normal cadence. Reconnaissance tends to be more opportunistic, more repetitive and more variable in target scope.
High-value signals include repeated failed attempts followed by success, access from a new source IP or region, access outside normal maintenance windows, and discovery that spans more than one resource family. A single identity that queries clusters, images, containers and metadata services in sequence deserves more scrutiny than the same query pattern confined to a single automated inventory workflow.
Correlate discovery with ownership and intent. If the identity has no operational reason to enumerate a broad resource set, the activity should be treated as suspicious even before you prove compromise. NHI Lifecycle Management Guide helps frame that ownership and visibility problem, which is often what makes enumeration hard to spot in the first place.
For container-centric cases, compare discovery volume against normal deployment and release behaviour. Build systems, cluster autoscalers and deployment tooling can look noisy, but they usually cluster around known events. Reconnaissance is more likely to appear as quiet, low-and-slow enumeration before a later spike in access attempts.
What to watch, validate and escalate before compromise spreads
Once discovery is suspected, the priority is to verify whether the same identity touched anything beyond passive listing. The most important follow-on checks are whether the actor requested secrets, service account material, pod specs, exec-like operations, registry credentials or metadata endpoints after the initial enumeration. That helps separate curiosity from an active intrusion path.
Look for chaining. Discovery followed by token use, workload impersonation, image pull activity, or reads against configuration stores is materially different from discovery alone. If the same source also shows privilege changes, unusual user-agent strings or access from a bastion or developer workstation that should not talk to the control plane, treat it as a likely intrusion sequence rather than an admin exception.
Container Security Guide is the better follow-on reference when you need to translate discovery signals into container runtime and orchestration checks, while Container Image Security Guide helps when enumeration appears to be aimed at registries, image provenance or image abuse.
Risk and Threat Considerations
container and resource discovery is risky because it gives an attacker a map of the environment before they try to exploit it. Broad enumeration can reveal naming conventions, cluster layout, registry exposure, metadata service access paths and the existence of privileged workloads, which shortens the path to credential theft or lateral movement.
Failure mechanism: A compromised or over-scoped identity uses legitimate API permissions to enumerate resources at scale, then pivots from inventory gathering to secret hunting, control-plane abuse or follow-on access.
Impact: Teams may miss the reconnaissance phase until the attacker has already identified the best place to steal tokens, reach workloads or target high-value container images and orchestration endpoints.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1613 — Container and Resource Discovery | Directly covers enumeration of container and cloud resources before compromise. |
| Recommendation — Map list and describe activity to T1613 and hunt for recon patterns before deeper access occurs. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Discovery detection depends on collecting and reviewing container and cloud API logs. |
| Recommendation — Centralise and review container API and cloud audit logs for unusual enumeration bursts. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Requires analysing audit events to detect suspicious resource enumeration and reconnaissance. |
| AC-6 — Least Privilege | Discovery by low-privilege identities is a key precursor to follow-on abuse and escalation. | |
| Recommendation — Correlate API audit events to spot abnormal discovery sequences and escalate suspicious patterns. Limit resource-list permissions to the minimum needed for each container identity. | ||
Practitioner Guidance
What to verify: Confirm whether the discovery source is a known automation identity, whether the resource family matches that identity’s job function, and whether the query pattern matches normal change windows rather than ad hoc exploration. If the caller cannot justify broad list activity, treat the alert as a meaningful investigation lead, not noise.
Decision rule: If discovery is broad, repeated and paired with low-privilege access, prioritise containment of the identity and follow-on access review before you spend time proving intent. The question is not only whether the actor listed resources, but whether that enumeration gave them the information needed for a next-stage compromise.
Practitioner takeaway: Discovery becomes operationally dangerous when it is both broad and contextual, meaning the same actor can see enough of the platform to plan the next move. The best detections therefore combine enumeration volume with identity, source and time-based anomalies, not just keyword matching on API calls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org