---
{
  "title": "Container and Resource Discovery",
  "summary": "Container and resource discovery enumerates orchestration objects that reveal workload and infrastructure relationships.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1613"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1613: Container and Resource Discovery",
      "url": "https://attack.mitre.org/techniques/T1613"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Container and resource discovery enumerates orchestration objects that reveal workload and infrastructure relationships. It can expose identities and targets for further activity.


## An investigation example

A compromised workload identity lists pods, nodes, or images beyond its normal application needs.

## Evidence to examine

Review API audit events, effective role bindings, query scope, and subsequent actions on discovered objects.

## A common analytical pitfall

Visibility into an object does not establish permission to execute within or modify it.

## Response considerations

Preserve the query-to-action sequence and reduce unnecessary discovery permissions while investigating actual resource access.


## Orchestration metadata describes relationships

Container environments expose information about workloads, namespaces, images, nodes, services, and related resources through management interfaces. That metadata can reveal where applications run and how they connect. Discovering an object does not necessarily grant permission to read its secrets, modify it, or execute inside its container. Those are separate authorization questions.

Expected automation often lists resources. Deployment controllers, monitoring tools, and administrators may generate frequent queries. Evaluate the requesting identity, permissions, source workload, scope, and timing. A newly observed service account querying unrelated namespaces may deserve review, but a broad query alone is not conclusive evidence of compromise.

## A fictional workload map

An academy's training cluster records an unexpected sequence of resource-listing calls from an application identity. Later, the same identity attempts an operation outside its normal role. Analysts preserve management audit events and workload context, then compare the behavior with the application's documented purpose and recent changes.

The response should consider both the identity and the workload that used it. Rotating a credential without understanding how it became accessible may leave the original weakness intact. Review least-privilege boundaries and relevant deployment configuration through an authorized process, and validate that normal application behavior remains supported.

## Trace a permission boundary

Draw a fictional cluster with two namespaces, a service account, and a few workloads. Mark which objects the account can list and which actions it can perform. Explain why visibility and modification are different capabilities. Then identify the audit evidence needed to distinguish discovery from successful workload execution. Use a dedicated lab or paper model rather than querying an unfamiliar live cluster.

Management audit records may include requested object types and authorization outcomes, but coverage depends on the platform's policy. A denied request can still reveal attempted discovery, while a successful list does not show every later action. Record the namespace, identity, time, and response context so the evidence can be evaluated independently.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]