Detecting and Mitigating Supply Chain Compromise (T1195)

Supply chain compromise (MITRE ATT&CK T1195) means an attacker manipulates a product, or the way it is delivered, before the final consumer receives it. The aim is data or system compromise. MITRE files it under Initial Access and lists Linux, SaaS, Windows and macOS as platforms. It has three sub-techniques: compromised dependencies and development tools (T1195.001), compromised software supply chain (T1195.002) and compromised hardware supply chain (T1195.003).

The defender's problem is that the thing you are installing looks legitimate, because it came from a source you chose to trust.

How attackers use it

MITRE says compromise can happen at any stage of the supply chain. Its list:

• 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 and distribution mechanisms
• Compromised or infected system images, such as removable media infected at the factory
• Replacement of legitimate software with modified versions
• Sales of modified or counterfeit products to legitimate distributors
• Shipment interdiction

Adversaries who want code execution have often focused on malicious additions to legitimate software in distribution or update channels. They may limit targeting to a desired victim set, or distribute widely and only follow up with specific victims. Popular open-source projects that many applications depend on can also be targeted, which adds malicious code for everyone who uses the dependency.

MITRE also describes "second-order" supply chain compromise, where access gained in one compromise is used to compromise another software component. That lets the attacker spread to more victims.

Some examples on the MITRE page: an attacker compromising IT providers and software developers to reach their customers, stealer malware delivered through cracked software downloads, and compromised versions of legitimate installers staged on forums.

How to detect it

MITRE's detection strategy describes a behavioral chain: package or update tamper, then install, then first run. By platform:

Windows. New or updated software arrives from an atypical source or with a signature or hash mismatch. The installer or updater writes binaries to unexpected paths or replaces existing signed files. On first run, unsigned or oddly signed modules load or child processes start, possibly followed by network traffic to new destinations.

Linux. A package manager, curl or wget installs or upgrades from a repository that is not approved, or from unsigned packages. A new ELF file lands in a PATH directory, or an existing binary or library is replaced. First run leads to unexpected child processes or outbound connections.

macOS. Packages or notarization checks show installs from atypical sources, or Gatekeeper and AMFI warnings. A new Mach-O file appears in /Applications or under ~/Library, or a signed component is swapped. The first run from the installer spawns unsigned children or sends data out.

The common thread is the first run. Many tampered packages look fine on disk and only show their hand when they execute. Log process creation, file writes in program and PATH directories, module loads and first-seen network destinations for new software.

How to reduce the risk

MITRE's mitigations, in plain steps:

• Guide your developers on dependencies. Be cautious about which third-party libraries go into an application, and lock dependencies to specific versions instead of pulling the latest version on build.
• Use internal repositories. Where possible, require developers to pull from internal repositories of verified and approved packages instead of external ones.
• Check boot integrity. Use secure boot methods and verify the operating system and loading mechanisms.
• Run a patch management process that also checks for unused, unmaintained or previously vulnerable dependencies and unnecessary features and files.
• Limit privileges. Software should run with the lowest privileges it needs. Avoiding root or administrator limits how far a compromise can spread.
• Scan for vulnerabilities continuously, using monitoring of vulnerability sources and automatic and manual code review tools.

Check your own environment

Work through these questions:

• Can you list every direct and transitive dependency in your main applications, with versions?
• Are versions pinned, and does your build use a lockfile?
• Does your CI pull from an approved internal repository, or straight from the public internet?
• Do you know which installers and updaters run with administrator or root rights?
• Do you alert on new binaries appearing in PATH directories or program folders?
• Do you have a way to answer "which of our systems contain package X at version Y" within the hour?

The last question is the one that decides how fast you can respond. You can get a first answer for a project with the free in-browser dependency scan at gold.safeguard.sh/scan. It needs no login, your file never leaves your machine, and it covers up to 100 dependencies.

Try it yourself

An inventory of what you depend on is the base of every supply chain control. This demo shows how a dependency inventory is built and read.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1195: Supply Chain Compromise