Join our Newsletter — 33% off our NHI Course
Home› Guides› T1608 Stage Capabilities Defensive Guide: Detecting Payloads Staged…
Guide SOC & Detection Engineering

T1608 Stage Capabilities Defensive Guide: Detecting Payloads Staged on Trusted SaaS, Repos and Package Registries

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 12 min read
On this page

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

IDNameWhat is stagedWhere it is used next
T1608.001Upload MalwarePayloads, droppers, backdoors; backdoored packages, binaries, VM and container images on stores, registries and repositoriesT1105 Ingress Tool Transfer, T1204 User Execution, T1195 Supply Chain Compromise
T1608.002Upload ToolDual-use tools (ATT&CK gives PsExec as an example) on adversary or third-party hostingT1105 Ingress Tool Transfer
T1608.003Install Digital CertificateSSL/TLS certificates on adversary servers, obtained (T1588.004) or self-signed (T1587.003)Encrypted C2 (T1573.002 with T1071.001), credible phishing sites
T1608.004Drive-by TargetMalicious scripts in compromised or adversary sites, writeable cloud buckets, malicious adsT1189 Drive-by Compromise, often watering holes
T1608.005Link TargetCloned login pages and other link destinations, including on link shorteners and PaaS domainsT1566.002 Spearphishing Link, T1204.001 Malicious Link
T1608.006SEO PoisoningContent that manipulates search rankings, including in-site search on developer platforms such as GitHubT1189, T1195 lures
T1608.007AI Result PoisoningWeb content designed to be retrieved, cited or recommended by generative AI and AI-powered searchPhishing 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

SignalSourceSub-technique
New certificate issued for a lookalike of your domainCertificate Transparency monitoringT1608.003, T1608.005
Cloned copy of your login page hosted elsewhereBrand monitoring, internet scan data, phishing reportsT1608.005
Packages or repositories impersonating your projects or namesRegistry and repository monitoring, typosquat watchT1608.001, T1608.006
Unexpected new versions of your own packagesRegistry publish notifications, provenance checksT1608.001
Search or AI assistant results pointing to fake downloads of your productPeriodic checks of brand and product queriesT1608.006, T1608.007
Known adversary infrastructure patterns reappearingThreat intelligence and internet scan pivotsAll

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 routeControlTrade-off
File sharing and cloud storageTenant restrictions or allow lists for sanctioned file sharing; block executable downloads from unsanctioned servicesBusiness users need exceptions; manage them by group
Code repositoriesAllow raw content downloads only for approved organisations or through an internal mirrorDevelopers lose ad hoc downloads; provide a request path
Package registriesInternal proxy registry, minimum package age before use, pinned lockfiles, install scripts disabled by defaultSlower access to new releases
Container imagesPull only from approved registries with signature verificationNeeds an image promotion process
Drive-by and SEO luresSoftware installed only from a managed catalogue; DNS filtering of newly registered domains; ad blocking on managed browsersCatalogue upkeep effort
Link targetsPhishing-resistant MFA so cloned login pages cannot replay credentials; URL rewriting with time-of-click checksRollout 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.

  1. Preserve evidence first: record the URL, timestamps, hashes of the content, screenshots and the certificate details before reporting, because the content may vanish.
  2. 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.
  3. Block internally in parallel: add the specific URL, repository or package version to proxy and registry blocks rather than the whole platform.
  4. Share: pass indicators to your intelligence sharing community, and record which detections fired so behaviour-based rules outlast the indicator.
  5. 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

  1. 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.
  2. 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.
  3. Enforce in rings: apply blocks to a pilot group, then to all users, keeping a documented exception group with an owner for rollback.
  4. Harden registries: route package installs through a proxy registry, set a minimum package age, and move your own publishing to trusted publishing.
  5. 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

FrameworkReferenceRelevance to T1608
MITRE ATT&CK v20T1608.001 to T1608.007; M1056; DET0839 and sub-technique strategiesTechnique definition, mitigation and detection guidance
NIST CSF 2.0ID.RA-02, DE.CM-01, DE.CM-09, GV.SC-07Threat intelligence, monitoring network and software, supplier risk
NIST SP 800-53 Rev 5SC-7 Boundary Protection, SI-3 Malicious Code Protection, SI-4 System Monitoring, CM-11 User-installed Software, SR-4 Provenance, SR-11 Component AuthenticityDownload controls, malware detection, software provenance
MITRE ATLASAML.T0079 Stage CapabilitiesAI 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

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.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org