{
	"id": "5aab598e-360a-4be5-9bad-6a6ce4e01fba",
	"created_at": "2026-04-06T00:17:21.969191Z",
	"updated_at": "2026-04-10T03:21:11.296729Z",
	"deleted_at": null,
	"sha1_hash": "27d8d9e77fa563ca507edf5cb48318a60fac7434",
	"title": "SolarWinds Backdoor (Sunburst) Incident Response Playbook",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 54626,
	"plain_text": "SolarWinds Backdoor (Sunburst) Incident Response Playbook\r\nArchived: 2026-04-05 18:16:21 UTC\r\nOver the last several days, TrustedSec has received queries on the best ways to contain, eradicate, and remediate\r\nthe SolarWinds backdoor (aka #solarigate aka Sunburst). The TrustedSec Incident Response team has put together\r\na playbook of recommended actions to provide some level of assurance that your organization is no longer\r\naffected by the backdoor.\r\nThis is almost the worst-case scenario for many organizations: an advanced, state-sponsored actor (may have) had\r\nan undetected backdoor into your network for months. Even worse, the system(s) that backdoor was on had full\r\naccess to your environment. Due to this, as many others in the industry have stated, organizations have to assume\r\nthey have been fully breached. Therefore, the following playbook operates under this assumption.\r\nTwo (2) notes before we get started:\r\n1. Even if you have already taken steps to respond, we recommend looking through this list. There may be\r\nsomething you did not think of.\r\n2. Do not blindly take all the actions below. Every organization must perform their own due diligence of\r\ndetermining what the effects of the actions below are and to ensure that the organization is OK with those\r\neffects.\r\nInvestigation\r\nThe investigation should take place concurrent to the containment, eradication, and recovery processes.\r\nSolarWinds Orion servers should be forensically preserved, if possible, to allow forensic examination. This\r\nincludes:\r\nObtaining live response data, including RAM\r\nImaging and hashing the disk\r\nSaving any network logs (e.g., firewall, NetFlow) of the servers before they are rolled out\r\nExporting any centralized logs from the servers before they are rolled out\r\nSince every organization’s internal visibility is different, rather than providing a list of tasks to perform when\r\ninvestigating, we have compiled a list of questions that should be answered. For any questions that cannot be\r\nanswered, organizations should determine what can be put in place in the future to sufficiently answer those\r\nquestions. Timeframes for all questions should be for as long as your organization has had SolarWinds Orion\r\ndeployed, going back to March 2020.\r\nUser Activity\r\nThe accounts mentioned below include both accounts used by SolarWinds Orion to perform its monitoring and\r\nmanagement, which are stored within SolarWinds, and local accounts in the Orion server operating system.\r\nhttps://www.trustedsec.com/blog/solarwinds-backdoor-sunburst-incident-response-playbook/?hss_channel=tw-403811306\r\nPage 1 of 4\n\nDid accounts authenticate (successful or failed) to any systems or applications that they should not have?\r\nIf you do not have logs that go back that far, you will have to perform a search across locally stored\r\nlogs in your environment.\r\nDid accounts receive authentication attempts (successful or failed) from external locations, especially those\r\nthey have not logged in from before (e.g., on the VPN)?\r\nHave accounts set off impossible travel alerts?\r\nAre any suspicious OAUTH applications allowed Mail.Read or Mail.ReadWrite permissions (or excessive\r\npermissions) within Office 365?\r\nNetwork Activity\r\nHave any systems connected to known command and control (C2) domains or IP addresses?\r\nHave any systems connected to the DNS sinkhole IP address (20.140.0.1)?\r\nHave the servers connected to any other external domains or IP addresses?\r\nHave the servers connected to any internal systems they should not have?\r\nHave the servers connected to any internal systems at odd times or days?\r\nHave any new federation trusts been added to existing Azure tenants?\r\nEndpoint Activity\r\nIs the backdoor Dynamic-Link Library (DLL) still present on the Orion servers?\r\nIs the backdoor DLL on any other servers? (Hint: Use FireEye Yara signatures or hashes of DLLs to\r\nsearch.)\r\nIs there any indication of suspicious activity on the Orion servers?\r\nIs there any indication of suspicious activity on any systems/applications whose credentials were held\r\nwithin the Orion servers?\r\nAre there any suspicious ASEPs on the servers or remote access software?\r\nWere any accounts added or reenabled on the Orion servers or any systems or applications to which Orion\r\nhad administrative access?\r\nHave all network device configuration files to which Orion had access been validated?\r\nHave security software (anti-virus, Endpoint Detection and Response (EDR)) detected any suspicious\r\nactivity or malware on systems?\r\nPost-Exploitation Activity\r\nHas any post-exploitation activity been detected on any system?\r\nFireEye reports state that Cobalt Strike has been used as a post-exploitation payload.\r\n(https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html)\r\nKnown files include c:\\windows\\syswow64\\netsetupsvc.dll.\r\nHas your organization’s domain been leaked in RDP SSL certificates online? (Hint: Check Shodan.)\r\nContainment\r\nhttps://www.trustedsec.com/blog/solarwinds-backdoor-sunburst-incident-response-playbook/?hss_channel=tw-403811306\r\nPage 2 of 4\n\nContainment is the process of stopping the spread of or preventing further damage from an attack.\r\n1. Quarantine the SolarWinds Orion servers that have the backdoor DLL so they cannot communicate with\r\nany other network or system. Possible options include:\r\n1. NULL-routing their IP addresses\r\n2. Placing the Orion servers in their own network with no access to any other systems or the Internet\r\n3. Utilizing EDR to contain the systems\r\n4. Shutting down the servers\r\nIf you go this route, be sure to grab live response forensic data first—it is better to have it\r\nand not need it than vice versa.\r\n2. Disable any accounts utilized by SolarWinds Orion to access other devices or communicate in your\r\nnetwork. These include:\r\n1. Orion platform service account\r\n2. SQL database service account\r\n3. Any accounts used for application/system/WMI monitoring from Orion\r\n4. Accounts used by Orion to email/send alerts\r\n5. SNMP community strings\r\n3. Block network communication to the known C2 domains and IP addresses for all systems. Possible options\r\ninclude:\r\n1. DNS sinkhole domains\r\n2. Block IP addresses at firewalls\r\n3. Block domains and IP addresses in proxy servers\r\n4. Turn on Sunburst-related IPS signatures\r\n4. Block all Internet access for SolarWinds Orion servers.\r\n5. Configure alerting for any system accessing known Indicators of Compromise (IoCs) of Sunburst or the\r\nuse of any user ID that has been disabled. This should be done for both endpoint and network monitoring.\r\nEradication\r\nEradication is the process of removing an attacker or affected system from an environment.\r\n1. Change passwords for any account used by SolarWinds Orion. User sturdyerde posted an excellent method\r\nto do this on SolarWinds' community forum. (https://thwack.solarwinds.com/t5/NPM-Discussions/When-you-have-to-change-all-passwords-for-the-Orion-monitoring/td-p/613340)\r\n2. Change any shared passwords for accounts that were on the SolarWinds Orion servers. This includes\r\nshared local account passwords or service accounts on the system.\r\n3. Change the passwords or community strings that are stored within Orion to perform monitoring.\r\n4. If this was not done in the containment phase, remove the Orion servers from the network.\r\nNote that instead of changing passwords for accounts, some reports have suggested that it is faster and easier to\r\ncreate new accounts and remove the old accounts used in and by SolarWinds Orion.\r\nRecovery\r\nhttps://www.trustedsec.com/blog/solarwinds-backdoor-sunburst-incident-response-playbook/?hss_channel=tw-403811306\r\nPage 3 of 4\n\nRecovery is the act of bringing systems back to normal operations.\r\n1. Back up the SolarWinds configuration and database.\r\n1. Information on how to do this should be in the SolarWinds Orion documentation.\r\n2. Rebuild the operating system from a known good golden image.\r\n3. Install SolarWinds version 2020.2.1 HF 2. (https://www.solarwinds.com/securityadvisory)\r\n4. Ensure security and endpoint visibility onto the server.\r\n5. Restore the data from the backed-up configuration and database.\r\n6. Verify the cryptographic hashes of the SolarWinds.Orion.Core.BusinessLayer.dll file installed to ensure\r\nthat the backdoor DLL is no longer present.\r\n1. Hashes can be found in the Microsoft customer guidance.\r\nAlternatively, it may not be possible to completely rebuild the server from scratch, although this is our preferred\r\nand recommended method. If you cannot do this, perform the following:\r\n1. Back up the SolarWinds configuration and database.\r\n2. Install the hotfix for SolarWinds Orion 2020.2.1 HF 2.\r\n3. Ensure security and endpoint visibility into the servers.\r\n4. Verify the cryptographic hashes of the SolarWinds.Orion.Core.BusinessLayer.dll file installed to ensure\r\nthat the backdoor DLL is no longer present.\r\nIf you take the restore approach rather than the rebuild approach, you still need to perform containment and\r\neradication procedures!\r\nRegardless of which approach is taken, the following recovery activities also need to occur:\r\n1. Remove any temporary containment measures that were put into place.\r\n2. Ensure endpoint and network alerting is configured for the following:\r\n1. Presence of any known IoCs\r\n2. Use of accounts in a suspicious manner (e.g., a SolarWinds service account trying to log in to the\r\nVPN)\r\n3. Ensure all network and endpoint security software is up to date on signatures, including those related to\r\nSunburst.\r\nReferences to Lists of Known Indicators\r\nhttps://github.com/fireeye/sunburst_countermeasures\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nSource: https://www.trustedsec.com/blog/solarwinds-backdoor-sunburst-incident-response-playbook/?hss_channel=tw-403811306\r\nhttps://www.trustedsec.com/blog/solarwinds-backdoor-sunburst-incident-response-playbook/?hss_channel=tw-403811306\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.trustedsec.com/blog/solarwinds-backdoor-sunburst-incident-response-playbook/?hss_channel=tw-403811306"
	],
	"report_names": [
		"?hss_channel=tw-403811306"
	],
	"threat_actors": [],
	"ts_created_at": 1775434641,
	"ts_updated_at": 1775791271,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/27d8d9e77fa563ca507edf5cb48318a60fac7434.pdf",
		"text": "https://archive.orkl.eu/27d8d9e77fa563ca507edf5cb48318a60fac7434.txt",
		"img": "https://archive.orkl.eu/27d8d9e77fa563ca507edf5cb48318a60fac7434.jpg"
	}
}