Behind the Scenes of the SUNBURST Attack

Check Point sponsored this post.

The biggest cyberattack in recent times came in the form of what seems like a nation-state-sponsored supply chain attack, in December when the SUNBURST malware was installed on SolarWinds’ Orion product. This made headlines worldwide for good reason — post-compromise activity included data theft through lateral movement, which is when the attacker moves through a network searching for targeted key data and assets. This attack was the work of a highly-skilled actor and the operation was conducted with significant operational security.

This attack consisted of lateral movement of the threat actor from the on-premises network to the cloud, and it was done in two phases:

1. Phase One: The On-Prem Golden SAML Attack. Here the threat actors gained administrative access to the organization’s Active Directory Federation Services (ADFS) server. This allowed them to forge Security Assertion Markup Language (SAML) tokens and create illegitimate registrations of SAML Trust Relationships. By impersonating a user with valid administrative credentials, the threat actors could change the configuration of the SAML Service Provider (in this case, Azure AD). From there, they successfully gained administrative access to the Azure AD.
2. Phase Two: Malicious activity in the Cloud. The threat actors then used the Azure Active Directory administrative credentials for malicious activities. This included (but was not limited to): enumeration of existing applications and service principals, injection of credentials into them, impersonation and execution of actions on behalf of them, and the exfiltration of sensitive data like users and mails.

In this analysis, we will focus on the second attack phase, in the cloud, and present key tactics and techniques used by the nation-state actors in the malicious campaign. By using the MITRE ATT&CK framework, we will provide the most likely technical attack flow of the nation-state actor’s actions.

Reviewing Microsoft’s article, the chain of events that occurred through this attack were:

1. Initial Access (On-Prem): Forged SAML tokens and illegitimate registrations of SAML Trust Relationships; impersonating a user with administrative credentials (in this case, Azure AD).
2. Discovery: The threat actor enumerates existing applications/service principals (preferably with high traffic patterns).
3. Credential Access: The threat actor adds credentials to an existing application or service principal.
4. Privilege Escalation: The threat actor elevates the privileges of the application/service-principal, to allow access to MS Graph APIs Application permissions.
5. Defense Evasion and Lateral Movement: The threat actor acquires OAuth access tokens of applications, allowing them to impersonate the applications and obfuscate their activity.
6. Exfiltration: The threat actor calls MS Graph APIs to exfiltrate sensitive data such as users’ data and emails.

👁 Image

Here we will focus on the attack flow in the Cloud Environment after the initial authentication(i.e. steps 2-6). But first, let’s elaborate on the AzureAD Authentication and Authorization mechanisms.

In short, Authentication is proving you are who you say you are. This is done by the Identity Provider (in this case 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

First, the threat actor gains an initial foothold into the Cloud Environment by compromising privileged cloud users with administrative access to the Azure AD. They then add credentials to an existing application or service principal. However, in order to do that, the threat actor needs to firstly list all the existing applications:

👁 Image

The threat actor prefers applications with high traffic patterns (e.g. mail archival applications) which can be used to obfuscate their activity. So, they decide to choose the “MailApp” (an imaginary application name) and extracts its ObjectId and ApplicationId:

👁 Image

In addition, the threat actor extracts the account’s tenantId:

👁 Image

Credential Access

Next, the threat actor creates new credentials and adds them to the application:

👁 Image

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

👁 Image

After this phase, the threat actor has the credentials of the application — which can be used to authenticate to AzureAD on behalf of the application.

Application/Service-Principal Privilege Escalation

In this step, the threat actor lists all the available permissions related to Microsoft Graph APIs:

👁 Image

The threat actor decides to add the User.ReadWrite.All permission to the MailApp application:

👁 Image

Afterward, the threat actor lists all the available permissions related to Mails and associated to the Microsoft Graph API:

👁 Image

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

👁 Image

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, they can send a request for admin approval. The request is sent to admins who have been designated as reviewers.

Due to the fact that the actor already has administrative permissions, they can launch an admin consent on their own:

👁 Image

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

Defense Evasion and Lateral Movement

Then, the actor acquired an OAuth access token for the application, by initiating an HTTP GET request which included the tenantId, objectId, appId and the secret (credentials) obtained from before:

👁 Image

This access token enabled the actor to move laterally, impersonate the MailApp application, and execute actions on behalf of it.

Exfiltration

Finally, the threat actor calls APIs with permissions assigned to the MailApp application.

The threat actor initiated an HTTP GET request, which included the access token to exfiltrate all users in the tenant and all emails related to a specific user.

In conclusion, the SUNBURST attack was by far one of the most sophisticated attacks of our time — extending beyond on-prem and into the cloud. The threat actor executed advanced techniques to cover their tracks; using discovery, credential access, privilege escalation, lateral movement, defense evasion, and exfiltration all in one attack flow.

Since the attack, the number of victims compromised by SUNBURST continues to rise, and could happen again on any of the cloud providers. Many security vendors are offering free trials to help organizations get a handle on the security of their environment. While this is a step in the right direction, the question is, will you know what to look for and will you be prepared?

Check Point sponsored this post.

Feature image via Pixabay.