analyst @ nohacky :~/mitre $
cat / mitre / t1195.002
analyst@nohacky:~/mitre/t1195002-compromise-software-supply-chain.html
reading mode 12 min read
technique_id T1195.002
category MITRE ATT&CK
tactics
Initial Access
parent_technique T1195 Supply Chain Compromise
published April 2026

T1195.002: Compromise Software Supply Chain

Adversaries manipulate application software before it reaches end users by targeting build pipelines, update mechanisms, or compiled release packages — then rely on the vendor's own distribution infrastructure to deliver the implant at scale to every customer who applies the update.

Software supply chain compromise sits at a unique intersection of scale and trust. When an adversary succeeds in embedding malicious code inside a legitimate vendor's build, they inherit the vendor's reputation. Security tools that whitelist signed software, network policies that permit update traffic, and IT teams that treat vendor updates as routine — all become vectors rather than defenses. The downstream organization never chose to install the attacker's code; they chose to keep their software current.

T1195.002 is classified under the Initial Access tactic, reflecting the reality that software supply chain compromise is typically how adversaries first establish a foothold across a wide set of targets. Unlike phishing or credential abuse — which require individual victims to take an action — a successful build pipeline compromise converts every update installation into an initial access event across the vendor's entire customer base simultaneously.

How Compromise Software Supply Chain Works

The attack surface for T1195.002 spans the entire software delivery lifecycle. Adversaries may target any of three primary entry points: the application source code repository, the build and compilation environment itself, or the update and distribution infrastructure through which finished packages reach customers.

Source code manipulation involves gaining write access to a version control repository and inserting malicious logic directly into the codebase. This approach requires the injected code to survive code review, automated testing, and the build process without triggering alerts. Sophisticated actors craft additions that mimic existing coding conventions, use variable names consistent with the surrounding logic, and avoid triggering known static analysis signatures.

Build environment compromise is often considered the most powerful variant because it leaves the source code repository clean. The adversary implants tooling — typically a background process — on the build server itself. This tooling monitors compilation activity and intercepts the build at the moment source files are compiled into binaries, injecting malicious code into the output artifact without modifying anything that developers would review. The resulting compiled binary differs from what the clean source would have produced, but the source itself appears unmodified.

Update and distribution channel hijacking targets the infrastructure responsible for hosting and delivering finished packages. If an adversary can replace a legitimate installer or update file on a distribution server — or redirect update traffic to a server they control — they can deliver malicious software to every client configured to pull from that source, regardless of whether the build process or source repository was ever touched.

warning

A valid digital signature on a software package does not guarantee that the package is free of malicious code. It only confirms that the package was signed with the vendor's certificate — which may have been used during a compromised build. Treat signature verification as a necessary but insufficient control.

In some documented incidents, adversaries have used access obtained from one supply chain compromise to pivot into a second vendor's environment, producing what MITRE refers to as a cascading or second-order supply chain compromise. This chaining behavior significantly amplifies the reach of an initial intrusion and complicates attribution.

Real-World Case Studies

SolarWinds Orion / SUNBURST (2020)

The SolarWinds incident remains the most extensively documented software supply chain attack on record. Beginning no later than September 2019, adversaries attributed to Russia's SVR (tracked by CrowdStrike as StellarParticle and by Microsoft as Nobelium) gained access to SolarWinds' internal environment. Rather than modifying source code in the repository directly, they deployed a build-server implant designated SUNSPOT. SUNSPOT monitored for MsBuild.exe process activity — the Visual Studio build component used to compile the Orion platform — and at the moment of compilation, it swapped a clean source file for a modified version containing the SUNBURST backdoor. Once the build completed, SUNSPOT cleaned up the temporary file, leaving the source repository in a state consistent with the clean codebase. The compiled DLL was then digitally signed with SolarWinds' legitimate certificate and distributed through official update channels. Between March and June 2020, SolarWinds delivered trojanized Orion updates to approximately 18,000 customers. SUNBURST remained dormant for up to two weeks after installation before beginning low-and-slow reconnaissance, communicating over legitimate-looking Orion Improvement Program traffic to avoid detection. A small subset of victims — including US government agencies and major technology companies — were escalated for hands-on follow-on operations involving TEARDROP, RAINDROP, and other secondary payloads.

3CX Desktop App / Cascading Supply Chain (2023)

The 3CX incident in March 2023 was the first publicly confirmed case of one software supply chain compromise directly enabling a second. 3CX Desktop App, a widely deployed enterprise voice-over-IP communications platform serving over 600,000 organizations, was trojanized by adversaries who had gained access to 3CX's Windows and macOS build environments. Mandiant's subsequent investigation traced the initial access vector to a 3CX employee who, in April 2022, had downloaded a trojanized version of X_Trader — a financial trading application from Trading Technologies. The X_Trader installer had been tampered with by North Korean operators tracked as UNC4736, a cluster associated with the AppleJeus campaign. The installer planted a backdoor called VEILEDSIGNAL on the employee's machine, which the adversaries used to move laterally through 3CX's network until they reached the build environment. The trojanized 3CX application contained a downloader, SUDDENICON, that retrieved encrypted command-and-control server addresses from icon files hosted on GitHub. Follow-on targeting was selective, with secondary payloads including Gopuram deployed primarily against victims in the defense and cryptocurrency sectors. The code-signing certificate used to legitimize the malicious X_Trader package had already been set to expire in October 2022, meaning the compromise of Trading Technologies had occurred no later than late 2021.

CCleaner / CCBkdr (2017)

In September 2017, Avast and Cisco Talos disclosed that version 5.33 of the widely used CCleaner utility had been shipped with an embedded backdoor designated CCBkdr. The malicious version was available for download from CCleaner's official distribution site and was digitally signed with a valid Piriform certificate. The backdoor collected system information and transmitted it to a command-and-control server. Subsequent analysis connected the infrastructure to APT41, a China-nexus threat actor conducting both espionage and financially motivated operations. Approximately 2.27 million users installed the compromised version. A third-stage payload was delivered to a small subset of targets — primarily technology companies — indicating that the broad distribution was used as a filtering mechanism to identify high-value victims for more targeted follow-on activity.

Detection Strategies

T1195.002 is difficult to detect at the point of delivery because the malicious code arrives inside a package that has passed the vendor's build process and carries a valid signature. Effective detection must combine pre-deployment verification, behavioral monitoring post-installation, and network-level anomaly detection.

File Integrity and Hash Verification

index=* sourcetype=sysmon EventCode=11
| eval expected_hash=case(
    file_name="SolarWinds.Orion.Core.BusinessLayer.dll", "known_clean_sha256_here",
    file_name="3CXDesktopApp.exe", "known_clean_sha256_here"
)
| where isnotnull(expected_hash) AND sha256!=expected_hash
| table _time, host, file_name, sha256, expected_hash, process_name

Post-Installation Behavioral Monitoring

index=* sourcetype=sysmon EventCode=3
| where process_name IN ("SolarWinds.BusinessLayerHost.exe","3CXDesktopApp.exe","ccleaner.exe")
| stats count by dest_ip, dest_port, process_name, host
| where dest_ip!="known_vendor_update_ip"
| sort -count

Build Server Process Anomaly Detection

index=* sourcetype=sysmon EventCode=1 host="build-server-*"
| where parent_process_name="MSBuild.exe"
  AND process_name NOT IN ("cl.exe","link.exe","csc.exe","vbc.exe","aspnet_compiler.exe")
| table _time, host, parent_process_name, process_name, command_line, user

Behavioral Indicators

Indicator What It Means
Installed binary hash differs from vendor-published checksum Package was modified after the vendor published it, or the vendor's published checksum does not correspond to the clean build
Newly installed software initiates DNS lookups to uncommon or dynamically generated domains Possible DGA-based or algorithmically selected C2 infrastructure consistent with backdoor beaconing
Monitoring or management process spawning unexpected child processes Legitimate infrastructure management tools rarely spawn shells or scripting engines; this warrants immediate investigation
Build server running unexpected injection or memory-reading operations during compilation Potential SUNSPOT-style build process hijack; adversary tooling is monitoring for compiler invocations
Outbound traffic from software update processes to IPs with no prior history in the environment May indicate update mechanism hijacking or post-installation C2 beacon traffic

Known Threat Actors Using T1195.002

T1195.002 is associated with some of the most capable nation-state and financially motivated threat actors documented in the MITRE ATT&CK knowledge base. The technique demands sustained access to a victim vendor environment, deep knowledge of the target's build infrastructure, and the operational patience to avoid detection across months-long intrusions.

  • APT29 / Nobelium / StellarParticle (Russia, SVR) — Deployed SUNSPOT to hijack the SolarWinds Orion build pipeline, resulting in the SUNBURST backdoor being distributed to approximately 18,000 organizations. Considered among the most operationally sophisticated uses of T1195.002 documented to date.
  • UNC4736 / AppleJeus-linked (North Korea) — Responsible for the cascading 3CX supply chain attack. Compromised Trading Technologies' X_Trader distribution first, then leveraged the resulting access to compromise 3CX's build environment. Financially motivated, with secondary targeting focused on cryptocurrency and defense-sector victims.
  • APT41 (China) — Gained access to production build environments and injected malicious code into legitimately signed software packages for wide distribution. Operates across both espionage and financially motivated objectives, using supply chain access to reach targets otherwise difficult to compromise directly.
  • Daggerfly / Evasive Panda (China-nexus) — Conducted multiple supply chain compromises using malicious updates to software popular among targeted ethnic or geographic communities, demonstrating the use of T1195.002 for selective rather than mass-scale targeting.
  • Dragonfly / IRON LIBERTY (Russia) — Placed trojanized installers for industrial control system software on legitimate vendor application stores, targeting the energy sector and critical infrastructure operators.
  • GOLD SOUTHFIELD — Distributed REvil/Sodinokibi ransomware by backdooring software installers obtained through strategic web compromise, demonstrating that T1195.002 is also used for ransomware delivery, not exclusively espionage.

Defensive Recommendations

  1. Verify hashes before deployment: Obtain SHA-256 checksums from vendor release notes and verify downloaded packages independently before installing in production. Automate this verification in deployment pipelines and treat a hash mismatch as a security incident, not an update error.
  2. Harden build environments as high-value targets: Apply the same security controls to build servers that you would to domain controllers. Restrict network egress from build systems, enforce least-privilege for build service accounts, enable comprehensive process and file creation logging, and monitor for unexpected parent-child process relationships during compilation.
  3. Implement a software bill of materials (SBOM) program: Require vendors to provide SBOMs for critical software. An SBOM documents all components included in a release and provides a baseline against which subsequent updates can be diffed to detect unexpected additions.
  4. Monitor post-installation behavior, not just signatures: Deploy endpoint detection and response tooling that monitors network connections, child process creation, and file writes initiated by newly installed or recently updated software. Flag any infrastructure management or monitoring tool communicating with external hosts not associated with the vendor's documented update infrastructure.
  5. Apply update staging and canary deployment practices: Do not apply vendor updates immediately across the entire environment. Deploy to a small, monitored canary group first and observe behavior for 48–72 hours before broader rollout. Anomalous network activity or unexpected process behavior in the canary group should pause the rollout.
  6. Enforce code signing policy with revocation awareness: Configure systems to check certificate revocation status at the point of execution, not only at installation time. A certificate that was valid at installation may subsequently be revoked after a compromise is discovered, and revocation checking at runtime provides an additional backstop.
  7. Conduct vendor security assessments for critical software: For software with privileged access to your environment — network monitoring tools, endpoint agents, backup software — assess the vendor's build security practices as part of procurement. Request documentation of their CI/CD pipeline security controls, code signing key management, and incident response capabilities.

MITRE ATT&CK Mapping

Field Value
Technique IDT1195.002
Technique NameSupply Chain Compromise: Compromise Software Supply Chain
Parent TechniqueT1195 Supply Chain Compromise
TacticInitial Access (TA0001)
PlatformsLinux, Windows, macOS
Data SourcesFile: File Metadata; Application Log: Application Log Content
MitigationsM1051 Update Software; M1016 Vulnerability Scanning; M1013 Application Developer Guidance
ATT&CK Versionv18 (Last Modified: 24 October 2025)
MITRE Referenceattack.mitre.org/techniques/T1195/002

Frequently Asked Questions

What is T1195.002 Compromise Software Supply Chain?

T1195.002 is a MITRE ATT&CK sub-technique under Supply Chain Compromise (T1195). It describes adversary manipulation of application software before delivery to end users, targeting source code, build pipelines, update servers, or compiled release packages to embed malicious code inside legitimate, digitally signed software.

How do adversaries execute a software supply chain compromise?

Adversaries typically gain access to a software vendor's development or build environment, then inject malicious code into the source or intercept the build process so that compiled artifacts contain a backdoor. The resulting package is signed with the vendor's legitimate certificate and distributed through official update channels, making it appear trustworthy to end users and security tools alike.

How can organizations detect T1195.002 software supply chain compromise?

Detection relies on file integrity monitoring of installed software binaries, hash verification against known-good checksums, monitoring build server activity for unauthorized process injection, and behavioral analysis of newly installed software communicating with unexpected external hosts. Network-level indicators include beaconing patterns, DNS lookups to uncommon domains shortly after software installation, and unusual outbound connections from processes associated with monitoring or infrastructure management tools.

Sources and References

  • MITRE ATT&CK — T1195.002 Compromise Software Supply Chain: attack.mitre.org
  • CrowdStrike — SUNSPOT Malware: A Technical Analysis: crowdstrike.com
  • Mandiant / Google Cloud — 3CX Software Supply Chain Compromise Initiated by a Prior Software Supply Chain Compromise: cloud.google.com
  • KPMG — SolarWinds Explainer (SUNSPOT / SUNBURST analysis): kpmg.com
  • MITRE ATT&CK — T1195 Supply Chain Compromise (parent technique): attack.mitre.org
  • MITRE ATT&CK — 3CX Supply Chain Attack Campaign C0057: attack.mitre.org