Adversaries increasingly stage their payloads, tools and phishing pages on the same services your organisation trusts, so a download from a code repository, a file sharing link or a package registry can be the first visible step of an intrusion. MITRE ATT&CK T1608 Stage Capabilities covers adversaries uploading, installing or otherwise setting up capabilities they developed or obtained on infrastructure they control, whether acquired, compromised, or a third-party web service. It sits in the Resource Development tactic (TA0042) and in ATT&CK v20 has seven sub-techniques: Upload Malware, Upload Tool, Install Digital Certificate, Drive-by Target, Link Target, SEO Poisoning and AI Result Poisoning. Staging happens outside your network, so this guide frames defence as exposure reduction, early external signals, takedown and the controls that decide whether a staged capability ever reaches a user or build system. It is for detection engineers, threat intelligence analysts and the owners of developer platforms and web proxies. Abuse of cloud services for command and control after compromise is covered in the Cloud Services Abuse for C2 Guide; this page covers the staging step before delivery.
Key takeaways
- Staging is invisible until delivery. ATT&CK's only mitigation is M1056 Pre-compromise, and its detection strategies point to internet scanning for known patterns plus detection at the later stages: user execution, ingress tool transfer and drive-by compromise.
- Trusted platforms are the default staging ground. ATT&CK procedure examples include GitHub, Google Drive, Dropbox, OneDrive, Amazon S3, Docker Hub, Discord's CDN and npm. Domain reputation alone will not catch them.
- Package registries turn staging into supply chain compromise. Shai-Hulud published trojanised npm packages from compromised maintainer accounts; CISA reported over 500 packages affected. Stolen publishing tokens are a non-human identity problem.
- Takedown is a defensive tool. GitHub, npm and other platforms run abuse reporting; a fast, evidence-backed report shortens the window a staged capability is live.
- Search and AI answers are now delivery channels. T1608.006 SEO Poisoning and the new T1608.007 AI Result Poisoning place staged content in front of users who search for software or ask an assistant.
The seven sub-techniques
| ID | Name | What is staged | Where it is used next |
|---|---|---|---|
| T1608.001 | Upload Malware | Payloads, droppers, backdoors; backdoored packages, binaries, VM and container images on stores, registries and repositories | T1105 Ingress Tool Transfer, T1204 User Execution, T1195 Supply Chain Compromise |
| T1608.002 | Upload Tool | Dual-use tools (ATT&CK gives PsExec as an example) on adversary or third-party hosting | T1105 Ingress Tool Transfer |
| T1608.003 | Install Digital Certificate | SSL/TLS certificates on adversary servers, obtained (T1588.004) or self-signed (T1587.003) | Encrypted C2 (T1573.002 with T1071.001), credible phishing sites |
| T1608.004 | Drive-by Target | Malicious scripts in compromised or adversary sites, writeable cloud buckets, malicious ads | T1189 Drive-by Compromise, often watering holes |
| T1608.005 | Link Target | Cloned login pages and other link destinations, including on link shorteners and PaaS domains | T1566.002 Spearphishing Link, T1204.001 Malicious Link |
| T1608.006 | SEO Poisoning | Content that manipulates search rankings, including in-site search on developer platforms such as GitHub | T1189, T1195 lures |
| T1608.007 | AI Result Poisoning | Web content designed to be retrieved, cited or recommended by generative AI and AI-powered search | Phishing sites, malicious downloads, impersonation pages |
ATT&CK notes for T1608.002 that adversaries can avoid uploading a tool at all by having a victim download it from its original hosting site, which is why allow lists that trust whole platforms are weak against this technique. The AI mirror of this technique is covered in AML.T0079 Stage Capabilities.
How adversaries stage capabilities: recorded cases
- Package registries: ATT&CK records Shai-Hulud (S9008) publishing malicious tarballs after modifying packages within compromised accounts, and TeamTNT (G0139) uploading backdoored images to Docker Hub. In the first Shai-Hulud wave in September 2025, a worm used npm tokens found on infected developer and CI machines to publish trojanised versions of every package the token owner maintained. CISA's alert reported over 500 packages affected and stolen credentials posted to public GitHub repositories named Shai-Hulud. See the Shai-Hulud npm Worm, First Wave (September 2025) analysis.
- Code repositories as lures: ATT&CK records Contagious Interview (G1052) hosting malicious payloads on code repositories used as lures for victims, and LazyScripter (G0140) hosting open-source remote access trojans on GitHub.
- File sharing and cloud storage: ATT&CK records APT32 (G0050) hosting payloads in Dropbox, Amazon S3 and Google Drive, EXOTIC LILY (G1011) using TransferNow, TransferXL, WeTransfer and OneDrive, and BlackByte (G1043) staging Cobalt Strike on public file sharing sites.
- Trojanised legitimate software: ATT&CK records FIN7 (G0046) staging trojanised legitimate software on Amazon S3 and modifying a compromised product site's download links, and Sandworm Team (G0034) staging compromised installers in forums.
- Stolen certificates: ATT&CK records Sea Turtle (G1041) capturing legitimate SSL certificates from victim organisations and installing them on its own infrastructure.
- Search poisoning: ATT&CK records Mustard Tempest (G1020) poisoning search results to return fake software updates, and NIMBUS MANTICORE (G1059) using SEO poisoning to deliver malware.
Where identity fits
Staging on trusted platforms usually needs an account on that platform: a compromised maintainer's npm token, a GitHub personal access token, a cloud storage key, or a hijacked SaaS tenant. When those credentials belong to your organisation, your platform becomes someone else's staging ground and your customers become the targets. Treat publishing credentials as high-value non-human identities: use trusted publishing with short-lived OIDC credentials where the registry supports it, scope tokens to single packages, require phishing-resistant MFA for maintainers, and audit who can publish. See the npm Trusted Publishing and Provenance Guide and the GitHub and GitHub Actions Security Guide.
What to detect and where
ATT&CK v20 publishes a detection strategy for each sub-technique (DET0839 for T1608, DET0824 Upload Malware, DET0834 Upload Tool, DET0840 Install Digital Certificate, DET0825 Drive-by Target, DET0893 Link Target, DET0881 SEO Poisoning, DET0922 AI Result Poisoning). Most rely on the Internet Scan data source and its Response Content component: if you already know an adversary's patterns, internet scanning may reveal newly staged content. DET0840 adds certificate tracking and pivoting on certificate details. DET0922 states there is no target-side behavioural analytic for AI Result Poisoning. The practical split is outside-in signals and inside-out controls.
Outside-in: signals before delivery
| Signal | Source | Sub-technique |
|---|---|---|
| New certificate issued for a lookalike of your domain | Certificate Transparency monitoring | T1608.003, T1608.005 |
| Cloned copy of your login page hosted elsewhere | Brand monitoring, internet scan data, phishing reports | T1608.005 |
| Packages or repositories impersonating your projects or names | Registry and repository monitoring, typosquat watch | T1608.001, T1608.006 |
| Unexpected new versions of your own packages | Registry publish notifications, provenance checks | T1608.001 |
| Search or AI assistant results pointing to fake downloads of your product | Periodic checks of brand and product queries | T1608.006, T1608.007 |
| Known adversary infrastructure patterns reappearing | Threat intelligence and internet scan pivots | All |
For certificate monitoring see the Certificate Transparency Monitoring Guide for Web Teams, and for lookalike domains the Typosquatting and Lookalike Domains Guide.
Inside-out: catching the staged capability on arrival
- Web proxy and DNS: downloads of executables, scripts, archives and disk images from file sharing, paste, raw repository content and CDN domains, especially by processes that are not browsers or package managers.
- Endpoint telemetry: a script interpreter or office application spawning a network download followed by execution; this is the T1105 and T1204 stage ATT&CK points to.
- Package installs: install-time scripts making outbound connections, new dependencies with very recent publish dates, and lockfile changes outside normal update windows.
- CI/CD: build jobs fetching from unpinned URLs or unpinned actions, and new outbound destinations from runners.
- TLS: certificates on newly contacted servers that are very recent, self-signed or mismatched to the hostname.
Mitigations and controls
ATT&CK maps T1608 and all sub-techniques only to M1056 Pre-compromise: the technique cannot be easily mitigated with preventive controls because it happens outside enterprise defences. The controls below are NHI Mgmt Group recommendations that limit where staged capabilities can reach.
| Staging route | Control | Trade-off |
|---|---|---|
| File sharing and cloud storage | Tenant restrictions or allow lists for sanctioned file sharing; block executable downloads from unsanctioned services | Business users need exceptions; manage them by group |
| Code repositories | Allow raw content downloads only for approved organisations or through an internal mirror | Developers lose ad hoc downloads; provide a request path |
| Package registries | Internal proxy registry, minimum package age before use, pinned lockfiles, install scripts disabled by default | Slower access to new releases |
| Container images | Pull only from approved registries with signature verification | Needs an image promotion process |
| Drive-by and SEO lures | Software installed only from a managed catalogue; DNS filtering of newly registered domains; ad blocking on managed browsers | Catalogue upkeep effort |
| Link targets | Phishing-resistant MFA so cloned login pages cannot replay credentials; URL rewriting with time-of-click checks | Rollout of authenticators |
For package controls see the Malicious Package and Dependency Confusion Guide and the npm Install-Time Security Guide; for search lures see the Malvertising and SEO Poisoning Guide and, for AI answers, LLM Grooming and AI Search Poisoning.
Takedown and reporting
When a staged capability targets your users or impersonates your organisation, getting it removed is part of the response.
- Preserve evidence first: record the URL, timestamps, hashes of the content, screenshots and the certificate details before reporting, because the content may vanish.
- Report to the platform: GitHub provides Report abuse on user and organisation pages and Report repository on repositories, with a contact form for other reports. npm provides a Report malware button on the package page; after validating a report, npm removes the package, publishes a security placeholder and publishes a security advisory.
- Block internally in parallel: add the specific URL, repository or package version to proxy and registry blocks rather than the whole platform.
- Share: pass indicators to your intelligence sharing community, and record which detections fired so behaviour-based rules outlast the indicator.
- Close the loop: if your own credentials were used to stage content, revoke them and audit everything that identity published.
For lookalike domains and cloned sites use the Brand Impersonation and Lookalike Domain Takedown Playbook.
Implementation and testing
- Baseline: export 30 days of proxy logs and list the file sharing, repository and paste domains that served executables or scripts. Identify which were business use.
- Monitor before blocking: run download rules for unsanctioned file sharing and raw repository content in alert-only mode for two to four weeks and tune exceptions.
- Enforce in rings: apply blocks to a pilot group, then to all users, keeping a documented exception group with an owner for rollback.
- Harden registries: route package installs through a proxy registry, set a minimum package age, and move your own publishing to trusted publishing.
- Test: host a benign test file on an approved and an unapproved file sharing service and confirm that proxy and EDR rules alert or block as designed; publish a test package version to a private registry and confirm it is held by the age rule.
Measuring it
- Unsanctioned downloads: executables and scripts downloaded from unsanctioned file sharing or repository hosts per week.
- Registry hygiene: share of builds pulling only through the proxy registry with pinned lockfiles.
- Publishing identity: share of your packages published through trusted publishing rather than long-lived tokens.
- Time to takedown: median hours from discovery of a staged capability targeting you to removal.
- Lookalike detection lead time: days between certificate issuance for a lookalike domain and your detection of it.
Common failure patterns
- Trusting whole platforms: allow listing all of a code hosting or storage service lets adversary-controlled content through on the same domain.
- Long-lived publishing tokens: a single stolen npm token let Shai-Hulud publish to every package its owner maintained.
- Installing the newest version immediately: builds that pull fresh releases with install scripts enabled run staged code within minutes of publication.
- Indicator chasing only: blocking a single URL after it is reported, without detecting the download-then-execute behaviour, misses the next staged copy.
- Takedown without evidence: reporting before capturing hashes and screenshots leaves nothing for the investigation once the content is removed.
Framework mapping
| Framework | Reference | Relevance to T1608 |
|---|---|---|
| MITRE ATT&CK v20 | T1608.001 to T1608.007; M1056; DET0839 and sub-technique strategies | Technique definition, mitigation and detection guidance |
| NIST CSF 2.0 | ID.RA-02, DE.CM-01, DE.CM-09, GV.SC-07 | Threat intelligence, monitoring network and software, supplier risk |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection, SI-3 Malicious Code Protection, SI-4 System Monitoring, CM-11 User-installed Software, SR-4 Provenance, SR-11 Component Authenticity | Download controls, malware detection, software provenance |
| MITRE ATLAS | AML.T0079 Stage Capabilities | AI system equivalent |
Related techniques with their own pages: T1105 Ingress Tool Transfer Defensive Guide, T1204 User Execution, MITRE ATT&CK T1195 Supply Chain Compromise and T1102 Web Service Defensive Guide.
Practitioner checklist
- Proxy rules alert on executable and script downloads from unsanctioned file sharing, paste and raw repository hosts.
- Package installs go through a proxy registry with pinned lockfiles and a minimum package age.
- Your own packages use trusted publishing; any remaining tokens are scoped and short-lived.
- Maintainer and developer accounts use phishing-resistant MFA.
- Certificate Transparency monitoring covers your domains and likely lookalikes.
- Software is installed from a managed catalogue, not from search results.
- An abuse reporting runbook names the platforms, the evidence to capture and the owner.
- EDR detections cover download-then-execute chains regardless of the source domain.
Standards and references
- MITRE ATT&CK: T1608 Stage Capabilities
- MITRE ATT&CK: T1608.001 Upload Malware
- MITRE ATT&CK: T1608.007 AI Result Poisoning
- MITRE ATT&CK: M1056 Pre-compromise
- CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
- npm Docs: Reporting malware in an npm package
- GitHub Docs: Reporting abuse or spam
Related NHI Mgmt Group resources: ATT&CK Resource Development Tactic Guide, Cloud Services Abuse for C2 Guide, Shai-Hulud npm Worm Guide, AML.T0079 Stage Capabilities.