In the last couple of years, security teams in large enterprises and high-profile government organizations have increasingly experienced a new form of attack. This attack leverages the supply chain of an organization’s software ecosystem (and less frequently, hardware components) to inject malicious code that is later used to compromise the breached entity. Supply chain attacks existed during the previous decade, but they have grown exponentially in frequency, scale, and sophistication since 2020. This has made supply chain attack mitigation exceedingly vexing.
The most famous supply chain attack to date was exposed in December 2020. Aiming to exfiltrate sensitive national defense-related information, it used Solarwinds’ popular Orion software management platform to breach high profile US federal agencies, major technology firms, and key government contractors. The victim list included among others, the US State Department, Department of Energy, Department of Homeland Security, and major corporations like Microsoft and Cisco. Information regarding many similar events was subsequently made public, including attacks exploiting major software and hardware suppliers such as Asus, Codecov, Kaseya, and Accellion.
A supply chain attack is a multi-phase breach operation usually performed by the most sophisticated attack organizations, such as advanced persistent threat (APT) groups. The point of a supply-chain attack is to allow unauthorized code execution inside what is presumed to be a protected system or a segmented/isolated network, leveraging the trusted relationship between the target organization and its software suppliers.
In this phase, an attacker breaches the network of a vendor to the software platform the attacker wishes to compromise. This platform will often be a common IT management product used in the target organization. The goal of this phase is to find and reach the R&D or DevOps environment of this supplier and inject malicious code into the next software version or the data/configuration update that is soon to be distributed to the supplier’s customers.
Next the perpetrator leverages the fact that customers of this software platform enable the supplier to have direct and relatively easy remote access to their enterprise network to allow ongoing software updates and upgrades. The open interface between the supplier and the customer enables malicious code (which is bundled and hidden within the legitimate code coming from the supplier) to be injected into the target enterprise. This malicious code is seldom detected by the organization’s security systems, as it seemingly comes from a recognized and trusted source.
The fact that a supplier’s software platforms are typically used by the IT teams of the target organization means they have high-level, administration access rights within the organization’s network. This makes it easier for an attacker to implement the third phase of the attack. To achieve an attacker's malicious goal(s), the third phase requires gaining control over an organization’s network and reaching the specific assets/resources they want to exploit by performing data exfiltration, component disablement, or inflicting physical damage. Unfortunately the malicious code is perceived to be a part of the trustworthy supplier software package and leverages its users’ access rights. This means a perpetrator can “roam around” without invoking security alerts related to unauthorized behavior until very late in the process—and usually not before much, or all of the damage is already done.
Supply chain attacks have a very large potential “damage footprint” in that they can affect the entire user base of any popular software product. This means they can be used by politically motivated attack organizations not only to breach a relatively small number of high-value agencies and enterprises, as in the Solarwinds and Asus attacks. They can also create havoc and even paralyze a nation by attacking a huge number of organizations using a widespread software product.
This seemingly theoretical scenario became reality in 2017. An attack group assumed to be connected to the Russian government leveraged a common Ukrainian accounting software supplier named M.E.Doc. It injected malicious code into M.E.Doc’s product, and used it to attack thousands of organizations in Ukraine. This basically brought the country’s government and most of its business sector to a halt. It disabled everything from the Chernobyl nuclear reactor’s monitoring system to international airports, causing billions of dollars in direct and collateral damage.
To date, few—if any—available security products or procedures can effectively and consistently block most of the variants of supply chain attacks. A Crowdstrike survey found 84 percent of responders say supply-chain attacks were one of the biggest cyber threats to their organization over the next three years. 63 percent said they were losing trust in their software suppliers—including major suppliers such as Microsoft—due to these frequent security incidents.
Enterprises threatened by these attacks can reduce the risk of a breach through rigorous supplier auditing, carefully managing software updates, and implementing a zero-trust approach. However, supply chains are in most cases very complex and opaque. They involve many open-source components whose suppliers can’t always be monitored and audited. So as important as these actions may be, they’re far from sufficient for effective supply chain attack mitigation.
In some cases, “security hygiene” best practices can even work against a target organization during a supply chain attack. The most security-aware enterprises are often breached first because they installed the latest supplier software updates quickly—and with them, the malicious code. Organizations which don’t stay up to date with the latest software versions are sometimes spared.
There are different directions and approaches that may be implemented for better supply chain attack mitigation. Software suppliers must improve visibility into their continuous integration and continuous delivery/deployment (CI/CD) process. This will enable them to detect malicious code injections before the software is sealed and released to the market. Crucially, target organizations should deploy run-time environment detection and prevention tools. These identify unauthorized or unusual behavior of what “appears to be” the software product within their environment and block it from accessing network resources that should be outside its reach.
One technology for achieving effective run-time protection in an enterprise network is Moving Target Defense (MTD). MTD randomizes trusted runtime application code so no two machines look precisely alike, and even a single system keeps changing over time. It allows you to randomize some of the underlying operating system components, frequently used services, and library APIs. While trusted applications are made aware of the modified runtime environment, MTD blocks any software component oblivious to the traps left behind.
What makes this approach so potent is the ability to perform this modification in memory, where an adversarial attempt to inspect, modify, or even bypass is immediately trapped and blocked. These periodic in-memory randomized changes make it incredibly difficult for an adversary to train in one place and then reuse the training results later on, or on other machines.
Supply chain attacks are here to stay, and will only become more prevalent and more harmful going forward. They are one of the most severe threats facing security teams at software suppliers, large enterprises, and government agencies. We may even see this type of attack hitting smaller enterprises as the techniques and skill-sets required to conduct such an attack become commoditized. (This was the case with other types of attacks, like DDoS and ransomware.) To learn more about how MTD can proactively block supply chain attacks—and other advanced attacks, request a demo now.