T1588.002: Tool
Adversaries may buy, steal, or download software tools that can be used during targeting. Tools can be open or closed source, free or commercial. A tool can be used for malicious purposes by an adversary, but (unlike malware) were not intended to be used for those purposes (ex: PsExec).
Adversaries may obtain tools to support their operations, including to support execution of post-compromise behaviors. Tools may also be leveraged for testing – for example, evaluating malware against commercial antivirus or endpoint detection and response (EDR) applications.CitationForescout Conti Leaks 2022CitationSentinel Labs Top Tier Target 2025
Tool acquisition may involve the procurement of commercial software licenses, including for red teaming tools such as Cobalt Strike. In addition to freely downloading or purchasing software, adversaries may steal software and/or software licenses from third-party entities (including other adversaries). Threat actors may also crack trial versions of software.CitationRecorded Future Beacon 2019
Security context for executives and security teams
T1588.002 covers adversaries acquiring legitimate software tools before an intrusion. The business issue is that many useful attacker capabilities are not malware at all: they may be open-source, commercial, trial, stolen, or cracked tools that also have legitimate administrative or red-team uses. That makes prevention and detection less about blocking a single bad file and more about knowing which tools are allowed, where they should appear, who may use them, and whether pre-compromise intelligence or later endpoint/network evidence shows abnormal use.
Executive priority
Treat this as a resilience and governance problem, not only a SOC alerting problem. Leaders should ask whether the organization has an approved-tool inventory, controls over administrative and security-testing software, evidence for audits showing who can obtain and run such tools, and incident response plans for dual-use tooling. The relationship context links this behavior to many ATT&CK campaigns, including espionage, ransomware, energy-sector, and safety-system-related cases, so sectors with operational technology or critical operations should ensure IT-to-OT visibility and response ownership are clear.
Technical view
This is a PRE-platform, Resource Development sub-technique under Obtain Capabilities. Because ATT&CK provides no official detection text, teams should validate coverage around both pre-compromise intelligence and post-acquisition use inside the environment. Practical validation includes: approved versus unapproved tool execution, downloads of dual-use administration or red-team software, suspicious license or cracked-tool artifacts where visible, unexpected use of tools such as PsExec-like utilities, and correlation with later execution, lateral movement, or command-and-control behaviors. DET0852 is listed as a detection strategy for this object, but the supplied fields do not provide its detection logic, so local engineering is required.
Likely telemetry
- Software asset inventory and approved-tool baselines
- Endpoint process execution and command-line telemetry
- EDR or host logs for administrative and security-testing tools
- Proxy, DNS, firewall, and web download logs
- Software license, procurement, and security testing authorization records
Detection direction
- Do not rely on malware signatures alone; many tools in this category are legitimate software used in unauthorized contexts.
- Build allowlists or baselines for administrative, remote execution, scanning, and red-team tools by owner, host group, and business purpose.
- Tune detections to context: the same tool may be expected on security team systems but suspicious on finance workstations, servers, domain controllers, or OT-adjacent hosts.
- Correlate tool appearance with download source, first-seen host, user identity, privilege level, and subsequent behaviors.
- Use campaign relationships as threat-intelligence context, not proof of exposure or attribution.
Mitigation priorities
- Implement M1056-style pre-compromise measures: reduce attack surface, limit unnecessary public information, and make adversary preparation harder to operationalize.
- Maintain an approved inventory of administrative and red-team tools, including where they may be stored and executed.
- Restrict acquisition, installation, and execution of powerful dual-use tools to authorized roles and systems.
- Harden exposed services and prioritize vulnerabilities that would make commodity or commercial tools immediately useful after access.
- Prepare IR playbooks for legitimate-tool abuse, including evidence preservation, containment decisions, and business-owner approval paths.
Additional notes and limits
The key defensive decision is whether the organization can distinguish authorized tool use from adversary-enabled tool use. ATT&CK relationships show this sub-technique appears across many campaign types, including cases involving open-source tools, commercial tooling, ransomware intrusions, espionage activity, and operational environments. That breadth supports prioritizing governance, telemetry, and response readiness over one-off blocking rules.
ATT&CK does not provide official detection text for this object, and the platform is PRE, meaning much adversary acquisition may occur outside defender visibility. The supplied fields do not support claims of active exploitation, customer exposure, attribution, or guaranteed detection. Local inventories, logs, identity context, and threat intelligence are required to assess coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Tool
Adversaries may buy, steal, or download software tools that can be used during targeting. Tools can be open or closed source, free or commercial. A tool can be used for malicious purposes by an adversary, but (unlike malware) were not intended to be used for those purposes (ex: PsExec).
Adversaries may obtain tools to support their operations, including to support execution of post-compromise behaviors. Tools may also be leveraged for testing – for example, evaluating malware against commercial antivirus or endpoint detection and response (EDR) applications.CitationForescout Conti Leaks 2022CitationSentinel Labs Top Tier Target 2025
Tool acquisition may involve the procurement of commercial software licenses, including for red teaming tools such as Cobalt Strike. In addition to freely downloading or purchasing software, adversaries may steal software and/or software licenses from third-party entities (including other adversaries). Threat actors may also crack trial versions of software.CitationRecorded Future Beacon 2019
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.
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.
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.