T1608.002: Upload Tool
Adversaries may upload tools to third-party or adversary controlled infrastructure to make it accessible during targeting. Tools can be open or closed source, free or commercial. Tools 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 upload tools to support their operations, such as making a tool available to a victim network to enable Ingress Tool Transfer by placing it on an Internet accessible web server.
Tools may be placed on infrastructure that was previously purchased/rented by the adversary (Acquire Infrastructure) or was otherwise compromised by them (Compromise Infrastructure).[1] Tools can also be staged on web services, such as an adversary controlled GitHub repo, or on Platform-as-a-Service offerings that enable users to easily provision applications.[2][3][4]
Adversaries can avoid the need to upload a tool by having compromised victim machines download the tool directly from a third-party hosting location (ex: a non-adversary controlled GitHub repo), including the original hosting site of the tool.
Analyst context for executives and security teams
Upload Tool is a pre-compromise resource-development behavior: adversaries make legitimate tools available on third-party, rented, compromised, or cloud-hosted infrastructure so they can later pull them into a target environment. The business issue is not the upload itself, which may happen outside your network, but whether your organization can recognize when approved-looking tools are being staged, fetched, or abused in ways that support an intrusion.
Executive priority
Treat this as a resilience and readiness gap rather than a single alert rule. Leaders should ask whether the organization can distinguish normal use of public repositories, PaaS, and administrative tools from suspicious staging and download activity. This matters for incident response speed, managed detection scope, cloud/SaaS visibility, and audit evidence around pre-compromise monitoring. Relationship context shows this technique is associated in ATT&CK with multiple campaigns and groups, so it should be considered when prioritizing threat-informed detection engineering, without assuming local exposure or active exploitation.
Technical view
This sub-technique sits under Stage Capabilities and the Resource Development tactic on the PRE platform. Official ATT&CK detection text is not provided, but a detection strategy relationship exists as DET0834. SOC and IR teams should validate coverage around the point where the staged tool becomes observable: external infrastructure intelligence, web/proxy/DNS records, downloads from GitHub-like repositories or PaaS hosting, and subsequent Ingress Tool Transfer-style activity. Because the tools may be legitimate open-source, commercial, or administrative utilities such as PsExec-like tooling, detection should focus on context, source, timing, destination host role, and whether the tool is approved for that environment.
Likely telemetry
- Web proxy, secure web gateway, and HTTP/S download logs showing retrieval of tools from public repositories, PaaS, or unusual Internet-hosted locations
- DNS and passive DNS observations for newly observed or unusual staging domains and hosting locations
- Endpoint process, file creation, and command execution telemetry showing newly downloaded administrative or dual-use tools
- Cloud/SaaS access logs where public repositories or application-hosting services are used as tool staging locations
- Threat intelligence or external attack-surface monitoring related to adversary-controlled, compromised, or suspicious infrastructure
Detection direction
- Validate whether DET0834 or equivalent local analytics exist; ATT&CK does not provide official detection logic for this object.
- Tune for suspicious combinations rather than tool names alone: legitimate tools, public repositories, and PaaS hosting create high false-positive potential.
- Correlate download source reputation, first-seen domains, hosting type, user/host role, file hash prevalence, and execution shortly after download.
- Pay special attention to environments where outbound web logging is incomplete, TLS inspection is limited, or developer/cloud service usage is broadly allowed without monitoring.
- Use relationship context to enrich hunting hypotheses, but do not treat the listed campaigns or groups as evidence of activity in your environment without local indicators.
Mitigation priorities
- Prioritize M1056 Pre-compromise practices: reduce exposed information and attack surface, and improve visibility into adversarial preparation activities.
- Maintain an approved software and administrative-tool baseline so unusual downloads of dual-use tools can be reviewed quickly.
- Control and monitor where endpoints and servers may download executable tools from, especially public repositories, PaaS, and unfamiliar web infrastructure.
- Ensure incident response playbooks include triage for staged-tool downloads: source validation, hash/prevalence checks, host containment criteria, and follow-on activity review.
- For cloud-heavy or developer-heavy organizations, balance controls with business workflows by documenting sanctioned repositories and hosting services.
Analyst notes and limits
This object is most valuable as an early-warning and coverage-validation topic. Since staging can occur outside the victim environment, many organizations will only see the behavior when a host retrieves or executes the tool. The ATT&CK relationships to campaigns and groups indicate observed use in reporting, including espionage, ransomware-related, and cyber-physical/energy-sector contexts, but those relationships should be used for prioritization and threat modeling, not attribution by themselves.
Official ATT&CK detection content is not provided for T1608.002, and the related DET0834 details are not included in the supplied fields. Platform is limited to PRE, so host/network telemetry recommendations are practical validation points for downstream observability rather than a claim that the upload action itself is visible inside every environment. Local baselines, approved-tool inventories, and egress logging determine real detection quality.
Upload Tool
Adversaries may upload tools to third-party or adversary controlled infrastructure to make it accessible during targeting. Tools can be open or closed source, free or commercial. Tools 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 upload tools to support their operations, such as making a tool available to a victim network to enable Ingress Tool Transfer by placing it on an Internet accessible web server.
Tools may be placed on infrastructure that was previously purchased/rented by the adversary (Acquire Infrastructure) or was otherwise compromised by them (Compromise Infrastructure).[1] Tools can also be staged on web services, such as an adversary controlled GitHub repo, or on Platform-as-a-Service offerings that enable users to easily provision applications.[2][3][4]
Adversaries can avoid the need to upload a tool by having compromised victim machines download the tool directly from a third-party hosting location (ex: a non-adversary controlled GitHub repo), including the original hosting site of the tool.
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.
Related techniques
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 | T1608 | Stage Capabilities | This object subtechnique of Stage Capabilities. |
Groups, software, and campaigns
G1051: Medusa Group
Medusa Group has been active since at least 2021 and was initially operated as a closed ransomware group before evolving into a Ransomware-as-a-Service (RaaS) operation. Some reporting indicates that certain attacks may still be conducted directly by the ransomware’s core developers. Public sources have also referred to the group as “Spearwing” or “Medusa Actors.” [1] [2] Medusa Group employs living-off-the-land techniques, frequently leveraging publicly available tools and common remote management software to conduct operations. The group engages in double extortion tactics, exfiltrating data prior to encryption and threatening to publish stolen information if ransom demands are not met. [3] For initial access, Medusa Group has exploited publicly known vulnerabilities, conducted phishing campaigns, and used credentials or access purchased from Initial Access Brokers (IABs). The group is opportunistic and has targeted a wide range of sectors globally. [4]
G0027: Threat Group-3390
Threat Group-3390 is a Chinese threat group that has extensively used strategic Web compromises to target victims.[1] The group has been active since at least 2010 and has targeted organizations in the aerospace, government, defense, technology, energy, manufacturing and gambling/betting sectors.[2][3][4]
C0022: Operation Dream Job
Operation Dream Job was a cyber espionage operation likely conducted by Lazarus Group that targeted the defense, aerospace, government, and other sectors in the United States, Israel, Australia, Russia, and India. In at least one case, the cyber actors tried to monetize their network access to conduct a business email compromise (BEC) operation. In 2020, security researchers noted overlapping TTPs, to include fake job lures and code similarities, between Operation Dream Job, Operation North Star, and Operation Interception; by 2022 security researchers described Operation Dream Job as an umbrella term covering both Operation Interception and Operation North Star.[1][2][3][4]
C0010: C0010
C0010 was a cyber espionage campaign conducted by UNC3890 that targeted Israeli shipping, government, aviation, energy, and healthcare organizations. Security researcher assess UNC3890 conducts operations in support of Iranian interests, and noted several limited technical connections to Iran, including PDB strings and Farsi language artifacts. C0010 began by at least late 2020, and was still ongoing as of mid-2022.[1]
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
All related ATT&CK context
Mitigation direction
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.2 | Current bundle | bbcae5275c56… |
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]
Dell TG-3390
Dell SecureWorks Counter Threat Unit Threat Intelligence. (2015, August 5). Threat Group-3390 Targets Organizations for Cyberespionage. Retrieved August 18, 2018.
Open source URL -
[2]
Dragos Heroku Watering Hole
Kent Backman. (2021, May 18). When Intrusions Don’t Align: A New Water Watering Hole and Oldsmar. Retrieved August 18, 2022.
Open source URL -
[3]
Malwarebytes Heroku Skimmers
Jérôme Segura. (2019, December 4). There's an app for that: web skimmers found on PaaS Heroku. Retrieved August 18, 2022.
Open source URL -
[4]
Intezer App Service Phishing
Paul Litvak. (2020, October 8). Kud I Enter Your Server? New Vulnerabilities in Microsoft Azure. Retrieved August 18, 2022.
Open source URL -
[5]
mitre-attack T1608.002Open 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.