DET0490: Detection Strategy for Container and Resource Discovery
MITRE ATT&CK DET0490: Detection Strategy for Container and Resource Discovery Detection Strategy details, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
DET0490 is a MITRE detection strategy placeholder for detecting Container and Resource Discovery, where an adversary looks for containers, images, deployments, pods, nodes, cluster status, or similar resources in a container environment. For leaders, the practical issue is visibility: if teams cannot see discovery activity against Docker or Kubernetes APIs, dashboards, or related logs, an intruder may be able to map the container estate before later actions are noticed.
Executive priority
Treat this as a container security readiness check rather than a complete detection recipe. The ATT&CK object provides no official detection logic, platforms, or tactics of its own, but it is related to T1613, a Discovery technique on Containers. Security leaders should ask whether container inventory, Kubernetes/Docker API access, dashboard usage, and cluster-resource queries are logged, retained, and reviewable during incidents. This supports incident response scoping, cloud/container governance, compliance evidence for access monitoring, and prioritization of controls around sensitive cluster metadata.
Technical view
SOC, detection engineering, and IR teams should validate coverage around the related technique T1613: discovery of containers and resources in container environments. Focus on evidence of queries or views of pods, nodes, deployments, images, cluster status, and similar resources through Kubernetes or Docker APIs and web interfaces such as Kubernetes dashboards. Because MITRE supplies no official detection text for DET0490, local baselining is required to distinguish normal administrator, platform engineering, CI/CD, and monitoring activity from unusual discovery behavior.
Likely telemetry
- Kubernetes API audit logs showing resource enumeration or cluster-status queries
- Docker API access logs or daemon logs where available
- Kubernetes dashboard or other container management web application access logs
- Container orchestration control-plane logs
- Authentication and authorization logs for users, service accounts, and API clients accessing container resources
Detection direction
- Confirm whether the organization collects API-level audit data for Kubernetes and Docker interactions relevant to resource discovery.
- Baseline expected discovery activity by administrators, service accounts, CI/CD tooling, monitoring platforms, and cluster management components to reduce false positives.
- Look for unusual breadth, timing, source identity, or source location of resource enumeration against pods, nodes, images, deployments, or cluster status.
- Correlate discovery activity with authentication context, authorization decisions, dashboard access, and recent changes to service account permissions.
- Pay attention to blind spots where dashboards, APIs, or control-plane logs are not centrally collected or have short retention.
Mitigation priorities
- Prioritize reliable audit logging and retention for container control-plane and API activity before writing high-confidence alerts.
- Review least-privilege access for users and service accounts that can list or view broad container and cluster resources.
- Restrict and monitor access to Kubernetes dashboards and container management interfaces.
- Ensure incident response playbooks include steps to review container resource discovery activity when investigating suspected compromise.
- Use asset and identity context to separate expected operational enumeration from unexpected or excessive discovery behavior.
Additional notes and limits
This take is based on DET0490 and its relationship to T1613 Container and Resource Discovery. The ATT&CK detection strategy object has no official description or detection content, so the value is in translating the related technique into validation questions for container telemetry, identity context, and SOC/IR readiness.
Platforms and tactics are not specified on DET0490 itself; Containers and Discovery come from the related T1613 technique. No official detection logic, analytic thresholds, data components, mitigations, or examples were supplied. Local architecture, logging configuration, normal administrative behavior, and retention policy are required to determine practical coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Detection Strategy for Container and Resource Discovery
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1613 | Container and Resource Discovery | This object detects Container and Resource Discovery. |
All related ATT&CK context
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 | 8b65556503bc… |
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-attackDET0490Open source URL
- [2]mitre-attackDET0490Open source URL
- [3]mitre-attackDET0490Open 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.