Category Archives: SolarWinds

FSB warns Russian businesses of cyber attacks as retaliation for SolarWinds hack

Russian authorities are alerting Russian organizations of potential cyberattacks launched by the United States in response to SolarWinds attack.

The Russian intelligence agency FSB has issued a security alert this week warning Russian organizations of potential cyberattacks launched by the United States in response to the SolarWinds supply chain attack.

The alert was issued after officials of the new Biden administration declared that attacks like the SolarWinds ones could trigger a response of their government.

The Russian government always denied any involvement in the SolarWinds attack.

The Russian National Coordination Center for Computer Incidents (NKTSKI) published a security bulletin to warn Russian businesses of the imminent risk of cyber attacks as a retaliation for the SolarWinds attacks that US Government agencies attributed to Moscow.

The Russian National Coordination Center for Computer Incidents (NKTSKI) was created by the Federal Security Service (FSB) in order to prevent, detect and counter cyberattacks on critical infrastructure facilities as well as repair damage from such attacks.

The news of the bulletin was first reported by ZDNet that also shared the alert (Russian language) published by the Russian Government.

The alert also includes a set of recommendations to Russian businesses to prevent cyber attacks.

If you want to receive the weekly Security Affairs Newsletter for free subscribe here.

Pierluigi Paganini

(SecurityAffairs – hacking, SolarWinds)

The post FSB warns Russian businesses of cyber attacks as retaliation for SolarWinds hack appeared first on Security Affairs.

SolarWinds Attack: Microsoft sheds lights into Solorigate second-stage activation

Microsoft’s report provides details of the entire SolarWinds attack chain with a deep dive in the second-stage activation of malware and tools.

Microsoft published a new report that includes additional details of the SolarWinds supply chain attack. The new analysis shad lights on the handover from the Solorigate DLL backdoor to the Cobalt Strike loader.

The attackers focused on separate these two components of the attack chain as much as possible to evade detection.

The report provides details regarding the Solorigate second-stage activation that allowed the attacker to deliver Cobalt Strike loaders, such as Teardrop, and Raindrop.

The known information on the attacks confirms that the Solorigate DLL backdoor was compiled at the end of February 2020 and distributed to the potential victims in late March.  Then attackers removed the Solorigate backdoor code from SolarWinds’ build environment in June 2020.

Considering that the Solorigate backdoor was designed to stay dormant for at least two weeks, the analysis of the timeline suggests that attackers spent approximately a month selecting the victims and preparing unique Cobalt Strike implants as well as command-and-control (C2) infrastructure. This means that the “hands-on-keyboard activity” likely started as early as May.

“The removal of the backdoor-generation function and the compromised code from SolarWinds binaries in June could indicate that, by this time, the attackers had reached a sufficient number of interesting targets, and their objective shifted from deployment and activation of the backdoor (Stage 1) to being operational on selected victim networks, continuing the attack with hands-on-keyboard activity using the Cobalt Strike implants (Stage 2).” states the report published by Microsoft.

Solarwinds Timeline-of-Solorigate-attacks

Microsoft experts analyzed forensic data across the entire environment of impacted organizations to discover how the attackers made lateral movements and how long they remaining within their target networks.

The experts conducted a deep analysis of data collected by Microsoft 365 Defender data and Microsoft Defender telemetry.

Solarwinds 2

While investigating the attack, Microsoft identified several second-stage malware and tools, including TEARDROP, Raindrop, and also other custom loaders for the Cobalt Strike beacon.

“TEARDROP, Raindrop, and the other custom Cobalt Strike Beacon loaders observed during the Solorigate investigation are likely generated using custom Artifact Kit templates.” continues the report. “Each custom loader loads either a Beacon Reflective Loader or a preliminary loader that subsequently loads the Beacon Reflective Loader. Reflective DLL loading is a technique for loading a DLL into a process memory without using the Windows loader.”

Microsoft added that additional attacker tactics, anti-forensic behavior, and operational security allowed them to avoid detection and outstand for operations security (OpSec) best practices.

Below a list of some examples of why threat actors stand out for their professional OpSec methodology and anti-forensic behavior:

Some examples of why these attackers stand out for their professional OpSec methodology and anti-forensic behavior are listed below:

  • Methodic avoidance of shared indicators for each compromised host. Attackers prepared a unique Cobalt Strike DLL implant for each machine and avoided at any cost overlap and reuse of folder name, file name, export function names, C2 domain/IP, HTTP requests, timestamp, file metadata, config, and child process launched. 
  • Camouflage and blending into the environment. Attackers always renamed tools and binaries they used (e.g., ADFIND legit tool) and placed them in folders that mimicked existing programs and files already present on a machine.
  • Disabling event logging using AUDITPOL and re-enabling it afterward.
  • To avoid noisy network enumeration activities (such as repeated NSLOOKUP or LDAP queries) being detected, the attackers created special firewall rules to minimize outgoing packets for certain protocols. Then the attackers methodically removed the rules after the reconnaissance was completed.
  • Lateral movement activities were never executed without preparation. 
  • Attackers used timestomping to change timestamps of artifacts and also leveraged professional wiping procedures and tools to complicate finding and recovering of DLL implants from affected environments.

“As we continue to gain deeper understanding of the Solorigate attack, we get a clearer picture of the skill level of the attackers and the extent of planning they put into pulling off one of the most sophisticated attacks in recent history. The combination of a complex attack chain and a protracted operation means that defensive solutions need to have comprehensive cross-domain visibility into attacker activity and provide months of historical data with powerful hunting tools to investigate as far back as necessary.” concludes Microsoft.

If you want to receive the weekly Security Affairs Newsletter for free subscribe here.

Pierluigi Paganini

(SecurityAffairs – hacking, SolarWinds)

The post SolarWinds Attack: Microsoft sheds lights into Solorigate second-stage activation appeared first on Security Affairs.

FireEye releases an auditing tool to detect SolarWinds hackers’ activity

Cybersecurity firm FireEye has released a report that sheds the light on the SolarWinds attack and the way hackers breached its networks.

Cybersecurity firm FireEye has released a report that sheds the light on the SolarWinds attack and the way hackers breached its networks.

The experts explained how the UNC2452 and other threat actors breached the infrastructure and moved laterally from on-premises networks to the Microsoft 365 cloud. The paper, titled Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452 also provides tips for organizations on how proactively harden their environments.

FireEye also released a tool named Azure AD Investigator that could be used by organizations to discover if their organization has been breached by the SolarWinds hackers, tracked by the security firm as UNC2452.

This FireEye GitHub repository contains a PowerShell module that can be used to detect artifacts associated with the UNC2452’s intrusion and other threat actor activity.

“Some indicators are “high-fidelity” indicators of compromise, while other artifacts are so called “dual-use” artifacts.” states FireEye. “Dual-use artifacts may be related to threat actor activity, but also may be related to legitimate functionality. Analysis and verification will be required for these.”

FireEye pointed out that the tool is read-only, which means that it does not make any changes to the Microsoft 365 environment.

The company warns that the tool could not identify a compromise 100% of the time, and is not able to distinguish if an artifact is the result of a legitimate admin activity or threat actor activity.

Mandiant researchers explained that UNC2452 and other threat actors primarily used four techniques for lateral movements:

  1. Steal the Active Directory Federation Services (AD FS) token-signing certificate and use it to forge tokens for arbitrary users (sometimes described as Golden SAML). This would allow the attacker to authenticate into a federated resource provider (such as Microsoft 365) as any user, without the need for that user’s password or their corresponding multi-factor authentication (MFA) mechanism.
  2. Modify or add trusted domains in Azure AD to add a new federated Identity Provider (IdP) that the attacker controls. This would allow the attacker to forge tokens for arbitrary users and has been described as an Azure AD backdoor.
  3. Compromise the credentials of on-premises user accounts that are synchronized to Microsoft 365 that have high privileged directory roles, such as Global Administrator or Application Administrator.
  4. Backdoor an existing Microsoft 365 application by adding a new application or service principal credential in order to use the legitimate permissions assigned to the application, such as the ability to read email, send email as an arbitrary user, access user calendars, etc.

The Cybersecurity and Infrastructure Security Agency (CISA)’s Cloud Forensics team has also released a PowerShell-based tool, dubbed Sparrow, that can that helps administrators to detect anomalies and potentially malicious activities in Azure/Microsoft 365 environments.

CrowdStrike experts also decided to create their own tool because they face difficulties in using Azure’s administrative tools to enumerate privileges assigned to third-party resellers and partners in their Azure tenant.

“CrowdStrike launches CrowdStrike Reporting Tool for Azure (CRT), a free community tool that will help organizations quickly and easily review excessive permissions in their Azure AD environments, help determine configuration weaknesses, and provide advice to mitigate risk.” states the security firm.

“Throughout our analysis, we experienced first hand the difficulties customers face in managing Azure’s administrative tools to know what relationships and permissions exist within Azure tenants, particularly with third-party partner/resellers, and how to quickly enumerate them. We found it particularly challenging that many of the steps required to investigate are not documented, there was an inability to audit via API, and there is the requirement for global admin rights to view important information which we found to be excessive. Key information should be easily accessible.”

The CrowdStrike Reporting Tool for Azure (CRT) tool could be used by administrators to analyze their Microsoft Azure environment and review the privileges assigned to third-party resellers and partners.

If you want to receive the weekly Security Affairs Newsletter for free subscribe here.

Pierluigi Paganini

(SecurityAffairs – hacking, SolarWinds APT)

The post FireEye releases an auditing tool to detect SolarWinds hackers’ activity appeared first on Security Affairs.

Malwarebytes was breached by the SolarWinds attackers

A fourth malware strain wielded by the SolarWinds attackers has been detailed by Symantec researchers, followed by the disclosure of the attackers’ ingenous lateral movement techniques and the release of an auditing script by FireEye researchers that organizations can use to check their Microsoft 365 tenants for signs of intrusion. Then, on Tuesday, Malwarebytes CEO Marcin Kleczynski disclosed that the same attackers targeted and breached the company, but not through the compromised SolarWinds Orion platform … More

The post Malwarebytes was breached by the SolarWinds attackers appeared first on Help Net Security.

Malwarebytes ‘s email systems hacked by SolarWinds attackers

Cyber security firm Malwarebytes announced that threat actor behind the SolarWinds attack also breached its network last year.

Malwarebytes revealed today that SolarWinds hackers also breached its systems and gained access to its email. Malwarebytes joins the club of security firms that were hit by Solarwinds attackers, after FireEye, Microsoft, and CrowdStrike.

The intrusion took place last year, the company pointed out that hackers exploited another attack vector and did use SolarWinds Orion software.

The intruders compromised some internal systems by exploiting a weakness in Azure Active Directory and abused malicious Office 365 applications.

“While Malwarebytes does not use SolarWinds, we, like many other companies were recently targeted by the same threat actor. We can confirm the existence of another intrusion vector that works by abusing applications with privileged access to Microsoft Office 365 and Azure environments.” reads the post published by malwarebytes. “After an extensive investigation, we determined the attacker only gained access to a limited subset of internal company emails. We found no evidence of unauthorized access or compromise in any of our internal on-premises and production environments.”

On December 15, Microsoft Security Response Center warned the security firm of suspicious activity from a third-party application in its Microsoft Office 365 tenant. The activity was consistent with the tactics, techniques, and procedures (TTPs) of the SolarWinds attackers.

Malwarebytes said it learned of the intrusion from the Microsoft Security Response Center (MSRC) on December 15.

With the support of Microsoft’s Detection and Response Team (DART), Malwarebytes discovered that the attackers leveraged a dormant email protection product within our Office 365 tenant that allowed access to a limited subset of internal company emails. The security firms explained that it does not use Azure cloud services in its production environments.

Malwarebytes performed a deep investigation through its infrastructure, inspecting its source code, build and delivery processes, but it confirmed that internal systems showed no evidence of unauthorized access or compromise. This means that the customers of the security firm were not impacted using its anti-malware solution.

“While we have learned a lot of information in a relatively short period of time, there is much more yet to be discovered about this long and active campaign that has impacted so many high-profile targets,” concludes the company.

“It is imperative that security companies continue to share information that can help the greater industry in times like these, particularly with such new and complex attacks often associated with nation state actors.”

If you want to receive the weekly Security Affairs Newsletter for free subscribe here.

Pierluigi Paganini

(SecurityAffairs – hacking, SolarWinds)

The post Malwarebytes ‘s email systems hacked by SolarWinds attackers appeared first on Security Affairs.

Raindrop, a fourth malware employed in SolarWinds attacks

The threat actors behind the SolarWinds attack used malware dubbed Raindrop for lateral movement and deploying additional payloads.

Security experts from Symantec revealed that threat actors behind the SolarWinds supply chain attack leveraged a malware named Raindrop for lateral movement and deploying additional payloads.

Raindrop is the fourth malware that was discovered investigating the SolarWinds attack after the SUNSPOT backdoor, the Sunburst/Solorigate backdoor and the Teardrop tool. 

Raindrop (Backdoor.Raindrop) is a loader that was used by attackers to deliver a Cobalt Strike payload. Raindrop is similar to the Teardrop tool, but while the latter was delivered by the initial Sunburst backdoor, the former was used for spreading across the victim’s network. 

“Symantec has seen no evidence to date of Raindrop being delivered directly by Sunburst. Instead, it appears elsewhere on networks where at least one computer has already been compromised by Sunburst.” reads a blog post published by Symantec.

Symantec investigated four Raindrop infections until today, the malware was employed in the last phases of the attacks against a very few selected targets.


Both Raindrop and Teardrop are used to deploy Cobalt Strike Beacon, but they use different packers and different Cobalt Strike configurations.

“To date, Symantec has seen four samples of Raindrop. In three cases, Cobalt Strike was configured to use HTTPS as a communication protocol. In the fourth it was configured to use SMB Named Pipe as a communication protocol.” continues the post.

“All three Raindrop samples using HTTPS communication follow very similar configuration patterns as previously seen in one Teardrop sample.”

In the following tables there are key differences between the two tools:

PAYLOAD FORMATCustom, reusing features from PE format. It may be possible to reuse the packer with a range of different payloads supplied as PE DLLs with automatic conversion.Shellcode only.
PAYLOAD EMBEDDINGBinary blob in data section.Steganography, stored at pre-determined locations within the machine code.
PAYLOAD ENCRYPTIONvisualDecrypt combined with XOR using long key.AES layer before decompression; separate XOR layer using one byte key after decompression.
OBFUSCATIONReading JPEG file. Inserted blocks of junk code, some could be generated using a polymorphic engine.Non-functional code to delay execution.
EXPORT NAMESExport names vary, in some cases names overlapping with Tcl/Tk projects.Export names overlap with Tcl/Tk projects.
STOLEN CODEByte-copy of machine code from pre-existing third-party components. The original code is distributed in compiled format only.Recompiled third-party source code.

The report published by Symantec includes IoCs and Yara Rules.

If you want to receive the weekly Security Affairs Newsletter for free subscribe here.

Pierluigi Paganini

(SecurityAffairs – hacking, SolarWinds)

The post Raindrop, a fourth malware employed in SolarWinds attacks appeared first on Security Affairs.

Researchers flag fourth piece of malware seen in SolarWinds hack and detail how Microsoft 365 got exploited

Two security vendors issued more details about the SolarWinds hack and abuse of its Orion network management platform.

Symantec says the list of malware pieces that could be delivered to victims of the SolarWinds Orion supply chain hack has grown to four. It found the new malware, a backdoor which it dubs Raindrop, was used against a select number of victims that were of interest to the attackers.

Raindrop is a loader that delivers a payload of the Cobalt Strike threat emulation software often used by infosec teams for penetration tests. It joins other malware used by the attackers, including the initial backdoor called Sunburst/Soloriagate and back another door later deposited called Teardrop. The malware used to get into the SolarWinds network is called Sunspot.

Raindrop, Symantec says, is very similar to Teardrop. But while the initial Sunburst backdoor delivered teardrop, Raindrop appears to be used for spreading across the victim’s network. The security firm also notes that its seen no evidence of Raindrop being delivered directly by Sunburst to date. Instead, it appears elsewhere on networks where Sunburst has already compromised at least one computer.

The attack by a threat group FireEye calls UNC2452 — believed by the U.S. to be of Russian origin — compromised updates downloaded by some 18,000 users of the Orion network management platform between March and August 2020. SolarWinds has evidence that the attack on its update mechanism started as early as the fall of 2019.

FireEye today also issued a report saying that the UNC2452 group used its access to on-premises networks to access victims’ Microsoft 365 environment during certain attacks. In addition to issuing a detailed paper describing these attacks and how to harden Microsoft environments, FireEye released a free tool on GitHub named Azure AD Investigator. The tool is meant to help organizations determine if the SolarWinds hackers got into Microsoft 365.

In its report, Symantec describes how Raindrop was used against one victim. In early July 2020, Sunburst was installed through the SolarWinds Orion update, compromising two computers. The following day, Teardrop was added to one of them.  That computer was found to have an Active Directory query tool and a credential dumper designed specifically for Orion databases. The credential dumper was similar to, but not the same as, the open-source Solarflare tool.

Eleven days later, on a third victim computer in the organization, where no previous malicious activity had been observed, a copy of the previously unseen Raindrop was installed under the name bproxy.dll. This computer was running computer access and management software. The attackers could have used this software to access any of the computers in the compromised organization.

One hour later, the Raindrop malware installed an additional file called “7z.dll”. Symantec was unable to retrieve this file because, within hours, a legitimate version of 7zip was used to extract a copy of what appeared to be Directory Services Internals (DSInternals) onto the computer. DSInternals is a legitimate tool that can be used for querying Active Directory servers and retrieving data, typically passwords, keys, or password hashes.

A pattern emerges

A second victim organization seen by Symantec had the Raindrop loader in late May. Several days later, PowerShell commands were executed on that computer, attempting to execute further instances of Raindrop on additional computers in the organization.

In a third victim, Symantec says Raindrop was used to install a version of Cobalt Strike that didn’t have an HTTP-based command and control server. Instead, it was rather configured to use a network pipe over Windows SMB (Server Message Block) protocol. Symantec theorizes the victim’s computer did not have direct access to the internet, so command and control was routed through another computer on the local network. Otherwise, the three Raindrop samples seen by Symantec used HTTPS communication.

The report outlines how UNC2452 and other threat actors moved laterally to the Microsoft 365 cloud using a combination of four primary techniques:

  1. Steal the Active Directory Federation Services (AD FS) token-signing certificate and use it to forge tokens for arbitrary users (sometimes described as Golden SAML). This would allow the attacker to authenticate into a federated resource provider (such as Microsoft 365) as any user, without the need for that user’s password or their corresponding multi-factor authentication (MFA) mechanism.
  2. Modify or add trusted domains in Azure AD to add a new federated Identity Provider (IdP) that the attacker controls. This would allow the attacker to forge tokens for arbitrary users and has been described as an Azure AD backdoor.
  3. Compromise the credentials of on-premises user accounts that are synchronized to Microsoft 365 that have high privileged directory roles, such as Global Administrator or Application Administrator.
  4. Backdoor an existing Microsoft 365 application by adding a new application or service principal credential to use the legitimate permissions assigned to the application, such as the ability to read email, send email as an arbitrary user, access user calendars, etc.

“It is important to note that there is no formal security boundary between on-premises networks and cloud services provided by Microsoft 365,” FireEye warned. “If an organization discovers evidence of targeted threat actor activity in their on-premises network, a thorough review of the cloud environment is often necessary as well.”

The post Researchers flag fourth piece of malware seen in SolarWinds hack and detail how Microsoft 365 got exploited first appeared on IT World Canada.

Understanding third-party hacks in the aftermath of the SolarWinds breach

In the aftermath of the SolarWinds hack, a better understanding of third-party hacks in any update that you provide to your colleagues, bosses, and even the board of directors may be warranted. Any such update that you provide on SolarWinds should certainly cover whether or not your organization is one of the 300,000 SolarWinds customers and whether or not you were one of the 18,000 or so that were using the specific version of Orion … More

The post Understanding third-party hacks in the aftermath of the SolarWinds breach appeared first on Help Net Security.

Cyber Security Roundup for January 2021

A suspected nation-state sophisticated cyber-attack of SolarWinds which led to the distribution of a tainted version the SolarWinds Orion network monitoring tool, compromising their customers, dominated the cyber headlines in mid-December 2020.  This was not only one of the most significant cyberattacks of 2020 but perhaps of all time. The United States news media reported the Pentagon, US intelligence agencies, nuclear labs, the Commerce, Justice, Treasury and Homeland Security departments, and several utilities were all compromised by the attack. For the full details of the SolarWinds cyber-attack see my article Sunburst: SolarWinds Orion Compromise Overview

Two other cyberattacks are possibly linked to the SolarWinds hack was also reported, the cyber-theft of sophisticated hacking tools from cybersecurity firm FireEye, a nation-state actor is suspected to be responsible. And the United States National Security Agency (NSA) advised a VMware security vulnerability was being exploited by Russian state-sponsored actors.

Amidst the steady stream of COVID-19 and Brexit news reports, yet another significant ransomware and cyber-extortion attack briefly made UK headlines. Hackers stole confidential records, including patient photos, from UK cosmetic surgery chain 'The Hospital Group', and threatening to publish patient's 'before and after' photos. The UK cosmetic surgery firm, which has a long history of celebrity endorsements, confirmed it was the victim of a ransomware attack, and that it had informed the UK's Information Commissioner's Office about their loss of personal data.

Spotify users had their passwords reset after security researchers alerted the music streaming platform of a leaky database which held the credentials of up to 350,000 Spotify users, which could have been part of a credential stuffing campaign. Security researchers at Avast reported 3 million devices may have been infected with malware hidden within 28 third-party Google Chrome and Microsoft Edge extensions.

A McAfee report said $1 Trillion was lost to cybercrime in 2020, and companies remained unprepared for cyberattacks in 2021.

Stay safe and secure.



    Using Microsoft 365 Defender to protect against Solorigate

    Microsoft security researchers continue to investigate and respond to the sophisticated cyberattack known as Solorigate (also referred to as Sunburst by FireEye) involving a supply chain compromise and the subsequent compromise of cloud assets. While the related investigations and impact assessments are ongoing, Microsoft is providing visibility into the attack chains and related threat intelligence to the defender community as early as possible so organizations can identify and take action to stop this attack, understand the potential scope of its impact, and begin the recovery process from this active threat. We have established a resource center that is constantly updated as more information becomes available at

    This blog is a comprehensive guide for security operations and incident response teams using Microsoft 365 Defender to identify, investigate, and respond to the Solorigate attack if it’s found in your environment. The description of the attack in this blog is based on current analysis and investigations by researchers across Microsoft, our partners, and the intelligence community who are actively collaborating to respond to the attack. This is an active threat that continues to evolve, and the findings included here represent what we know at the time of publishing. We continue to publish and update intelligence, indicators, tactics, techniques, and procedures (TTPs), and related details as we discover them. The report from the Microsoft Security Response Center (MSRC) includes the latest analysis of this threat, known indicators of compromise (IOCs), and initial recommended defenses, and will be updated as new data becomes available.

    This blog covers:

    Tracking the cross-domain Solorigate attack from endpoint to the cloud

    The Solorigate attack is an example of a modern cross-domain compromise. Since these kinds of attacks span multiple domains, having visibility into the entire scope of the attack is key to stopping and preventing its spread.

    This attack features a sophisticated technique involving a software supply chain compromise that allowed attackers to introduce malicious code into signed binaries on the SolarWinds Orion Platform, a popular IT management software. The compromised application grants attackers “free” and easy deployment across a wide range of organizations who use and regularly update the application, with little risk of detection because the signed application and binaries are common and are considered trusted. With this initial widespread foothold, the attackers can then pick and choose the specific organizations they want to continue operating within (while others remain an option at any point as long as the backdoor is installed and undetected). Based on our investigations, the next stages of the attack involve on-premises activity with the goal of off-premises access to cloud resources through the following steps:

    1. Using the compromised SolarWinds DLL to activate a backdoor that enables attackers to remotely control and operate on a device
    2. Using the backdoor access to steal credentials, escalate privileges, and move laterally to gain the ability to create valid SAML tokens using any of two methods:
      1. Stealing the SAML signing certificate (Path 1)
      2. Adding to or modifying existing federation trust (Path 2)
    3. Using attacker-created SAML tokens to access cloud resources and perform actions leading to the exfiltration of emails and persistence in the cloud

    Diagram of the high-level Solorigate attack chain

    Figure 1. High-level end-to-end Solorigate attack chain

    This attack is an advanced and stealthy campaign with the ability to blend in, which could allow attackers to stay under the radar for long periods of time before being detected. The deeply integrated cross-domain security capabilities in Microsoft 365 Defender can empower organizations and their security operations (SOC) teams to uncover this attack, scope out the end-to-end breach from endpoint to the cloud, and take action to block and remediate it. This blog will offer step-by-step guidance to do this by outlining:

    • How indicators of attack show up across endpoints, identity, and the cloud
    • How Microsoft 365 Defender automatically combines alerts across these different domains into a comprehensive end-to-end story
    • How to leverage the powerful toolset available for deep investigation, hunting, and response to enable SOCs to battle the attackers and evict these attackers from both on-premises and cloud environments

    Threat analytics: Understanding and responding to active attacks

    As soon as this attack was discovered, Microsoft researchers published two threat analytics reports to help organizations determine if they are affected, assess the impact of the attack, and identify actions to contain it.

    The reports are published in Microsoft 365 security center, available to all Microsoft Defender for Endpoint customers and Microsoft 365 Defender early adopters. In addition to detailed descriptions of the attack, TTPs, and indicators of compromise (IoCs), the reports provide real-time data aggregated from signals across Microsoft 365 Defender, indicating the all-up impact of the threat to the organization, as well as details about relevant incidents and alerts to initiate investigation on. These reports continue to be updated as additional information becomes available.

    Given the significance of this threat, we are making similar relevant Microsoft threat intelligence data, including the updated list of IOCs, available to everyone publicly.  A comprehensive list of guidance and insights is available at

    Screenshot of threat analytics report on Soloriage in Microsoft Defender Security Center

    Figure 2. Threat analytics report on Solorigate attack

    We recommend Microsoft 365 Defender customers to start their investigations here. After gaining deep understanding of the threat and getting the latest research findings, you can take the following recommended steps:

    Find devices with the compromised SolarWinds Orion application

    The threat analytics report uses insights from threat and vulnerability management to identify devices that have the compromised SolarWinds Orion Platform binaries or are exposed to the attack due to misconfiguration.

    From the Vulnerability patching status chart in threat analytics, you can view the mitigation details to see a list of devices with the vulnerability ID TVM-2020-0002, which was added specifically to help with Solorigate investigations:

    Threat and vulnerability management insights on impact of Solorigate

    Figure 3. Threat and vulnerability management data shows data on exposed devices

    Threat and vulnerability management provides more info about the vulnerability ID TVM-2020-0002, as well as all relevant applications, via the Software inventory view. There are also multiple security recommendations to address this specific threat, including instructions to update the software versions installed on exposed devices.

    Screenshot of security recommendations for Solorigate in Microsoft Defender Security Center

    Figure 4. Security recommendations from threat and vulnerability management

    Investigate related alerts and incidents

    From the threat analytics report, you can quickly locate devices with alerts related to the attack. The Devices with alerts chart identifies devices with malicious components or activities known to be directly related to Solorigate. Click through to get the list of alerts and investigate.

    Some Solorigate activities may not be directly tied to this specific threat but will trigger alerts due to generally suspicious or malicious behaviors. All alerts in Microsoft 365 Defender provided by different Microsoft 365 products are correlated into incidents. Incidents help you see the relationship between detected activities, better understand the end-to-end picture of the attack, and investigate, contain, and remediate the threat in a consolidated manner.

    Review incidents in the Incidents queue and look for those with alerts relevant to this attacker’s TTPs, as described in the threat analytics report (also listed at the end of this blog).

    Screenshot of Microsoft Defender Security Center incidents view for Solorigate

    Figure 5. Consolidated Incident view for Solorigate

    Some alerts are specially tagged with Microsoft Threat Experts to indicate malicious activities that Microsoft researchers found in customer environments during hunting. As part of the Microsoft Threat Experts service, researchers investigated this attack as it unfolded, hunting for associated attacker behaviors, and sent targeted attack notifications. If you see an alert tagged with Microsoft Threat Experts, we strongly recommend that you give it immediate attention.

    Screenshot of Microsoft Defender Security Center showing Microsoft Threat Experts detections

    Figure 6. Microsoft Threat Experts targeted attack notification

    Additionally, Microsoft Threat Experts customers with Experts on demand subscriptions can reach out directly to our on-demand hunters for additional help in understanding the Solorigate threat and the scope of its impact in their environments.

    Hunt for related attacker activity

    The threat analytics report also provides advanced hunting queries that can help analysts locate additional related or similar activities across endpoint, identity, and cloud. Advanced hunting uses a rich set of data sources, but in response to Solorigate, Microsoft has enabled streaming of Azure Active Directory (Azure AD) audit logs into advanced hunting, available for all customers in public preview. These logs provide traceability for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD, such as adding or removing users, apps, groups, roles, and policies.  Customers who do not have Microsoft Defender for Endpoint or are not early adopters for Microsoft 365 Defender can see our recommended advanced hunting queries.

    Currently, this data is available to customers who have Microsoft Cloud App Security with the Office365 connector. Our intent is to expand availability to more Microsoft 365 Defender customers. The new log data is available in the CloudAppEvents table:

    | where Application == “Office 365”

    The log data contains activity logs useful for investigating and finding Azure AD-related activities. This data further enriches the CloudAppEvents table, which also has Exchange Online and Microsoft Teams activities.

    As part of making this new data available, we also published a handful of relevant advanced hunting queries, identified by the suffix [Solorigate], to the GitHub repo.

    Here’s an example query that helps you see when credentials are added to an Azure AD application after ‘Admin Consent’ permissions were granted:

    | where Application == “Office 365”
    | where ActionType == “Consent to application.”
    | where RawEventData.ModifiedProperties[0].Name == “ConsentContext.IsAdminConsent” and RawEventData.ModifiedProperties[0].NewValue == “True”
    | extend spnID = tostring(RawEventData.Target[3].ID)
    | parse RawEventData.ModifiedProperties[4].NewValue with * “=> [[” dummpy “Scope: ” After “]]” *
    | extend PermissionsGranted = split(After, “]”,0)
    | project ConsentTime = Timestamp , AccountDisplayName , spnID , PermissionsGranted
    | join (
    | where Application == “Office 365”
    | where ActionType == “Add service principal credentials.” or ActionType == “Update application – Certificates and secrets management “
    | extend spnID = tostring(RawEventData.Target[3].ID)
    | project AddSecretTime = Timestamp, AccountDisplayName , spnID
    ) on spnID
    | where ConsentTime < AddSecretTime and AccountDisplayName <> AccountDisplayName1

    Microsoft 356 Defender advanced hunting can also assist in many of the recommended incident investigation tasks outlined in the blog, Advice for incident responders on recovery from systemic identity compromises.

    In the remaining sections, we will discuss select examples of alerts raised by Microsoft 365 solutions that monitor and detect Solorigate activities across the attack chain on endpoint, identity, and the cloud. These are alerts you may encounter when investigating incidents in Microsoft 365 security center if your organization is affected by this threat. We will also indicate activities which are now blocked by Microsoft 365 Defender. Lastly, each section contains examples of hunting queries you will find useful for hunting for various attacker activities in your environment.

    Detecting and blocking malware and malicious behavior on endpoints

    Diagram showing attack chain on endpoints involving the Solorigate malware

    Figure 7. Solorigate attack chain: Initial access and command-and-control

    Discovering and blocking backdoor activity

    When the compromised SolarWinds binary SolarWinds.Orion.Core.BusinessLayer.dll gets loaded on a device through normal update channels, the backdoor goes through an extensive list of checks to ensure it’s running in an actual enterprise network and not on an analyst’s machine. It then contacts a command-and-control (C2) server using a subdomain that is generated partly with information gathered from the affected device, which means a unique subdomain is generated for each affected domain. The backdoor allows the attackers to remotely run commands on the device and move to the next stages of the attack. For more information, read our in-depth analysis of the Solorigate malware.

    Microsoft Defender for Endpoint delivers comprehensive protection against this threat (see full list of detection and protection alerts at the end of this blog). Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines the malware, even if the process is running.

    Screenshot of Microsoft Defender Security Center showing alert for blocking of Solorigate malware

    Figure 8. Microsoft Defender for Endpoint blocks malicious binaries

    If the malicious code is successfully deployed, the backdoor lies dormant for up to two weeks. It then attempts to contact numerous C2 domains, with the primary domain being *.avsvmcloud[.]com. The backdoor uses a domain generation algorithm to evade detection. Microsoft 365 Defender detects and blocks this behavior.

    Screenshot of Microsoft Defender Security Center showing alert for malicious network connection

    Figure 9. Microsoft Defender for Endpoint prevented malicious C2 callback

    Discovering potentially tampered devices

    To evade security software and analyst tools, the Solorigate malware enumerates the target system looking for certain running processes, loaded drivers, and registry keys, with the goal of disabling them.

    The Microsoft Defender for Endpoint sensor is one of the processes the malware attempts to disable. Microsoft Defender for Endpoint has built-in protections against many techniques attackers use to disable endpoint sensors ranging from hardened OS protection, anti-tampering policies, and detections for a variety of tampering attempts, including “Attempt to stop Microsoft Defender for Endpoint sensor”, “Tampering with Microsoft Defender for Endpoint sensor settings”, or “Possible sensor tampering in memory”.

    Successfully disabling Microsoft Defender for Endpoint can prevent the system from reporting observed activities. However, the multitude of signals reported into Microsoft 365 Defender provides a unique opportunity to hunt for systems where the tampering technique used might have been successful. The following advanced hunting query can be used to locate devices that should be reporting but aren’t:

    // Times to be modified as appropriate
    let timeAgo=1d;
    let silenceTime=8h;
    // Get all silent devices and IPs from network events
    let allNetwork=materialize(DeviceNetworkEvents
    | where Timestamp > ago(timeAgo)
    and isnotempty(LocalIP)
    and isnotempty(RemoteIP)
    and ActionType in (“ConnectionSuccess”, “InboundConnectionAccepted”)
    and LocalIP !in (“”, “::1”)
    | project DeviceId, Timestamp, LocalIP, RemoteIP, ReportId);
    let nonSilentDevices=allNetwork
    | where Timestamp > ago(silenceTime)
    | union (DeviceProcessEvents | where Timestamp > ago(silenceTime))
    | summarize by DeviceId;
    let nonSilentIPs=allNetwork
    | where Timestamp > ago(silenceTime)
    | summarize by LocalIP;
    let silentDevices=allNetwork
    | where DeviceId !in (nonSilentDevices)
    and LocalIP !in (nonSilentIPs)
    | project DeviceId, LocalIP, Timestamp, ReportId;
    // Get all remote IPs that were recently active
    let addressesDuringSilence=allNetwork
    | where Timestamp > ago(silenceTime)
    | summarize by RemoteIP;
    // Potentially disconnected devices were connected but are silent
    | where LocalIP in (addressesDuringSilence)
    | summarize ReportId=arg_max(Timestamp, ReportId), Timestamp=max(Timestamp), LocalIP=arg_max(Timestamp, LocalIP) by DeviceId
    | project DeviceId, ReportId=ReportId1, Timestamp, LocalIP=LocalIP1

    Microsoft is continuously developing additional measures to both block and alert on these types of tampering activities.

    Detecting hands-on-keyboard activity within an on-premises environment

    Diagram showing Solorigate hands-on-keyboard attack on premises

    Figure 10. Solorigate attack chain: Hands-on-keyboard attack on premises

    After establishing a backdoor connection on an affected device, the attacker’s next goal is to achieve off-premises access to the organization’s cloud services. To do this, they must find a way to gain permissions to those services. One technique we have seen the attackers use is to go after the organization’s Active Directory Federation Services (AD FS) server to obtain the proverbial “keys” to the identity kingdom. AD FS enables federated identity and access management by securely sharing digital identity and entitlement rights across security and enterprise boundaries; effectively, it is the “LSASS for the cloud.” Among other things, AD FS stores the Security Assertion Markup Language (SAML) token signing certificate, which is used to create authorization tokens for users or services in the organization so they can access cloud applications and resources after authentication.

    To 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 above, the attackers leverage fileless techniques for privilege escalation, persistence, and lateral movement, including evading analysis by using system binaries and exploration tools that masquerade as other benign binaries. The attackers also carefully chose organization-specific command-and-control (C2) domains and use custom organization-specific tool naming and locations.

    Microsoft Defender for Endpoint detects a wide array of these attack techniques, allowing SOC teams to track the attacker’s actions in the environment and take actions to contain the attack. The following section covers detections for the techniques used by the attackers to compromise the AD FS infrastructure.

    Identifying attacker reconnaissance

    Attackers collect data from Active Directory using a renamed version of the utility ADFind, running queries against Domain Controllers as part of the reconnaissance stage of the attack. Microsoft Defender for Endpoint detects this behavior and allows the SOC analyst to track compromised devices at this stage to gain visibility into the information the attacker is looking for.

    Screenshot of Microsoft Defender Security Center alert for detection of exploration tools

    Figure 11. Microsoft Defender for Endpoint detects usage of masquerading exploration tools

    Screenshot of Microsoft Defender Security Center alert for detection of LDAP queries

    Figure 12. Microsoft Defender for Endpoint detects usage LDAP query for reconnaissance.

    Stopping lateral movement and credential theft

    To gain access to a highly privileged account needed for later steps in the kill chain, the attackers move laterally between devices and dump credentials until an account with the needed privileges is compromised, all while remaining as stealthy as possible.

    A variety of credential theft methods, such as dumping LSASS memory, are detected and blocked by Microsoft Defender for Endpoint. The example below shows the detection of lateral movement using Windows Management Instrumentation (WMI) to run the attacker’s payload using the Rundll32.exe process.

    Screenshot of Microsoft Defender Security Center alert for detection of remote WMI execution

    Figure 13. Microsoft Defender for Endpoint alert for suspicious remote WMI execution highlighting the attacker’s device and payload

    Microsoft Defender for Identity also detects and raises alerts on a variety of credential theft techniques. In addition to watching for alerts, security analysts can hunt across identity data in Microsoft 365 Defender for signs of identity compromise. Here are a couple of example Microsoft Defender for Identity queries looking for such patterns:

    Enumeration of high-value DC assets followed by logon attempts to validate stolen credentials in time proximity

    let MaxTime = 1d;
    let MinNumberLogon = 5;
    //devices attempting enumeration of high-value DC
    | where Timestamp > ago(30d)
    | where Application == “Active Directory”
    | where QueryTarget in (“Read-only Domain Controllers”)
    //high-value RODC assets
    | project Timestamp, Protocol, Query, DeviceName, AccountUpn
    | join kind = innerunique (
    //devices trying to logon {MaxTime} after enumeration
    | where Timestamp > ago(30d)
    | where ActionType == “LogonSuccess”
    | project LogonTime = Timestamp, DeviceName, DestinationDeviceName) on DeviceName
    | where LogonTime between (Timestamp .. (Timestamp + MaxTime))
    | summarize n=dcount(DestinationDeviceName), TargetedDC = makeset(DestinationDeviceName) by Timestamp, Protocol, DeviceName
    | where n >= MinNumberLogon

    High-volume of LDAP queries in short time filtering for non-DC devices

    let Threshold = 12;
    let BinTime = 1m;
    //approximate list of DC
    let listDC=IdentityDirectoryEvents
    | where Application == “Active Directory”
    | where ActionType == “Directory Services replication”
    | summarize by DestinationDeviceName;
    | where Timestamp > ago(30d)
    //filter out LDAP traffic across DC
    | where DeviceName !in (listDC)
    | where ActionType == “LDAP query”
    | parse Query with * “Search Scope: ” SearchScope “, Base Object:” BaseObject “, Search Filter: ” SearchFilter
    | summarize NumberOfDistinctLdapQueries = dcount(SearchFilter) by DeviceName, bin(Timestamp, BinTime)
    | where NumberOfDistinctLdapQueries > Threshold

    At this point, SOC teams can take containment measures within the Microsoft 365 security center, for example, using indicators to isolate the devices involved and block the remotely executed payload across the environment, as well as mark suspect users as compromised.

    Detecting and remediating persistence

    Microsoft Defender for Endpoint also detects the advanced defense evasion and masquerading techniques used by the attackers to make their actions as close to normal as possible, such as binding a WMI event filter with a logical consumer to remain persistent. Follow the recommended actions in the alert to remove persistence and prevent the attacker’s payload from loading after reboot.

    Screenshot of Microsoft Defender Security Center alert for detection of WMI event filter bound to suspicious consumer

    Figure 14. Microsoft Defender for Endpoint alert for WMI event filter bound to a suspicious consumer showing the persistence and the scheduled command line

    Catching AD FS compromise and the attacker’s ability to impersonate users in the cloud

    The next step in the attack focuses on the AD FS infrastructure and can unfold in two separate paths that lead to the same outcome—the ability to create valid SAML tokens allowing impersonation of users in the cloud:

    • Path 1 – Stealing the SAML signing certificate: After gaining administrative privileges in the organization’s on-premises network, and with access to the AD FS server itself, the attackers access and extract the SAML signing certificate. With this signing certificate, the attackers create valid SAML tokens to access various desired cloud resources as the identity of their choosing.
    • Path 2 – Adding to or modifying existing federation trust: After gaining administrative Azure Active Directory (Azure AD) privileges using compromised credentials, the attackers add their own certificate as a trusted entity in the domain either by adding a new federation trust to an existing tenant or modifying the properties of an existing federation trust. As a result, any SAML token they create and sign will be valid for the identity of their choosing.

    In the first path, obtaining the SAML signing certificate normally entails first querying the private encryption key that resides on the AD FS container and then using that key to decrypt the signing certificate. The certificate can then be used to create illicit but valid SAML tokens that allow the actor to impersonate users, enabling them to access enterprise cloud applications and services.

    Microsoft Defender for Endpoint and Microsoft Defender for Identity detect the actions that attackers take to steal the encryption key needed to decrypt the SAML signing certificate. Both solutions leverage unique LDAP telemetry to raise high-severity alerts highlighting the attacker’s progress towards creating illicit SAML tokens.

    Screenshot of Microsoft Defender Security Center alert for LDAP query and AD FS private key extraction 

    Figure 15. Microsoft Defender for Endpoint detects a suspicious LDAP query being launched and an attempted AD FS private key extraction

    Figure 16. Microsoft Defender for Identity detects private key extraction via malicious LDAP requests

    For the second path, the attackers create their own SAML signing certificate outside of the organization’s environment. With Azure AD administrative permissions, they then add the new certificate as a trusted object. The following advanced hunting query over Azure AD audit logs shows when domain federation settings are changed, helping to discover where the attackers configured the domain to accept authorization tokens signed by their own signing certificate. As these are rare actions, we advise verifying that any instances identified are the result of legitimate administrative activity.


    let auditLookback = 1d; CloudAppEvents
    | where Timestamp > ago(auditLookback)
    | where ActionType =~ “Set federation settings on domain.”
    | extend targetDetails = parse_json(ActivityObjects[1])
    | extend targetDisplayName = targetDetails.Name
    | extend resultStatus = extractjson(“$.ResultStatus”, tostring(RawEventData), typeof(string))
    | project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, targetDisplayName, resultStatus, InitiatingIPAddress=IPAddress, UserAgent

    If the SAML signing certificate is confirmed to be compromised or the attacker has added a new one, follow the best practices for invalidating through certificate rotation to prevent further use and creation of SAML tokens by the attacker. Additionally, affected AD FS servers may need to be isolated and remediated to ensure no remaining attacker control or persistence.

    If the attackers accomplish either path, they gain the ability to create illicit SAML tokens for the identities of their choosing and bypass multifactor authentication (MFA), since the service or application accepting the token assumes MFA is a necessary previous step in creating a properly signed token. To prevent attackers from progressing to the next stage, which is to access cloud resources, the attack should be discovered and remediated at this stage.

    Detecting the hands-on-keyboard activity in the cloud environment

    Diagram of hands-on-keyboard attacks in the cloud

    Figure 17. Solorigate attack chain: Hands-on-keyboard attack in the cloud

    With the ability to create illicit SAML tokens, the attackers can access sensitive data without having to originate from a compromised device or be confined to on-premises persistence. By abusing API access via existing OAuth applications or service principals, they can attempt to blend into the normal pattern of activity, most notably apps or service principals with existing Mail.Read or Mail.ReadWrite permissions to read email content via Microsoft Graph from Exchange Online. If the application does not already have read permissions for emails, then the app may be modified to grant those permissions.

    Identifying unusual addition of credentials to an OAuth app

    Microsoft Cloud App Security (MCAS) has added new automatic detection of unusual credential additions to an OAuth application to alert SOCs about apps that have been compromised to extract data from the organization. This detection logic is built on an anomaly detection engine that learns from each user in the environment, filtering out normal usage patterns to ensure alerts highlight real attacks and not false positives. If you see this alert in your environment and confirm malicious activity, you should take immediate action to suspend the user, mark the user as compromised, reset the user’s password, and remove the credential additions. You may consider disabling the application during investigation and remediation.

    Figure 18. Microsoft Defender Cloud App Security alert for unusual addition of credentials to an OAuth app

    SOCs can use the following Microsoft 365 Defender advanced hunting query over Azure AD audit logs to examine when new credentials have been added to a service principle or application. In general, credential changes may be rare depending on the type and use of the service principal or application. SOCs should verify unusual changes with their respective owners to ensure they are the result of legitimate administrative actions.


    let auditLookback = 1d; CloudAppEvents
    | where Timestamp > ago(auditLookback)
    | where ActionType in (“Add service principal.”, “Add service principal credentials.”, “Update application – Certificates and secrets management “)
    | extend RawEventData = parse_json(RawEventData)
    | where RawEventData.ResultStatus =~ “success”
    | where AccountDisplayName has “@”
    | extend targetDetails = parse_json(ActivityObjects[1])
    | extend targetId = targetDetails.Id
    | extend targetType = targetDetails.Type
    | extend targetDisplayName = targetDetails.Name
    | extend keyEvents = RawEventData.ModifiedProperties
    | where keyEvents has “KeyIdentifier=” and keyEvents has “KeyUsage=Verify”
    | mvexpand keyEvents
    | where keyEvents.Name =~ “KeyDescription”
    | parse keyEvents.NewValue with * “KeyIdentifier=” keyIdentifier:string “,KeyType=” keyType:string “,KeyUsage=” keyUsage:string “,DisplayName=” keyDisplayName:string “]” *
    | parse keyEvents.OldValue with * “KeyIdentifier=” keyIdentifierOld:string “,KeyType” *
    | where keyEvents.OldValue == “[]” or keyIdentifier != keyIdentifierOld
    | where keyUsage == “Verify”
    | project-away keyEvents
    | project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, InitiatingIPAddress=IPAddress, UserAgent, targetDisplayName, targetId, targetType, keyDisplayName, keyType, keyUsage, keyIdentifier

    Discovering malicious access to mail items

    OAuth applications or service principals with Mail.Read or Mail.ReadWrite permissions can read email content from Exchange Online via the Microsoft Graph. To help increase visibility on these behaviors, the MailItemsAccessed action is now available via the new Exchange mailbox advanced audit functionality. See if this feature is enabled by default for you. Important note for customers: If you have customized the list of audit events you are collecting, you may need to manually enable this telemetry.

    If more than 1,000 MailItemsAccessed audit records are generated in less than 24 hours, Exchange Online stops generating auditing records for MailItemsAccessed activity for 24 hours and then resumes logging after this period. This throttling behavior is a good starting point for SOCs to discover potentially compromised mailboxes.


    let starttime = 2d;
    let endtime = 1d;
    | where Timestamp between (startofday(ago(starttime))..startofday(ago(endtime)))
    | where ActionType == “MailItemsAccessed”
    | where isnotempty(RawEventData[‘ClientAppId’]) and RawEventData[‘OperationProperties’][1] has “True”
    | project Timestamp, RawEventData[‘OrganizationId’],AccountObjectId,UserAgent

    In addition to looking for throttled telemetry, you can also hunt for OAuth applications reading mail via the Microsoft Graph API whose behavior has changed prior to a baseline period.


    //Look for OAuth App reading mail via GraphAPI — that did not read mail via graph API in prior week
    let appMailReadActivity = (timeframeStart:datetime, timeframeEnd:datetime) {
    | where Timestamp between (timeframeStart .. timeframeEnd)
    | where ActionType == “MailItemsAccessed”
    | where RawEventData has “00000003-0000-0000-c000-000000000000” // performance check
    | extend rawData = parse_json(RawEventData)
    | extend AppId = tostring(parse_json(rawData.AppId))
    | extend OAuthAppId = tostring(parse_json(rawData.ClientAppId)) // extract OAuthAppId
    | summarize by OAuthAppId
    appMailReadActivity(ago(1d),now()) // detection period
    | join kind = leftanti appMailReadActivity(ago(7d),ago(2d)) // baseline period
    on OAuthAppId

    Microsoft 365 Defender’s cross-domain XDR correlation enables stronger response to critical security incidents

    Like the rest of the security industry, Microsoft continues to track the Solorigate attack, an active threat that continues to unfold as well as evolve. As part of empowering our customers and the larger security community to respond to this attack through sharing intelligence and providing advice, this blog serves to guide Microsoft 365 customers to take full advantage of the comprehensive visibility and the rich investigation tools available in Microsoft 365 Defender. This blog shows that many of the existing capabilities in Microsoft 365 Defender help address this attack, but the unique scenarios created by the threat resulted in some Solorigate-specific detections and other innovative protections, including ones that are made possible by deeply integrated cross-domain threat defense.

    For additional information and further guidance, refer to these Microsoft resources:

    Microsoft will continue to provide public information about the patterns and techniques of this attack and related intelligence for customers to defend themselves, in addition to enhancing the protection capabilities of Microsoft security solutions.


    Appendix: Additional details for detection and hunting

    Detection details

    Attack stage Microsoft 365 Defender detection or alert
    Initial access Microsoft Defender for Endpoint:

    • ‘Solorigate’ high-severity malware was detected/blocked/prevented (Trojan:MSIL/Solorigate.BR!dha)
    • SolarWinds Malicious binaries associated with a supply chain attack
    Execution and persistence Microsoft Defender for Endpoint:

    Command and Control Microsoft Defender for Endpoint:

    Defense evasion Microsoft Defender for Endpoint:

    • Suspicious audit policy tampering
    Reconnaissance Microsoft Defender for Endpoint:

    • Masquerading Active Directory exploration tool
    • Suspicious sequence of exploration activities
    • Execution of suspicious known LDAP query fragments
    Credential access Microsoft Defender for Endpoint:

    • Suspicious access to LSASS (credential access)
    • AD FS private key extraction attempt
    • Possible attempt to access ADFS key material
    • Suspicious ADFS adapter process created

    Microsoft Defender for Identity:

    • Unusual addition of permissions to an OAuth app
    • Active Directory attributes Reconnaissance using LDAP

    Microsoft Cloud App Security:

    • Unusual addition of credentials to an OAuth app
    Lateral movement Microsoft Defender for Endpoint

    • Suspicious file creation initiated remotely (lateral movement)
    • Suspicious Remote WMI Execution (lateral movement)
    Exfiltration Microsoft Defender for Endpoint

    • Suspicious mailbox export or access modification
    • Suspicious archive creation

    Advanced hunting queries

    Attack stage Query link in GitHub repo
    General Microsoft Defender for Endpoint Threat and Vulnerability Management:

    Initial access Microsoft Defender for Endpoint:

    Execution Microsoft Defender for Endpoint:

    | where InitiatingProcessFileName =~”Microsoft.IdentityServer.ServiceHost.exe”
    | where FileName in~(“werfault.exe”, “csc.exe”)
    | where ProcessCommandLine !contains (“nameId”)

    Command and Control Microsoft Defender for Endpoint

    Credential access Azure Active Directory (Microsoft Cloud App Security):

    Exfiltration Exchange Online (Microsoft Cloud App Security):

    The post Using Microsoft 365 Defender to protect against Solorigate appeared first on Microsoft Security.

    Sunburst: SolarWinds Orion Compromise Overview

    On 13th December 2020, it came to light SolarWinds IT systems were compromised by hackers between March 2020 and June 2020. SolarWinds provides software to help organisations manage their IT networking infrastructure. The attackers exploited their SolarWinds IT access to covertly insert a vulnerability, coined 'Sunburst', within the SolarWinds Orion platform software builds. 

    The following SolarWinds Orion versions are considered to be compromised. 
    • Orion Platform 2019.4 HF5, version 2019.4.5200.9083
    • Orion Platform 2020.2 RC1, version 2020.2.100.12219
    • Orion Platform 2020.2 RC2, version 2020.2.5200.12394
    • Orion Platform 2020.2, 2020.2 HF1, version 2020.2.5300.12432
    The vulnerability within these 'tainted' SolarWinds Orion versions permits an attacker to compromise the server on which the SolarWinds Orion product is installed and runs.  Given SolarWinds is a popular network traffic monitoring product, thousands of organisations are said to be impacted by a potential hidden 'backdoor' into their internal networks, which is open to be exploited by malicious hackers, granting them remote access to their internal IT systems and confidential data.  Organisations with the compromised versions of SolarWinds Orion present should immediately disconnect the software's host server from their network, and conduct a digital forensic investigation to determine if their IT systems were remotely compromised.

    How to Update SolarWinds Orion to a Safe Version
    Upgrading to Orion Platform version 2020.2.1 HF 2 ensures the platform is not vulnerable to the SUNBURST vulnerability. The update is currently available at Hotfix installation instructions are available in the 2020.2.1 HF 2 Release notes here.

    The Impact
    In the order of 18,000 organisations from 19 different countries, including the UK, are known to have downloaded the tainted SolarWinds Orion software. Around 50 organisations are known to have been compromised by hackers via the vulnerability, so far.  The United States news media reported the Pentagon, US intelligence agencies, nuclear labs, the Commerce, Justice, Treasury and Homeland Security departments and several utilities were compromised.

    As for the UK, Paul Chichester, NCSC Director of Operations, said “This is a complex, global cyber incident, and we are working with international partners to fully understand its scale and any UK impact. That work is ongoing and will take some time, but simply having SolarWinds does not automatically make an organisation vulnerable to real world impact.' Given that NCSC statement and what has been publically disclosed to date, it is clear the United States governing apparatus are the primary targets of the cyber-attack.

    Russia Accused of Orchestrating this Cyber Attack
    Given the sophistication of the attack and the reported compromises (aka targets) of United States government departments and utilities, it has all the hallmarks of a significant nation-station orchestrated cyber-attack. The fingers of suspicion are pointing directly at Russia, with the Russian backed hacking group APT29 'Fancy Bear' cited as the culprits by many security researchers and intelligence analysts. US Secretary of State Mike Pompeo and Attorney General Bill Barr both publically stated they believe Moscow are behind the attack, as did the chairs of the Senate and House of Representatives' intelligence committees. Russia Denies 'Baseless' SolarWinds claims, while outgoing President Donald Trump seemed to be blaming China for the attack in a Tweet on 19th December.

    Further Information
    Indicators of Compromise (IOCs)




    Additional DLLs


    Network indicators