{
	"id": "e7fbde53-af75-4fd4-8839-0af7503cc1eb",
	"created_at": "2026-04-06T00:22:04.255456Z",
	"updated_at": "2026-04-10T03:21:50.662842Z",
	"deleted_at": null,
	"sha1_hash": "dc1a18291f56291e00e19ecd0b037bba66051618",
	"title": "customer-guidance-on-recent-nation-state-cyber-attacks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 97404,
	"plain_text": "customer-guidance-on-recent-nation-state-cyber-attacks\r\nBy MSRC\r\nPublished: 2020-12-14 · Archived: 2026-04-05 18:07:38 UTC\r\nNote: we are updating as the investigation continues. Revision history listed at the bottom.\r\nThis post contains technical details about the methods of the actor we believe was involved in Recent Nation-State Cyber\r\nAttacks, with the goal to enable the broader security community to hunt for activity in their networks and contribute to a\r\nshared defense against this sophisticated threat actor. Please see the Microsoft Product Protections and Resources section\r\nfor additional investigative updates, guidance, and released protections.\r\nAs we wrote in that blog, while these elements aren’t present in every attack, this is a summary of techniques that are part of\r\nthe toolkit of this actor.\r\nAn intrusion through malicious code in the SolarWinds Orion product. This results in the attacker gaining a foothold\r\nin the network, which the attacker can use to gain elevated credentials. Microsoft Defender now has detections for\r\nthese files. Also, see SolarWinds Security Advisory.\r\nOnce in the network, the intruder then uses the administrative permissions acquired through the on-premises\r\ncompromise to gain access to the organization’s global administrator account and/or trusted SAML token signing\r\ncertificate. This enables the actor to forge SAML tokens that impersonate any of the organization’s existing users and\r\naccounts, including highly privileged accounts.\r\nAnomalous logins using the SAML tokens created by the compromised token signing certificate can then be made\r\nagainst any on-premises resources (regardless of identity system or vendor) as well as to any cloud environment\r\n(regardless of vendor) because they have been configured to trust the certificate. Because the SAML tokens are\r\nsigned with their own trusted certificate, the anomalies might be missed by the organization.\r\nUsing the global administrator account and/or the trusted certificate to impersonate highly privileged accounts, the\r\nactor may add their own credentials to existing applications or service principals, enabling them to call APIs with the\r\npermission assigned to that application.\r\nDue to the critical nature of this activity, Microsoft is sharing the following information to help detect, protect, and respond\r\nto this threat.\r\nActivity Description\r\nInitial Access\r\nAlthough we do not know how the backdoor code made it into the library, from the recent campaigns, research indicates that\r\nthe attackers might have compromised internal build or distribution systems of SolarWinds, embedding backdoor code into a\r\nlegitimate SolarWinds library with the file name SolarWinds.Orion.Core.BusinessLayer.dll . This backdoor can be\r\ndistributed via automatic update platforms or systems in target networks. Microsoft security researchers currently have\r\nlimited information about how the attackers compromised these platforms.\r\nExecution\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nPage 1 of 6\n\nWhile updating the SolarWinds application, the embedded backdoor code loads before the legitimate code executes.\r\nOrganizations are misled into believing that no malicious activity has occurred and that the program or application\r\ndependent on the libraries is behaving as expected.\r\nThe attackers have compromised signed libraries that used the target companies’ own digital certificates, attempting to evade\r\napplication control technologies. Microsoft already removed these certificates from its trusted list. The certificate details\r\nwith the signer hash are shown below:\r\nThe DLL then loads from the installation folder of the SolarWinds application. Afterwards, the main implant installs as a\r\nWindows service and as a DLL file in the following path using afolder with different names:\r\nSolarWinds Orion installation folder, for example,\r\n%PROGRAMFILES%\\SolarWinds\\Orion\\SolarWinds.Orion.Core.BusinessLayer.dll\r\nThe .NET Assembly cache folder (when compiled)\r\n%WINDIR%\\System32\\config\\systemprofile\\AppData\\Local\\assembly\\tmp\\\\SolarWinds.Orion.Core.BusinessLayer.dll\r\nMicrosoft security researchers observed malicious code from the attacker activated only when running under\r\nSolarWinds.BusinessLayerHost.exe process context for the DLL samples currently analyzed.\r\nCommand-and-control (C2)\r\nThe malicious DLL calls out to a remote network infrastructure using the domains avsvmcloud.com. to prepare possible\r\nsecond-stage payloads, move laterally in the organization, and compromise or exfiltrate data.\r\nMicrosoft detects the main implant and its other components as Solorigate.\r\nActions on Objectives\r\nIn actions observed at the Microsoft cloud, attackers have either gained administrative access using compromised privileged\r\naccount credentials (e.g. stolen passwords) or by forging SAML tokens using compromised SAML token signing\r\ncertificates.\r\nIn cases where we see SAML token signing certificate compromise, there are cases where the specific mechanism by which\r\nthe actor gains access to the certificate has not been determined. In the cases we have determined that the SAML token\r\nsigning certificate was compromised, common tools were used to access the database that supports the SAML federation\r\nserver using administrative access and remote execution capabilities.\r\nIn other cases, service account credentials had been granted administrative privileges; and in others, administrative accounts\r\nmay have been compromised by unrelated mechanisms. Typically, the certificate is stored on the server that provides the\r\nSAML federation capabilities; this makes it accessible to anyone with administrative rights on that server, either from\r\nstorage or by reading memory.\r\nOnce the certificate has been acquired, the actor can forge SAML tokens with whatever claims and lifetime they choose,\r\nthen sign it with the certificate that has been acquired. By doing this, they can access any resources configured to trust\r\ntokens signed with that SAML token signing certificate. This includes forging a token which claims to represent a highly\r\nprivileged account in Azure AD.\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nPage 2 of 6\n\nAs with on premises accounts, the actor may also gain administrative Azure AD privileges with compromised credentials.\r\nThis is particularly likely if the account in question is not protected by multi-factor authentication.\r\nRegardless of whether the actor minted SAML tokens or gained access to Azure AD through other means, specific malicious\r\nactivities have been observed using these administrative privileges to include long term access and data access as described\r\nbelow.\r\nLong Term Access\r\nHaving gained a significant foothold in the on premises environment, the actor has made modifications to Azure Active\r\nDirectory settings to facilitate long term access.\r\n1. Federation Trusts\r\nMicrosoft has observed the actor adding new federation trusts to an existing tenant or modifying the properties\r\nof an existing federation trust to accept tokens signed with actor-owned certificates.\r\n2. OAuth Application \u0026 Service Principal Credentials\r\nThe actor has been observed adding credentials (x509 keys or password credentials) to one or more legitimate\r\nOAuth Applications or Service Principals, usually with existing Mail.Read or _Mail.ReadWrite _permissions,\r\nwhich grants the ability to read mail content from Exchange Online via Microsoft Graph or Outlook REST.\r\nExamples include mail archiving applications. Permissions are usually, but not always, AppOnly.\r\nThe actor may use their administrator privileges to grant additional permissions to the target Application or\r\nService Principal (e.g. Mail.Read, Mail.ReadWrite).\r\nData Access\r\nData access has relied on leveraging minted SAML tokens to access user files/email or impersonating the Applications or\r\nService Principals by authenticating and obtaining Access Tokens using credentials that were added in 2a. Above. The actor\r\nperiodically connects from a server at a VPS provider to access specific users’ emails using the permissions granted to the\r\nimpersonated Application or Service Principal. In many cases, the targeted users are key IT and security personnel. By\r\nimpersonating existing applications that use permissions like Mail.Read to call the same APIs leveraged by the actor, the\r\naccess is hidden amongst normal traffic. For this reason, if you suspect you are impacted you should assume your\r\ncommunications are accessible to the actor.\r\nRecommended Defenses\r\nIf your organization has not been attacked or compromised by this actor, Microsoft recommends you consider the following\r\nactions to protect against the techniques described above as part of your overall response. This is not an exhaustive list, and\r\nMicrosoft may choose to update this list as new mitigations are determined:\r\n1. Run up to date antivirus or EDR products that detect compromised SolarWinds libraries and potentially anomalous\r\nprocess behaviour by these binaries. Consider disabling SolarWinds in your environment entirely until you are\r\nconfident that you have a trustworthy build free of injected code. For more details consult SolarWinds’ Security\r\nAdvisory.\r\n2. Block known C2 endpoints listed below in IOCs using your network infrastructure.\r\n3. Follow the best practices of your identity federation technology provider in securing your SAML token signing keys.\r\nConsider hardware security for your SAML token signing certificates if your identity federation technology provider\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nPage 3 of 6\n\nsupports it. Consult your identity federation technology provider for specifics. For Active Directory Federation\r\nServices, review Microsoft’s recommendations here: Best Practices for Securing ADFS\r\n4. Ensure that user accounts with administrative rights follow best practices, including use of privileged access\r\nworkstations, JIT/JEA, and strong authentication. Reduce the number of users that are members of highly privileged\r\nDirectory Roles, like Global Administrator, Application Administrator, and Cloud Application Administrator.\r\n5. Ensure that service accounts and service principals with administrative rights use high entropy secrets, like\r\ncertificates, stored securely. Monitor for changes to secrets used for service accounts and service principals as part of\r\nyour security monitoring program. Monitor for anomalous use of service accounts. Monitor your sign ins . Microsoft\r\nAzure AD indicates session anomalies, as does Microsoft Cloud App Security if in use.\r\n6. Reduce surface area by removing/disabling unused or unnecessary applications and service principals. Reduce\r\npermissions on active applications and service principals, especially application (AppOnly) permissions.\r\n7. See Secure your Azure AD identity infrastructure for more recommendations.\r\nMicrosoft Product Protections and Resources\r\nIf you believe your organization has been compromised, we recommend that you comprehensively audit your on premises\r\nand cloud infrastructure to include configuration, per-user and per-app settings, forwarding rules, and other changes the\r\nactor may have made to persist their access. In addition, we recommend comprehensively removing user and app access,\r\nreviewing configurations for each, and re-issuing new, strong credentials in accordance with documented industry best\r\npractices.\r\nIndicators of Compromise (IOCs)\r\nThe below list provides IOCs observed during this activity. We encourage our customers to implement detections and\r\nprotections to identify possible prior campaigns or prevent future campaigns against their systems. This list is not exhaustive\r\nand may expand as investigations continue. We also recommend you review the IOCs provided by FireEye at Highly\r\nEvasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST\r\nBackdoor | FireEye Inc.\r\nCommand and Control\r\navsvmcloud[.]com Command and Control (C2)\r\nObserved malicious instances of SolarWinds.Orion.Core.BusinessLayer.dll\r\nSHA256 File Version Date first seen\r\ne0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d 2020.2.100.11713 February 2020\r\na58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2 2020.2.100.11784 March 2020\r\n32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77 2019.4.5200.9083 March 2020\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nPage 4 of 6\n\nSHA256 File Version Date first seen\r\ndab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b 2020.2.100.12219 March 2020\r\neb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed 2020.2.100.11831 March 2020\r\nc09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77 Not available March 2020\r\nffdbdd460420972fd2926a7f460c198523480bc6279dd6cca177230db18748e8 2019.4.5200.9065 March 2020\r\nb8a05cc492f70ffa4adcd446b693d5aa2b71dc4fa2bf5022bf60d7b13884f666 2019.4.5200.9068 March 2020\r\n20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9 2019.4.5200.9078 March 2020\r\n0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589 2019.4.5200.9078 March 2020\r\ncc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6 2019.4.5200.9083 March 2020\r\nac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c 2020.4.100.478 April 2020\r\n019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134 2020.2.5200.12394 April 2020\r\nce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6 2020.2.5300.12432 May 2020\r\n2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d 2019.4.5200.9078 May 2020\r\n92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690 2020.4.100.751 May 2020\r\na3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d Not available Not available\r\na25cadd48d70f6ea0c4a241d99c5241269e6faccb4054e62d16784640f8e53bc 2019.4.5200.8890 October 2019\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nPage 5 of 6\n\nSHA256 File Version Date first seen\r\nd3c6785e18fba3749fb785bc313cf8346182f532c59172b69adfb31b96a5d0af 2019.4.5200.8890 October 2019\r\nAnalyst’s comment: These indicators should not be considered exhaustive for this observed activity. Moreover, aside from\r\nthe malicious DLLs, Microsoft researchers have observed two files in October 2019 with code anomalies when a class was\r\nadded to the SolarWinds DLL. Note however that these two do not have active malicious code or methods.\r\nRevision history\r\n2020-12-21: Added link to the Solorigate Resource Center\r\n2020-12-21: Added link to DART blog\r\n2020-12-18: Updated links to include Microsoft product protections and resources\r\n2020-12-17: Added link to Azure Sentinel blog post, added more observed malicious instances\r\n2020-12-16: Updated links to Azure Sentinel detections\r\n2020-12-13: Published\r\nSource: https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"MITRE"
	],
	"references": [
		"https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/"
	],
	"report_names": [
		"customer-guidance-on-recent-nation-state-cyber-attacks"
	],
	"threat_actors": [],
	"ts_created_at": 1775434924,
	"ts_updated_at": 1775791310,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dc1a18291f56291e00e19ecd0b037bba66051618.pdf",
		"text": "https://archive.orkl.eu/dc1a18291f56291e00e19ecd0b037bba66051618.txt",
		"img": "https://archive.orkl.eu/dc1a18291f56291e00e19ecd0b037bba66051618.jpg"
	}
}