Print this page

SolarWinds Supply Chain Attack is the Gift that Keeps on Giving for Security Research

Rate this item
(0 votes)

Reading time is around minutes.

The SolarWinds supply chain attack was and still is one of the most complex and ingenious attacks that has come to light. How it was discovered is also an interesting topic for another conversation. The attack group in question is still being speculated on although one most people tend to gravitate towards is the Russian APT group COZY BEAR (APT29). The actual attack and compromise of the software repository at SolarWinds is the stuff of legend. Once that was completed it allowed the attackers access to a wide swath of business verticals along with government agencies from a single trusted source. They could, almost on a whim, compromise anyone that leveraged the SolarWinds product. Of course, supply chain attacks are nothing new and are not going anywhere. They are complicated to set up and maintain, but once in place they can yield amazing results.

Returning our focus back to the SolarWinds compromise, researchers have been pouring through the data since to get a better understanding of the tools and techniques (TTPs) used by this attack group. Last month CrowdStrike released a report on some additional tactics and techniques possibly associated with the group. These techniques range from a different twist on older tactics to new malware (or variants of malware) that were implemented. All of these were part of the post exploitation period of an attack.

After getting into an organization and establishing a beachhead the attackers spent a great deal of effort in masking who they were and how they were moving around a compromised environment. One of the methods for this was by credential hopping. By entering the environment through a “front door” service like SSH using one set of credentials (typically a local set), then establishing an RDP session with a random internal server using a compromised service account. From there they would establish another RDP connection to a different server using a compromised domain admin account. The final step and the goal in the chain was to access Office 365 using a different account with privileged access.

This type of tactic can make it hard to spot the odd person out. Since the same credentials are not used for each step pattern matching and behavior matching systems might not pick up the movement. The same can be said for the Office 365 access. As the connection is coming from a likely well known and/or trusted IP it might not show up as a risky account use. This tactic does require the compromised of many accounts which we will cover in some of the other tactics used during the campaign. Although hard to detect, there are things that can be done to prevent an attack of this type including installing or implementing zero trust systems, leveraging Privileged Account Management (PAM), and requiring additional validation/authorization before access of servers in an environment.

You may have noticed that we did not mention MFA in the list of methods to prevent the post exploitation techniques used. Well, that is because in this case the attackers were able to steal MFA session cookies right out of Chrome and replay them to gain access. This method is an interesting one and did require the attackers to already have a significant level of control in the environment in question. The threat actor was able to gain access to a targeted endpoint via SMB and an administrator account. Once they had this, they were able to copy and exfiltrate the user’s Chrome profile and data protection API (DPAPI) information in an encrypted format. From there they decrypted the cookies using a few different methods so that they could insert an MFA cookie into a Chrome session using a Cookie Editor plugin for Chrome. They were also observed to have used the built-in export function in Chrome to export a csv of all saved passwords (this is why you should never save passwords in a browser).

The attackers abused Office 365, AzureAD and On-Prem AD resources. They pivoted from O365 partner accounts that had delegated access, impersonated O365 apps, leveraged O365 service principals, created their own service principals, downloaded user accounts and password hashes using PowerShell commands (Get-ADReplAccount), and a lot more.

The list goes on and on with each new technique described showing the level of skill and sophistication of this group. It also shows how even internal “trusted” systems, partners and accounts need to be monitored and maintained. The adage of “trust but verify” seems sorely lacking and outdated compared top how this attacker lived inside of a compromised environment. Of course, all of this was made possible by the original supply chain compromise. That provided the red-carpet invitation into the environment and allowed for such a deep level of control and access.

Sean Kalinich

Latest from Sean Kalinich

Related items