This post is also available in: 日本語 (Japanese)
In today’s world, no company develops everything by itself. No matter which industry vertical we look at - from financial institutions, government, oil companies, nuclear reactors and military organizations - everyone uses software or hardware that was developed by third-party vendors. In doing so, every company essentially puts its trust in the protection not only in that third-party vendor, but also every other company in that vendor’s vendor list. It is a recursive chain of suppliers, and each one is susceptible to an attack.
This creates an opportunity for determined attackers, whether from cybercrime groups or nation-state-sponsored attackers, to target the weakest link in such a chain in an effort to gain access to the attacker’s primary target.
A software-based supply chain attack is the case where an attacker, commonly a nation-state-sponsored one, breaks into the systems of a software vendor and adds or modifies the code in a manner that would benefit the attacker. As stated before, the benefit to the attacker is gaining access to all or some of that vendor’s customers. This can be achieved with a minimal backdoor - a vulnerability that’s only known to the attacker and will be used to attack that vendor’s customers.
An attacker can also embed additional logic into that vendor’s software to move along the attack’s kill chain, such as reconnaissance capabilities and more. This was the case not too long ago in the SolarWinds supply chain attack, where attackers embedded code in updates to the SolarWinds Orion software that allowed access to the systems, networks, and data of Orion users as well as their customers and partners.
In the case of the SolarWinds supply chain attack, the attackers used known offensive cybersecurity tools such as Cobalt Strike at later stages of the attack. In the realm of nation-state-sponsored attacks, that’s considered negligence, because once an attacker uses known public attack tools and methods, it raises the chances of getting caught. That’s why nation-state-sponsored attackers refrain from using public tools in a mix with sensitive access capabilities that allow them access to targets of interest.
This implies that the method used in the SolarWinds attack isn’t considered a sensitive capability by that attacker, which could mean nation-state-sponsored attackers have many more SolarWinds-like supply-chain-attacks in their arsenal, with an even larger prevalence and impact.
The term supply chain attack is commonly used by cybersecurity vendors, but the definition is often loose enough to fit a vendor’s needs. That’s understandable, as there’s a lot of hype around supply chain attacks. But it is important to differentiate between different types of attacks. Not every vulnerability that allows remote code execution (RCE) on a largely adopted product is a supply chain attack. Meaning neither Log4Shell, SpringShell (AKA Spring4Shell) or other similar high impact vulnerabilities are supply chain attacks.
Additionally, there are products in the cybersecurity space that use the term “supply chain attack protection” when referring to source code inspection capabilities. However, this does not protect the customer using that product from supply chain attacks. What it does is protect that customer from putting its own customers at risk from running software that has known vulnerabilities as dependencies.
Currently, existing protection solutions in the space of the supply chain focus on security products that are sold to software companies. These products analyze code and continuous integration/continuous delivery (CI/CD) scripts in order to identify already known problems and vulnerabilities. Two important points here are that this only protects from already known vulnerabilities, not against any attack group with zero-day vulnerabilities or capabilities gained through actual supply chain attacks. Additionally, it has nothing to do with protecting you as a customer from possible vulnerabilities and errors that exist in products developed by your vendors.
We can divide the supply chain security domain into two categories:
This includes security products that are part of the DevSecOps approach, analyzing code and CI/CD scripts for configuration errors, known mistakes that are introduced by software and DevOps engineers, as well as usage of open source packages with known vulnerabilities. This is relevant only for companies that develop and sell software.
This approach is relevant to all companies, not just software development companies. It protects every enterprise, not just the vendor. Every company that uses computers is susceptible to an attack made possible because of an attack on one of its suppliers, or one of their suppliers.
At the time of writing, Palo Alto Networks is the only cybersecurity company that offers such protection, as can be deducted by the inability of security products to detect the SolarWinds supply chain attack. Also, very few companies even have a starting chance of attempting it. The reason for this high bar is that in order to tackle this challenge, a cybersecurity vendor must be able to fulfill several requirements:
- Have an enormous amount of Endpoint Detection Response (EDR) data from a very large number of enterprise customers that are viable final targets for nation-state-sponsored attackers.
- Continuous upload and storage of events of low-level operating system internal behaviors and actions.
- And most importantly, established, high quality and highly scalable analytics capabilities with proven algorithms and models on top of highly granular EDR data that is being collected.
Cortex XDR analytics is essentially a learning mechanism used to detect attacks that are otherwise very difficult or even impossible to detect using other methods. Analytics capabilities on eXtended Detection and Response (XDR) data rely on many collection and ingestion techniques that operate in a highly scalable and efficient manner.
Based on this high quality data that goes through tracking, normalization, association and stitching phases, analytics models learn various types of behaviors on multiple entities. This process is applied on event data of various data sources - endpoint, network, identity, SaaS and cloud data. Some examples for insights that are learned by analytics models on endpoint data include: what entities are proxy servers or domain controllers, which endpoints communicate with which domains and IP addresses, what processes inject threads into what processes and how, which syscalls are executed, how much and when are they used in each process.
Global Analytics is a new and powerful capability added to Cortex XDR, the concept of analytics learning—that takes place on a customer environment level in which various baselines are learned specifically for each customer environment—and extends it to a global level. Meaning that if previously analytics were able to determine a baseline and detect anomalies in the customer’s environment, now, with Global Analytics, Cortex XDR is able to determine a baseline and detect anomalies on applications used across our customer base.
All of this learning is taking place on normalized and pseudonymised data. Using sophisticated models and normalization techniques, this capability is tremendous in terms of:
- Detecting global-scale anomalies that could be part of an APT that’s using exotic tools.
- Improving existing detection methods with an even higher precision rate.
Cortex XDR agents continuously collect vast amounts of highly granular internal operating system data. Events that are collected span process executions, module loads, networking, system calls, remote procedure calls (RPC), Windows Management Instrumentation (WMI) queries, registry, file, mount, injection and many other types of events. These events are enriched with additional data that adds context, from stack traces, file entropy, ancestor process metadata and others.
Once all of this highly granular data, continuously collected from a large enterprise customer-base, is pushed into a scalable analytics engine, we get well-trained models that learn how various applications behave. The more data we have, the better we can identify globally unusual behaviors in these applications, which can indicate a malicious technique being used.
So what do supply chain attacks look like through the eyes of Cortex XDR?
As previously discussed, in a supply chain attack an attacker inserts code into existing software, in order to gain access to that supplier’s customers. Once a supplier is attacked, the customers of that supplier might automatically download the updated malicious version, and this updated version will be digitally signed by that vendor’s signature.
This process is true for any software that gets updated regularly, as well as for software and vendors targeted by a supply chain attack. So how can we differentiate legitimate software updates and malicious software updates? The answer is Global Analytics and Cortex XDR agents.
Most of the time, nation state actors and intelligence agencies are after intelligence data. Each actor has intelligence collection goals that need to be met one way or the other. These intelligence collection goals may include think tanks, nuclear reactors, private companies, persons of political interest, or any other vertical or group of people.
Some places are easier to gain initial access into, some are harder, but eventually a persistent actor will find its way in. This can be done in various ways, such as social engineering, software exploitation and supply chain attacks. Each method and capability is valuable, but once used in a wide manner it will be detected and burned. This means not only that the method can’t be used anymore, but it becomes highly likely that investigations will uncover previous uses and everything this capability helped achieve will also become known.
This is why nation state actors are cautious about using powerful sensitive capabilities, and especially in the case of a supply chain attack, where success provides access to all sorts of organizations around the world.
Of course, the vast majority of those may not be interesting targets for that attacker. So the first step for that actor would be to understand exactly which of the organizations it gained access to are interesting enough to invest further effort into. That’s the reconnaissance stage. The next step would be to deepen its grasp in that organization, move laterally, and look for intelligence and crown jewels.
What this means is that the actor will do very few slightly suspicious actions on many of the companies it gained access to, while performing relatively more suspicious actions on very few companies it gained access to. And that’s exactly what Global Analytics uses in order to detect that actor.
The first step in solving a problem is focus. Instead of looking for supply chain attacks in all applications that exist, we reduce the problem space into products and vendors that are viable and attractive targets for a supply chain attacker. These vendors and applications are divided into several verticals, and each vertical of viable supply chain attack vendors is learned across various EDR event types in our entire customer base.
Each of the monitored signed processes continuously collects and uploads highly granular and OS-specific low level data on the behavior of that process. Using Cortex XDR analytics on this data, we generate profiles on a daily basis for each customer. These profiles store and learn how each signed and monitored application behaves on each endpoint. This includes:
- Which domains and IP addresses it accessed, using what protocols, parameters and ports?
- Where and how did it inject threads?
- Which modules were dynamically loaded?
- What are their hashes?
- Who were they signed by?
All of this as well as additional profiles on additional event types. These analytics profiles are then joined together in a process that builds global profiles on the behavior of these signed processes, also on a daily basis.
Using these global profiles, detectors are defined and compared in real-time against every event that’s uploaded to Cortex XDR from any relevant data source. For each event a score is calculated, based on features that are based on the commonality of the behavior, in various aspects, both in terms of local profiles as well as in terms of global profiles.
In addition to uniquely detecting actual supply chain attacks, Global Analytics also provides high-precision detection and broad coverage for malicious code execution techniques within the context of another legitimate process. These include DLL hijacking/side-loading, exploitation and any method of thread injection that’s not known and published yet, including those that are rootkit-based.
A recent APT attacker was recently found using a Global Analytics detector and described in a Unit 42 blog in detail.
Once again, Cortex XDR has you covered against the most sophisticated attacks out there. Global Analytics is available with the release of Cortex XDR version 3.3. Detectors that provide detection for supply chain attacks and additional techniques mentioned in the blog are variations of the detector “Globally uncommon <action> from a signed process”.