Deep into the SunBurst Attack

By Lior Sonntag

During the week of December 13th, we witnessed what many are calling one of the biggest cyberattacks in recent times.  SunBurst, the malware installed on SolarWinds’ Orion product, perpetrated what seems like a nation-state sponsored supply chain attack, and as a result featured prominently in global headlines.
The attack raised awareness to supply chain based compromises and previous reports offered best practices on how to identify and mitigate the impact of the attack, provided deep dive to TEARDROP– one of the payloads used, and offered advice on protecting from the attack itself.
The activity following this supply chain attack included lateral movement and data theft.

In this blog, we focus on the second phase in the cloud and present some of the key tactics and techniques used by the nation-state actors in the malicious campaign. Using the MITRE ATT&CK framework, we provide the most likely technical attack flow.

According to the Microsoft article, this is the chain of events from a high-level perspective:

1. Initial Access (On-Prem) – Use Forged SAML tokens and illegitimate registrations of SAML Trust Relationships to impersonate a user with administrative credentials (in this case, Azure AD).
2. Discovery – Enumerate existing applications / service principals (preferably with high traffic patterns) .
3. Credential Access – Add credentials to an existing application or service principal.
4. Privilege Escalation – Elevate the privileges of the  application/service-principal to allow access to MS Graph APIs Application permissions.
5. Defense Evasion and Lateral Movement – Acquire OAuth access tokens for applications to impersonate the applications and obfuscate malicious activity.
6. Exfiltration – Call MS Graph APIs to exfiltrate sensitive data such as users’ data and emails.

As mentioned previously, our focus is on the attack flow in the Cloud Environment after the initial authentication (i.e. steps b-f).
Before we go into the attack flow, some background on the AzureAD Authentication and Authorization mechanisms.
Authentication is providing proof that you are who you say you are. This is done by the Identity Provider i.e. Azure AD.
Authorization is the act of granting an authenticated party permission to do something. This is done by the resource the identity is trying to query, utilizing the OAuth 2.0 protocol.

Discovery

After the threat actors gain an initial foothold in the Cloud Environment by compromising privileged cloud users with administrative access to the Azure AD, they add credentials to an existing application or service principal.
To do that, the attackers first need to list all the existing applications:

The attackers prefer an application with high traffic patterns (e.g. mail archival applications) which can be used to obfuscate their activity, so they choose  “MailApp” (an imaginary application name) and extract its ObjectId and ApplicationId:

In addition, the attackers extract the account’s tenantId:

Credential Access

Next, the attackers create new credentials and add them to the application:

Alternatively, they can create new credentials and add them to an existing service principal associated with the MailApp application:

After this phase, the attackers now have credentials for the application, which can be used to authenticate to Azure AD on behalf of the application.

Application/Service-principal Privilege Escalation

In this step, the attackers list all the available permissions related to Microsoft Graph APIs:

The attackers add the User.ReadWrite.All permission to the MailApp application:

Afterward, the attackers list all the available permissions related to Mails that are associated with the Microsoft Graph API:

They also add the Mail.ReadWrite permission to the MailApp application:

The error in red indicates that an admin consent must be launched to approve this permission.
The admin consent workflow gives admins a secure way to grant access to applications that require admin approval. When a user tries to access an application but is unable to provide consent, he can send a request for admin approval. The request is sent to admins who are designated as reviewers.
As the attackers already have administrative permissions, they can launch an admin consent on their own:

The admin consent is successful and the Microsoft Graph APIs permissions are successfully added to the MailApp application!

Defense Evasion and Lateral Movement

The next step for the attackers is to acquire an OAuth access token for the application by initiating a HTTP GET request which includes the tenantId, objectId, appId and the secret (credentials) obtained earlier:

This access token enables the attackers to move laterally, impersonate the MailApp application, and execute actions on its behalf. 

Exfiltration

In the final step, the attackers call APIs with permissions assigned to the MailApp application.
The attackers initiate a HTTP GET request which includes the access token to exfiltrate all users in the tenant and all emails related to a specific user.

Users exfiltration

Emails exfiltration

Emails’ subjects exfiltration

Conclusion

The SolarWinds supply-chain attack is one of the most sophisticated attacks of our time. The scope of the attack extends beyond on-prem to the cloud. The attackers used advanced techniques to cover their tracks while they stole sensitive information, and used discovery, credential access, privilege escalation, lateral movement, defense evasion, and exfiltration in a single attack flow.
Many of the characteristics and operations seen in this type of attack can also apply to other cloud providers such as AWS and GCP.
The number of victims compromised by SunBurst continues to rise since the attack was initially uncovered. We will update with any new information as more details concerning this attack emerge.