{
	"id": "854d0ebc-3bf0-4ae4-b52f-f32d4eb1907a",
	"created_at": "2026-04-06T00:15:44.919618Z",
	"updated_at": "2026-04-10T03:21:19.806534Z",
	"deleted_at": null,
	"sha1_hash": "d471c11a9b1af1bd108778026419a750c567624f",
	"title": "Using Splunk to Detect Sunburst Backdoor | Splunk",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 88195,
	"plain_text": "Using Splunk to Detect Sunburst Backdoor | Splunk\r\nBy Ryan Kovar\r\nPublished: 2020-12-14 · Archived: 2026-04-05 12:45:01 UTC\r\nIntroduction to Sunburst Backdoor\r\nOn Sunday afternoon, FireEye released a report on what they are calling the “Sunburst Backdoor.” I highly\r\nrecommend you read their phenomenal whitepaper for an in-depth analysis, but here are the basics: an advanced\r\nadversary trojanized a legitimate dll of the SolarWinds Orion software and fed that into the Solarwinds' customers’\r\nupdate cycle. Once infected, this trojanized backdoor allows the adversary to move laterally in a victim’s network\r\nand steal their critical data.\r\nAt this time, FireEye has detected global activity going back at least to the spring of 2020 with many different\r\nverticals targeted. Combined with the recent CISA Emergency Directive 21-01, we felt it was essential to provide\r\na quick response with high-level guidance to our customers to help them detect and protect their networks.\r\nSplunk’s research team will provide much more bespoke and customized detections as they work the scenario\r\nthrough our labs in the coming days.\r\nWhat You Need to Know\r\nThe FireEye report reveals that this attack was perpetrated by an advanced adversary who carefully selected\r\ntargets and changed their attacking infrastructure to match geographical location and even named attacking hosts\r\nto match their victims to disguise their traffic better. By using a trusted software partner like Solarwinds Orion,\r\nthey could utilize Solarwinds' position in the network to spread laterally across on-prem and cloud infrastructures\r\nto capture and exfiltrate data.\r\nWhile Sunburst Backdoor is a sophisticated attack vector, it is still just a trojan on a network with lateral\r\nmovement. Many of your typical network defense techniques and incident response techniques can be utilized\r\nimmediately. If you happen to know which hosts on your network are running SolarWinds Orion, start your\r\nhunting with those hosts as this is where the adversary gains a foothold. The Sunburst Backdoor should only be\r\neffective on those hosts. Still, the added threat here is any lateral movement out from the Orion hosts, using\r\ncommon techniques or credentials harvested from Orion.\r\nDetection in Splunk Enterprise Security\r\nAn event like Sunburst is a great time to revisit our blog, “How Do I Add COVID (or Any) Threat Intelligence\r\nFrom the Internet to Splunk Enterprise Security?” on adding threat intelligence quickly to Splunk Enterprise\r\nSecurity (ES). You can simply swap out the “COVID” threat lists with “SUNBURST” threat lists. This blog will\r\nhelp you update your Splunk SIEM with the IOCs currently released from FireEye and give you detection results\r\nif any hosts become infected in the future.\r\nhttps://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html\r\nPage 1 of 6\n\nMy colleague Shannon Davis has already whipped together several local threat intel files for you to ingest into ES\r\nusing the techniques above!\r\nIOCs: DNS, Hashes, and IPs\r\nFirst, let’s review the IOCs that FireEye kindly released in their GitHub repo. You could go through and make\r\nmany “OR” statements and look through your DNS, but I have created some quick lookup files that you could use,\r\nespecially as those IOCs start getting more and more verbose. Take the guidance from my previous blog posts\r\nLookup Before You Go-Go...Hunting. I’ve also started throwing some lookup files into a GitHub repo, which you\r\ncan explore independently. Please note, this is based on what has been released by FireEye or other vendors, but it\r\nshould get you started.\r\nFor example, create lookup tables as I indicated in the blogs above or from my Github repository. Then, run a\r\nsearch like below, and you can find hosts that have communicated to the domains so far detected.\r\nindex=main sourcetype=stream:*\r\n| lookup sunburstDOMAIN_lookup Domain AS query\r\n| search isBad=TRUE\r\n| stats VALUES(query) AS \"Sunburst\" by src_ip\r\nJust change the search query and lookup file to match what type of IOC you are looking for (domains, IPs, or\r\nhashes).\r\nIf you detect traffic to these IPs or domains, take a good look at the Snort alerts released by FireEye. If you are\r\ncollecting any firewall or proxy traffic logs, you might be able to have a better idea of your compromised hosts\r\nlooking for traffic with these strings in the URL:\r\n/swip/upd/SolarWinds.CortexPlugin.Components.xml\r\nswip/Upload.ashx\r\n/swip/upd/\r\nLateral Movement\r\nOnce the adversary has access to the network via the trojanized dll, they can be detected moving laterally to find\r\nand exfiltrate information. Although we have not seen the logs, we can safely assume they are still obeying the\r\nlaws of network traffic. Using the ever handy-dandy Splunk Security Essentials (SSE) tool, I exported several\r\nsearches into this PDF. You can use these searches either as is or as inspiration for your own. I highly recommend\r\nthat you start by looking at any suspicious traffic emanating to or from SolarWinds machines in your network.\r\nhttps://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html\r\nPage 2 of 6\n\nSysmon and Named Pipe\r\nOne interesting tidbit released in the FireEye report was also the existence of a named pipe. If you are using\r\nSysmon and Splunk please take a look at Event Codes 17 and 18 and the named pipe “583da945-62af-10e8-4902-\r\na8f205c72b2e”. We’ve provided an example search below:\r\nindex=windows sourcetype=\"XmlWinEventLog:Microsoft-Windows-Sysmon/Operational\"\r\n(EventCode=17 OR EventCode=18) PipeName=583da945-62af-10e8-4902-a8f205c72b2e\r\nWe are also seeing some great work done by the community for Sysmon and Splunk queries but have been unable\r\nto test them at this time. Take a quick google and your may find some gold!\r\nAzure Active Directory\r\nMicrosoft has also determined that adversaries utilizing the Sunburst Backdoor targeted the Azure AD of victims\r\nas part of their lateral movement. This was either done via captured administrative passwords or forged SAML\r\ntokens. Luckily, Splunk (via the dapper Ryan Lait) has you covered! If you brought your Azure data into Splunk,\r\nyou can get some great insight into the activity that the adversary may have taken.\r\nThe Azure Active Directory Audit data collected by the Microsoft Azure Add-on for Splunk can help hunt some of\r\nthe techniques leveraged by this actor. These audit logs capture every interaction between users and resources\r\ninside Azure. Here are some example searches to detect:\r\nMonitoring For Changes to App Registrations and Service Principals: New Service Principals:\r\nsourcetype=\"azure:aad:audit\" activityDisplayName=\"Add service principal\"\r\n| stats values(activityDisplayName) AS Action, values(initiatedBy.user.userPrincipalName)\r\nAS UPN, values(targetResources{}.displayName) AS Target,\r\nvalues(targetResources{}.modifiedProperties{}.displayName) AS \"Modified Resources\",\r\nvalues(targetResources{}.modifiedProperties{}.oldValue) AS \"Old Values\",\r\nvalues(targetResources{}.modifiedProperties{}.newValue) AS \"New Values\" by correlationId\r\n| fields - correlationId\r\nCredentials and certificates added to Apps or Service Principals:\r\nsourcetype=\"azure:aad:audit\" activityDisplayName=\"Add service principal credentials\"\r\nPermissions and role assignments added to Apps or Service Principals:\r\nhttps://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html\r\nPage 3 of 6\n\nsourcetype=\"azure:aad:audit\" activityDisplayName=\"Add app role assignment to service principal\" OR\r\nactivityDisplayName=\"Add delegated permission grant\" OR activityDisplayName=\"Add application\"\r\n| stats values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName)\r\nAS Target, values(targetResources{}.modifiedProperties{}.displayName) AS \"Modified Resources\",\r\nvalues(targetResources{}.modifiedProperties{}.oldValue) AS \"Old Values\",\r\nvalues(targetResources{}.modifiedProperties{}.newValue)\r\nAS \"New Values\" by correlationId activityDisplayName\r\n| fields - correlationId\r\nUse this search to investigate users adding sensitive permissions to app registrations. #ReadMailInAllMailboxes\r\nApps modified to allow multi-tenant access:\r\nsourcetype=\"azure:aad:audit\" activityDisplayName=\"Update application\" operationType=Update\r\nresult=success targetResources{}.modifiedProperties{}.displayName=AvailableToOtherTenants\r\n| table activityDateTime initiatedBy.user.userPrincipalName,\r\ntargetResources{}.displayName additionalDetails{}.value\r\nChanges to Azure AD Custom Domains:\r\nsourcetype=\"azure:aad:audit\" activityDisplayName=\"Add unverified domain\" OR\r\nactivityDisplayName=*domain* | stats values(activityDisplayName) AS\r\nAction, values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName)\r\nAS Target, values(targetResources{}.modifiedProperties{}.displayName)\r\nAS \"Modified Resources\", values(targetResources{}.modifiedProperties{}.oldValue)\r\nAS \"Old Values\", values(targetResources{}.modifiedProperties{}.newValue)\r\nAS \"New Values\" by correlationId\r\n| fields - correlationId\r\nVPS Hosts\r\nAt this time, it is believed that adversaries have utilized geographically relevant (meaning IP addresses will be\r\nlocal to the country of the victim) Virtual Private Servers (VPS) hosts to access victim networks. Although there is\r\nno definitive list of these IPs, we recommend that customers review external to internal network traffic to\r\ndetermine if unknown IP addresses have accessed their systems (especially SolarWinds devices) since spring\r\n2020.\r\nhttps://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html\r\nPage 4 of 6\n\nTSTAT Searches (Updated!)\r\nAs Splunkers around the world have been working to find/detect the Sunburst activity, many of our customers\r\nhave found that our quick searches above were not scalable and turned to TSTATS to help them cope with the\r\nvolume in their data models. My colleague Don Slife went ahead and whipped up some queries that you might\r\nfind useful AND scalable. Please note, you must have CIM compliant data in data models to run these searches.\r\nTo find malicious domains in network resolution datamodel This search will look across DNS data in the\r\nNetwork Resolution data model using the sunburstDOMAIN_loopup file above. If you would prefer, remove the\r\nsubsearch and just look for the avsvmcloud[.]com domain in order to detect the primary IOC.\r\n| tstats summariesonly=true earliest(_time) as earliest latest(_time) as latest count as total_conn values(DNS\r\n [| inputlookup sunburstDOMAIN_lookup\r\n | rename Domain as DNS.query\r\n | table DNS.query] OR DNS.query=*avsvmcloud.com by DNS.src DNS.vendor_product DNS.record_type DNS.message_t\r\n| sort earliest\r\n| eval earliest=strftime(earliest, \"%c\"), latest=strftime(latest, \"%c\")\r\nTo find malicious IP addresses in network traffic datamodel This search will look across the network traffic\r\ndatamodel using the sunburstIP_lookup files we referenced above.\r\n| tstats summariesonly=true earliest(_time) as earliest latest(_time) as latest count as total_conn values(All_\r\n [| inputlookup sunburstIP_lookup\r\n | rename IP as All_Traffic.dest\r\n | table All_Traffic.dest] by All_Traffic.src All_Traffic.vendor_product\r\n| sort earliest\r\n| eval earliest=strftime(earliest, \"%c\"), latest=strftime(latest, \"%c\")\r\nhttps://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html\r\nPage 5 of 6\n\nMITRE ATT\u0026CK\r\nThe folks at FireEye were kind enough to map their findings to MITRE ATT\u0026CK. Like the lateral movement\r\nwork above, I went through Splunk Security Essentials and pulled any content we might have associated with the\r\nobserved tactics and techniques. The PDF ended up being pretty big, but we hope it’s useful. If you would rather\r\njust pivot in your own SSE instance, here are the 1-1 searches that you should review (I did add anything I thought\r\nuseful in the PDF, so you might take a peek at it if you have a chance):\r\nMalicious Powershell Process - Encoded Command\r\nAnomalous Audit Trail Activity Detected\r\nTor Traffic\r\nConcentration of Attacker Tools by Filename\r\nConcentration of Attacker Tools by SHA1 Hash\r\nSc Exe Manipulating Windows Services\r\nProhibited Service Detected\r\nProhibited Process Detected\r\nAnomalous New Service\r\nAbnormally High Number of Endpoint Changes By User\r\nFirst Time Seen Running Windows Service\r\nProcesses with Lookalike (typo) Filenames\r\nSMB Traffic Allowed\r\nAnomalous New Process\r\nHigh Process Count\r\nProhibited Service Detected\r\nConclusion\r\nWe have tried to keep this blog short, sweet and concise. The information above is pulled from our existing\r\nproducts like SSE, ESCU, previous research, and some off the cuff SPL’ing by great Splunkers like Shannon\r\nDavis and Ryan Lait. Much (if not all) of the analysis and IOCs above were derived from FireEye and Microsoft\r\nblogs on the subject. However, as mentioned above, our threat research team will be releasing more up-to-date\r\ninformation and additional detections as details (and data) become more available.\r\nSource: https://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html\r\nhttps://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.splunk.com/en_us/blog/security/sunburst-backdoor-detections-in-splunk.html"
	],
	"report_names": [
		"sunburst-backdoor-detections-in-splunk.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434544,
	"ts_updated_at": 1775791279,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d471c11a9b1af1bd108778026419a750c567624f.pdf",
		"text": "https://archive.orkl.eu/d471c11a9b1af1bd108778026419a750c567624f.txt",
		"img": "https://archive.orkl.eu/d471c11a9b1af1bd108778026419a750c567624f.jpg"
	}
}