Adversaries may manipulate products or product delivery mechanisms prior to receipt by a final consumer for the purpose of data or system compromise.
Supply chain compromise can take place at any stage of the supply chain including:
* Manipulation of development tools
* Manipulation of a development environment
* Manipulation of source code repositories (public or private)
* Manipulation of source code in open-source dependencies
* Manipulation of software update/distribution mechanisms
* Compromised/infected system images (removable media infected at the factory)[1][2]
* Replacement of legitimate software with modified versions
* Sales of modified/counterfeit products to legitimate distributors
* Shipment interdiction
While supply chain compromise can impact any component of hardware or software, adversaries looking to gain execution have often focused on malicious additions to legitimate software in software distribution or update channels.[3][4][5] Adversaries may limit targeting to a desired victim set or distribute malicious software to a broad set of consumers but only follow up with specific victims.[6][3][5] Popular open-source projects that are used as dependencies in many applications may also be targeted as a means to add malicious code to users of the dependency.[7]
In some cases, adversaries may conduct “second-order” supply chain compromises by leveraging the access gained from an initial supply chain compromise to further compromise a software component.[8] This may allow the threat actor to spread to even more victims.
64th pctamong all ATT&CK techniques for number of groups
3 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has compromised information technology providers and software developers providing services to targets of interest, building initial access to ultimate victims at least in part through compromise of service providers that work with the victim organizations.1
Staged compromised versions of legitimate software installers on forums to achieve initial, untargetetd access in victim environments.1
created 2017-05-311 referenceaka ELECTRUM
All 3 groups for this technique
2 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
1) New or updated software is delivered/installed from atypical sources or with signature/hash mismatches; 2) installer/updater writes binaries to unexpected paths or replaces existing signed files; 3) first run causes unsigned/abnormally signed modules to load or child processes to execute, optionally followed by network egress to new destinations.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
First-time egress from host after new install to unknown update endpoints
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
Field
What you tune
TimeWindow
Correlation window between install events and first-run activity (default 2h; adjust for staged rollouts).
TrustedPublishers
Publisher/Signer allow-list to suppress expected updates.
TrustedUpdateHosts
Known update CDNs/APIs (e.g., download.microsoft.com) to reduce egress false positives.
RiskScoreThreshold
Score cut-off for alerting when combining path, signer, and reputation features.
AN1481 · Linux
1) Package manager or curl/wget installs/upgrades from non-approved repos or unsigned packages; 2) new ELF written into PATH directories or replacement of existing binaries/libraries; 3) first run leads to unexpected child processes or outbound connections.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
1) pkg/notarization installs from atypical sources or with Gatekeeper/AMFI warnings; 2) new Mach-O written into /Applications or ~/Library paths or substitution of signed components; 3) first run from installer spawns unsigned children or exfil.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
Application developers should be cautious when selecting third-party libraries to integrate into their application. Additionally, where possible, developers should lock software dependencies to specific versions rather than pulling the latest version on build.
Where possible, consider requiring developers to pull from internal repositories containing verified and approved packages rather than from external ones.
A patch management process should be implemented to check unused dependencies, unmaintained and/or previously vulnerable dependencies, unnecessary features, components, files, and documentation.
Implement robust user account management practices to limit permissions associated with software execution. Ensure that software runs with the lowest necessary privileges, avoiding the use of root or administrator accounts when possible. By restricting permissions, you can minimize the risk of propagation and unauthorized actions in the event of a supply chain compromise, reducing the attack surface for adversaries to exploit within compromised systems.
The following analytic hunts for any creations or modifications to GitHub Actions workflow YAML files across the organization's Linux or Windows endpoints. (...)