Customer Guidance on Recent Nation-State Cyber Attacks | MSRC Blog

Note: we are updating as the investigation continues. Revision history listed at the bottom.

This post contains technical details about the methods of the actor we believe was involved in Recent Nation-State Cyber Attacks, with the goal to enable the broader security community to hunt for activity in their networks and contribute to a shared defense against this sophisticated threat actor. Please see the Microsoft Product Protections and Resources section for additional investigative updates, guidance, and released protections.

As we wrote in that blog, while these elements aren’t present in every attack, this is a summary of techniques that are part of the toolkit of this actor.

  • An intrusion through malicious code in the SolarWinds Orion product. This results in the attacker gaining a foothold in the network, which the attacker can use to gain elevated credentials. Microsoft Defender now has detections for these files. Also, see SolarWinds Security Advisory.
  • Once in the network, the intruder then uses the administrative permissions acquired through the on-premises compromise to gain access to the organization’s global administrator account and/or trusted SAML token signing certificate. This enables the actor to forge SAML tokens that impersonate any of the organization’s existing users and accounts, including highly privileged accounts.
  • Anomalous logins using the SAML tokens created by the compromised token signing certificate can then be made against any on-premises resources (regardless of identity system or vendor) as well as to any cloud environment (regardless of vendor) because they have been configured to trust the certificate. Because the SAML tokens are signed with their own trusted certificate, the anomalies might be missed by the organization.
  • Using the global administrator account and/or the trusted certificate to impersonate highly privileged accounts, the actor may add their own credentials to existing applications or service principals, enabling them to call APIs with the permission assigned to that application.

Due to the critical nature of this activity, Microsoft is sharing the following information to help detect, protect, and respond to this threat.

Initial Access
Initial Access

Although we do not know how the backdoor code made it into the library, from the recent campaigns, research indicates that the attackers might have compromised internal build or distribution systems of SolarWinds, embedding backdoor code into a legitimate SolarWinds library with the file name SolarWinds.Orion.Core.BusinessLayer.dll. This backdoor can be distributed via automatic update platforms or systems in target networks. Microsoft security researchers currently have limited information about how the attackers compromised these platforms.

Execution
Execution

While updating the SolarWinds application, the embedded backdoor code loads before the legitimate code executes. Organizations are misled into believing that no malicious activity has occurred and that the program or application dependent on the libraries is behaving as expected.

The attackers have compromised signed libraries that used the target companies’ own digital certificates, attempting to evade application control technologies. Microsoft already removed these certificates from its trusted list. The certificate details with the signer hash are shown below:

The DLL then loads from the installation folder of the SolarWinds application. Afterwards, the main implant installs as a Windows service and as a DLL file in the following path using afolder with different names:

  • SolarWinds Orion installation folder, for example, %PROGRAMFILES%SolarWindsOrionSolarWinds.Orion.Core.BusinessLayer.dll
  • The .NET Assembly cache folder (when compiled) %WINDIR%System32configsystemprofileAppDataLocalassemblytmp<VARIES>SolarWinds.Orion.Core.BusinessLayer.dll

Microsoft security researchers observed malicious code from the attacker activated only when running under SolarWinds.BusinessLayerHost.exe process context for the DLL samples currently analyzed.

Command-and-control (C2)
Command-and-control (C2)

The malicious DLL calls out to a remote network infrastructure using the domains avsvmcloud.com. to prepare possible second-stage payloads, move laterally in the organization, and compromise or exfiltrate data.

Microsoft detects the main implant and its other components as Solorigate.

Actions on Objectives
Actions on Objectives

In actions observed at the Microsoft cloud, attackers have either gained administrative access using compromised privileged account credentials (e.g. stolen passwords) or by forging SAML tokens using compromised SAML token signing certificates.

In cases where we see SAML token signing certificate compromise, there are cases where the specific mechanism by which the actor gains access to the certificate has not been determined. In the cases we have determined that the SAML token signing certificate was compromised, common tools were used to access the database that supports the SAML federation server using administrative access and remote execution capabilities.

In other cases, service account credentials had been granted administrative privileges; and in others, administrative accounts may have been compromised by unrelated mechanisms. Typically, the certificate is stored on the server that provides the SAML federation capabilities; this makes it accessible to anyone with administrative rights on that server, either from storage or by reading memory.

Once the certificate has been acquired, the actor can forge SAML tokens with whatever claims and lifetime they choose, then sign it with the certificate that has been acquired. By doing this, they can access any resources configured to trust tokens signed with that SAML token signing certificate. This includes forging a token which claims to represent a highly privileged account in Azure AD.

As with on premises accounts, the actor may also gain administrative Azure AD privileges with compromised credentials. This is particularly likely if the account in question is not protected by multi-factor authentication.

Regardless of whether the actor minted SAML tokens or gained access to Azure AD through other means, specific malicious activities have been observed using these administrative privileges to include long term access and data access as described below.

Long Term Access
Long Term Access

Having gained a significant foothold in the on premises environment, the actor has made modifications to Azure Active Directory settings to facilitate long term access.

  1. Federation Trusts

    • Microsoft has observed the actor adding new federation trusts to an existing tenant or modifying the properties of an existing federation trust to accept tokens signed with actor-owned certificates.
  2. OAuth Application & Service Principal Credentials

    • The actor has been observed adding credentials (x509 keys or password credentials) to one or more legitimate OAuth Applications or Service Principals, usually with existing Mail.Read or _Mail.ReadWrite _permissions, which grants the ability to read mail content from Exchange Online via Microsoft Graph or Outlook REST. Examples include mail archiving applications. Permissions are usually, but not always, AppOnly.
    • The actor may use their administrator privileges to grant additional permissions to the target Application or Service Principal (e.g. Mail.Read, Mail.ReadWrite).

Data Access
Data Access

Data access has relied on leveraging minted SAML tokens to access user files/email or impersonating the Applications or Service Principals by authenticating and obtaining Access Tokens using credentials that were added in 2a. Above. The actor periodically connects from a server at a VPS provider to access specific users’ emails using the permissions granted to the impersonated Application or Service Principal. In many cases, the targeted users are key IT and security personnel. By impersonating existing applications that use permissions like Mail.Read to call the same APIs leveraged by the actor, the access is hidden amongst normal traffic. For this reason, if you suspect you are impacted you should assume your communications are accessible to the actor.

If your organization has not been attacked or compromised by this actor, Microsoft recommends you consider the following actions to protect against the techniques described above as part of your overall response. This is not an exhaustive list, and Microsoft may choose to update this list as new mitigations are determined:

  1. Run up to date antivirus or EDR products that detect compromised SolarWinds libraries and potentially anomalous process behaviour by these binaries. Consider disabling SolarWinds in your environment entirely until you are confident that you have a trustworthy build free of injected code. For more details consult SolarWinds’ Security Advisory.
  2. Block known C2 endpoints listed below in IOCs using your network infrastructure.
  3. Follow the best practices of your identity federation technology provider in securing your SAML token signing keys. Consider hardware security for your SAML token signing certificates if your identity federation technology provider supports it. Consult your identity federation technology provider for specifics. For Active Directory Federation Services, review Microsoft’s recommendations here: Best Practices for Securing ADFS
  4. Ensure that user accounts with administrative rights follow best practices, including use of privileged access workstations, JIT/JEA, and strong authentication. Reduce the number of users that are members of highly privileged Directory Roles, like Global Administrator, Application Administrator, and Cloud Application Administrator.
  5. Ensure that service accounts and service principals with administrative rights use high entropy secrets, like certificates, stored securely. Monitor for changes to secrets used for service accounts and service principals as part of your security monitoring program. Monitor for anomalous use of service accounts. Monitor your sign ins . Microsoft Azure AD indicates session anomalies, as does Microsoft Cloud App Security if in use.
  6. Reduce surface area by removing/disabling unused or unnecessary applications and service principals. Reduce permissions on active applications and service principals, especially application (AppOnly) permissions.
  7. See Secure your Azure AD identity infrastructure for more recommendations.

Microsoft Product Protections and Resources
Microsoft Product Protections and Resources

If you believe your organization has been compromised, we recommend that you comprehensively audit your on premises and cloud infrastructure to include configuration, per-user and per-app settings, forwarding rules, and other changes the actor may have made to persist their access. In addition, we recommend comprehensively removing user and app access, reviewing configurations for each, and re-issuing new, strong credentials in accordance with documented industry best practices.

The below list provides IOCs observed during this activity. We encourage our customers to implement detections and protections to identify possible prior campaigns or prevent future campaigns against their systems. This list is not exhaustive and may expand as investigations continue. We also recommend you review the IOCs provided by FireEye at Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor | FireEye Inc.

Command and Control
Command and Control

avsvmcloud[.]com Command and Control (C2)

Observed malicious instances of SolarWinds.Orion.Core.BusinessLayer.dll
Observed malicious instances of SolarWinds.Orion.Core.BusinessLayer.dll

SHA256 File Version Date first seen
e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d 2020.2.100.11713 February 2020
a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2 2020.2.100.11784 March 2020
32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77 2019.4.5200.9083 March 2020
dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b 2020.2.100.12219 March 2020
eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed 2020.2.100.11831 March 2020
c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77 Not available March 2020
ffdbdd460420972fd2926a7f460c198523480bc6279dd6cca177230db18748e8 2019.4.5200.9065 March 2020
b8a05cc492f70ffa4adcd446b693d5aa2b71dc4fa2bf5022bf60d7b13884f666 2019.4.5200.9068 March 2020
20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9 2019.4.5200.9078 March 2020
0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589 2019.4.5200.9078 March 2020
cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6 2019.4.5200.9083 March 2020
ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c 2020.4.100.478 April 2020
019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134 2020.2.5200.12394 April 2020
ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6 2020.2.5300.12432 May 2020
2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d 2019.4.5200.9078 May 2020
92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690 2020.4.100.751 May 2020
a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d Not available Not available
a25cadd48d70f6ea0c4a241d99c5241269e6faccb4054e62d16784640f8e53bc 2019.4.5200.8890 October 2019
d3c6785e18fba3749fb785bc313cf8346182f532c59172b69adfb31b96a5d0af 2019.4.5200.8890 October 2019

Analyst’s comment: These indicators should not be considered exhaustive for this observed activity. Moreover, aside from the malicious DLLs, Microsoft researchers have observed two files in October 2019 with code anomalies when a class was added to the SolarWinds DLL. Note however that these two do not have active malicious code or methods.

  • 2020-12-21: Added link to the Solorigate Resource Center
  • 2020-12-21: Added link to DART blog
  • 2020-12-18: Updated links to include Microsoft product protections and resources
  • 2020-12-17: Added link to Azure Sentinel blog post, added more observed malicious instances
  • 2020-12-16: Updated links to Azure Sentinel detections
  • 2020-12-13: Published



0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *