Editors’ note: While the analysis remains applicable, this page has not been updated since 2022.
Supply chain compromises were prevalent in 2021, and these incidents aren’t going away any time soon. It’s important to understand the different types of supply chain compromises. To state it simply, a supply chain compromise occurs when an adversary compromises a software developer, hardware manufacturer, or service provider and uses that access to target customers who use the affected software, hardware, or service. For example, the SolarWinds and Kaseya incidents involved an adversary compromising update servers to target customers of the companies’ IT management software. Separately, NPM package and Log4j incidents involved adversaries exploiting open source libraries in sweeping compromises that impacted products that use Log4j or NPM packages as a dependency—as well as anyone who uses those products directly. Each of these incidents made headlines in mainstream media as well as infosec publications.
Adversaries compromised SolarWinds, accessed the update infrastructure for its Orion IT management software, and sent backdoored updates to the company’s thousands of customers in December 2020, affecting organizations well into 2021. The trojanized Orion platform updates included a legitimately signed dynamic link library (DLL) file, and some featured backdoor functionality that, after a dormancy period lasting as long as two weeks, initiated communication with command and control (C2) servers. Adversaries identified targets of interest for further exploitation and conducted follow-on activity such as installing additional malicious binaries. These malicious binaries were used to install a backdoor where adversaries could access the victim organizations’ accounts. SolarWinds had a massive impact across many networks, and it took months for enterprises to investigate and respond. This compromise initiated important discussions about supply chain risks that remain relevant in 2022 and beyond.
In July 2021, adversaries exploited vulnerabilities in Kaseya VSA IT Management software in a campaign ultimately designed to deploy Sodinokibi ransomware, also known as REvil. VSA is popular among managed service providers (MSP) that use it to remotely administer IT systems. The adversaries exploited zero days to gain remote control over the MSPs’ VSA installations, which they used to infect the MSPs’ customers’ endpoints with ransomware. Kaseya estimated that about 50 direct customers who were running Kaseya VSA systems—and between 800 and 1,500 other businesses—were impacted by this breach. While the damage was not as bad as it could have been, this incident further highlights the importance of tracking supply chain threats. It also resulted in significant attention from the U.S. government, which later indicted the adversaries responsible for the intrusion.
Read about how Red Canary responded to the compromises and protected several customers from ransomware infections.
NPM package compromises
ua-parser-js, was downloaded around 8 million times a week at the time and is used by Google, Amazon, Facebook, IBM, and Microsoft. The U.S. Cybersecurity and Infrastructure Agency (CISA) published a security alert about the incident, warning victims to update to a safe version.
There were many other NPM compromises throughout the year, most notably
ua-parser-js. Prior to this compromise, an adversary copied the legitimate
ua-parser-js library and combined it with malicious code to publish a malicious library. Following this compromise, an adversary took control of two NPM packages,
rc. These incidents used a combination of XMRig coinminer on macOS and Danabot on Windows. Red Canary continues to track this activity.
Log4j is a popular Java logging library underlying many third-party applications that was hit with a remote code execution vulnerability in December 2021. The primary threats initially exploiting this vulnerability were coinminers and botnets, though the community feared exploitation would expand because of Log4j’s massive intrusion surface. In some scenarios, the Log4j library was affected by a remote code execution vulnerability.
One reason the community didn’t observe a large volume of exploitation in the first few days may be that these vulnerabilities are highly application-specific, depending on how they’ve implemented Log4j. This means an adversary could not have crafted a single exploit that would have had a broad impact on many types of applications at once. Though it took adversaries a few weeks to ramp up targeting, in late December 2021 and early 2022, internet-facing VMware Horizon servers using vulnerable versions of Log4j became a target for multiple operators. Adversaries were likely attracted to VMware Horizon because it is widely used and often internet-facing. We anticipate the continued targeting of internet-facing applications using vulnerable versions of Log4j for months to come.