How T1613 container and resource discovery shows up in a cluster
Picture the SOC lead's situation: one workload has been compromised, and within minutes the attacker starts asking what else is running around it. They list namespaces, pods, containers and the cluster resources those workloads can reach. This is T1613 Container and resource discovery, and it sits under the Discovery tactic (TA0007), which MITRE defines as: "The adversary is trying to figure out your environment." In a container platform, the attacker is not looking for a single host. They are mapping which workloads exist, which images they run, and which service accounts and secrets they can touch. The output of that mapping decides what the attacker does next.
In intrusions this activity usually appears early, often right after initial access to a pod or a build job. It is frequently followed by lateral movement toward other namespaces, nodes or cloud resources, so the window between discovery and movement is the window defenders should watch. The signal is a sequence of read-only API requests from an identity that does not normally query the cluster inventory, rather than any single noisy command. Your first decision is whether the platform team can see those API requests at all. Confirm that API server audit logging is enabled, that it records the requesting identity and the verb, and that the logs reach your SIEM, such as Wazuh, with retention that covers a realistic investigation window.
This page targets ATT&CK version 20.0, released by MITRE on 2026-10-13, and the technique mapping, its data components and its mitigations should be re-checked against the enterprise-attack STIX bundle for each release. ATT&CK can rename, deprecate or revoke techniques between versions, so any detection rule you build should record the version it was written against. Treat the bundle as the source of truth for current mappings, and confirm with your own environment which container telemetry you actually collect before you assume coverage.
Which telemetry reveals container and resource enumeration
This table maps each telemetry source that reveals T1613 activity to the ATT&CK data component it belongs to and the open-source collectors that can gather it. Read each row as a question to answer in your own environment: does the collector see this signal, and do the fields needed to act on it actually arrive? The main takeaway is that Kubernetes API audit logs and runtime sensors usually carry the strongest signal, while network sensors add context but rarely confirm enumeration on their own.
| Telemetry | ATT&CK data component | Open-source collectors | Fields to confirm in your environment |
|---|---|---|---|
| Pod Enumeration (API list and get requests for pods) | Network Traffic Content (DC0085) when API traffic is inspected; Command Execution (DC0064) when run from a shell | Kubernetes API audit logs shipped to Wazuh or a SIEM; Zeek or Suricata on API server traffic where TLS is terminated or mirrored | Verb, requested resource, namespace, requesting user or service account, source IP, user agent, response code |
| Container Enumeration (runtime listing of containers and their metadata) | Process Creation (DC0032) and Command Execution (DC0064) | Falco-style runtime sensors; Wazuh agent process and command auditing on container hosts | Process name, parent process, container ID, image name, pod label, host user, working directory |
| Container runtime socket and file reads | File Access (DC0055) | Wazuh file integrity and audit rules on runtime socket paths; Falco file access rules | Accessing process, file path, container ID, read or write flag, timestamp, host identity |
| Service account token use from inside a container | File Access (DC0055) and Network Traffic Content (DC0085) | Kubernetes API audit logs for token-authenticated requests; Falco rules on mounted service account token reads | Service account name, namespace, token source (in-pod or external), authentication result, client address |
| Cluster-wide list requests from unexpected sources | Network Traffic Content (DC0085) | Kubernetes API audit logs; Suricata or Zeek on the control plane network segment | Source workload identity, request scope (all namespaces or one), rate over time, destination API server |
| Host-level enumeration tools run on nodes | Process Creation (DC0032) and Command Execution (DC0064) | Wazuh command monitoring; Falco process rules on node hosts | Executable path, arguments, user, parent chain, whether the host is a control plane or worker node |
| Access to other containers' filesystems or process views | Process Access (DC0035) | Falco rules on process and namespace access; host audit rules | Source and target container IDs, namespace identifiers, capability settings, host PID namespace use |
Detection logic for T1613 that SOC teams can tune
The four detection ideas below look at the same activity from different angles: who is calling the Kubernetes API, from where, which processes start inside containers, and what traffic moves between pods. Each one only becomes reliable after you have measured normal behavior in your own clusters, so treat the thresholds as starting points to tune rather than fixed values.
Bursts of list and watch requests
Alert when a single identity or service account issues an unusual volume of list or watch requests against pods, namespaces, services or secrets within a short window. The logic compares each identity's request rate against its own rolling baseline, not a cluster-wide average, because controllers and operators are chatty by design. Tune the window and multiplier per identity class. Pay close attention to requests for resource types the identity has never touched before. Common false positives include monitoring agents, GitOps controllers that reconcile many objects, and backup tools that list everything on a schedule.
Enumeration from unexpected namespaces
Flag API discovery calls that originate from a workload in a namespace that has no operational reason to read cluster-wide resources. The check uses the requesting service account, its namespace and the resource scope requested, and it is most useful when those values are mapped against an agreed list of namespaces permitted to read across the cluster. Expect noise from platform namespaces that run operators, ingress controllers and policy engines. Confirm with the platform team which namespaces hold cluster-scoped read rights before you set the alert to page anyone.
Container runtime commands from unusual parents
Alert when a container runtime or orchestration CLI runs on a host under a parent process that is not a known administration path, such as a web server process, a cron job or an interactive shell opened by an unfamiliar user. Process creation telemetry from the node, paired with the parent chain, is the core signal. Validate the logic by checking that your own administrators and automation produce the expected parent chains. Common false positives include configuration management runs, node maintenance scripts and vendor agents that call the runtime to collect health data.
East-west scanning from inside a pod
Detect a pod opening connections to many distinct pod IPs or service ports in a short period, especially on ports it has never used. This is network-level evidence of discovery that complements the API-level signals above, and it depends on flow or connection telemetry from the cluster network. Compare against the expected service graph so that known dependencies do not trigger. Health probes, service meshes, databases with replica sets and load testing tools are the usual sources of legitimate fan-out, so exclude them by workload label after review.
How to validate that the T1613 detection fires
This sequence proves that the T1613 detection fires on the right container and orchestrator telemetry, with known gaps and false positives recorded before the rule goes into production. It turns a planned emulation in a private cyber range into tuned detection content and a re-test record that the security team can reuse.
Agree scope and rules of engagement
The security lead, the platform owner and the cyber range operator agree in writing which clusters, namespaces and test accounts are in scope, which activities are allowed, when the exercise runs and who can stop it. The emulation stays inside an isolated lab or cyber range built for the purpose, never on production clusters. The sign-off record names an owner for every rule and a contact for escalation, and it is the starting point for the rest of the sequence.
Map expected telemetry to each emulation step
The detection engineer writes down, for each step in the emulation plan, which telemetry should appear: Pod Enumeration and Container Enumeration events from the Kubernetes audit log, plus any container runtime or host records the platform collects. The plan references the ATT&CK version and the detection strategy it targets, so later reviewers know which mapping was tested. The output is a table of steps, expected data sources, expected fields and the alert name that should fire. Teams should confirm which audit policy levels and log fields their Kubernetes distribution actually emits before they finalize the table.
Confirm log collection before the run
Before the emulation starts, the operator checks that audit logs from the API server reach the SIEM, for example a Wazuh or Security Onion pipeline, with the expected timestamps and fields intact. A test event is sent through the pipeline and found in the index, and the parser output is compared with the field names the rule uses. The check is done when the operator can show a sample event for each expected data source and can name any field that is missing or renamed.
Run the emulation plan in the cyber range
A designated operator runs the agreed steps under the rules of engagement, using the test accounts and namespaces defined in step one. A second person records the start and end time of each step, the account used, and any deviation from the plan. The operator does not improvise outside the plan, and any unplanned activity is logged as a separate finding. The run is complete when every planned step has a recorded start and end time and a status of executed, skipped or blocked.
Check each alert against the expected detection
The detection engineer compares each alert with the expected result from step two. For every step, the review records whether an alert fired, its timestamp, the fields it carried, the namespace and account it named, and whether the alert matched the intended logic. Steps with no alert are classified as gaps, and alerts with no matching step are classified as false positives or unplanned activity. The output is a validation table that shows detected, missed and noisy events for each step.
Record timestamps, fields and gaps
The team writes a short validation report that keeps the raw evidence: event identifiers, alert identifiers, timestamps, the fields used by the rule and the query that found each result. Gaps are assigned to an owner with a cause, such as missing audit policy, a renamed field, a parser error or a rule that only matches one orchestrator version. False positives are recorded with the benign activity that produced them. The report is stored with the rule version and ATT&CK version so that an auditor or future engineer can trace the result.
Tune the rule and re-test
The detection engineer changes the rule or its exclusions to close the gaps and reduce the false positives found in the report, then records each change as a new rule version. The same emulation steps are run again in the cyber range, and the results are compared with the first run to confirm that gaps closed without new noise. The cycle ends when the re-test meets the success criteria agreed in step one and the changes, results and remaining exceptions are signed off by the security lead.
Why detection engineers should separate normal cluster inventory from attacker enumeration
Detection for T1613 cannot rely on a single API call. Pod and resource listing is what monitoring agents, GitOps controllers, backup jobs, service meshes and operators do all day, so an alert that fires on the presence of a list request will be noisy from the first hour. Instead, combine identity, source, scope and rate. Ask which service account or user made the request, from which workload or network location, against which namespaces and resource types, and how often. An enumeration pattern usually looks different on those four dimensions: a credential that normally reads one namespace suddenly listing pods across all of them, from a pod that has never called the API server, at a rate far above its usual cadence.
Build the baseline per namespace and per service account. Pull Kubernetes audit logs over a representative period, grouping requests by user.username, sourceIPs, objectRef.namespace, objectRef.resource and verb. Record which identities list pods, services, secrets metadata or custom resources, and at what volume. Confirm the audit policy captures these verbs at a level that supports the analysis, since a policy set too narrowly will hide the data you need. Treat the output as a living reference that the platform team reviews when workloads change, not a one-time spreadsheet.
Document every exception so it stays reviewable. For each approved identity, record the owner, the business reason, the permitted namespaces and resource types, the expected source and the review date. Store these records in version control next to the Sigma or Wazuh rule logic so that a change to either is visible. Exceptions without an owner or expiry tend to accumulate until the rule stops meaning anything. Ask your auditors and internal reviewers how they want to sample these records, and confirm that your RBAC mitigation, User Account Management (M1018), and your network segmentation work (M1030) are reflected in the same register.
Mitigations that limit what an attacker can enumerate
Discovery in a container platform succeeds when the identity making the calls can see too much and the network lets it reach too much. The three cards below cover the identity scope, the network reach and the audit trail that together decide how much T1613 Container and resource discovery an adversary can carry out, and how quickly your team notices it.
Scope cluster and service identities
User Account Management (M1018) is the mitigation that determines what a compromised account can list. Review every service account bound to workloads, and every human or CI identity with cluster-wide read access, and confirm that each one holds only the namespaces and resource types it needs. Pay particular attention to default service accounts that have been granted broad list or get permissions, because a single pod with a stolen token can enumerate pods, secrets metadata and nodes across the cluster. Confirm whether automountable tokens are disabled on workloads that do not call the API.
Limit pod-to-control-plane reach
Network Segmentation (M1030) decides whether a pod can even reach the API server or the kubelet endpoints that answer discovery requests. Write network policies that restrict egress from application namespaces, and confirm that the control plane endpoints are reachable only from administrative subnets. Test from inside a representative pod to verify that the policy works as written, since a policy that exists in the manifest but is not enforced by the cluster network plugin gives no protection. Ask your platform team which network plugin enforces policy in your environment.
Restrict pod-to-pod enumeration
Namespace boundaries only hold if traffic between namespaces is denied by default. Apply a default-deny ingress policy in each namespace and allow only the flows that the application documents. Lateral probing of neighboring pods is a common follow-on to container enumeration, so a flat pod network turns one foothold into a map of the whole workload estate. Verify the default-deny posture after every chart upgrade, because a new chart can add a permissive policy or a service that exposes a port.
Make enumeration visible in audit logs
Audit (M1047) is the mitigation that turns enumeration into a signal. Enable API server audit logging at a level that records list and get requests with the requesting identity, source address and namespace, and confirm that the logs leave the cluster to a store your security team controls. Without this record, a discovery sweep by a valid service account looks like normal platform activity. Ask your platform team which audit policy is active, how long logs are retained and whether anyone is alerted on bursts of cluster-wide list requests.
Triage and response when a T1613 alert fires
The first decision is whether the alert reflects a real actor or an authorized workload. Confirm the identity behind the enumeration (the service account, user or workload identity that issued the list or get requests) and the source it came from, such as a cluster node, a CI runner, an administrator workstation or a pod with an unexpected address. Check the identity's recorded purpose and owner against your change records. If no owner can explain the activity within a short window, treat the alert as suspicious and move on to scoping. Do not assume that a monitoring agent or GitOps controller is benign until you have matched its service account to a documented deployment.
Next, establish whether the workload or identity was already compromised before the discovery activity. Review the preceding hours of audit logs for authentication anomalies, new or modified role bindings, unexpected exec sessions into pods, and image pulls from unfamiliar registries. Scope which namespaces and resource types were listed, including pods, services, secrets, config maps and nodes, and whether the requests were cluster-wide or limited to one namespace. Listing secrets or cluster-scoped objects raises the severity considerably. Record the time window and the number of distinct resources touched so the investigation has a defined boundary.
Preserve evidence before you contain. Export the relevant audit log entries and retain them in write-once storage, snapshot or capture the state of the affected pods (including logs and ephemeral containers) where your platform allows it, and record the current role bindings and token issuance for the identity. Then contain: suspend or rotate the affected service account credentials, restrict the identity's role bindings to the minimum needed, and isolate the workload with a network policy if its traffic is still open. Decide on escalation to incident response when the identity is privileged, when secrets were listed, when discovery is paired with other suspicious activity, or when you cannot establish ownership. Confirm your escalation criteria and containment authority with your incident response team in advance, because these decisions are hard to make under pressure.
Rehearsing T1613 detection and response in a private cyber range
The range should mirror the production pattern you actually run, so the detections you tune reflect real telemetry. For T1613 that means a self-hosted Kubernetes cluster with API server audit logging turned on, a Wazuh or Security Onion stack ingesting that audit log along with host and network telemetry, and a network layout where workloads sit in separate segments that can be reached only through defined paths. Keep the range private and isolated from corporate networks, and use synthetic data and accounts only.
- Cluster with audit logging: Confirm that audit policy records read requests against pod, namespace and cluster-level resources, and that the log is shipped off the cluster before the exercise starts.
- Log pipeline: Verify that Wazuh or Security Onion parses the audit records and that timestamps, user identities and source addresses survive the pipeline.
- Segmented network: Place the control plane, workload namespaces and the monitoring stack in separate zones with explicit allow rules, so that lateral reach is visible and testable.
- Baseline capture: Record normal inventory activity for a defined period before the exercise, so the team knows which service accounts and tools are expected.
- Ask your provider: Confirm exercise duration, team sizes, range capacity and data handling in the written scope, since these are not fixed by the technique.
Check that every log source you plan to score against is confirmed working before the first inject runs.
Injects give the blue team something to find. Design them to test the detection logic, not the exercise designer's ingenuity. Two scenarios cover most of the risk for T1613: a compromised workload that begins enumerating the cluster from inside a pod, and a legitimate inventory job that produces similar records. The second matters because a detection that fires on every inventory call will be ignored within a week.
- Compromised workload (illustrative): A workload identity inside one namespace starts listing resources across namespaces it has no business reading. The team should see a sequence of denied or unusual read requests from a single identity.
- Legitimate inventory job (illustrative): A scheduled reporting job lists the same resource types under a known service account. The team should classify it as expected once the baseline and allow list are in place.
- Escalation variant: After the enumeration, the adversary attempts a broader read or a new role binding. This tests whether analysts connect discovery with the next step.
- Inject timing: Release injects on a schedule written into the scope, and record when each one starts so detection latency can be measured.
- Mixed traffic: Run the legitimate job during the same window as the compromised workload to test whether analysts can separate the two.
Check that each inject has a documented expected outcome before the exercise, so that scoring does not depend on memory.
A rehearsal is only useful if it produces numbers the team can compare across exercises. Define the criteria before the exercise starts and record them in the same format each time. Measure whether the right signal was produced, whether it reached an analyst, whether the analyst classified it correctly, and whether containment followed the runbook. Tie each criterion to the ATT&CK version you target, since detection strategies and data component references can change between releases.
- Telemetry coverage: Record which expected audit or host events were present for each inject, and flag any gap in the pipeline.
- Detection latency: Measure the time from the first adversary action to an alert in the case queue, and record the time to analyst triage.
- Classification accuracy: Count how many legitimate inventory events were correctly marked as expected and how many adversary events were escalated.
- Response steps: Check that the runbook steps for revoking the identity, restricting the namespace and preserving logs were carried out in order.
- Version tracking: Note the ATT&CK version and the detection strategy identifiers used, so later reruns compare like with like.
After each exercise, review the criteria with the platform and security leads and agree which gaps become tuning tasks.
Questions SOC leads ask about detecting T1613
How do I separate GitOps and monitoring tools from an attacker doing container discovery?
Start by building an allowlist of the service accounts, source addresses and workloads that legitimately list pods, namespaces and containers, then alert on everything outside it. Controllers, GitOps reconcilers and monitoring agents usually make high-volume, repetitive API reads from fixed identities, while an intruder tends to enumerate from an interactive or unexpected identity, at unusual hours, or across namespaces the identity never touches. Confirm each tool's exact service account and expected verbs with its owner before tuning, because a broad exception for a monitoring agent can hide the activity you most need to see. Review the allowlist on a schedule, since platform changes add new legitimate readers.
Which Kubernetes audit log levels matter for T1613 detection?
The useful signal is in the request metadata of the API audit trail: who made the call, the verb, the resource type, the namespace and the source address. Metadata-level logging covers most discovery use cases because it records these fields without storing request and response bodies, which keeps volume and sensitive data exposure lower. Request-level logging for read verbs on pods and namespaces can help when you need to see which resources were queried, but it raises storage cost and may capture secrets in some payloads. Check the audit policy shipped in your distribution and confirm with your platform team which rules are active, since defaults vary.
How portable are Sigma rules for container discovery telemetry?
Sigma rules describe detection logic in a vendor-neutral format, but container telemetry fields differ between audit log sources, runtime sensors and host logs, so a rule written for one pipeline rarely works unchanged in another. Plan a field-mapping layer that normalizes names such as verb, objectRef and user identity into the fields your SIEM expects, then convert the rules with the backend you run. Test each converted rule against replayed events from your own cluster, because a rule that compiles is not the same as a rule that fires. Keep the mapping files under version control alongside the rules.
How do I re-map detections when ATT&CK releases change technique mappings?
Pin every detection to the ATT&CK version it targets, and record that version in the rule metadata and in your coverage tracker. MITRE's updates pages list the version history, and releases can rename, deprecate or revoke techniques, and v18 replaced technique-page detections with detection strategies and analytics. When a new version ships, diff the technique and data component references for the techniques you cover, using the STIX bundle for that version, then update only the affected rules and rerun your validation tests. Treat a changed mapping as a review item, not an automatic update.
How do I measure detection coverage for T1613 without overstating it?
Measure coverage as the share of in-scope discovery behaviors that have a tested detection and a documented response, not as the number of rules in the repository. For each relevant data component, such as process creation or command execution on nodes and API audit events on the control plane, record whether you collect it, whether a rule consumes it, and when a cyber range exercise last proved the rule fires. A rule with no recent validation should count as unproven. Share the method with auditors so the evidence trail, not a headline figure, carries the claim.
Can our own team build and tune these detections, or do we need DeployOpen?
A capable platform or SOC team can build and tune these detections in-house if it has access to cluster audit logs, a SIEM, and a place to replay test events. The work is ongoing rather than one-time: allowlists, field mappings and ATT&CK version updates all need an owner. DeployOpen implements and hardens self-hosted open-source platforms inside your own infrastructure and runs cyber range exercises, so it can help with setup and rehearsal under a written, fixed scope, or as a retainer for continuing tuning. Ask any provider to state in writing which detections, log sources and environments are covered.
What does a fixed-scope detection project for container discovery usually include?
A typical fixed-scope engagement is defined by the clusters, log sources, SIEM and rule set named in writing before work starts. Common components include reviewing audit policy, shipping control plane and node telemetry, writing and converting rules, documenting the allowlist, and running a cyber range exercise to show which alerts fire. Costs come from the hours of engineers and analysts, the infrastructure needed for telemetry, and the time for validation, and they recur when clusters or ATT&CK versions change. Ask for the list of deliverables, the environments in scope, and what is excluded.
How DeployOpen builds T1613 detections and range scenarios
DeployOpen works on T1613 Container and resource discovery inside the client's own environment, whether that is their cloud account, data center or air-gapped network. Each engagement starts with a written, fixed scope that names the container platform, the telemetry sources and the detection and range deliverables before any build work begins.
How we scope
- Confirm which container orchestrators, clusters and namespaces are in the written scope for T1613 detection.
- Inventory the audit logging, API server logs and container runtime events the client can already forward.
- Agree the ATT&CK version the detection mappings will target, since releases can rename or deprecate techniques.
How we build
- Build detection logic for pod enumeration and container enumeration activity, described in plain words and tested against the client's own log fields.
- Deploy and tune open-source collection and alerting components, such as Wazuh rules or Sigma-based detections, inside the client's environment.
- Document the network segmentation and user account management controls that limit what an enumerating identity can see.
How we hand over
- Deliver the detection logic, data source mappings and tuning notes as versioned documentation the client's team can maintain.
- Provide cyber range scenarios that replay benign and adversarial enumeration so the client can rehearse alerting and response.
- Walk the client's analysts through validation results, known gaps and the evidence produced for their compliance assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work completes.
- Review detection mappings when a new ATT&CK version changes T1613 or its related data components.
- Confirm with the client's team which changes need a new range rehearsal before they reach production.
