Protecting Against Supply Chain Attacks

Supply chain attacks are a fast growing method for infiltration. In a supply chain attack, bad actors attempt to infiltrate an organization by exploiting vulnerabilities in its supply chain network.

Statistics

While the attack is indirect, bad actors are attracted to attempt supply chain attacks to gain immediate access to a broader set of end-users. For example, when remote management vendor, Kaseya, was breached in July 2021, bad actors were able to immediately spread ransomware to more than 1,500 of their customers.

The number of software supply chain attacks is significantly increasing. In Sonatype’s 2021 State of Software Supply Chain recognizes a 650% year-over-year increase in supply chain attacks from 2015 to 2021. According to the Identity Theft Resource Center (ITRC), there were 19 supply chain attacks just in Q4 2020.

60%

year of year increase in attempted intrusions.
650%

year over year increase in software supply chain attacks.
1,500

the number of customers estimated to have been impacted by the Kaseya supply chain attack.

How do supply chain attacks work?

Supply chain attacks are multi-staged attacks leveraging a variety of attack techniques to reach desired goals. By indirectly infiltrating supply chain vendors, bad actors seek to gain access to the networks of their end-users or customers. Two varieties of a supply chain attack are:

Method 1: Partner network access

In this supply chain attack, bad actors gain access to a partner network, such as a managed service provider (MSP), to then gain access to the MSP’s clients’ networks. For example, in the 2013 Target breach, bad actor’s initially gained access to Target’s HVAC partner’s network. This network is used to monitor the HVAC systems at Target stores. By gaining access to this less secure partner network, the bad actors were able to find their way to the Point-of-Sale (POS) networks to install RAM scraping software on POS units to steal credit card information.
Method 2: Software supply chain

In this supply chain attack, bad actors infiltrate supply chain vendors to discover source code repositories or update systems to inject their own malicious software. In today’s networking environments, both software applications and hardware appliances regularly ‘phone home’ to retrieve and perform updates. Often these updates are automated. It is not uncommon for upgrades to fetch data for other libraries, including third-party sources. Often upgrades run with root or administrator privileges, and execute a variety of scripts throughout the update process.

For example, in the SolarWinds breach, bad actors successfully added a malicious DLL (Microsoft Data Link Library) file to a SolarWinds update. Once installed on a customer’s system and activated after a random wait period, the DLL performs command-and-control, retrieving and executing commands from a third party system managed by the Bad Actor.

How the chain of attacks is usually detected

While performing all of these methods reduces risk of a successful attack, it will not guarantee an attack can be prevented. For many organizations, it is difficult at best to sustainably accomplish all three methods.

Inventory and monitor third-party tools
Monitor remote access granted to suppliers
Monitor third-party providers

Customer case study

Challenge
- Lack of perimeter breach detection for Linux instances exposed to the public internet
- Increased supply chain and compliance risks with inability to monitor third-party vendor products using Linux, like AWS
- High operational costs for staff with Linux programming experience
Solution
- Visibility into all Linux environments, including owned and vendor supplied
- Ability to apply behavior analysis to Linux
- Trace supply chain attacks at the operator level
- Trace supply chain attacks at the operator level
Benefits
- Reduced mean time from incident detection to root cause
- Protect assets and monitor Linux at the OS level
- Trace full path of events across Linux environments
- Create alerts from playbooks for consistent detection across environments

Spyderbat captures the causal relationships across every process, network connection, and file access performed by the update

Once attack techniques are detected, Spyderbat allows for an immediate recognition of the source back to the third-party update even if months prior. The attack’s full footprint is revealed since any/all activity between the previous software update and the current detection is captured, even if the bad actor/malware uses random weight periods in between activities.

Because Spyderbat does not rely on log data analysis, the attack trace is captured even if logging systems were disabled (or never enabled to begin with). This allows for full mitigation of the threat including new installed backdoors, created user accounts, etc.

Ready to See Spyderbat in Action?