Solorigate, the ‘Pyramid of Pain’, and the Future of Mitigation: A Rapid Assessment
Along with many, I’ve found David Bianco’s Pyramid of Pain to be a really useful rubric to understand breaches. It’s held up really well over the years (circa 2013!) and across a myriad of incidents. This is partially due to the simplicity of it: at a glance, defenders have an understanding of how their tooling and indicators align with the pyramid’s tranches, which correspond to the components of an attackers’ stack.
More importantly, it communicates how defenders can alter the calculus for attackers targeting their environment. By optimizing for detection of signatures and patterns at the top of the pyramid, an attack could be uncovered earlier and/or deemed ‘not worth it’ by virtue of blocking some critical part of the stack. Or so it would seem.
Time and resources soothe pain
Nation-states are tenacious and will typically spare no expense to compromise a target environment. The calculus in doing so extends to the realm of grand strategy. A state will determine that something is in the national interest — perhaps existential in nature — and devote treasure and time to attaining that thing. Today, that tends to be information that can be leveraged for political and/or economic ends. The known targets of the Solorigate episode suggest an interest in various government functions; the broad access realized by a supply-chain compromise likely led to other targets of secondary and tertiary interest (still, they were apparently selective).
FireEye and Microsoft have produced the best technical analysis about Solorigate to date. What it shows is that the responsible party invested a lot of time to ensure that indicators did not exist for tooling and network artifacts, (and even things lower down in the Pyramid). For example, the compromised code library (DLL) was digitally signed (since revoked by MSFT), indicating access to SolarWind’s code base repository. Furthermore, the added lines of code invoked a backdoor via a parallel process, ensuring the “DLL’s normal operations [were] not altered or interrupted,” in addition layered obfuscation (Source). In totality, the attacker’s level of sophistication and persistence becomes quickly apparent.
The deployment of in-country C2 is trivial enough, but the mimicry of standard application behaviour was more thought out (Source) and probably indicates a carefully designed test environment in which actual target environments were replicated. This was likely slow, iterative work, once the attackers recognized the opportunity before them sometime in late 2019. Modifications in the environment were observed to be temporary — perhaps timed between scan windows that may have detected and alerted on changes. The use of different credentials to achieve lateral movement suggests a degree of discipline, and also patience as it relates to procuring those account details (Ibid.).
Mitigation Tomorrow
Bianco’s Pyramid is still relevant, but the landscape is changing. Aspects of the attack stack that were harder to replace or build in 2013 are more dynamic today. Well-resourced attackers will devote the time to customize what they need to avoid detection in a given environment. Prevention will remain elusive; organizations can raise barriers against certain attackers and be successful over the long term, but not all and not for forever. So that places the onus, once again, on digital forensics and incident response, and post-breach mitigation. Same as it ever was, with a few potential improvements.
Environments will become compromised and therefore must be both highly isolated and highly ephemeral. Computing will be purpose-based, brought up for a given period of time, allowed access into a secure data store and to other processes, and brought back down once a task is completed. In parallel, dynamic trust will be increasingly important: no process or system should be explicitly trusted once validated at inception; it’s reliability must be confirmed time and again (see BeyondCorp). Credentials will be more dynamic and integrate many more factors of authenticity, in the way that TOTP is starting to provide today.
Moreover, updates from external parties must be vetted not just for compatibility, but for changes that could indicate compromise as with the code library in this case. EDR tooling should extend to meet this use case, which requires detection based on behaviour, and not just known patterns and signatures. Such an approach must extend much more broadly to all services, processes and commands in a given environment; each of these must be scrutinized constantly. When a deviation is detected, alerts must sound. Ideally, the response to such alerting is automated and conditional, resulting in isolation of a suspect system and remediation in rapid fashion.
The most painful aspects to change within the attacker’s stack are those things the attacker cannot control. It’s impossible not to have some effect on an environment, create or change outbound communications, or generate new processes and libraries (and so on). According to Locard’s principle, which applies to criminal forensics, an attacker will leave some trace, and vice versa. The signatures might be barely perceptible, but they are there.
