{
	"id": "59a003de-562a-4c5c-85b1-4774f0c5cd73",
	"created_at": "2026-04-06T00:18:14.078092Z",
	"updated_at": "2026-04-10T03:37:33.149762Z",
	"deleted_at": null,
	"sha1_hash": "f0bcaaf5c7edb6ebcfc64683b89a30917a6ac9b0",
	"title": "Using Microsoft 365 Defender to protect against Solorigate | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3519545,
	"plain_text": "Using Microsoft 365 Defender to protect against Solorigate |\r\nMicrosoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2020-12-28 · Archived: 2026-04-05 17:19:20 UTC\r\nUPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor\r\nbehind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple\r\nother organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving\r\nforward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the\r\nexamples of malware used by the actors. Microsoft Threat Intelligence Center (MSTIC) has named the actor\r\nbehind the attack against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components\r\nas NOBELIUM. As we release new content and analysis, we will use NOBELIUM to refer to the actor and the\r\ncampaign of attacks.\r\nMicrosoft security researchers continue to investigate and respond to the sophisticated cyberattack known as\r\nSolorigate (also referred to as Sunburst by FireEye) involving a supply chain compromise and the subsequent\r\ncompromise of cloud assets. While the related investigations and impact assessments are ongoing, Microsoft is\r\nproviding visibility into the attack chains and related threat intelligence to the defender community as early as\r\npossible so organizations can identify and take action to stop this attack, understand the potential scope of its\r\nimpact, and begin the recovery process from this active threat. We have established a resource center that is\r\nconstantly updated as more information becomes available at https://aka.ms/solorigate.\r\nThis blog is a comprehensive guide for security operations and incident response teams using Microsoft 365\r\nDefender to identify, investigate, and respond to the Solorigate attack if it’s found in your environment. The\r\ndescription of the attack in this blog is based on current analysis and investigations by researchers across\r\nMicrosoft, our partners, and the intelligence community who are actively collaborating to respond to the attack.\r\nThis is an active threat that continues to evolve, and the findings included here represent what we know at the time\r\nof publishing. We continue to publish and update intelligence, indicators, tactics, techniques, and procedures\r\n(TTPs), and related details as we discover them. The report from the Microsoft Security Response Center (MSRC)\r\nincludes the latest analysis of this threat, known indicators of compromise (IOCs), and initial recommended\r\ndefenses, and will be updated as new data becomes available.\r\nThis blog covers:\r\nThe Solorigate attack chain\r\nReviewing affected devices and related incidents with Threat analytics\r\nDetecting and blocking malicious activity on endpoint (Microsoft Defender for Endpoint, Microsoft 365\r\nDefender hunting)\r\nDetecting hands-on-keyboard activity within on-prem environment (Microsoft Defender for Endpoint,\r\nMicrosoft Defender for Identity, Microsoft 365 Defender hunting)\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 1 of 24\n\nDetecting hands-on-keyboard activity in the cloud environment (Microsoft Cloud App Security, Microsoft\r\n365 Defender hunting)\r\nSummary of detections and hunting queries across Microsoft 365 Defender\r\nTracking the cross-domain Solorigate attack from endpoint to the cloud\r\nThe Solorigate attack is an example of a modern cross-domain compromise. Since these kinds of attacks span\r\nmultiple domains, having visibility into the entire scope of the attack is key to stopping and preventing its spread.\r\nThis attack features a sophisticated technique involving a software supply chain compromise that allowed\r\nattackers to introduce malicious code into signed binaries on the SolarWinds Orion Platform, a popular IT\r\nmanagement software. The compromised application grants attackers “free” and easy deployment across a wide\r\nrange of organizations who use and regularly update the application, with little risk of detection because the\r\nsigned application and binaries are common and are considered trusted. With this initial widespread foothold, the\r\nattackers can then pick and choose the specific organizations they want to continue operating within (while others\r\nremain an option at any point as long as the backdoor is installed and undetected). Based on our investigations, the\r\nnext stages of the attack involve on-premises activity with the goal of off-premises access to cloud resources\r\nthrough the following steps:\r\n1. Using the compromised SolarWinds DLL to activate a backdoor that enables attackers to remotely control\r\nand operate on a device\r\n2. Using the backdoor access to steal credentials, escalate privileges, and move laterally to gain the ability to\r\ncreate valid SAML tokens using any of two methods:\r\n1. Stealing the SAML signing certificate (Path 1)\r\n2. Adding to or modifying existing federation trust (Path 2)\r\n3. Using attacker-created SAML tokens to access cloud resources and perform actions leading to the\r\nexfiltration of emails and persistence in the cloud\r\nFigure 1. High-level end-to-end Solorigate attack chain\r\nThis attack is an advanced and stealthy campaign with the ability to blend in, which could allow attackers to stay\r\nunder the radar for long periods of time before being detected. The deeply integrated cross-domain security\r\ncapabilities in Microsoft 365 Defender can empower organizations and their security operations (SOC) teams to\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 2 of 24\n\nuncover this attack, scope out the end-to-end breach from endpoint to the cloud, and take action to block and\r\nremediate it. This blog will offer step-by-step guidance to do this by outlining:\r\nHow indicators of attack show up across endpoints, identity, and the cloud\r\nHow Microsoft 365 Defender automatically combines alerts across these different domains into a\r\ncomprehensive end-to-end story\r\nHow to leverage the powerful toolset available for deep investigation, hunting, and response to enable\r\nSOCs to battle the attackers and evict these attackers from both on-premises and cloud environments\r\nThreat analytics: Understanding and responding to active attacks\r\nAs soon as this attack was discovered, Microsoft researchers published two threat analytics reports to help\r\norganizations determine if they are affected, assess the impact of the attack, and identify actions to contain it.\r\nSophisticated actor attacks FireEye provides information about the FireEye breach and compromised red\r\nteam tools\r\nSolorigate supply chain attack provides a detailed analysis of the SolarWinds supply chain compromise\r\nThe reports are published in Microsoft 365 security center, available to all Microsoft Defender for Endpoint\r\ncustomers and Microsoft 365 Defender early adopters. In addition to detailed descriptions of the attack, TTPs, and\r\nindicators of compromise (IoCs), the reports provide real-time data aggregated from signals across Microsoft 365\r\nDefender, indicating the all-up impact of the threat to the organization, as well as details about relevant incidents\r\nand alerts to initiate investigation on. These reports continue to be updated as additional information becomes\r\navailable.\r\nGiven the significance of this threat, we are making similar relevant Microsoft threat intelligence data, including\r\nthe updated list of IOCs, available to everyone publicly.  A comprehensive list of guidance and insights is\r\navailable at https://aka.ms/solorigate.\r\nFigure 2. Threat analytics report on Solorigate attack\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 3 of 24\n\nWe recommend Microsoft 365 Defender customers to start their investigations here. After gaining deep\r\nunderstanding of the threat and getting the latest research findings, you can take the following recommended\r\nsteps:\r\nFind devices with the compromised SolarWinds Orion application\r\nThe threat analytics report uses insights from threat and vulnerability management to identify devices that have\r\nthe compromised SolarWinds Orion Platform binaries or are exposed to the attack due to misconfiguration.\r\nFrom the Vulnerability patching status chart in threat analytics, you can view the mitigation details to see a list of\r\ndevices with the vulnerability ID TVM-2020-0002, which was added specifically to help with Solorigate\r\ninvestigations:\r\nFigure 3. Threat and vulnerability management data shows data on exposed devices\r\nThreat and vulnerability management provides more info about the vulnerability ID TVM-2020-0002, as well as\r\nall relevant applications, via the Software inventory view. There are also multiple security recommendations to\r\naddress this specific threat, including instructions to update the software versions installed on exposed devices.\r\nFigure 4. Security recommendations from threat and vulnerability management\r\nInvestigate related alerts and incidents\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 4 of 24\n\nFrom the threat analytics report, you can quickly locate devices with alerts related to the attack. The Devices with\r\nalerts chart identifies devices with malicious components or activities known to be directly related to Solorigate.\r\nClick through to get the list of alerts and investigate.\r\nSome Solorigate activities may not be directly tied to this specific threat but will trigger alerts due to generally\r\nsuspicious or malicious behaviors. All alerts in Microsoft 365 Defender provided by different Microsoft 365\r\nproducts are correlated into incidents. Incidents help you see the relationship between detected activities, better\r\nunderstand the end-to-end picture of the attack, and investigate, contain, and remediate the threat in a consolidated\r\nmanner.\r\nReview incidents in the Incidents queue and look for those with alerts relevant to this attacker’s TTPs, as\r\ndescribed in the threat analytics report (also listed at the end of this blog).\r\nFigure 5. Consolidated Incident view for Solorigate\r\nSome alerts are specially tagged with Microsoft Threat Experts to indicate malicious activities that Microsoft\r\nresearchers found in customer environments during hunting. As part of the Microsoft Threat Experts service,\r\nresearchers investigated this attack as it unfolded, hunting for associated attacker behaviors, and sent targeted\r\nattack notifications. If you see an alert tagged with Microsoft Threat Experts, we strongly recommend that you\r\ngive it immediate attention.\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 5 of 24\n\nFigure 6. Microsoft Threat Experts targeted attack notification\r\nAdditionally, Microsoft Threat Experts customers with Experts on demand subscriptions can reach out directly to\r\nour on-demand hunters for additional help in understanding the Solorigate threat and the scope of its impact in\r\ntheir environments.\r\nThe threat analytics report also provides advanced hunting queries that can help analysts locate additional related\r\nor similar activities across endpoint, identity, and cloud. Advanced hunting uses a rich set of data sources, but in\r\nresponse to Solorigate, Microsoft has enabled streaming of Azure Active Directory (Azure AD) audit logs into\r\nadvanced hunting, available for all customers in public preview. These logs provide traceability for all changes\r\ndone by various features within Azure AD. Examples of audit logs include changes made to any resources within\r\nAzure AD, such as adding or removing users, apps, groups, roles, and policies.  Customers who do not have\r\nMicrosoft Defender for Endpoint or are not early adopters for Microsoft 365 Defender can see our recommended\r\nadvanced hunting queries.\r\nCurrently, this data is available to customers who have Microsoft Cloud App Security with the Office365\r\nconnector. Our intent is to expand availability to more Microsoft 365 Defender customers. The new log data is\r\navailable in the CloudAppEvents table:\r\nCloudAppEvents\r\n| where Application == “Office 365”\r\nThe log data contains activity logs useful for investigating and finding Azure AD-related activities. This data\r\nfurther enriches the CloudAppEvents table, which also has Exchange Online and Microsoft Teams activities.\r\nAs part of making this new data available, we also published a handful of relevant advanced hunting queries,\r\nidentified by the suffix [Solorigate], to the GitHub repo.\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 6 of 24\n\nHere’s an example query that helps you see when credentials are added to an Azure AD application after ‘Admin\r\nConsent’ permissions were granted:\r\nCloudAppEvents\r\n| where Application == “Office 365”\r\n| where ActionType == “Consent to application.”\r\n| where RawEventData.ModifiedProperties[0].Name == “ConsentContext.IsAdminConsent” and\r\nRawEventData.ModifiedProperties[0].NewValue == “True”\r\n| extend spnID = tostring(RawEventData.Target[3].ID)\r\n| parse RawEventData.ModifiedProperties[4].NewValue with * “=\u003e [[” dummpy “Scope: ” After “]]” *\r\n| extend PermissionsGranted = split(After, “]”,0)\r\n| project ConsentTime = Timestamp , AccountDisplayName , spnID , PermissionsGranted\r\n| join (\r\nCloudAppEvents\r\n| where Application == “Office 365”\r\n| where ActionType == “Add service principal credentials.” or ActionType == “Update application –\r\nCertificates and secrets management “\r\n| extend spnID = tostring(RawEventData.Target[3].ID)\r\n| project AddSecretTime = Timestamp, AccountDisplayName , spnID\r\n) on spnID\r\n| where ConsentTime \u003c AddSecretTime and AccountDisplayName \u003c\u003e AccountDisplayName1\r\nMicrosoft 356 Defender advanced hunting can also assist in many of the recommended incident investigation\r\ntasks outlined in the blog, Advice for incident responders on recovery from systemic identity compromises.\r\nIn the remaining sections, we will discuss select examples of alerts raised by Microsoft 365 solutions that monitor\r\nand detect Solorigate activities across the attack chain on endpoint, identity, and the cloud. These are alerts you\r\nmay encounter when investigating incidents in Microsoft 365 security center if your organization is affected by\r\nthis threat. We will also indicate activities which are now blocked by Microsoft 365 Defender. Lastly, each section\r\ncontains examples of hunting queries you will find useful for hunting for various attacker activities in your\r\nenvironment.\r\nDetecting and blocking malware and malicious behavior on endpoints\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 7 of 24\n\nFigure 7. Solorigate attack chain: Initial access and command-and-control\r\nDiscovering and blocking backdoor activity\r\nWhen the compromised SolarWinds binary SolarWinds.Orion.Core.BusinessLayer.dll gets loaded on a device\r\nthrough normal update channels, the backdoor goes through an extensive list of checks to ensure it’s running in an\r\nactual enterprise network and not on an analyst’s machine. It then contacts a command-and-control (C2) server\r\nusing a subdomain that is generated partly with information gathered from the affected device, which means a\r\nunique subdomain is generated for each affected domain. The backdoor allows the attackers to remotely run\r\ncommands on the device and move to the next stages of the attack. For more information, read our in-depth\r\nanalysis of the Solorigate malware.\r\nMicrosoft Defender for Endpoint delivers comprehensive protection against this threat (see full list of detection\r\nand protection alerts at the end of this blog). Microsoft Defender Antivirus, the default antimalware solution on\r\nWindows 10, detects and blocks the malicious DLL and its behaviors. It quarantines the malware, even if the\r\nprocess is running.\r\nFigure 8. Microsoft Defender for Endpoint blocks malicious binaries\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 8 of 24\n\nIf the malicious code is successfully deployed, the backdoor lies dormant for up to two weeks. It then attempts to\r\ncontact numerous C2 domains, with the primary domain being *.avsvmcloud[.]com. The backdoor uses a domain\r\ngeneration algorithm to evade detection. Microsoft 365 Defender detects and blocks this behavior.\r\nFigure 9. Microsoft Defender for Endpoint prevented malicious C2 callback\r\nDiscovering potentially tampered devices\r\nTo evade security software and analyst tools, the Solorigate malware enumerates the target system looking for\r\ncertain running processes, loaded drivers, and registry keys, with the goal of disabling them.\r\nThe Microsoft Defender for Endpoint sensor is one of the processes the malware attempts to disable. Microsoft\r\nDefender for Endpoint has built-in protections against many techniques attackers use to disable endpoint sensors\r\nranging from hardened OS protection, anti-tampering policies, and detections for a variety of tampering attempts,\r\nincluding “Attempt to stop Microsoft Defender for Endpoint sensor”, “Tampering with Microsoft Defender for\r\nEndpoint sensor settings”, or “Possible sensor tampering in memory”.\r\nSuccessfully disabling Microsoft Defender for Endpoint can prevent the system from reporting observed\r\nactivities. However, the multitude of signals reported into Microsoft 365 Defender provides a unique opportunity\r\nto hunt for systems where the tampering technique used might have been successful. The following advanced\r\nhunting query can be used to locate devices that should be reporting but aren’t:\r\n// Times to be modified as appropriate\r\nlet timeAgo=1d;\r\nlet silenceTime=8h;\r\n// Get all silent devices and IPs from network events\r\nlet allNetwork=materialize(DeviceNetworkEvents\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 9 of 24\n\n| where Timestamp \u003e ago(timeAgo)\r\nand isnotempty(LocalIP)\r\nand isnotempty(RemoteIP)\r\nand ActionType in (“ConnectionSuccess”, “InboundConnectionAccepted”)\r\nand LocalIP !in (“127.0.0.1”, “::1”)\r\n| project DeviceId, Timestamp, LocalIP, RemoteIP, ReportId);\r\nlet nonSilentDevices=allNetwork\r\n| where Timestamp \u003e ago(silenceTime)\r\n| union (DeviceProcessEvents | where Timestamp \u003e ago(silenceTime))\r\n| summarize by DeviceId;\r\nlet nonSilentIPs=allNetwork\r\n| where Timestamp \u003e ago(silenceTime)\r\n| summarize by LocalIP;\r\nlet silentDevices=allNetwork\r\n| where DeviceId !in (nonSilentDevices)\r\nand LocalIP !in (nonSilentIPs)\r\n| project DeviceId, LocalIP, Timestamp, ReportId;\r\n// Get all remote IPs that were recently active\r\nlet addressesDuringSilence=allNetwork\r\n| where Timestamp \u003e ago(silenceTime)\r\n| summarize by RemoteIP;\r\n// Potentially disconnected devices were connected but are silent\r\nsilentDevices\r\n| where LocalIP in (addressesDuringSilence)\r\n| summarize ReportId=arg_max(Timestamp, ReportId), Timestamp=max(Timestamp),\r\nLocalIP=arg_max(Timestamp, LocalIP) by DeviceId\r\n| project DeviceId, ReportId=ReportId1, Timestamp, LocalIP=LocalIP1\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 10 of 24\n\nMicrosoft is continuously developing additional measures to both block and alert on these types of tampering\r\nactivities.\r\nDetecting hands-on-keyboard activity within an on-premises environment\r\nFigure 10. Solorigate attack chain: Hands-on-keyboard attack on premises\r\nAfter establishing a backdoor connection on an affected device, the attacker’s next goal is to achieve off-premises\r\naccess to the organization’s cloud services. To do this, they must find a way to gain permissions to those services.\r\nOne technique we have seen the attackers use is to go after the organization’s Active Directory Federation\r\nServices (AD FS) server to obtain the proverbial “keys” to the identity kingdom. AD FS enables federated identity\r\nand access management by securely sharing digital identity and entitlement rights across security and enterprise\r\nboundaries; effectively, it is the “LSASS for the cloud.” Among other things, AD FS stores the Security Assertion\r\nMarkup Language (SAML) token signing certificate, which is used to create authorization tokens for users or\r\nservices in the organization so they can access cloud applications and resources after authentication.\r\nTo attack the AD FS infrastructure, the attackers must first obtain appropriate domain permissions through on-premises intelligence gathering, lateral movement, and credential theft. Building from the backdoor described\r\nabove, the attackers leverage fileless techniques for privilege escalation, persistence, and lateral movement,\r\nincluding evading analysis by using system binaries and exploration tools that masquerade as other benign\r\nbinaries. The attackers also carefully chose organization-specific command-and-control (C2) domains and use\r\ncustom organization-specific tool naming and locations.\r\nMicrosoft Defender for Endpoint detects a wide array of these attack techniques, allowing SOC teams to track the\r\nattacker’s actions in the environment and take actions to contain the attack. The following section covers\r\ndetections for the techniques used by the attackers to compromise the AD FS infrastructure.\r\nIdentifying attacker reconnaissance\r\nAttackers collect data from Active Directory using a renamed version of the utility ADFind, running queries\r\nagainst Domain Controllers as part of the reconnaissance stage of the attack. Microsoft Defender for Endpoint\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 11 of 24\n\ndetects this behavior and allows the SOC analyst to track compromised devices at this stage to gain visibility into\r\nthe information the attacker is looking for.\r\nFigure 11. Microsoft Defender for Endpoint detects usage of masquerading exploration tools\r\nFigure 12. Microsoft Defender for Endpoint detects usage LDAP query for reconnaissance.\r\nStopping lateral movement and credential theft\r\nTo gain access to a highly privileged account needed for later steps in the kill chain, the attackers move laterally\r\nbetween devices and dump credentials until an account with the needed privileges is compromised, all while\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 12 of 24\n\nremaining as stealthy as possible.\r\nA variety of credential theft methods, such as dumping LSASS memory, are detected and blocked by Microsoft\r\nDefender for Endpoint. The example below shows the detection of lateral movement using Windows Management\r\nInstrumentation (WMI) to run the attacker’s payload using the Rundll32.exe process.\r\nFigure 13. Microsoft Defender for Endpoint alert for suspicious remote WMI execution highlighting the attacker’s\r\ndevice and payload\r\nMicrosoft Defender for Identity also detects and raises alerts on a variety of credential theft techniques. In addition\r\nto watching for alerts, security analysts can hunt across identity data in Microsoft 365 Defender for signs of\r\nidentity compromise. Here are a couple of example Microsoft Defender for Identity queries looking for such\r\npatterns:\r\nEnumeration of high-value DC assets followed by logon attempts to validate stolen credentials in time proximity\r\net MaxTime = 1d;\r\nlet MinNumberLogon = 5;\r\n//devices attempting enumeration of high-value DC\r\nIdentityQueryEvents\r\n| where Timestamp \u003e ago(30d)\r\n| where Application == “Active Directory”\r\n| where QueryTarget in (“Read-only Domain Controllers”)\r\n//high-value RODC assets\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 13 of 24\n\n| project Timestamp, Protocol, Query, DeviceName, AccountUpn\r\n| join kind = innerunique (\r\n//devices trying to logon {MaxTime} after enumeration\r\nIdentityLogonEvents\r\n| where Timestamp \u003e ago(30d)\r\n| where ActionType == “LogonSuccess”\r\n| project LogonTime = Timestamp, DeviceName, DestinationDeviceName) on DeviceName\r\n| where LogonTime between (Timestamp .. (Timestamp + MaxTime))\r\n| summarize n=dcount(DestinationDeviceName), TargetedDC = makeset(DestinationDeviceName) by\r\nTimestamp, Protocol, DeviceName\r\n| where n \u003e= MinNumberLogon\r\nHigh-volume of LDAP queries in short time filtering for non-DC devices\r\nlet Threshold = 12;\r\nlet BinTime = 1m;\r\n//approximate list of DC\r\nlet listDC=IdentityDirectoryEvents\r\n| where Application == “Active Directory”\r\n| where ActionType == “Directory Services replication”\r\n| summarize by DestinationDeviceName;\r\nIdentityQueryEvents\r\n| where Timestamp \u003e ago(30d)\r\n//filter out LDAP traffic across DC\r\n| where DeviceName !in (listDC)\r\n| where ActionType == “LDAP query”\r\n| parse Query with * “Search Scope: ” SearchScope “, Base Object:” BaseObject “, Search Filter: ”\r\nSearchFilter\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 14 of 24\n\n| summarize NumberOfDistinctLdapQueries = dcount(SearchFilter) by DeviceName, bin(Timestamp,\r\nBinTime)\r\n| where NumberOfDistinctLdapQueries \u003e Threshold\r\nAt this point, SOC teams can take containment measures within the Microsoft 365 security center, for example,\r\nusing indicators to isolate the devices involved and block the remotely executed payload across the environment,\r\nas well as mark suspect users as compromised.\r\nDetecting and remediating persistence\r\nMicrosoft Defender for Endpoint also detects the advanced defense evasion and masquerading techniques used by\r\nthe attackers to make their actions as close to normal as possible, such as binding a WMI event filter with a logical\r\nconsumer to remain persistent. Follow the recommended actions in the alert to remove persistence and prevent the\r\nattacker’s payload from loading after reboot.\r\nFigure 14. Microsoft Defender for Endpoint alert for WMI event filter bound to a suspicious consumer showing\r\nthe persistence and the scheduled command line\r\nCatching AD FS compromise and the attacker’s ability to impersonate users in the cloud\r\nThe next step in the attack focuses on the AD FS infrastructure and can unfold in two separate paths that lead to\r\nthe same outcome—the ability to create valid SAML tokens allowing impersonation of users in the cloud:\r\nPath 1 – Stealing the SAML signing certificate: After gaining administrative privileges in the\r\norganization’s on-premises network, and with access to the AD FS server itself, the attackers access and\r\nextract the SAML signing certificate. With this signing certificate, the attackers create valid SAML tokens\r\nto access various desired cloud resources as the identity of their choosing.\r\nPath 2 – Adding to or modifying existing federation trust: After gaining administrative Azure Active\r\nDirectory (Azure AD) privileges using compromised credentials, the attackers add their own certificate as a\r\ntrusted entity in the domain either by adding a new federation trust to an existing tenant or modifying the\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 15 of 24\n\nproperties of an existing federation trust. As a result, any SAML token they create and sign will be valid for\r\nthe identity of their choosing.\r\nIn the first path, obtaining the SAML signing certificate normally entails first querying the private encryption key\r\nthat resides on the AD FS container and then using that key to decrypt the signing certificate. The certificate can\r\nthen be used to create illicit but valid SAML tokens that allow the actor to impersonate users, enabling them to\r\naccess enterprise cloud applications and services.\r\nMicrosoft Defender for Endpoint and Microsoft Defender for Identity detect the actions that attackers take to steal\r\nthe encryption key needed to decrypt the SAML signing certificate. Both solutions leverage unique LDAP\r\ntelemetry to raise high-severity alerts highlighting the attacker’s progress towards creating illicit SAML tokens.\r\nFigure 15. Microsoft Defender for Endpoint detects a suspicious LDAP query being launched and an attempted\r\nAD FS private key extraction\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 16 of 24\n\nFigure 16. Microsoft Defender for Identity detects private key extraction via malicious LDAP requests\r\nFor the second path, the attackers create their own SAML signing certificate outside of the organization’s\r\nenvironment. With Azure AD administrative permissions, they then add the new certificate as a trusted object. The\r\nfollowing advanced hunting query over Azure AD audit logs shows when domain federation settings are changed,\r\nhelping to discover where the attackers configured the domain to accept authorization tokens signed by their own\r\nsigning certificate. As these are rare actions, we advise verifying that any instances identified are the result of\r\nlegitimate administrative activity.\r\nADFSDomainTrustMods\r\nlet auditLookback = 1d; CloudAppEvents\r\n| where Timestamp \u003e ago(auditLookback)\r\n| where ActionType =~ “Set federation settings on domain.”\r\n| extend targetDetails = parse_json(ActivityObjects[1])\r\n| extend targetDisplayName = targetDetails.Name\r\n| extend resultStatus = extractjson(“$.ResultStatus”, tostring(RawEventData), typeof(string))\r\n| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, targetDisplayName,\r\nresultStatus, InitiatingIPAddress=IPAddress, UserAgent\r\nIf the SAML signing certificate is confirmed to be compromised or the attacker has added a new one, follow the\r\nbest practices for invalidating through certificate rotation to prevent further use and creation of SAML tokens by\r\nthe attacker. Additionally, affected AD FS servers may need to be isolated and remediated to ensure no remaining\r\nattacker control or persistence.\r\nIf the attackers accomplish either path, they gain the ability to create illicit SAML tokens for the identities of their\r\nchoosing and bypass multifactor authentication (MFA), since the service or application accepting the token\r\nassumes MFA is a necessary previous step in creating a properly signed token. To prevent attackers from\r\nprogressing to the next stage, which is to access cloud resources, the attack should be discovered and remediated\r\nat this stage.\r\nDetecting the hands-on-keyboard activity in the cloud environment\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 17 of 24\n\nFigure 17. Solorigate attack chain: Hands-on-keyboard attack in the cloud\r\nWith the ability to create illicit SAML tokens, the attackers can access sensitive data without having to originate\r\nfrom a compromised device or be confined to on-premises persistence. By abusing API access via existing OAuth\r\napplications or service principals, they can attempt to blend into the normal pattern of activity, most notably apps\r\nor service principals with existing Mail.Read or Mail.ReadWrite permissions to read email content via Microsoft\r\nGraph from Exchange Online. If the application does not already have read permissions for emails, then the app\r\nmay be modified to grant those permissions.\r\nIdentifying unusual addition of credentials to an OAuth app\r\nMicrosoft Cloud App Security (MCAS) has added new automatic detection of unusual credential additions to an\r\nOAuth application to alert SOCs about apps that have been compromised to extract data from the organization.\r\nThis detection logic is built on an anomaly detection engine that learns from each user in the environment,\r\nfiltering out normal usage patterns to ensure alerts highlight real attacks and not false positives. If you see this\r\nalert in your environment and confirm malicious activity, you should take immediate action to suspend the user,\r\nmark the user as compromised, reset the user’s password, and remove the credential additions. You may consider\r\ndisabling the application during investigation and remediation.\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 18 of 24\n\nFigure 18. Microsoft Defender Cloud App Security alert for unusual addition of credentials to an OAuth app\r\nSOCs can use the following Microsoft 365 Defender advanced hunting query over Azure AD audit logs to\r\nexamine when new credentials have been added to a service principle or application. In general, credential\r\nchanges may be rare depending on the type and use of the service principal or application. SOCs should verify\r\nunusual changes with their respective owners to ensure they are the result of legitimate administrative actions.\r\nNewAppOrServicePrincipalCredential\r\nlet auditLookback = 1d; CloudAppEvents\r\n| where Timestamp \u003e ago(auditLookback)\r\n| where ActionType in (“Add service principal.”, “Add service principal credentials.”, “Update\r\napplication – Certificates and secrets management “)\r\n| extend RawEventData = parse_json(RawEventData)\r\n| where RawEventData.ResultStatus =~ “success”\r\n| where AccountDisplayName has “@”\r\n| extend targetDetails = parse_json(ActivityObjects[1])\r\n| extend targetId = targetDetails.Id\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 19 of 24\n\n| extend targetType = targetDetails.Type\r\n| extend targetDisplayName = targetDetails.Name\r\n| extend keyEvents = RawEventData.ModifiedProperties\r\n| where keyEvents has “KeyIdentifier=” and keyEvents has “KeyUsage=Verify”\r\n| mvexpand keyEvents\r\n| where keyEvents.Name =~ “KeyDescription”\r\n| parse keyEvents.NewValue with * “KeyIdentifier=” keyIdentifier:string “,KeyType=” keyType:string\r\n“,KeyUsage=” keyUsage:string “,DisplayName=” keyDisplayName:string “]” *\r\n| parse keyEvents.OldValue with * “KeyIdentifier=” keyIdentifierOld:string “,KeyType” *\r\n| where keyEvents.OldValue == “[]” or keyIdentifier != keyIdentifierOld\r\n| where keyUsage == “Verify”\r\n| project-away keyEvents\r\n| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName,\r\nInitiatingIPAddress=IPAddress, UserAgent, targetDisplayName, targetId, targetType, keyDisplayName,\r\nkeyType, keyUsage, keyIdentifier\r\nDiscovering malicious access to mail items\r\nOAuth applications or service principals with Mail.Read or Mail.ReadWrite permissions can read email content\r\nfrom Exchange Online via the Microsoft Graph. To help increase visibility on these behaviors, the\r\nMailItemsAccessed action is now available via the new Exchange mailbox advanced audit functionality. See if this\r\nfeature is enabled by default for you. Important note for customers: If you have customized the list of audit events\r\nyou are collecting, you may need to manually enable this telemetry.\r\nIf more than 1,000 MailItemsAccessed audit records are generated in less than 24 hours, Exchange Online stops\r\ngenerating auditing records for MailItemsAccessed activity for 24 hours and then resumes logging after this\r\nperiod. This throttling behavior is a good starting point for SOCs to discover potentially compromised mailboxes.\r\nMailItemsAccessedThrottling\r\nlet starttime = 2d;\r\nlet endtime = 1d;\r\nCloudAppEvents\r\n| where Timestamp between (startofday(ago(starttime))..startofday(ago(endtime)))\r\n| where ActionType == “MailItemsAccessed”\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 20 of 24\n\n| where isnotempty(RawEventData[‘ClientAppId’]) and RawEventData[‘OperationProperties’][1] has\r\n“True”\r\n| project Timestamp, RawEventData[‘OrganizationId’],AccountObjectId,UserAgent\r\nIn addition to looking for throttled telemetry, you can also hunt for OAuth applications reading mail via the\r\nMicrosoft Graph API whose behavior has changed prior to a baseline period.\r\nOAuthGraphAPIAnomalies\r\n//Look for OAuth App reading mail via GraphAPI — that did not read mail via graph API in prior week\r\nlet appMailReadActivity = (timeframeStart:datetime, timeframeEnd:datetime) {\r\nCloudAppEvents\r\n| where Timestamp between (timeframeStart .. timeframeEnd)\r\n| where ActionType == “MailItemsAccessed”\r\n| where RawEventData has “00000003-0000-0000-c000-000000000000” // performance check\r\n| extend rawData = parse_json(RawEventData)\r\n| extend AppId = tostring(parse_json(rawData.AppId))\r\n| extend OAuthAppId = tostring(parse_json(rawData.ClientAppId)) // extract OAuthAppId\r\n| summarize by OAuthAppId\r\n};\r\nappMailReadActivity(ago(1d),now()) // detection period\r\n| join kind = leftanti appMailReadActivity(ago(7d),ago(2d)) // baseline period\r\non OAuthAppId\r\nMicrosoft 365 Defender’s cross-domain XDR correlation enables stronger response\r\nto critical security incidents\r\nLike the rest of the security industry, Microsoft continues to track the Solorigate attack, an active threat that\r\ncontinues to unfold as well as evolve. As part of empowering our customers and the larger security community to\r\nrespond to this attack through sharing intelligence and providing advice, this blog serves to guide Microsoft 365\r\ncustomers to take full advantage of the comprehensive visibility and the rich investigation tools available in\r\nMicrosoft 365 Defender. This blog shows that many of the existing capabilities in Microsoft 365 Defender help\r\naddress this attack, but the unique scenarios created by the threat resulted in some Solorigate-specific detections\r\nand other innovative protections, including ones that are made possible by deeply integrated cross-domain threat\r\ndefense.\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 21 of 24\n\nFor additional information and further guidance, refer to these Microsoft resources:\r\nCustomer guidance on recent nation-state cyber attacks\r\nAnalyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack\r\nSolarWinds post-compromise hunting with Azure Sentinel\r\nAdvice for incident responders on recovery from systemic identity compromises\r\nMicrosoft will continue to provide public information about the patterns and techniques of this attack and related\r\nintelligence for customers to defend themselves, in addition to enhancing the protection capabilities of Microsoft\r\nsecurity solutions.\r\nAppendix: Additional details for detection and hunting\r\nDetection details\r\nAttack stage Microsoft 365 Defender detection or alert\r\nInitial access\r\nMicrosoft Defender for Endpoint:\r\n‘Solorigate’ high-severity malware was detected/blocked/prevented\r\n(Trojan:MSIL/Solorigate.BR!dha)SolarWinds Malicious binaries\r\nassociated with a supply chain attack\r\nExecution and\r\npersistence\r\nMicrosoft Defender for Endpoint:\r\n‘Solorigate’ high-severity malware was detected/blocked/prevented\r\n(Trojan:Win64/Cobaltstrike.RN!dha,\r\nTrojan:PowerShell/Solorigate.H!dha)Suspicious process launch by\r\nRundll32.exeUse of living-off-the-land binary to run malicious\r\ncodeA WMI event filter was bound to a suspicious event consumer\r\nCommand and\r\nControl\r\nMicrosoft Defender for Endpoint:\r\nAn active ‘Solorigate’ high-severity malware was detected/\r\nblocked/prevented (Trojan:Win64/Cobaltstrike.RN!dha)\r\nDefense evasion\r\nMicrosoft Defender for Endpoint:\r\nSuspicious audit policy tampering\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 22 of 24\n\nReconnaissance\r\nMicrosoft Defender for Endpoint:\r\nMasquerading Active Directory exploration toolSuspicious sequence\r\nof exploration activitiesExecution of suspicious known LDAP query\r\nfragments\r\nCredential\r\naccess\r\nMicrosoft Defender for Endpoint:\r\n– Suspicious access to LSASS (credential access)\r\n– AD FS private key extraction attempt\r\n– Possible attempt to access ADFS key material\r\n– Suspicious ADFS adapter process created\r\nMicrosoft Defender for Identity:\r\n– Unusual addition of permissions to an OAuth app\r\n– Active Directory attributes Reconnaissance using LDAP\r\nMicrosoft Cloud App Security:\r\n– Unusual addition of credentials to an OAuth app\r\nLateral\r\nmovement\r\nMicrosoft Defender for Endpoint\r\nSuspicious file creation initiated remotely (lateral\r\nmovement)Suspicious Remote WMI Execution (lateral movement)\r\nExfiltration\r\nMicrosoft Defender for Endpoint\r\nSuspicious mailbox export or access modificationSuspicious archive\r\ncreation\r\nAdvanced hunting queries\r\nAttack stage Query link in GitHub repo\r\nGeneral\r\nMicrosoft Defender for Endpoint Threat and Vulnerability Management:\r\nSolarWinds Orion software in your org\r\nInitial access\r\nMicrosoft Defender for Endpoint:\r\nMalicious DLLs loaded in memoryMalicious DLLs created in the\r\nsystem or locallyCompromised SolarWinds certificate\r\nExecution Microsoft Defender for Endpoint:\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 23 of 24\n\nSolarWinds processes launching PowerShell with Base64SolarWinds\r\nprocesses launching CMD with echoADFS adapter process spawning:\r\nDeviceProcessEvents\r\n| where InitiatingProcessFileName\r\n=~”Microsoft.IdentityServer.ServiceHost.exe”\r\n| where FileName in~(“werfault.exe”, “csc.exe”)\r\n| where ProcessCommandLine !contains (“nameId”)\r\nCommand\r\nand Control\r\nMicrosoft Defender for Endpoint\r\nC2 communicationsC2 lookup\r\nCredential\r\naccess\r\nAzure Active Directory (Microsoft Cloud App Security):\r\nCredentials added to AAD app after admin consentNew access\r\ncredential added to application or service principalDomain federation\r\ntrust settings modifiedAdd uncommon credential type to\r\napplicationService Principal Added To Role\r\nExfiltration\r\nExchange Online (Microsoft Cloud App Security):\r\nMail Items Accessed Throttling AnalyticMail Items Accessed Anomaly\r\nAnalyticOAuth Apps reading mail via GraphAPI anomalyOAuth Apps\r\nreading mail both via GraphAPI and directly\r\nSource: https://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nhttps://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/\r\nPage 24 of 24",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"Malpedia"
	],
	"references": [
		"https://www.microsoft.com/security/blog/2020/12/28/using-microsoft-365-defender-to-coordinate-protection-against-solorigate/"
	],
	"report_names": [
		"using-microsoft-365-defender-to-coordinate-protection-against-solorigate"
	],
	"threat_actors": [
		{
			"id": "b43e5ea9-d8c8-4efa-b5bf-f1efb37174ba",
			"created_at": "2022-10-25T16:07:24.36191Z",
			"updated_at": "2026-04-10T02:00:04.954902Z",
			"deleted_at": null,
			"main_name": "UNC2452",
			"aliases": [
				"Dark Halo",
				"Nobelium",
				"SolarStorm",
				"StellarParticle",
				"UNC2452"
			],
			"source_name": "ETDA:UNC2452",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "1d3f9dec-b033-48a5-8b1e-f67a29429e89",
			"created_at": "2022-10-25T15:50:23.739197Z",
			"updated_at": "2026-04-10T02:00:05.275809Z",
			"deleted_at": null,
			"main_name": "UNC2452",
			"aliases": [
				"UNC2452",
				"NOBELIUM",
				"StellarParticle",
				"Dark Halo"
			],
			"source_name": "MITRE:UNC2452",
			"tools": [
				"Sibot",
				"Mimikatz",
				"Cobalt Strike",
				"AdFind",
				"GoldMax"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "a241a1ca-2bc9-450b-a07b-aae747ee2710",
			"created_at": "2024-06-19T02:03:08.150052Z",
			"updated_at": "2026-04-10T02:00:03.737173Z",
			"deleted_at": null,
			"main_name": "IRON RITUAL",
			"aliases": [
				"APT29",
				"Blue Dev 5 ",
				"BlueBravo ",
				"Cloaked Ursa ",
				"CozyLarch ",
				"Dark Halo ",
				"Midnight Blizzard ",
				"NOBELIUM ",
				"StellarParticle ",
				"UNC2452 "
			],
			"source_name": "Secureworks:IRON RITUAL",
			"tools": [
				"Brute Ratel C4",
				"Cobalt Strike",
				"EnvyScout",
				"GoldFinder",
				"GoldMax",
				"NativeZone",
				"RAINDROP",
				"SUNBURST",
				"Sibot",
				"TEARDROP",
				"VaporRage"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "46b3c0fc-fa0c-4d63-a38a-b33a524561fb",
			"created_at": "2023-01-06T13:46:38.393409Z",
			"updated_at": "2026-04-10T02:00:02.955738Z",
			"deleted_at": null,
			"main_name": "APT29",
			"aliases": [
				"Cloaked Ursa",
				"TA421",
				"Blue Kitsune",
				"BlueBravo",
				"IRON HEMLOCK",
				"G0016",
				"Nobelium",
				"Group 100",
				"YTTRIUM",
				"Grizzly Steppe",
				"ATK7",
				"ITG11",
				"COZY BEAR",
				"The Dukes",
				"Minidionis",
				"UAC-0029",
				"SeaDuke"
			],
			"source_name": "MISPGALAXY:APT29",
			"tools": [
				"SNOWYAMBER",
				"HALFRIG",
				"QUARTERRIG"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "70872c3a-e788-4b55-a7d6-b2df52001ad0",
			"created_at": "2023-01-06T13:46:39.18401Z",
			"updated_at": "2026-04-10T02:00:03.239111Z",
			"deleted_at": null,
			"main_name": "UNC2452",
			"aliases": [
				"DarkHalo",
				"StellarParticle",
				"NOBELIUM",
				"Solar Phoenix",
				"Midnight Blizzard"
			],
			"source_name": "MISPGALAXY:UNC2452",
			"tools": [
				"SNOWYAMBER",
				"HALFRIG",
				"QUARTERRIG"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a",
			"created_at": "2022-10-25T15:50:23.548494Z",
			"updated_at": "2026-04-10T02:00:05.292748Z",
			"deleted_at": null,
			"main_name": "APT29",
			"aliases": [
				"APT29",
				"IRON RITUAL",
				"IRON HEMLOCK",
				"NobleBaron",
				"Dark Halo",
				"NOBELIUM",
				"UNC2452",
				"YTTRIUM",
				"The Dukes",
				"Cozy Bear",
				"CozyDuke",
				"SolarStorm",
				"Blue Kitsune",
				"UNC3524",
				"Midnight Blizzard"
			],
			"source_name": "MITRE:APT29",
			"tools": [
				"PinchDuke",
				"ROADTools",
				"WellMail",
				"CozyCar",
				"Mimikatz",
				"Tasklist",
				"OnionDuke",
				"FatDuke",
				"POSHSPY",
				"EnvyScout",
				"SoreFang",
				"GeminiDuke",
				"reGeorg",
				"GoldMax",
				"FoggyWeb",
				"SDelete",
				"PolyglotDuke",
				"AADInternals",
				"MiniDuke",
				"SeaDuke",
				"Sibot",
				"RegDuke",
				"CloudDuke",
				"GoldFinder",
				"AdFind",
				"PsExec",
				"NativeZone",
				"Systeminfo",
				"ipconfig",
				"Impacket",
				"Cobalt Strike",
				"PowerDuke",
				"QUIETEXIT",
				"HAMMERTOSS",
				"BoomBox",
				"CosmicDuke",
				"WellMess",
				"VaporRage",
				"LiteDuke"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f27790ff-4ee0-40a5-9c84-2b523a9d3270",
			"created_at": "2022-10-25T16:07:23.341684Z",
			"updated_at": "2026-04-10T02:00:04.549917Z",
			"deleted_at": null,
			"main_name": "APT 29",
			"aliases": [
				"APT 29",
				"ATK 7",
				"Blue Dev 5",
				"BlueBravo",
				"Cloaked Ursa",
				"CloudLook",
				"Cozy Bear",
				"Dark Halo",
				"Earth Koshchei",
				"G0016",
				"Grizzly Steppe",
				"Group 100",
				"ITG11",
				"Iron Hemlock",
				"Iron Ritual",
				"Midnight Blizzard",
				"Minidionis",
				"Nobelium",
				"NobleBaron",
				"Operation Ghost",
				"Operation Office monkeys",
				"Operation StellarParticle",
				"SilverFish",
				"Solar Phoenix",
				"SolarStorm",
				"StellarParticle",
				"TEMP.Monkeys",
				"The Dukes",
				"UNC2452",
				"UNC3524",
				"Yttrium"
			],
			"source_name": "ETDA:APT 29",
			"tools": [
				"7-Zip",
				"ATI-Agent",
				"AdFind",
				"Agentemis",
				"AtNow",
				"BEATDROP",
				"BotgenStudios",
				"CEELOADER",
				"Cloud Duke",
				"CloudDuke",
				"CloudLook",
				"Cobalt Strike",
				"CobaltStrike",
				"CosmicDuke",
				"Cozer",
				"CozyBear",
				"CozyCar",
				"CozyDuke",
				"Danfuan",
				"EnvyScout",
				"EuroAPT",
				"FatDuke",
				"FoggyWeb",
				"GeminiDuke",
				"Geppei",
				"GoldFinder",
				"GoldMax",
				"GraphDrop",
				"GraphicalNeutrino",
				"GraphicalProton",
				"HAMMERTOSS",
				"HammerDuke",
				"LOLBAS",
				"LOLBins",
				"LiteDuke",
				"Living off the Land",
				"MagicWeb",
				"Mimikatz",
				"MiniDionis",
				"MiniDuke",
				"NemesisGemina",
				"NetDuke",
				"OnionDuke",
				"POSHSPY",
				"PinchDuke",
				"PolyglotDuke",
				"PowerDuke",
				"QUIETEXIT",
				"ROOTSAW",
				"RegDuke",
				"Rubeus",
				"SNOWYAMBER",
				"SPICYBEAT",
				"SUNSHUTTLE",
				"SeaDaddy",
				"SeaDask",
				"SeaDesk",
				"SeaDuke",
				"Sharp-SMBExec",
				"SharpView",
				"Sibot",
				"Solorigate",
				"SoreFang",
				"TinyBaron",
				"WINELOADER",
				"WellMail",
				"WellMess",
				"cobeacon",
				"elf.wellmess",
				"reGeorg",
				"tDiscoverer"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434694,
	"ts_updated_at": 1775792253,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f0bcaaf5c7edb6ebcfc64683b89a30917a6ac9b0.pdf",
		"text": "https://archive.orkl.eu/f0bcaaf5c7edb6ebcfc64683b89a30917a6ac9b0.txt",
		"img": "https://archive.orkl.eu/f0bcaaf5c7edb6ebcfc64683b89a30917a6ac9b0.jpg"
	}
}