TA0007: Discovery
The adversary is trying to figure out your environment.
Discovery consists of techniques an adversary may use to gain knowledge about the system and internal network. These techniques help adversaries observe the environment and orient themselves before deciding how to act. They also allow adversaries to explore what they can control and what’s around their entry point in order to discover how it could benefit their current objective. Native operating system tools are often used toward this post-compromise information-gathering objective.
Analyst context for executives and security teams
Discovery is the post-compromise phase where an adversary tries to understand the victim environment before choosing the next move. For leaders, its significance is that many intrusions become more damaging after the attacker learns where identities, systems, networks, and reachable resources are. Because MITRE notes that native operating system tools are often used, this behavior can blend into normal administration unless organizations have clear baselines and usable telemetry.
Executive priority
Treat Discovery as an early decision point for incident response and containment. Security leaders should ask whether the organization can quickly show what systems, accounts, and network areas a compromised user or host can enumerate, and whether SOC teams can distinguish routine administration from suspicious post-compromise orientation. This matters for business continuity because discovery activity often precedes broader movement or objective-driven actions, even though this ATT&CK tactic object does not specify a particular platform, technique, or impact outcome.
Technical view
This object is a tactic-level description, not a specific technique, and provides no ATT&CK detection guidance. SOC and IR teams should therefore validate coverage across the Discovery techniques relevant to their environment rather than relying on this object alone. Practical validation should focus on whether logs can reconstruct post-compromise information-gathering behavior, especially use of native operating system tooling to observe systems, networks, accessible resources, and nearby control opportunities. Detection engineering should prioritize context: initiating account, source host, timing, command or process patterns where available, and whether the activity is expected for that user or administrative role.
Likely telemetry
- Endpoint process execution and command-line evidence where collected
- Authentication and account activity logs showing who initiated discovery-like actions
- Host and system audit logs that show local enumeration or configuration queries
- Network connection and internal traffic metadata that can show environment mapping behavior
- Administrative tooling logs or management-plane records where native tools are used
Detection direction
- Map locally relevant ATT&CK Discovery techniques to available telemetry; this tactic object alone has no official detection text.
- Baseline normal administrative discovery activity so detections do not simply alert on legitimate inventory, troubleshooting, or operations work.
- Tune for unusual combinations of user, host, timing, scope, and sequence rather than single benign commands or queries in isolation.
- Validate whether native operating system tool usage is logged with enough detail to support incident reconstruction.
- Look for post-compromise orientation patterns: repeated enumeration, broad internal querying, or discovery from an unusual entry point, while avoiding claims of maliciousness without corroborating evidence.
Mitigation priorities
- Prioritize visibility first: ensure endpoint, identity, system, and network records can support investigation of discovery behavior.
- Reduce unnecessary exposure by limiting what standard users and compromised hosts can enumerate where business operations allow.
- Strengthen identity and access governance so discovery from one account or host does not reveal excessive reachable resources.
- Prepare IR playbooks that treat suspicious discovery as a containment trigger requiring scoping of affected accounts, hosts, and accessible network areas.
- Use ATT&CK technique-level mappings under the Discovery tactic for more specific control, detection, and testing decisions.
Analyst notes and limits
The supplied object is the enterprise ATT&CK tactic TA0007 Discovery. It explains adversary intent at a high level: learning about systems and internal networks, often using native operating system tools. No platforms, technique relationships, aliases, or official detection guidance were supplied, so this take emphasizes governance, telemetry validation, and SOC/IR decision value rather than platform-specific analytics.
This assessment is limited to the official STIX fields, the MITRE external reference, and the absence of relationship context provided in the prompt. It does not identify specific Discovery techniques, affected platforms, adversary groups, active exploitation, or guaranteed detections. Local environment architecture, logging, identity model, and administrative practices are required to determine actual coverage and risk.
Discovery
The adversary is trying to figure out your environment.
Discovery consists of techniques an adversary may use to gain knowledge about the system and internal network. These techniques help adversaries observe the environment and orient themselves before deciding how to act. They also allow adversaries to explore what they can control and what’s around their entry point in order to discover how it could benefit their current objective. Native operating system tools are often used toward this post-compromise information-gathering objective.
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 | eac5e4cde6b2… |
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 TA0007Open 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.