Introduction
After I saw the buzz about Kaseya on July 2nd, I decided it was time to start writing a blog post about targeting the supply chain.
Software supply chain “attacks” aren’t new, however, they will become much more mainstream now that there has been extended media coverage of the SolarWinds incident. You may have noticed a similar uptick with IoT botnets, cryptominers, and ransomware over the years due to copycats within the categories that typically learn from their predecessors and build more sophisticated, resilient and profitable TTPs. There was even a slight uptick in OT attacks for a while. I hypothesize that this was temporarily put on hold as the international community made it known that the consequences for disrupting, destroying, or otherwise causing harm to critical infrastructure could rise to the level of an act of war, particularly in cases where there are losses of life. These attacks too are returning as ransomware operators target the IT side of critical infrastructure or go even as far to ransom HMIs but not to fully disrupt the OT. Threat actors understand our processes well. They know how to achieve desired effects without having to pull the trigger themselves. Instead, as we saw with the Colonial Pipeline ransomware incident, the threat actors can cause such chaos on the business and IT side that the business chooses to deny and shut down their own OT out of an abundance of caution. Unfortunately, supply chain exploitation, although a serious national security issue, does not present the same levels of risk that “attacks” on true operational critical infrastructure presents, such as the loss of life. However, they do give an entry point for these types of attacks to occur, and we should understand how our adversaries will pick their next targets for supply chain exploitation.
What we have seen thus far within the community in regards to software supply chain exploitation is that the key objective of the threat actor is intelligence collection. Typically, we see two different routes that cyber espionage can go, that is, “CNE” (exploitation) or “CNA” (attack). Exploitation typically furthers some other end objective like intelligence collection or the deployment of other cyber effects under the attack category like deny, disrupt, destroy, degrade, deceive, or manipulate. This post isn’t really going to get into depth on the effects that could be deployed via a supply chain compromise, however, just keep in mind that the implications from the Confidentiality-Integrity-Availability (CIA) triad perspective are far greater than violating the Confidentiality portion through the intelligence gathering that we have seen to date.
Upstream [Initial] Target(s)
First, let’s talk about our upstream target. These are our “manufacturers” and “suppliers” in traditional supply chain speak. These are the software development companies that are writing the code that a consumer will ultimately install onto one of their devices. Sometimes, depending on the supply chain, the manufacturer may be building a component that goes to another manufacture who then assembles a larger product before it is delivered to a consumer. Sometimes the product goes through suppliers, channel partners, or resellers before it gets to the consumers. Either way for our purposes the software development company will be our “manufacturer” and thus our “upstream target”. So, what are some of the characteristics that could make a software development company an ideal upstream target? Let’s get into an adversarial mindset and draw some conclusions based off recent supply chain compromises. First, let’s start with the Target Software Characteristics.
| Characteristics | Additional Notes |
|---|---|
| Software with the capability to communicate across network boundaries | This is especially true if the software beacons using encrypted communications and the downstream target does not have a “break-and inspect” capability. Adversaries have utilized stolen certificates in the past. |
| Software that has system/root/kernel level access | This gives the software the ability to bypass other detective and preventative security controls. |
| Software with cross-platform / cross-operating system capabilities across the enterprise* | Many asset management, antivirus / endpoint protection platforms (EPP), endpoint detection and response (EDR) / extended detection and response (XDR), network monitoring, remote monitoring and management (RMM), mobile device management (MDM), Mobile App Management (MAM), Enterprise Mobility Management (EMM), and Unified Endpoint Management (UEM), professional services automation (PSA), log forwarding, centralized policy management, data loss prevention (DLP), etc agents have this capability. Think beyond Active Directory, which often stops at Windows hosts within many Enterprises. |
| Software that acts as a centralized management platform to many or all nodes within an enterprise, regardless if it is agent-based or agentless** | Many agentless platforms utilize protocols in conjunction with administrator or root credentials that allow them to communicate with nodes including PCs, servers, network appliances (e.g. routers), OT devices, IoT devices, and other types of nodes on the network and perform commands or other functionality that could enable secondary compromises. This includes software that manages configuration baselines, deployment of patches and scripts, vulnerability scanning and other IT and security operations. |
| Software that is often whitelisted | Obviously, this is counter-intuitive to a zero-trust approach. In addition, it often allows software to bypass detective and preventative security controls. This makes the software a perfect candidate for injecting malicious code. |
| Software that has previously caused defenders to suffer from “alert fatigue” if taking a zero-trust approach | Defenders will often ignore these alerts by saying, “ah, it’s just X again”. |
Target Software Characteristics
Based on the Target Software Characteristics I’ve generated a list of categories below. Although these categories do contain organizations based on what Gartner has compiled, it doesn’t mean that this list is holistic, nor is it representative of the characteristics that will be outlined in the next section titled “Upstream Target Manufacturer Characteristics”. It is meant to provide a starting point for broader research.
| Application Performance Monitoring | Asset Performance Management Software | Client Management Tools | Continuous Configuration Automation Tools |
| E-Discovery Solutions | Endpoint Detection and Response Solutions | Endpoint Protection Platforms | Enterprise Asset Management Software |
| Enterprise Data Loss Prevention | Enterprise Mobility Management Suites | File Analysis Software | IT Infrastructure Monitoring Tools |
| IT Process Automation | Information-Centric Endpoint and Mobile Protection | Intrusion Detection and Prevention Systems | IoT Integration |
| IoT Platforms | IoT Security | Mobile Application Management | Mobile Data Protection Solutions |
| Mobile Threat Defense | Network Automation and Orchestration Tools | Operational Technology Security | Security Information and Event Management |
| Security Orchestration, Automation and Response Solutions | Software Asset Management Tools | Unified Endpoint Management | User and Entity Behavior Analytics |
| Vulnerability Assessment |
Upstream Target Software Categories
Aside from the Target Software, there will also be characteristics about the Upstream Target Manufacturer that will make them an ideal candidate.
| Characteristics | Additional Notes |
|---|---|
| Upstream manufacturer vulnerabilities | N/A |
| Level of Difficulty | Some of the upstream targets will be more difficult to target and exploit than others. Of course, with a little persistence any target can be exploited, so no target should be discarded just because they seem difficult. |
| Their relationship to the primary objective, which is typically a downstream target or targets | N/A |
Upstream Target Manufacturer Characteristics
The attack chain for the upstream target will vary, but initial access can include any of the initial access techniques within the MITRE ATT&CK Matrix. Expect at least one full attack chain to have been carried out on the upstream target. This attack chain will precede the attack chain for the downstream target. The downstream targets attack chain will begin with the initial access technique of “supply chain compromise” and subsequent tactics and techniques will be utilized from that point forward. To get an idea of what Software Supply Chain Exploitation looks like check out my blog post here.
Downstream [Intermediary and/or Primary] Target(s)
As stated in the “Upstream Target Manufacturer Characteristics”, one characteristic that makes the upstream target a good target is its relationship to the primary objective, which is typically a downstream target or targets. If we look at the SolarWinds Customers page from December 2020, we can draw some basic conclusions about the types of intermediary and primary targets that a threat actor may want to target.
| Target Name | Intermediary or Primary |
|---|---|
| Fortune 500 Companies | Both |
| Federal Government Departments/Agencies | Primary |
| State, Local, Tribal, and Territorial (SLTT) Departments/Agencies | Primary |
Down Stream Targets
To understand the reason for targeting the downstream targets, we have to understand the threat actor’s desired end state(s). As discussed before, what we have observed up to this point is purely intelligence collection. We haven’t seen the delivery of any real “cyber effects”. There is still very much that is not understood about the impacts of the SolarWinds incident. For example, there are multiple software companies listed on this Customer page. This is about as basic of a depiction as it gets of what this looks like:
Were there subsequent supply chain compromises to establish even longer-term persistence throughout America? Think about these scenarios depicted in the diagram below based on the customer page. Do note however that to my knowledge, these are made up. In these scenarios, the yellow boxes are intermediary downstream targets and the red box represent primary downstream targets. These primary downstream targets could always also be selected and developed as new intermediary targets once access is gained.
These scenarios are based on only three organizations listed on the Customers page, but hopefully this does enough to demonstrate just a few of many implications that could occur if subsequent supply chain compromises were to occur. Just imagine what the eradication steps would be like for something that far-reaching.
Conclusion
In conclusion, my approach would be to continue applying zero-trust. I would adjust to heavily scrutinize software that falls into the “Upstream Target Software Categories” or otherwise possesses the “Target Software Characteristics”.
Ideas for Future Research on This Topic
- Generate a list of Intermediary Target Software Categories
- Map Possible Paths between Upstream Targets (Manufacturer:Software) -> Downstream Targets (Intermediary:Software/Primary:Software)
For feedback on this post feel free to message us on Twitter, LinkedIn, or via Email.