Netlogon Domain Controller Enforcement Mode is enabled by default beginning with the February 9, 2021 Security Update, related to CVE-2020-1472

January 15th, 2021 No comments

Microsoft addressed a Critical RCE vulnerability affecting the Netlogon protocol (CVE-2020-1472) on August 11, 2020.  We are reminding our customers that beginning with the February 9, 2021 Security Update release we will be enabling Domain Controller enforcement mode by default.  This will block vulnerable connections from non-compliant devices.  DC enforcement mode requires that all Windows and non-Windows devices use secure RPC with Netlogon secure channel unless customers have explicitly allowed the account to be vulnerable by adding an exception for the …

Netlogon Domain Controller Enforcement Mode is enabled by default beginning with the February 9, 2021 Security Update, related to CVE-2020-1472 Read More »

Simplify compliance and manage risk with Microsoft Compliance Manager

January 14th, 2021 No comments

The cost of non-compliance is more than twice that of compliance costs. Non-compliance with the ever-increasing and changing regulatory requirements can have a significant impact on your organization’s brand, reputation, and revenue. According to a study by the Ponemon Institute and Globalscape, being compliant will cost you less compared to business disruptions, loss of revenue, and hefty fines.

Data explosion and regulatory environment

As organizations go through digital transformation, they are generating and consuming much more data than in the past to help them gain an edge over their competitors. This data is necessary to continue to stay relevant by empowering employees, engaging customers, and optimizing operations. Managing this data and the variety of devices on which it is created can be complicated, especially when it comes to ensuring compliance.

Not only is the amount of data IT must manage exploding, regulations on how that data can and should be handled are also increasing. Collecting customer and citizen data is often an integral part of how public and private sector organizations function. While there has been progress over the last few years, the challenge of maintaining and protecting personal data continues. Regulations are creating a need for the responsible usage of personal data, and the stakes are high. Not complying with regulations can result in significant fines and reduced credibility with regulators, customers, and citizens.

Manage compliance challenges

According to a recent report about the cost of compliance, there were more than 215 regulation updates a day from over 1,000 regulatory bodies all over the world, a slight decrease from the previous year. For example, enforcement of the California Consumer Privacy Act (CCPA), Brazil’s Lei Geral de Proteção de Dados (LGPD), and Thailand’s Personal Data Protection Act (PDPA) began in 2020.

Organizations face all kinds of risks, including financial, legal, people, IT, and cybersecurity risks. Below are some of the challenges we are seeing due to the dynamic nature of the compliance landscape.

  • Keeping up with constantly changing regulations is a struggle. With all the regulatory and standards bodies creating new or revising existing requirements and guidelines, keeping up to date is time and resource-intensive.
  • Point-in-time assessments create a digital blind spot. Many organizations rely on point-in-time assessments, like annual audits. Unfortunately, they can go out of date quickly and expose the organization to potential risks until the next assessment is done. Organizations are looking for ways to improve integration and create near real-time assessments to control risks caused by digital assets.
  • Inefficient collaboration and siloed knowledge lead to duplication of effort. Organizations are often challenged due to siloed knowledge concerning IT risk management. IT and security admins know the technology solutions but find regulations difficult to understand. Contrast that with compliance, privacy, and legal teams who tend to be familiar with the regulations but are not experts in the technology available to help them comply. In addition, many organizations start their compliance journey using general-purpose tools like Microsoft Excel and try to track compliance manually, but quickly outgrow this approach because of the complexities of managing compliance activities.
  • Complexity across IT environments hinders adoption. Understanding how to integrate the many solutions available and configure each one to minimize compliance risks can be difficult. This is especially true in organizations with solutions sourced from multiple vendors that often have overlapping functionality. Decision-makers want simple step-by-step guidance on how to make the tools work for the industry standards and regulations they are subject to.

Simplify compliance with Microsoft Compliance Manager

Microsoft Compliance Manager is the end-to-end compliance management solution included in the Microsoft 365 compliance center. It empowers organizations to simplify compliance, reduce risk, and meet global, industry, and regional compliance regulations and standards. Compliance Manager translates complicated regulations, standards, company policies, and other desired control frameworks into simple language, maps regulatory controls and recommended improvement actions, and provides step-by-step guidance on how to implement those actions to meet regulatory requirements. Compliance Manager helps customers prioritize work by associating a score with each action, which accrues to an overall compliance score. Compliance Manager provides the following benefits:

  • Pre-built assessments for common industry and regional standards and regulations, and custom assessments to meet your unique compliance needs. Assessments are available depending on your licensing agreement.
  • Workflow functionality to help you efficiently complete risk assessments.
  • Detailed guidance on actions you can take to improve your level of compliance with the standards and regulations most relevant for your organization.
  • Risk-based compliance score to help you understand your compliance posture by measuring your progress completing improvement actions.

Shared responsibility

For organizations running their workloads only on-premises, they are 100 percent responsible for implementing the controls necessary to comply with standards and regulations. With cloud-based services, such as Microsoft 365, that responsibility becomes shared between your organization and the cloud provider, although is ultimately responsible for the security and compliance of their data.

Microsoft manages controls relating to physical infrastructure, security, and networking with a software as a service (SaaS) offering like Microsoft 365. Organizations no longer need to spend resources building datacenters or setting up network controls. With this model, organizations manage the risk for data classification and accountability. And risk management is shared in certain areas like identity and access management. The chart below is an example of how responsibility is shared between the cloud customer and cloud provider with various on-premises and online services models.

shows the Shared responsibility model

Figure 1: Shared responsibility model

Apply a shared responsibility model

Because responsibility is shared, transitioning your IT infrastructure from on-premises to a cloud-based service like Microsoft 365 significantly reduces your burden of complying with regulations. Take the United States National Institute of Standards and Technology’s NIST 800-53 regulation as an example. It is one of the largest and most stringent security and data protection control frameworks used by the United States government and large organizations. If your organization were adhering to this standard and using Microsoft 365, Microsoft would be responsible for managing more than 75 percent of the 500 plus controls. You would only need to focus on implementing and maintaining the controls not managed by Microsoft. Contrast that situation with one where your organization was running 100 percent on-premises. In that case, your organization would need to implement and maintain all the NIST 800-53 controls on your own. The time and cost savings managing your IT portfolio under the shared responsibility model can be substantial.

shows the NIST examples of shared responsibilities

Figure 2: NIST examples of shared responsibilities

Assess your compliance with a compliance score

Compliance Manager helps you prioritize which actions to focus on to improve your overall compliance posture by calculating your compliance score. The extent to which an improvement action impacts your compliance score depends on the relative risk it represents. Points are awarded based on whether the action risk level has been identified as a combination of the following action characteristics:

  • Mandatory or discretionary.
  • Preventative, detective, or corrective.

Your compliance score measures your progress towards completing recommended actions that help reduce risks around data protection and regulatory standards. Your initial score is based on the Data Protection Baseline, which includes controls common to many industry regulations and standards. While the Data Protection Baseline is a good starting point for assessing your compliance posture, a compliance score becomes more valuable once you add assessments relevant to the specific requirements of your organization. You can also use filters to view the portion of your compliance score based on criteria that includes one or more solutions, assessments, and regulations. More on that later.

The image below is an example of the Overall compliance score section of the Compliance Manager dashboard. Notice that even though the number under Your points achieved is zero, the Compliance Score is 75 percent. This demonstrates the value of the shared responsibility model. Since Microsoft has already implemented all the actions it is responsible for, a substantial portion of what is recommended to achieve compliance is already complete even though you have yet to take any action.

Shows the Compliance Score from Microsoft Compliance Manager

Figure 3: Compliance Score from Microsoft Compliance Manager

For more information on Microsoft Compliance Manager, please visit the Microsoft Compliance Manager documentation. To learn more about Microsoft Security solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Simplify compliance and manage risk with Microsoft Compliance Manager appeared first on Microsoft Security.

Top MSRC 2020 Q4 Security Researchers – Congratulations!

January 14th, 2021 No comments

We’re excited to announce the top contributing researchers for the 2020 Fourth Quarter (Q4)! Congratulations to all of the researchers who made this quarter’s leaderboard and a huge thank you to everyone who continues to help secure our customers and the ecosystem. The top three researchers of the 2020 Q4 Security Researcher Leaderboard are: Cameron …

Top MSRC 2020 Q4 Security Researchers – Congratulations! Read More »

Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender

January 14th, 2021 No comments

­Even as investigations into the sophisticated attack known as Solorigate are still underway, details and insights about the tools, patterns, and methods used by the attackers point to steps that organizations can take to improve their defenses against similar attacks. Solorigate is a cross-domain compromise—comprehensive visibility and coordinated defense are critical in responding to the attack. The same unified end-to-end protection is key to increasing resilience and preventing such attacks.

This blog is a guide for security administrators using Microsoft 365 Defender and Azure Defender to identify and implement security configuration and posture improvements that harden enterprise environments against Solorigate’s attack patterns.

This blog will cover:

The recommendations on this blog are based on our current analysis of the Solorigate attack. While this threat continues to evolve and investigations continue to unearth more information, we’re publishing these recommendations to help customers apply improvements today. To get the latest information and guidance from Microsoft, visit https://aka.ms/solorigate. Security operations and incident response teams looking for detection coverage and hunting guidance can refer to https://aka.ms/detect_solorigate.

What the Solorigate attack tells us about the state of cyberattacks

Solorigate is a complex, multi-stage attack that involved the use of advanced attacker techniques across multiple environments and multiple domains to compromise high-profile targets. To perpetrate this sophisticated attack, the attackers performed the steps below, which are discussed in detail in this blog:

  1. Compromise a legitimate binary belonging to the SolarWinds Orion Platform through a supply-chain attack
  2. Deploy a backdoor malware on devices using the compromised binary to allow attackers to remotely control affected devices
  3. Use the backdoor access on compromised devices to steal credentials, escalate privileges, and move laterally across on-premises environments to gain the ability to create SAML tokens
  4. Access cloud resources to search for accounts of interest and exfiltrate emails

Diagram of high-level Solorigate attack chain

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

As its intricate attack chain shows, Solorigate represents a modern cyberattack conducted by highly motivated actors who have demonstrated they won’t spare resources to get to their goal. The collective intelligence about this attack shows that, while hardening individual security domains is important, defending against today’s advanced attacks necessitates a holistic understanding of the relationship between these domains and how a compromise in one environment can be a jump-off point to another.

The Microsoft Defender for Endpoint threat analytics reports published in Microsoft 365 security center enable customers to trace such cross-domain threats by providing end-to-end analysis of critical threats. In the case of Solorigate, Microsoft researchers have so far published two threat analytics reports, which continue to be updated as additional information becomes available:

In addition to providing detailed descriptions of the attack, TTPs, indicators of compromise (IoCs), and the all-up impact of the threat to the organization, the threat analytics reports empower security administrators to review organizational resilience against the attack and apply recommended mitigations. These mitigations and other recommended best practices are discussed in the succeeding sections. Customers who don’t have access to threat analytics can refer to a publicly available customer guidance.

Screenshot of Threat analytics report on Solorigate

Figure 2. Microsoft Defender for Endpoint threat analytics report on Solorigate attack

Protecting devices and servers

The attackers behind Solorigate gain initial access to target networks by activating backdoor codes inserted into the compromised SolarWinds binary. Protecting devices against this stage of the attack can help prevent the more damaging impact of the latter stages.

Ensure full visibility into your device estate by onboarding them to Microsoft Defender for Endpoint

In the ongoing comprehensive research into the complex Solorigate attack, one thing remains certain: full in-depth visibility into your devices is key to gaining insights on security posture, risk, and potential attack activity. Make sure all your devices are protected and monitored by Microsoft Defender for Endpoint.

Screenshot of status tile in device configuration

Figure 3.  Status tile in the Device configuration management tab of Microsoft Defender for Endpoint, showing onboarded devices compared to the total number of devices managed via Endpoint Manager

Identify and patch vulnerable SolarWinds Orion applications

The Solorigate attack uses vulnerable versions of the SolarWinds Orion application so we recommend that you identify devices running vulnerable versions of the application and ensure they are updated to the latest version. The threat analytics report uses insights from threat and vulnerability management to identify such devices. On the Mitigations page in Threat analytics, you can view the number of devices exposed to vulnerability ID TVM-2020-0002, which we added specifically to help with Solorigate investigations:

Screenshot of Microsoft Defender Security Center Threat analytics Mitigations page

Figure 4. The Threat analytics Mitigations page shows information on exposed devices

The new vulnerability ID TVM-2020-0002 was added to the threat and vulnerability management Weaknesses page in Microsoft Defender for Endpoint so you can easily find exposed devices that have vulnerable SolarWinds software components installed. Additional details are available in the vulnerability details pane.

Screenshot of the vulnerability detail for TVM-2020-0002

Figure 5. Threat and vulnerability management vulnerability details pane for TVM-2020-0002  

Customers can also use the software inventory page in threat and vulnerability management to view the SolarWinds Orion versions present on endpoints in your environment and whether the vulnerable versions are present. Links to the threat analytics reports are provided under the Threats column. You can then assess the footprint of a specific software in your organization and identify the impacted devices without the need to run scans across the install base.

Screenshot of threat and vulnerability management software inventory page

Figure 6. Threat and Vulnerability Management software inventory page displaying installed SolarWinds Orion software

Security recommendations are provided to update devices running vulnerable software versions.

Screenshot of threat and vulnerability management security recommendations page

Figure 7. Threat and Vulnerability Management security recommendations page

Security admins can also use advanced hunting to query, refine, and export data. The following query retrieves an inventory of the SolarWinds Orion software in your organization, organized by product name and sorted by the number of devices that have software installed:

DeviceTvmSoftwareInventoryVulnerabilities

| where SoftwareVendor == ‘solarwinds’

| where SoftwareName startswith ‘orion’

| summarize dcount(DeviceName) by SoftwareName

| sort by dcount_DeviceName desc

The following query searches threat and vulnerability management data for SolarWinds Orion software known to be affected by Solorigate:

DeviceTvmSoftwareInventoryVulnerabilities

| where CveId == ‘TVM-2020-0002’

| project DeviceId, DeviceName, SoftwareVendor, SoftwareName, SoftwareVersion

For each security recommendation you can submit a request to the IT administrator to remediate vulnerable devices. Doing this creates a security task in Microsoft Endpoint Manager (formerly Intune) that can be continuously tracked in the threat and vulnerability management Remediation page. To use this capability, you need to enable a Microsoft Endpoint Manager connection.

Screenshot of threat and vulnerability management remediation options

Figure 8. Threat and vulnerability management ‘Remediation options’ for security recommendations and ‘Remediation activities’ tracking

Implement recommended security configurations

In addition to providing vulnerability assessments, Threat and Vulnerability Management also provides security recommendation guidance and device posture assessment that help mitigate this attack. These recommendations use vulnerability data that is also present in the Solorigate threat analytics report.

Screenshot of threat analytics mitigations page

Figure 9. Threat analytics Mitigation page shows secure configuration recommendations for devices exposed to Solorigate

The following security recommendations are provided in response to Solorigate:

Component  Secure configuration recommendations  Attack stage
Security controls (Antivirus) Turn on real-time protection Stage 1
Security controls (Antivirus) Update Microsoft Defender Antivirus definitions to version 1.329.427.0 or later Stage 1
Security controls (Attack surface reduction) Block execution of potentially obfuscated scripts Stage 2
Security controls (Attack surface reduction) Block executable files from running unless they meet a prevalence, age, or trusted list criterion Stage 2
Security controls (Microsoft Defender SmartScreen) Set Microsoft Defender SmartScreen Microsoft Edge site and download checking to block or warn Stage 2

Applying these security controls can be accomplished using Microsoft Endpoint Manager (Intune and Configuration Manager). Refer to the following documentation for guidance on deploying and managing policies with Endpoint Manager:

Protecting on-premises and cloud infrastructure

In addition to compromising client endpoints, attackers can also activate backdoor code via the compromised SolarWinds binary installed on cloud or on-premises servers, allowing them to gain a stronger foothold in the environment.

Protect your on-premises and cloud servers

A large part of many customers’ infrastructure are virtual machines. Azure Defender helps security professionals protect cloud workloads spanning virtual machines, SQL, storage, containers, IoT, Azure network layer, Azure Key Vault, and more.

As mentioned earlier, one of the key actions that should be taken to help prevent Solorigate and similar attacks is to ensure that all devices are protected and monitored by Microsoft Defender for Endpoint. Deploying Azure Defender for Servers enables Defender for Endpoint for your virtual machines to provide comprehensive detection coverage across the Solorigate attack chain. Azure Defender’s integrated vulnerability assessment solution for Azure and hybrid machines can also help address the Solorigate attack by providing visibility into vulnerability assessment findings in Azure Security Center.

Enable additional infrastructure protection and monitoring

To help provide additional in-depth defenses against Solorigate, Azure Defender recently introduced new protection modules for Azure resources. Enabling these protections can improve your visibility into malicious activities and increase the number of Azure resources protected by Azure Defender.

Azure Defender for Resource Manager allows you to continuously monitor all Azure resource management operations and breadth in protection, which includes the ability to detect attempts to exclude known malicious files by the VM Antimalware extension and other suspicious activities that could limit antimalware protection on Azure VMs.

In addition, Azure Defender for DNS ensures that all DNS queries from Azure resources using Azure DNS, including communication with malicious domains used in the Solorigate attack, are monitored, and helps identify Solorigate activity across any of your Azure cloud resources. This helps prevent the malicious Solorigate DLL from being able to connect to a remote network infrastructure to prepare for possible second-stage payloads.

Protect your Active Directory and AD FS infrastructure

After gaining access, attackers may attempt to steal credentials, escalate privileges, and move laterally in the environment. Having complete visibility into your Active Directory, either completely on-premises or hosted in IaaS machines, is key in detecting these attacks and identifying opportunities to harden security posture to prevent them.

In hybrid environments, make sure that Microsoft Defender for Identity sensor components are deployed on all your Domain Controllers and Active Directory Federation Services (AD FS) servers. Microsoft Defender for Identity not only detects malicious attempts to compromise your environment but also builds profiles of your on-premises identities for proactive investigations and provides you with built-in security assessments. We recommend prioritizing the deployment of Microsoft Defender for Identity sensors and using the “Unmonitored domain controllers” security assessment, which lists any detected domain controllers in your environment that are unmonitored. (Note: this capability can monitor your environment only after deploying at least one sensor on a domain controller.)

Screenshot of Microsoft Cloud App security showing unmonitored domain controllers

Figure 10. Unmonitored domain controllers security assessment in the Microsoft Cloud App Security portal

Protecting Microsoft 365 cloud from on-premises attacks

The end goal of the attackers behind Solorigate is to gain access to a target organization’s cloud environment, search for accounts of interest, and exfiltrate emails. From a compromised device, they move laterally across the on-premises environment, stealing credentials and escalating privileges until they can gain the ability to create SAML tokens that they then use to access the cloud environment. Protecting cloud resources from on-premises attack can prevent the attackers from successfully achieving their long game.

Implement recommended security configurations to harden cloud posture

Further best practices and recommendations to reduce the attack surface and protect the cloud from on-premise compromise can be found in our protecting Microsoft 365 cloud from on-premises attacks blog.

Implement conditional access and session control to secure access to cloud resources

In addition to hardening the individual surfaces to disrupt and prevent the attack, extending policies to implement zero trust and access controls is key in preventing compromised or unhealthy devices from accessing corporate assets, as well as governing cloud access from compliant devices.

Enable conditional access policies

Conditional access helps you better protect your users and enterprise information by making sure that only secure users and devices have access. We recommend implementing the common recommended policies for securing access to Microsoft 365 cloud services, including on-premises applications published with Azure Active Directory (Azure AD) Application Proxy.

Additionally, you can configure user risk and device risk conditional access policies to enable access to enterprise information based on the risk level of a user or device, helping keep trusted users on trusted devices using trusted applications.

Enable real-time monitoring and session control

Directly integrated with conditional access, session controls in Microsoft Cloud App Security enable extending access decisions into the session, with real-time monitoring and control over user actions in your sanctioned apps. Implement policies to prevent data exfiltration in risky situations, including blocking or protecting downloads to risky or unmanaged devices, as well as for partner users.

Additional recommendations and best practices

Strengthen your security posture even further by reviewing all improvement actions available via Microsoft Secure Score. Secure Score helps operationalize security posture management and improve your organizational security hygiene for your production tenant. Below are some of the Secure Score improvement actions for Azure Active Directory that have a direct impact against Solorigate attack patterns:

  • Do not allow users to grant consent to unmanaged applications
  • Enable Password Hash Sync if hybrid
  • Enable policy to block legacy authentication
  • Enable self-service password reset
  • Ensure all users can complete multi-factor authentication for secure access
  • Require MFA for administrative roles
  • Turn on sign-in risk policy
  • Turn on user risk policy
  • Use limited administrative roles

In addition, you can use the identity security posture assessment feature in Microsoft Defender for Identity to identify common protection gaps that might exist in your environment. Addressing detection gaps such as the following improves your Microsoft Secure Score and improves your overall resilience to a wide range of credential theft attacks:

  • Stop entities that are exposing credentials in cleartext, including ones that are tagged as sensitive. Attackers listen to cleartext credentials being sent over the network to harvest credentials and escalate privileges. While we have no indication that this technique was used in Solorigate, this is a general attack trend that organizations must be aware of and prevent.

Screenshot of Microsoft Defender for Identity portal showing Identity Security Posture

Figure 11. Entities exposing credentials in clear text security assessment in the Microsoft Cloud App Security portal

  • Remediate accounts with unsecure attributes that could allow attackers to compromise them once an initial foothold in the environment is established.

Screenshot of Microsoft Defender for Identity showing unsecure account attributes

Figure 12. Unsecure account attributes security assessment in the Microsoft Cloud App Security portal

  • Reduce risky lateral movement paths to sensitive users. An attacker could move across devices to elevate to a more privileged role and operate deeper in your organization’s environment, as we’ve witnessed in the Solorigate attack.

Screenshot of Microsoft Defender for Identity portal showing risky lateral movement

Figure 13. Risky lateral movement paths security assessment in the Microsoft Cloud App Security portal

Multiple layers of coordinated defense against advanced cross-domain attacks

Microsoft 365 Defender and Azure Defender deliver unified, intelligent, and automated security across domains to empower organizations to gain end-to-end threat visibility, which as the Solorigate attack has shown, is a critical security capability for all organizations to have. In addition to providing comprehensive visibility and rich investigation tools, Microsoft 365 Defender and Azure Defender help you to continuously improve your security posture as a direct result of insights from collective industry research or your own investigations into attacks through configurations you can make directly in the product or in-product recommendations you can implement.

For additional information and guidance from Microsoft, refer to the following:

 

The post Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender appeared first on Microsoft Security.

Azure Active Directory empowers frontline workers with simplified and secure access

January 13th, 2021 No comments

Howdy folks,

The past year has shown us all just how critical frontline workers are to our communities and our economy. They’re the people behind the counter, in the call centers, in hospital ICUs, on the supermarket floor—doing the critical work that makes the difference in feeding our families, caring for the sick, and driving the long-tail economy. Frontline workers account for over 80 percent of the global workforce—two billion people worldwide. Yet because of high scale, rapid turnover, and fragmented processes, frontline workers often lack the tools to make their demanding jobs a little easier.

We believe identity is at the center of digital transformation and the key to democratizing technology for the entire frontline workforce including managers, frontline workers, operations, and IT. This week at the National Retail Federation (NRF) tradeshow, we announced several new features for frontline workers. Building on this announcement, I’m excited to dive into three generally available Azure Active Directory features that empower frontline workers:

1. Streamline common IT tasks with My Staff

Azure Active Directory provides the ability to delegate user management to frontline managers through the My Staff portal, helping save valuable time and reduce security risks. By enabling simplified password resets and phone management directly from the store or factory floor, managers can grant access to employees without routing the request through the helpdesk, IT, or operations.

Delegated user management in the My Staff portal

Figure 1: Delegated user management in the My Staff portal

2. Accelerate onboarding with simplified authentication

My Staff also enables frontline managers to register their team members’ phone numbers for SMS sign-in. In many verticals, frontline workers maintain a local username and password—a cumbersome, expensive, and error-prone solution. When IT enables authentication using SMS sign-in, frontline workers can log in with single sign-on (SSO) for Microsoft Teams and other apps using just their phone number and a one-time passcode (OTP) sent via SMS. This makes signing in for frontline workers simple and secure, delivering quick access to the apps they need most.

Showing SMS sign-in on two devices

Figure 2: SMS sign-in

Additional layers of Conditional Access enable you to control who is signing in using SMS, allowing for a balance of security and ease of use.

3. Improve security for shared devices

Many companies use shared devices so frontline workers can do inventory management and point-of-sale transactions—without the IT burden of provisioning and tracking individual devices. With shared device sign out, it’s easy for a firstline worker to securely sign out of all apps and web browsers on any shared device before handing it back to a hub or passing it off to a teammate on the next shift. You can choose to integrate this capability into all your line-of-business iOS and Android apps using the Microsoft Authentication Library.

Shared device sign-out screen

Figure 3: Shared device sign-out screen

Additionally, you can use Microsoft Endpoint Manager to set up and customize how frontline workers use shared devices, with three new preview features for provisioning, setting up device-based Conditional Access policies, and customizing the sign-in experience with Managed Home Screen.

Looking ahead

Working in partnership with our customers, we’re committed to bringing you purpose-built frontline capabilities that deliver secure identity and access that is tailored to your needs and environment. We’ll continue to innovate in 2021, adding features that simplify work, bring people together, and help organizations of all sizes achieve more.

To learn more about Microsoft Identity solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @AzureAD and @MSFTSecurity for the latest news and updates on cybersecurity.

The post Azure Active Directory empowers frontline workers with simplified and secure access appeared first on Microsoft Security.

Categories: Azure Security, cybersecurity Tags:

Security Update Guide Supports CVEs Assigned by Industry Partners

January 13th, 2021 No comments

Hi Folks, This month we are introducing a new data element for each CVE in the Security Update Guide, called Assigning CNA.  First let me back up a bit and give some information about the CVE program. The purpose of a CVE is to uniquely identify a cybersecurity vulnerability.  The CVE program was started back …

Security Update Guide Supports CVEs Assigned by Industry Partners Read More »

Building Faster AMD64 Memset Routines

January 11th, 2021 No comments

Over the past several years, Microsoft has rolled out several changes that result in more memory being zeroed. These mitigations include: The InitAll mitigation which zeros most stack variables Switching most Microsoft kernel code over to the ExAllocatePool2/ExAllocatePool3 API’s which zero memory by default. Where possible the compiler will unroll calls to memset. This means …

Building Faster AMD64 Memset Routines Read More »

New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely

January 11th, 2021 No comments

VBS and HVCI-enabled devices help protect from advanced attacks

Escalation of privilege attacks are a malicious actor’s best friend, and they often target sensitive information stored in memory. These kinds of attacks can turn a minor user mode compromise into a full compromise of your OS and device. To combat these kinds of attacks, Microsoft developed virtualization-based security (VBS) and Hypervisor-protected code integrity (HVCI, also commonly referred to as memory integrity). VBS and HVCI use the power of hardware capabilities like virtualization to provide better protection against common and sophisticated malware by performing sensitive security operations in an isolated environment.

Today, Microsoft announced that the new Surface Pro 7+ for Business will ship with these Windows enhanced hardware security features enabled out of the box to give customers even stronger security that is built-in and turned on by default. The Surface Pro 7+ for Business joins existing recently shipped devices like the Surface Book 3, Surface Laptop Go, and the Surface Pro X in enabling VBS and HVCI by default.

Surface enables added security features by default to combat common threats

Surface devices are used by customers across a variety of mission critical scenarios – from collaborating in Office on important documents to Microsoft Teams calls with coworkers across the globe. Providing robust protection against the latest malware and ransomware is a critical goal for Surface as customers expect that their devices and data can withstand common attacks. To meet this customer need, Surface has worked diligently across multiple hardware platforms to enable VBS and HVCI by default on capable new Surface models, including the Surface Book 3 and Surface Laptop Go, to provide the latest security protections consistently across different form factors and price points available to customers.

VBS and HVCI create and isolate a region of memory from the normal operating system using hardware virtualization capabilities. This security capability can stop most escalation of privilege attacks. The security subsystems running in the isolated environment provided by the hypervisor can help enforce HVCI protections, including preventing kernel memory pages from being both writeable and executable.

VBS provides significant security gains against practical attacks including several we saw last year, including human-operated ransomware attacks like RobbinHood and sophisticated malware attacks like Trickbot, which employ kernel drivers and techniques that can be mitigated by HVCI. Our research shows that there were 60% fewer active malware reports from machines reporting detections to Microsoft 365 Defender with HVCI enabled compared to systems without HVCI.  The Surface Book 3 shipped in May 2020 and the Surface Laptop Go shipped in October 2020, and users may not have noticed they are running VBS and are therefore better protected based on the work done under the hood.

The simple choice for device security

Endpoint security has always been at the core of Surface devices. Our engineering team has been using a unified approach to firmware protection and device security since 2015 through complete end-to-end ownership of hardware design, in-house firmware development, and a holistic approach to device updates and management.

For Surface, our Unified Extensible Firmware Interface (UEFI) is written in-house, continuously maintained through Windows Update, and fully managed through the cloud by Microsoft Endpoint Manager. This level of control enables enterprises to minimize risk and maximize control at the firmware level before the device even starts Windows 10. IT organizations now have the ability through the cloud to disable a camera or disable the ability to boot from USB all at the pre-boot firmware level. The result is a reduced attack vector that is critical to endpoint protection. Microsoft is making this UEFI* available broadly via open source through Project Mu on GitHub.

To protect the firmware and initial boot of your device, Surface enables Secure boot to ensure an authentic version of Windows 10 is started and make certain the firmware is as genuine as it was when it left the factory. Surface also ensures that each commercial device includes a security processor (TPM 2.0) to provide advanced encryption capabilities such as BitLocker to secure and encrypt your data and Windows Hello to enable passwordless sign-in. Each of these built-in security options helps protect your device from malicious software attacks.

With the necessary hardware and OS settings configured during manufacturing, the simple choice for customers looking for devices with advanced Windows security enabled is a Windows PC. Today, the Surface Pro 7 + for Business, Surface Book 3, Surface Laptop Go, and Surface Pro X already ship with VBS and HVCI enabled by default. Future Surface models on capable silicon will ship with these capabilities also enabled by default. Most recent Surface devices and Windows PCs from many other OEMs that have virtualization support are also capable of using these features. Customers can turn on the Memory integrity feature in the device security settings, which also automatically checks if devices are capable.

The post New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely appeared first on Microsoft Security.

Privacy breaches: Using Microsoft 365 Advanced Audit and Advanced eDiscovery to minimize impact

January 6th, 2021 No comments

GDPR, HIPPA, GLBA, all 50 U.S. States, and many countries have privacy breach reporting requirements. If an organization experiences a breach of customer or employee personal information, they must report it within the required time frame. The size and scope of this reporting effort can be massive. Using Microsoft 365 Advanced Audit and Advanced eDiscovery to better understand the scope of the breach can minimize the burden on customers as well as the financial and reputational cost to the organization.

A changing privacy landscape

In 2005 ChoicePoint, a Georgia-based financial data aggregator had a data breach of 145,000 of its customers. There were multiple security lapses and resulting penalties, but initially, only ChoicePoint’s California-based customers were required to be notified because, at the time, California, with California Senate Bill 1386, was the only state that had a mandatory privacy breach notification law.

Since that time, all 50 U.S. States have put in place mandatory privacy breach notification laws. Countries in the Americas, the Middle East, Europe, and Asia have adopted privacy standards including mandatory breach notification. Broader regulations that address this issue include California Consumer Privacy Act, China’s Personal Information Security Specification, Brazil’s Lei Geral de Proteção de Dados Pessoais (LGPD), and the European General Data Protection Regulation (GDPR). Given how often these laws are added or updated, it’s challenging for any organization to keep up. As one solution, Microsoft 365 Compliance Manager provides a set of continually updated assessments (174 and growing) to assist our customers with these standards.

A board-level business risk

The reputational and financial risk to a company from a privacy breach can be massive. For example, under California Civil Code 1798.80, which deals with the breach of personal health information, there is a penalty of up to $25,000 per patient record breached. For many standards, there are not only regulatory penalties imposed, but also the right of private action by those whose records have been breached (such as, those who have had their records breached can sue for damages, creating financial liability for a company beyond the regulatory penalties).

There are timeframes under which notification must be made. The California Code requires notification to the regulator within 15 days after unauthorized disclosure is detected. Article 33 of GDPR requires notification to the regulator within 72 hours after the organization becomes aware of the breach.

According to a list compiled by the Infosec Institute, the average cost of a data breach in 2019 was $3.9 million but can range as high as $2 billion in cases like the Equifax breach of 2017.

The reputational damage associated with a breach of customer, employee, or other stakeholders’ personal or business information can substantially reduce a company’s value.

The scope of notification (if any is needed at all) and remediation depends on understanding the scope of the breach in a timely fashion. In the absence of reliable information, companies need to make worst-case assumptions that may result in larger notifications, higher costs, and unnecessary hardship for customers and other stakeholders.

Preparation for breach

As security and compliance professionals, our priority is to avoid breaches with a defense in depth strategy including Zero Trust architecture.

Microsoft has comprehensive security solutions for Microsoft 365, as well as compliance and risk management solutions that enable our compliance pillar framework:

But we also must prepare for breaches even as we defend against them. Part of that preparation is putting our organization in a position to scope a breach and limit its impact. This means ensuring we have the data governance and signal in place before the breach happens. Security professionals know that they have to deploy solutions like Data Loss Prevention, firewalls, and encryption to defend against attacks, but they may not focus as much on having the right audit data available and retained, and visualizations and playbooks in place beforehand to scope a future breach.

Use Microsoft 365 Advanced Audit and Advanced eDiscovery to investigate compromised accounts

The Microsoft 365 Advanced Audit solution makes a range of data available that is focused on what will be useful to respond to crucial events and forensic investigations. It retains this data for one year (rather than the standard 90-day retention), with an option to extend the retention to ten years. This keeps the audit logs available to long-running investigations and to respond to regulatory and legal obligations.

These crucial events can help you investigate possible breaches and determine the scope of compromise. Advanced Audit provides the following crucial events:

There are built-in default alert policies that use the Advanced Audit data to provide situational awareness either through Microsoft 365’s own security and compliance portal, through Microsoft’s Azure Sentinel cloud-native SIEM, or through a customer’s third-party SIEM. A customer can create customized alerts to use the audit data as well.

Let’s look at how a customer might use Advanced Audit to investigate a compromised account and scope the extent of a data breach:

In an account takeover, an attacker uses a compromised user account to gain access and operate as a user. The attacker may or may not have intended to access the user’s email. If they intend to access the user’s email, they may or may not have had the chance to do so. This is especially true if the defense in-depth and situational awareness discussed above is in place. The attack may have been detected, password changed, account locked, and more.

If the user’s email has confidential information of customers or other stakeholders, we need to know if this email was accessed. We need to separate legitimate access by the mailbox owner during the account takeover from access by the attacker.

With Advanced Audit, we have this ability. Without it, a customer will have to assume all information in the user’s mailbox is now in the hands of the attacker and proceed with reporting and remediation on this basis.

The MailItemsAccessed audit data item will indicate if a mailbox item has been accessed by a mail protocol. It covers mail accessed by both sync and bind. In the case of sync access, the mail was accessed by a desktop version of the Outlook client for Windows or Mac. In bind access, the InternetMessageId of the individual message will be recorded in the audit record.

We have the ability to forensically analyze mail access via a desktop client or via Outlook Web Access.

We also need to differentiate between the mailbox owner’s legitimate access to a mail item during the attack time period and access by the attacker. We can do this by examining the audit records to see the context of the access, including the session ID and IP address used for access. We match these with other audit records and known good access by the user.

Advanced Audit retains other events like Teams Joins, File Accessed, Messages Sent, Searches Queries, and many others that can support a breach analysis.

When we’ve properly scoped the data that the attacker has had access to, we want to deep dive and inspect the content.

With Advanced eDiscovery we can collect all emails, documents, Microsoft Teams, and Yammer interactions of the account that was taken over. We can search for confidential information and metadata to identify the material in question:

There is metadata for each item which, for emails, includes InternetMessageID as well as many other items such as from, to, and when it was sent, and any Microsoft Information Protection sensitivity label.

Advanced Audit and Advanced eDiscovery are an important part of an effective security risk and compliance strategy. These Microsoft 365 native tools allow our customers to understand the true scope of a breach. It has the potential to substantially reduce or eliminate the reporting requirements stemming from a compromised account. Advanced Audit can reduce the financial and reputational damage to a company, its customers, employees, partners, and other stakeholders.

To learn more about Microsoft Security solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.


This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. This document is not intended to communicate legal advice or a legal or regulatory compliance opinion. Each customer’s situation is unique, and legal and regulatory compliance should be assessed in consultation with their legal counsel.

The post Privacy breaches: Using Microsoft 365 Advanced Audit and Advanced eDiscovery to minimize impact appeared first on Microsoft Security.

The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 1

January 5th, 2021 No comments

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the first post of our new Voice of the Community blog series, Microsoft Product Marketing Manager Natalia Godyla talks with Jake Williams, Founder of Rendition Infosec. In part one of this blog Jake shares his insights on the 2020 threat landscape—who to watch for and why—and how to think about red and blue teaming within your organization.

Looking back at the threat landscape of 2020, what stands out?  

The biggest thing that stands out has to be the continued ransomware advances. With IANS, I actually coined the term ransomware 2.0 in early 2019. We were trying to differentiate between the drive-by ransomware attacks and what I call the more APT-style ransomware attacks, where they’re doing lateral movement and actively targeting backups before encryption. Disaster recovery (DR) plans work for the former but really not the latter because the latter cases are actively targeting disaster recovery infrastructure. What I saw this year was just a lot of advancement in attacks.

The second thing is that the number of different groups that are using that commodity malware has definitely gone up. They’re using that commodity malware to get back into orbit for initial access into a network. We’re seeing a lot more of that, like TrickBot. Cybersecurity professionals I’m talking to say, “the TrickBot takedown” but it was an interruption, not a takedown, unlike other malware and botnets in the past that have been wiped out. DNSChanger is a good example. DNSChanger was cut off at the knees but not TrickBot. This is a flesh wound.

We’re seeing a lot more of this commodity malware being used as an entryway. This is the stuff that a lot of folks, myself included, have been talking about for years. This is always a risk. You can’t just say, “Don’t worry, Microsoft Defender Antivirus caught and quarantined it so we’re good now.” From maybe mid-September on, it’s been even more viral than the rest of the year put together. It’s really accelerating, too.

What critical threat groups should security teams be actively monitoring? 

The week before last, I was in a dark web forum and an account that I and a number of other folks in the intel community assess with moderate confidence to be associated with Ryuk was advertising for help with their ransomware operations. They’re looking for experienced ransomware operators, and they have a whole set of criteria, including that they want to see a history that you’re getting an average $400,000 payout. They haven’t asked for help in the past. They have more work than they can handle. That gives you an idea of scope, and I think it comes from the commodity malware. Before now, I haven’t seen large, established ransomware groups advertising for help with their operations. If they thought those accesses were going to last forever, they wouldn’t worry about recruiting others right now.

There’s definitely a place for dark web monitoring but most organizations don’t have the maturity level where they’re getting a good return on that investment. Because even if I tell you that cybercrime groups are recruiting, how do I take that and turn that into something actionable that will help with detection and prevention? I don’t know how much any guidance I provide will help if you’re not patching domain controllers.

From a cybercrime standpoint, we’re seeing a lot more lateral movement being critical to cybercriminals’ attacks. We’re not seeing as many point attacks where they land a phishing email and bam, they’ve extracted a bunch of data and gone. It sounds almost like a cop-out but focus on lateral movement because it kills two birds with one stone. Nation-state groups have to do a lateral movement. So do cybercrime groups to get maximum payouts. Once they’ve had a bite of that big apple, how do they ever go back? I think you’re seeing more groups spending in some cases up to six weeks in a network before they’re doing data extraction and playing a little bit of a longer game versus that immediate gratification.

Cybersecurity mixes both defensive and offensive practices to combat cybercrime. How should organizations think about red and blue teaming in their organization? Do organizations need both, and why?  

A huge majority of people who get into cybersecurity these days want to be red team. I get it. It’s sexy. Bottom line, if you’re thinking of red team as those folks who are actually attempting to penetrate your internal network, I think the number is 1 to 20, 1 to 25, or something like that compared to blue team. You need a lot less red team focus. I’m not saying that organizations where red team is similarly sized to blue don’t provide value. They definitely do, but it’s a question of could you take those same resources and plug them elsewhere and get more value? I think generally, I need a lot more defense than I need offense.

In way too many organizations that have much more balanced red and blue teams, I see a lot of red teams identifying problems that the blue team simply can’t fix from a resourcing standpoint. I also am working with organizations that have very large red teams but haven’t yet moved into hunt teaming. In those situations, I don’t know whether you put hunt under red or blue. I’m ambivalent there but the bottom line is I do need the red team, but I need them for a lot less than a lot of people use them for. I say that as an ex-government hacker; and I still do red team occasionally, but it’s just not where most organizations are going to get the most significant return on investment. I’m not trying to say red team isn’t important but generally, we need to structure significantly more blue team people than red team, and that’s just an unpopular thing for a lot of people to hear.

If you don’t have a solid blue team and have holes today in your defenses, you shouldn’t have a red team. When people say, “We need our own internal red team,” my question is, “Have you had an external red team come in and do a red team evaluation? And if you have, have you actioned those findings?” Not one of them but all of them. If the answer is no, we need to step back and figure out what we need to do. Let’s make sure that you’ve got a blue team that is functioning today and ready to roll forward with the recommendations from the red team. Separate from pragmatism, there’s also a legality issue. Knowing about something and not doing anything about it puts you in a more legally compromising position than not knowing about it at all.

That’s what we find a lot of folks with internal red teams end up with. They’ve got this red team that is basically pushing identified risks into a funnel. How much are we stuffing that funnel? How much do we need defense versus offense?

How does an organization know when to hire an internal red team? What’s the breaking point?

A lot of that depends on the reaction. How quickly are you actioning those findings? If you’re in a spot where you fix all the findings from the annual red team in two months, that’s when I would say, “Yes, without a shadow of a doubt, let’s go hire a red team.” Because that’s going to give me more of that constant churn of findings. On the other hand, if it takes you nine months to get through those findings, you’re going to have another external red team likely in a month anyway. Where’s our value there? If it takes you somewhere in the middle, a lot of it is going to depend on how much risk do we accept.

When we’re documenting where we have gaps and where we don’t, it comes down to where can I get the best return on my investment for our organization? If I still have a lot of blue team gaps, investing in red team would be throwing more gaps at blue team, which causes huge morale issues.

Keep an eye for the second part of the interview as Jake Williams shares best practices on how to structure and evolve red and blue teaming within your organization.

To learn more about Microsoft Security solutions visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity or on LinkedIn for the latest news and updates on cybersecurity.

The post The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 1 appeared first on Microsoft Security.

Forcepoint and Microsoft: Risk-based access control for the remote workforce

January 4th, 2021 No comments

This blog post is part of the Microsoft Intelligence Security Association (MISA) guest blog series. Learn more about MISA here.

Adopting cloud-based services as part of an organization’s digital transformation strategy is no longer optional, it’s a necessity. Last year, only 18 percent of the workforce worked remotely full-time. Today, companies have been forced to accelerate their digital transformation efforts to ensure the safety and well-being of employees. At the same time, organizations cannot afford to sacrifice productivity for the sake of security. With the massive move to online experiences and remote working, comes a new set of challenges—how do you ensure your data, your network, and your employees stay secure, wherever they are?

Forcepoint has integrated with Azure Active Directory (Azure AD) to enhance existing Conditional Access capabilities by orchestrating change in authentication policies dynamically so that every user authenticates with steps aligned to their risk score. Active sessions can be terminated upon risk score increase so that users must re-authenticate using an enhanced sequence of challenges, and users can be temporarily blocked in the case of high risk. Forcepoint risk scores, combined with Azure AD risk, are calculated based on the user’s context, such as location or IP, to help automatically and accurately prioritize the riskiest users. The joint solution enables administrators to protect critical data and leverage the power of automation to prevent data compromise and exfiltration from occurring. By combining the power of Azure AD with Forcepoint security solutions, organizations can scale a risk-adaptive approach to identity and access management and cloud application access without changing their existing infrastructure.

People are the perimeter

Before COVID-19, in our 2020 Forcepoint Cybersecurity Predictions and Trends report, we detailed the shifting emphasis to a “cloud-first” posture by public and private sector organizations alike. There was, and still is, a clear need for organizations to expand their view of network security and begin to understand that their people are the new perimeter. Today, more than ever, it is imperative for businesses to comprehend and to manage the interaction between their two most valuable assets—their people and their data.

Human-centric cybersecurity is about focusing on not just individuals, but how their behaviors evolve over time. Forcepoint risk scores are designed to continuously calculate the level of risk associated with individual behavior in the past, present, and future. Most organizations today will adopt blanket policies to improve their security posture. Even though policies for individuals may have some level of flexibility, most tend to apply policies to all users within a group—regardless of the individual risk profile. This results in unnecessarily complicated steps for low-risk users accessing common applications, and weak authentication challenges for privileged users logging into critical systems. In short, these implementations are likely frustrating your low-risk users by creating barriers to productivity and allowing high-risk users to fly under the radar.

Forcepoint’s mission is to provide enterprises with the tools needed to understand and quickly assess the risk levels of human behavior across their networks and endpoints and take automated action by implementing risk adaptive protection. We offer a portfolio of security solutions designed to quickly and continuously assess the potential of compromised user risk and automatically apply the appropriate protective measures.

Forcepoint + Azure Active Directory = Better together

Forcepoint has partnered with the Azure Active Directory team on a series of integrations designed to provide remote workers secure access to their cloud and legacy on-premise applications. Together, our integrated solutions combine the risk score calculated by Forcepoint’s Cloud Access Security Broker (CASB)—with Azure AD—to apply the appropriate conditional access policies tailored to each individual user risk.

integrated solutions combine the risk score calculated by Forcepoint’s CASB - with Azure AD- to apply the appropriate conditional access policies tailored to each individual user risk.

Learn more about the Forcepoint products that integrate with Microsoft Azure, including the technical implementation and demonstrations of how Forcepoint risk adaptive protection influences the conditional access policies of a potentially compromised user:

Give your organization the control it needs to protect critical assets and data by combining Forcepoint with the power of Azure AD today.

About Forcepoint

Forcepoint is a leading user and data protection cybersecurity company, entrusted to safeguard organizations while driving digital transformation and growth. Our solutions adapt in real-time to how people interact with networks, data, and systems. Forcepoint provides secure access solutions without compromising employee productivity. For more information, visit forcepoint.com.

Forcepoint is a member of the Microsoft Intelligent Security Association.

To learn more about the Microsoft Intelligent Security Association (MISA), visit our website where you can learn about the MISA program, product integrations, and find MISA members. Visit the video playlist to learn about the strength of member integrations with Microsoft products.

For more information about Microsoft Security Solutions, visit the Microsoft Security website. Bookmark the Security blog to keep up with our expert coverage of security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Forcepoint and Microsoft: Risk-based access control for the remote workforce appeared first on Microsoft Security.

Microsoft Internal Solorigate Investigation Update

December 31st, 2020 No comments

As we said in our recent blog, we believe the Solorigate incident is an opportunity to work together in important ways, to share information, strengthen defenses and respond to attacks. Like other SolarWinds customers, we have been actively looking for indicators of the Solorigate actor and want to share an update from our ongoing internal …

Microsoft Internal Solorigate Investigation Update Read More »

Categories: Investigation, SolarWinds, Solorigate Tags:

Using Microsoft 365 Defender to protect against Solorigate

December 28th, 2020 No comments

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 https://aka.ms/solorigate.

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 https://aka.ms/solorigate.

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:

CloudAppEvents
| 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:

CloudAppEvents
| 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 (
CloudAppEvents
| 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 (“127.0.0.1”, “::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
silentDevices
| 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 11. 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 12. Microsoft Defender for Endpoint detects usage of masquerading exploration tools

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

Figure 13. 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 14. 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
IdentityQueryEvents
| 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
IdentityLogonEvents
| 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;
IdentityQueryEvents
| 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 15. 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 16. Microsoft Defender for Endpoint detects a suspicious LDAP query being launched and an attempted AD FS private key extraction

Figure 17. 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.

ADFSDomainTrustMods

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 18. 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 19. 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.

NewAppOrServicePrincipalCredential

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.

MailItemsAccessedThrottling

let starttime = 2d;
let endtime = 1d;
CloudAppEvents
| 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.

OAuthGraphAPIAnomalies

//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) {
CloudAppEvents
| 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:

DeviceProcessEvents
| 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.

December 21st, 2020 – Solorigate Resource Center

December 22nd, 2020 No comments

Alongside our industry partners and the security community, Microsoft continues to investigate the extent of the recent nation-state attack on SolarWinds. Our goal is to provide the latest threat intelligence, Indicators of Compromise (IOC)s, and guidance across our products and solutions to help the community respond, harden infrastructure, and begin to recover from this unprecedented attack. As new information becomes available, we will make updates to this article at https://aka.ms/solorigate   Executive Summary and Background Information  …

December 21st, 2020 – Solorigate Resource Center Read More »

Categories: Uncategorized Tags:

Advice for incident responders on recovery from systemic identity compromises

December 21st, 2020 No comments

As Microsoft alongside our industry partners and the security community continues to investigate the extent of the Solorigate attack, our goal is to provide the latest threat intelligence including IOCs and guidance across our products and solutions to help the community fight back against, harden your infrastructure, and begin to recover from this attack of unprecedented scale. As new information becomes available, we will make updates to this article.

This blog will outline lessons learned from this and other incident response to date in on-premises and cloud environments. This latest guidance is for customers looking to re-establish trusted identities for credentials that are suspected of compromise by Solorigate malware.

This article is intended to give experienced incident responders some advice on techniques to consider when helping an organization respond to a suspected systemic identity compromise, like we’re seeing in some victims of the Solorigate malware, based on our experience in the field in similar scenarios. Re-establishing trust in the organization’s on-premises and cloud environments with minimal business impact requires in-depth investigation and an understanding of potential methods of persistence. While not meant to cover every possible scenario, this guidance is intended to summarize our experience with similar customer breaches and will be updated if we learn of new information that would help with successful recovery. Please review the resources referenced at the end of this article for additional information. This information is provided as-is and constitutes generalized guidance; the ultimate determination about how to apply this guidance to your IT environment and tenant(s) must consider your unique environment and needs, which each Customer is in the best position to determine.

The Solorigate investigation referenced in this guidance is ongoing at the time of publication and our teams continue to act as first responders to these attacks. As new information becomes available, we will make updates through our Microsoft Security Response Center (MSRC) blog.

Overview of the intrusion

As described in this Microsoft blog post, the hallmarks of this actor’s activity include, but are not limited to, the following techniques that are likely to result in systemic identity compromise:

  • An intrusion through malicious code in the SolarWinds Orion product. This results in the attacker gaining a foothold in the network, which the attacker can use to gain elevated credentials. Microsoft Defender now has detections for these files. Read our in-depth technical analysis of the Solorigate malware.
  • An intruder using administrative permissions (acquired through an on-premises compromise) to gain access to an organization’s trusted SAML token-signing certificate. This enables them to forge SAML tokens to impersonate any of the organization’s existing users and accounts, including highly privileged accounts.
  • Anomalous logins using the SAML tokens signed with a compromised token-signing certificate, which can be used against any on-premises resources (regardless of identity system or vendor) as well as against any cloud environment (regardless of vendor) because they have been configured to trust the certificate. An organization may miss the use of illegitimate SAML tokens because they are signed with a legitimate certificate.
  • The use of highly privileged accounts (acquired through the technique above or other means) to add illegitimate credentials to existing application service principals, enabling the attacker to call APIs with the permission assigned to that application.

Overview of response objectives

Organizations that have experienced systemic identity compromise need to start recovery by re-establishing trustworthy communications. This will enable effective triage and coordination of business operations recovery.

Many organizations have complex internal and external interdependencies. Core business processes and applications in an organization are likely to be temporarily impacted during recovery efforts until trust within your environment is re-established. Microsoft recommends that Incident Responders establish secure communications with key organizational personnel as the first step toward organizational recovery. If your investigation indicates that the attacker has used techniques outside of identity compromise at lower levels of your organizations’ infrastructure, such as hardware or firmware attacks, you will need to address those threats to reduce the risk of re-compromise.

Response objectives in approximate order:

  1. Establish secure communications for personnel key to the investigation and response effort.
  2. Investigate the environment for persistence and initial access point, while establishing continuous monitoring operations during recovery efforts.
  3. Regain and retain administrative control of your environment and remediate or block possible persistence techniques and initial access exploits.
  4. Improve posture by enabling security features and capabilities following best practice recommendations.

We recommend that incident responders review and digest the entirety of this guidance before taking action, as the specific order of actions taken to achieve the response objectives is very situational and depends heavily on the results (and completeness) of investigation and the business constraints of the specific organization. The following sections describe the incident Response techniques we recommend you consider for each of the above objectives.

Establish secure communications and productivity

Successful response requires being able to communicate without the attacker eavesdropping on your communications. Until you have achieved assurance in the privacy of your communications on your current infrastructure, use completely isolated identities and communication resources to coordinate your response and discuss topics that could potentially tip off the attacker to your investigation. Until your investigation has achieved assurance in actor eviction, we strongly recommend that you keep all incident-related comms isolated to enable you to have the element of surprise when taking remediation actions.

  • Initial one-on-one and group communications can be achieved through phone (PSTN) calling, conference bridges not connected to the corporate infrastructure, and end-to-end encrypted messaging solutions.
  • One way that many customers have established secure productivity and collaboration is to create a new Office 365 tenant which is completely isolated from the organization’s production tenant and create accounts only for the key personnel needed, and any incident response vendors or partners who need to be part of the response.
    • Make sure to follow best practices for securing this tenant, especially administrative accounts and rights by default. The new tenant should be limited on Administrative rights along with no trusts with outside applications or vendors. If you need further assistance or want information on hardening Microsoft 365, you can review the guidance here.

Investigate your environment

Once your incident responders and key personnel have a secure place to collaborate, the next step is to investigate the suspected compromised environment. Successful investigation will be a balance between getting to the bottom of every anomalous behavior to fully scope the extent of attacker activity and persistence and taking action quickly to stop any further activity on objectives by the attacker. Successful remediation requires as complete an understanding of the initial method of entry and persistence mechanisms controlled by the attacker as possible. Any persistence mechanisms missed could result in continued access by the attacker and potential for re-compromise.

  • Investigate and review cloud environment logs for suspicious actions and attacker IOCs, including:
    • Unified Audit Logs (UAL).
    • Azure Active Directory (Azure AD) logs.
    • Active Directory logs.
    • Exchange on-prem logs.
    • VPN logs.
    • Engineering systems logging.
    • Antivirus and endpoint detection logging.
  • Review endpoint audit logs for changes from on-premises for actions including, but not limited to, the following:
    • Group membership changes.
    • New user account creation.
    • Delegations within Active Directory.
    • Along with other typical signs of compromise or activity.
  • Review Administrative rights in your environments
    • Review privileged access in the cloud and remove any unnecessary permissions. Implement Privileged Identity Management (PIM); setup Conditional Access policies to limit administrative access during hardening.
    • Review privileged access on-premise and remove unnecessary permissions. Reduce membership of built-in groups, verify Active Directory delegations, harden Tier 0 environment, and limit who has access to Tier 0 assets.
    • Review all Enterprise Applications for delegated permissions and consent grants that allow (sample script to assist):
      • Modification of privileged users and roles.
      • Reading or accessing all mailboxes.
      • Sending or forwarding email on behalf of other users.
      • Accessing all OneDrive or SharePoint sites content.
      • Adding service principals that can read/write to the Directory.
    • Review access and configuration settings for the following Office 365 products:
      • SharePoint Online Sharing
      • Teams
      • PowerApps
      • OneDrive for Business
    • Review user accounts
      • Review and remove guest users that are no longer needed.
      • Review email configurations using Hawk or something similar.
        • Delegates
        • Mailbox folder permissions
        • ActiveSync mobile device registrations
        • Inbox Rules
        • Outlook on the Web Options
      • Validate that both MFA and self-service password reset (SSPR) contact information for all users is correct.

You may find that one or more of the logging sources above are data sources that the organization does not currently include in its security program. Some of them, especially the logging available in the cloud, are available only if configured and we recommend that you configure them as soon as possible to enable both the detections in the next section and forensics review of logs going forward. Make sure to configure your log retention to support your organization’s investigation goals going forward and retain evidence, if needed for legal, regulatory, or insurance purposes.

Establish continuous monitoring

There are many ways to detect activity associated with this campaign. Exactly how your organization will detect attacker behavior depends on which security tools you have available, or choose to deploy in response. Microsoft has provided examples publicly for some of the core security products and services that we offer and are continually updating those documents as new threat intelligence is identified related to this attacker. If you use other vendor’s products, review your vendor’s recommendations, and review the Microsoft documentation below to understand the detection techniques if you need to implement analogous detections in your environment on your own.

For readers using Azure Sentinel in their environments, review SolarWinds Post-Compromise Hunting guidance.

For readers using Microsoft Defender for Endpoint, review our guidance here, and review Microsoft Defender Antivirus guidance.

Azure Active Directory sign-ins

You can view this information from the Azure Active Directory Sign-in blade by selecting an appropriate time window and then downloading the report as either a CSV or JSON file. NOTE: You can download interactive, as well as non-interactive, sign-in reports via this interface. Once you have downloaded the results, look for the value “MFA requirement satisfied by claim in the token” in the “MFA result” field.

You can also use the Get-AzureADAuditSignInLogs cmdlet (see the details here) and filter the results to only return entries that match this field value, as seen in this example:

Get-AzureADAuditSignInLogs -All:$true -Filter "createdDateTime gt <startdate> and createdDateTime lt <enddate>"  | where {$_.Status.AdditionalDetails -eq "MFA requirement satisfied by claim in the token"} | select-object CreatedDateTime, IpAddress,UserAgent, ResourceDisplayName, CorrelationId, RequestId, UserPrincipalName -ExpandProperty Status

If your ADFS environment is configured to send a claim for MFA being satisfied, this may not be a strong signal. However, for many organizations using ADFS, and this claim is not included per your configuration; in those cases, the presence of this claim may be a strong indicator of attacker activity. You may also wish to add additional filters or conditions in the where clause to further improve your signal to noise ratio, such as only surfacing results from domains that are federated.

If suspicious sign-ins are detected, you can further pivot your investigation based on IP addresses identified, user accounts identified, and/or other indicators such as the UserAgent string and client operating system observed, if based on your knowledge of your environment these appear to be strong indicators.

Analysis of risky sign-in events

In some cases, Azure Active Directory and its Identity Protection platform will generate risk events associated with the use of attacker generated SAML tokens. These can be labeled as “unfamiliar properties”, “anonymous IP address”, “impossible travel” and the other risk events as described here.

Closely analyze all risk events associated with accounts that have administrative privileges. It is also important to analyze events that have been dismissed or remediated as some of these actions are done automatically. For example, a risk event for an anonymous IP address can be automatically remediated because the user passed MFA.

Detection of domain authentication properties

The attacker may attempt to manipulate the domain authentication policies which are recorded in the Azure Active Directory Audit Logs and reflected in the Unified Audit Log. An attacker who has gained access with Global Administrator privileges can modify the domains that are federated and/or trusted. Review any events associated with “Set domain authentication” in either the Unified Audit Log, Azure AD Audit Logs, and/or your SIEM environment. Verify that all activities were expected and planned.

The sample command below returns the entries from the Unified Audit Log which were associated with manipulation of domain authentication settings.

Search-UnifiedAuditLog -StartDate <startdate> -EndDate <enddate> -ResultSize 5000 -Operations "Set domain authentication"

Detection of credentials to a service principal associated with an OAuth application

If the attacker has gained control of a credential with sufficient privileges, the attack pattern includes locating an application that has been granted the ability to access any user’s e-mail in the organization and adding attacker controlled credentials to that application. In some cases, the attacker has modified these applications granting them additional rights such as access to all e-mail in the organization.

The following are operations that would be consistent with attacker behavior:

  • Add service principal credentials.
  • Update application- certificates and secrets management.
  • Update service principal.
  • Add app role assignment to service principal.
  • Add app role assignment grant to user.
  • Add OAuth2PermissionGrant.

Detection e-mail access by applications

Detection of access to e-mail by applications can be achieved using the Advanced Auditing capabilities of Office 365. Access to messages inside of Office 365 is audited via the MailItemsAccessed capability.

Analyze events in the Unified Audit Log for the Operation of MailItemsAccessed.

Detection of non-interactive sign-ins to service principals

Azure Active Directory in the Sign-In reports provides reporting of non-interactive sign-ins using credentials issued to service principals (as was observed in this attack). Analyzing the sign-ins for service principals reports can provide valuable data such as the IP Address the attacker was using to access the applications for e-mail access.

If there is evidence found that uncovers administrative permissions acquired through the on-premises compromise to gain access to your organization’s global administrator account and/or trusted SAML token signing certificate, Microsoft recommends taking the following immediate actions:

Remediate and retain administrative control

Regaining and retaining administrative control of your environment

If your investigation has identified that the attacker has administrative control in the organization’s cloud environment and/or on-prem, it’s critical to regain control in such a way as to ensure that the attacker isn’t persistent. Exactly which steps you will take depend both on what persistence you discovered in your investigation, and your level of confidence in the completeness of that investigation and discovery of all possible methods of entry and persistence. While it is possible to regain control with high confidence, even in the face of an incomplete investigation, doing so requires significant impact to business operations, so most organizations choose to remediate based on the results of the investigation in our experience.

We recommend you consider the following steps when building your administrative control recovery plan, but the exact order and timing should be planned based on the results of your investigation and understanding of adversary owned administrative assets and methods of persistence.

  • Ensure that any actions described here are performed from a trusted device built from a clean source, such as a privileged access workstation.
  • If the organization has lost control of its token signing certificates or federated trust the highest assurance approach is to remove trust and switch to cloud mastered identity while remediating on-prem. A detailed plan for doing so is beyond the scope of this document and requires careful planning and understanding of the business operations impacts of isolating identity. Review the Azure Active Directory guidance or key considerations.
  • Should your organization choose not to break trust while recovering administrative control on-prem, you’ll need to rotate your SAML token signing certificate once you have regained administrative control on-prem and blocked the attacker’s ability to access the signing certificate again. It’s critical that your organization follow the certificate rotation instructions below to ensure that the attacker doesn’t maintain the ability to forge tokens for your domain.

Rotation of ADFS token signing certificate

For a compromised or potentially compromised ADFS Token Signing certificate, rotating the Token Signing certificate a single time would still allow the previous Token Signing certificate to work. The rationale for this is to permit a grace period to update your Relying Party Trusts prior to expiration of the certificate during normal rotation of the signing certificate.

If instead of rolling the Token Signing Certificate your organization feels the need to replace the ADFS servers with known clean systems, you can follow steps to remove the existing ADFS from your environment and build a new one.

Delete Azure AD Cloud Provisioning agent configuration.

Should your organization decide to rotate the certificate on your current ADFS servers, follow these steps in the below order, from the ADFS server:

  1. Check to make sure that your AutoCertificateRollover is set to True.
    Get-AdfsProperties | FL AutoCert*, Certificate*
    • If it is not, you can set it with this command:
      Set-ADFSProperties -AutoCertificateRollover $true
  2. Connect to the Microsoft Online Service
    Connect-MsolService
  3. Document both your on-premise and cloud Token Signing Certificate thumbprint and expiration dates.
    Get-MsolFederationProperty -DomainName <domain>
    
  4. Replace the primary Token Signing certificate using the -Urgent switch to cause ADFS to replace the primary certificate immediately without making it a Secondary certificate.
    Update-AdfsCertificate -CertificateType Token-Signing -Urgent
  5. Create a secondary Token Signing certificate without using the -Urgent switch to allow for two on-premise Token Signing certificates, before syncing with Azure cloud.
    Update-AdfsCertificate -CertificateType Token-Signing
    
  6. Update the cloud environment with both the primary and secondary certificates on-premise to immediately remove the cloud published token signing certificate. If this step is not completed using this method you leave the potential for the old token signing certificate to still authenticate users.
    Update-MsolFederatedDomain -DomainName <domain>
     
    
  7. Verification that you completed the above steps and removed the certificate that was displayed in Step 3 above.
    Get-MsolFederationProperty -DomainName <domain>
    
  8. Revoke refresh tokens via PowerShell, information can be found here and you can also reference how to “Revoke user access in Azure Active Directory.”
    • Note: This will log users out of their phone, current webmail sessions, along with other items that are using Tokens and Refresh Tokens.

Additional cloud remediation activities to complete

  • Reset passwords on any break-glass accounts and reduce the number of break-glass accounts to the absolute minimum required.
  • We recommend that service and user accounts with Privileged access should be Cloud Only accounts and not use on-premise accounts synced or federated to Azure Active Directory.
  • Enforce Multi-Factor Authentication (MFA) across all elevated users in the tenant. We recommend enforcing MFA across all users in the tenant.
  • Implement Privileged Identity Management (PIM) and conditional access to limit administrative access.
    • For Office 365 users, implement Privileged Access Management (PAM) to limit access to sensitive capabilities (including eDiscovery, Global Admin, Account Administration, and more).
  • Review and reduce all Enterprise Applications delegated permissions or consent grants that allow such as:
    • Modification of privileged users and roles.
    • Reading, sending email, or accessing all mailboxes.
    • Accessing OneDrive, Teams, or SharePoint content.
    • Adding of Service Principals that can read/write to the Directory.
    • Application Permissions versus Delegated Access.

Additional on-premises remediation activities to complete

  • Rebuild systems that were identified as compromised by the attacker during your investigation.
  • Remove unnecessary members from Domain Admins, Backup Operators, and Enterprise Admin groups. Reference Microsoft’s Securing Privileged Access.
  • Reset passwords of all privileged accounts in the environment.
    • Privilege accounts are not limited to Built-In groups but can also be groups that are delegated access to Server Administration / Workstation Administration and other aspects of your environment.
  • Reset the krbtgt account using this script twice.
    • Note: If you are using Read-Only Domain Controllers, you will need to run the script for Read-Write Domain Controllers and Read-Only Domain Controllers.
  • After you validate that no persistence mechanisms created by the attacker exist or remain on your system, schedule a restart. This can assist with removing memory resident malware.
  • Reset each domain controller’s DSRM (Directory Services Restore Mode) password to something unique and complex.

Remediate or block persistence discovered during investigation

Remediate the persistence techniques identified in your investigation stage earlier. Investigation is an iterative process and you’ll need to balance the organizational desire to remediate as you identify anomalies and the chance that remediation will alert the attacker of your detection and cause them to react by changing techniques or creating additional persistence. For Office 365 accounts, automatically remediate known persistence techniques, if any are discovered, using the scripts described

Remediate user and service account access

Some of the user-level actions we recommend were described above already, specifically in terms of ensuring that MFA is enabled and running specific remediation scripts to clean up known persistence techniques. Here are some additional steps you should consider taking to remediate and restore user accounts:

  • Enforce conditional access based on trusted device.
    • If possible, enforce location-based conditional access that suits your organizational requirements.
  • For any user accounts suspected of being compromised, immediately reset passwords after eviction; make sure you also implement a mid-term plan to reset credentials for all accounts in your directory.
  • After credential rotation, use PowerShell to revoke refresh tokens immediately. More information can be found here and additional resources can be found at Revoke user access in an emergency in Azure Active Directory | Microsoft Docs.

Improve security posture

After a security event is a good time for organizations to reflect on their security strategy and priorities. Incident Responders are often asked to provide recommendations after an event on what investments the organization should prioritize now that it’s been faced with new threats. In addition to the recommendations documented earlier, we recommend you consider these areas of focus for your post-incident review recommendations that are responsive to the post-exploitation techniques used by this attacker and the common security posture gaps that enable them.

General security posture

  • Review Microsoft Secure Score for security fundamentals recommendations customized for the Microsoft products and services you consume.
  • Ensure that your organization has EDR and SIEM solutions in place.
  • Review Microsoft’s Enterprise access model.

Identity

  1. Review Five steps to securing your identity infrastructure and prioritize steps as appropriate for your Identity architecture.
  2. Consider migrating to Azure AD Security Defaults for your authentication policy- details can be found here.
  3. Eliminate your organization’s use of legacy authentication, if systems or applications still require it- review the guidance here.
    • As announced last year, the Exchange Team is planning to disable Basic Authentication for the EAS, EWS, POP, IMAP, and RPS protocols in the second half of 2021. As a point of clarity, Security Defaults and Authentication Policies are separate but provide complementary features. We recommend that customers use Authentication Policies to turn off Basic Authentication for a subset of Exchange Online protocols or to gradually turn off Basic Authentication across a large organization. While more details will come in future announcements, as mentioned in April, we plan to begin disabling Basic Authentication in existing tenants with no recorded usage as early as October 2020. We will provide notifications via Message Center posts before we disable Basic Authentication for any tenant.
  4. In order to help protect your ADFS/Azure AD Connect systems, beyond the ADFS guidance located, we recommend that you consider the following actions:
    • Treat your ADFS infrastructure and AD Connect infrastructure as a Tier 0 asset.
    • Restrict local administrative access to the system, including the account that is used to run the ADFS service.
      • The least privilege necessary for the account running ADFS is the Log on as a Service User Right Assignment.
    • Restrict administrative access to limited users and from limited IP address ranges by leveraging Windows Firewall policies for Remote Desktop.
      • It is recommended to set up a Tier 0 jump box or equivalent system.
    • Block all inbound SMB access to the systems from anywhere in the environment. See this resource for further details.
      • Get the Windows Firewall logs to a SIEM for historical and proactive monitoring.
    • If you are using a Service Account and your environment supports it, migrate from a Service Account to a group Managed Service Account (gMSA). If you cannot move to a gMSA, rotate the password on the Service Account to a complex password.
    • Ensure Verbose logging is enabled on your ADFS systems by executing the following commands:
Set-AdfsProperties -AuditLevel verbose
Restart-Service -Name adfssrv
Auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable

Contributors: We thank the team at FireEye for their contributions and review.

The post Advice for incident responders on recovery from systemic identity compromises appeared first on Microsoft Security.

Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect

December 18th, 2020 No comments

We, along with the security industry and our partners, continue to investigate the extent of the Solorigate attack. While investigations are underway, we want to provide the defender community with intelligence to understand the scope, impact, remediation guidance, and product detections and protections we have built in as a result.

While the full extent of the compromise is still being investigated by the security industry as a whole, in this blog we are sharing insights into the compromised SolarWinds Orion Platform DLL that led to this sophisticated attack at scale. The addition of a few benign-looking lines of code into a single DLL file spelled a serious threat to organizations using the affected product, a widely used IT administration software used across verticals, including government and the security industry. The discreet malicious codes inserted into the DLL called a backdoor composed of almost 4,000 lines of code that allowed the threat actor behind the attack to operate unfettered in compromised networks.

The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Therefore, insertion of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll likely occurred at an early stage, before the final stages of the software build, which would include digitally signing the compiled code. As a result, the DLL containing the malicious code is also digitally signed, which enhances its ability to run privileged actions—and keep a low profile.

In many of their actions, the attackers took steps to maintain a low profile. For example, the inserted malicious code is lightweight and only has the task of running a malware-added method in a parallel thread such that the DLL’s normal operations are not altered or interrupted. This method is part of a class, which the attackers named OrionImprovementBusinessLayer to blend in with the rest of the code. The class contains all the backdoor capabilities, comprising 13 subclasses and 16 methods, with strings obfuscated to further hide malicious code.

Once loaded, the backdoor goes through an extensive list of checks to make sure it’s running in an actual enterprise network and not on an analyst’s machines. It then contacts a command-and-control (C2) server using a subdomain generated partly from information gathered from the affected device, which means a unique subdomain for each affected domain. This is another way the attackers try to evade detection.

With a lengthy list of functions and capabilities, this backdoor allows hands-on-keyboard attackers to perform a wide range of actions. As we’ve seen in past human-operated attacks, once operating inside a network, adversaries can perform reconnaissance on the network, elevate privileges, and move laterally. Attackers progressively move across the network until they can achieve their goal, whether that’s cyberespionage or financial gain.

 

Figure 1. Solorigate malware infection chain

The challenge in detecting these kinds of attacks means organizations should focus on solutions that can look at different facets of network operations to detect ongoing attacks already inside the network, in addition to strong preventative protection.

We have previously provided guidance and remediation steps to help ensure that customers are empowered to address this threat. In this blog, we’ll share our in-depth analysis of the backdoor’s behavior and functions, and show why it represents a high risk for business environments. We’ll also share details of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint. In an upcoming blog, we’ll discuss protections across the broader Microsoft 365 Defender, which integrates signals from endpoints with other domains – identities, data, cloud – to provide coordinated detection, investigation, and remediation capabilities.

Where it all starts: A poisoned code library

The attackers inserted malicious code into SolarWinds.Orion.Core.BusinessLayer.dll, a code library belonging to the SolarWinds Orion Platform. The attackers had to find a suitable place in this DLL component to insert their code. Ideally, they would choose a place in a method that gets invoked periodically, ensuring both execution and persistence, so that the malicious code is guaranteed to be always up and running. Such a suitable location turns out to be a method named RefreshInternal.

Figure 2: The method infected with the bootstrapper for the backdoor

Figure 3: What the original method looks like

The modification to this function is very lightweight and could be easily overlooked—all it does is to execute the method OrionImprovementBusinessLayer.Initialize within a parallel thread, so that the normal execution flow of RefreshInternal is not altered.

Why was this method chosen rather than other ones? A quick look at the architecture of this DLL shows that RefreshInternal is part of the class SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory.InventoryManager and is invoked by a sequence of methods that can be traced back to the CoreBusinessLayerPlugin class. The purpose of this class, which initiates its execution with a method named Start (likely at an early stage when the DLL is loaded), is to initialize various other components and schedule the execution of several tasks. Among those tasks is Background Inventory, which ultimately starts the malicious code.

Figure 4. The inserted malicious code runs within a parallel thread

The functionality of the backdoor resides entirely in the class OrionImprovementBusinessLayer, comprising 13 subclasses and 16 methods. Its name blends in with the rest of the legitimate code. The threat actors were savvy enough to avoid give-away terminology like “backdoor”, “keylogger”, etc., and instead opted for a more neutral jargon. At first glance, the code in this DLL looks normal and doesn’t raise suspicions, which could be part of the reason why the insertion of malicious code was undetected for months, especially if the code for this DLL was not frequently updated.

To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.

Figure 5: Example of obfuscated strings

Initial reconnaissance

The Initialize method is the de facto execution entry point of the backdoor. It carries out several checks to verify that it is running in a real victim’s environment:

  • It verifies that the process hosting the malicious DLL is named businesslayerhost.exe
  • It checks that the last write-time of the malicious DLL is at least 12 to 14 days earlier
  • It delays execution by random amounts of time
  • It verifies that the domain name of the current device meets the following conditions:
    • The domain must not contain certain strings; the check for these strings is implemented via hashes, so at this time the domain names that are block-listed are unknown
    • The domain must not contain “solarwinds”
    • The domain must not match the regular expression (?i)([^a-z]|^)(test)([^a-z]|$), or in simpler terms, it must not look like a test domain
  • It checks that there are no running processes related to security-related software (e.g., Windbg, Autoruns, Wireshark)
  • It checks that there are no drivers loaded from security-related software (e.g., sys)
  • It checks that the status of certain services belonging to security-related software meets certain conditions (e.g., windefend, sense, cavp)
  • It checks that the host “api.solarwinds.com” resolves to an expected IP address

If any of these checks fail, the backdoor terminates. All these inspections are carried out to avoid exposing the malicious functionality to unwanted environments, such as test networks or machines belonging to SolarWinds.

The backdoor

After the extensive validation described above, the backdoor enters its main execution stage. At its core, the backdoor is a very standard one that receives instructions from the C2 server, executes those instructions, and sends back information. The type of commands that can be executed range from manipulating of registry keys, to creating processes, and deleting files, etc., effectively providing the attackers with full access to the device, especially since it’s executing from a trusted, signed binary.

In its first step, the backdoor initiates a connection to a predefined C2 server to report some basic information about the compromised system and receive the first commands. The C2 domain is composed of four different parts: three come from strings that are hardcoded in the backdoor, and one component is generated dynamically based on some unique information extracted from the device. This means that every affected device generates a different subdomain to contact (and possibly more than one). Here’s an example of a generated domain:

Figure 6: Dynamically generated C2 domain

The dynamically generated portion of the domain is the interesting part. It is computed by hashing the following data:

  • The physical address of the network interface
  • The domain name of the device
  • The content of the MachineGuid registry value from the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography

The backdoor also generates a pseudo-random URI that is requested on the C2 domain. Like the domain, the URI is composed using a set of hardcoded keywords and paths, which are chosen partly at random and partly based on the type of HTTP request that is being sent out. Possible URIs that can be generated follow these formats:

  • pki/crl/<random components>.crl, where <random components> can be numbers and one of the following strings:
    • “-root”
    • “-cert”
    • “-universal_ca”
    • “-ca”
    • “-primary_ca”
    • “-timestamp”
    • “-global”
    • “-secureca”
  • fonts/woff/<random components>-webfont<random component>.woff2 or fonts/woff/<random components>.woff2, where the <random components> can be numbers and one or more of the following strings:
    • “Bold”
    • “BoldItalic”
    • “ExtraBold”
    • “ExtraBoldItalic”
    • “Italic”,
    • “Light”
    • “LightItalic”
    • “Regular”
    • “SemiBold”
    • “SemiBoldItalic”
    • “opensans”
    • “noto”
    • “freefont”
    • “SourceCodePro”
    • “SourceSerifPro”
    • “SourceHanSans”
    • “SourceHanSerif”
  • swip/upd/<random components>, where <random components> can be one or more of the following strings:
    • “SolarWinds”
    • “.CortexPlugin”
    • “.Orion”
    • “Wireless”
    • “UI”
    • “Widgets”
    • “NPM”
    • “Apollo”
    • “CloudMonitoring”
    • “Nodes”,
    • “Volumes”,
    • “Interfaces”,
    • “Components”
  • swip/Upload.ashx
  • swip/Events

Here are examples of final URLs generated by the backdoor:

  • hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml
  • hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-2[.]avsvmcloud[.]com /pki/crl/492-ca[.]crl
  • hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com /fonts/woff/6047-freefont-ExtraBold[.]woff2

Finally, the backdoor composes a JSON document into which it adds the unique user ID described earlier, a session ID, and a set of other non-relevant data fields. It then sends this JSON document to the C2 server.

Figure 7: Example of data generated by the malware

If the communication is successful, the C2 responds with an encoded, compressed buffer of data containing commands for the backdoor to execute. The C2 might also respond with information about an additional C2 address to report to. The backdoor accepts the following commands:

  • Idle
  • Exit
  • SetTime
  • CollectSystemDescription
  • UploadSystemDescription
  • RunTask
  • GetProcessByDescription
  • KillTask
  • GetFileSystemEntries
  • WriteFile
  • FileExists
  • DeleteFile
  • GetFileHash
  • ReadRegistryValue
  • SetRegistryValue
  • DeleteRegistryValue
  • GetRegistrySubKeyAndValueNames
  • Reboot
  • None

In a nutshell, these commands allow the attackers to run, stop, and enumerate processes; read, write, and enumerate files and registry keys; collect and upload information about the device; and restart the device, wait, or exit. The command CollectSystemDescription retrieves the following information:

  • Local Computer Domain name
  • Administrator Account SID
  • HostName
  • Username
  • OS Version
  • System Directory
  • Device uptime
  • Information about the network interfaces

Resulting hands-on-keyboard attack

Once backdoor access is obtained, the attackers follow the standard playbook of privilege escalation exploration, credential theft, and lateral movement hunting for high-value accounts and assets. To avoid detection, attackers renamed Windows administrative tools like adfind.exe which were then used for domain enumeration.

C:\Windows\system32\cmd.exe /C csrss.exe -h breached.contoso.com -f (name=”Domain Admins”) member -list | csrss.exe -h breached.contoso.com -f objectcategory=* > .\Mod\mod1.log

Lateral movement was observed via PowerShell remote task creation, as detailed by FireEye and Volexity:

$scheduler = New-Object -ComObject (“Schedule.Service”);$scheduler.Connect($env:COMPUTERNAME);$folder = $scheduler.GetFolder(“\Microsoft\Windows\SoftwareProtectionPlatform”);$task = $folder.GetTask(“EventCacheManager”);$definition = $task.Definition;$definition.Settings.ExecutionTimeLimit = “PT0S”;$folder.RegisterTaskDefinition($task.Name,$definition,6,”System”,$null,5);echo “Done” C:\Windows\system32\cmd.exe /C schtasks /create /F /tn “\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager” /tr “C:\Windows\SoftwareDistribution\EventCacheManager.exe” /sc ONSTART /ru system /S [machine_name]

Persistence is achieved via backdoors deployed via various techniques:

  1. PowerShell:

Powershell -nop -exec bypass -EncodedCommand

The –EncodedCommand, once decoded, would resemble:

Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\windows\idmu\common\ypprop.dll _XInitImageFuncPtrs’ -ComputerName WORKSTATION

  1. Rundll32:

C:\Windows\System32\rundll32.exe C:\Windows\Microsoft.NET\Framework64\[malicious .dll file], [various exports]

With Rundll32, each compromised device receives a unique binary hash, unique local filesystem path, pseudo-unique export, and unique C2 domain.

The backdoor also allows the attackers to deliver second-stage payloads, which are part of the Cobalt Strike software suite. We continue to investigate these payloads, which are detected as Trojan:Win32/Solorigate.A!dha, as the situation continues to unfold.

Microsoft Defender for Endpoint product and hardening guidance

Supply chain compromise continues to be a growing concern in the security industry. The Solorigate incident is a grave reminder that these kinds of attacks can achieve the harmful combination of widespread impact and deep consequences for successfully compromised networks. We continue to urge customers to:

  • Isolate and investigate devices where these malicious binaries have been detected
  • Identify accounts that have been used on the affected device and consider them compromised
  • Investigate how those endpoints might have been compromised
  • Investigate the timeline of device compromise for indications of lateral movement

Hardening networks by reducing attack surfaces and building strong preventative protection are baseline requirements for defending organizations. On top of that, comprehensive visibility into system and network activities drive the early detection of anomalous behaviors and potential signs of compromise. More importantly, the ability to correlate signals through AI could surface more evasive attacker activity.

Microsoft Defender for Endpoint has comprehensive detection coverage across the Solorigate attack chain. These detections raise alerts that inform security operations teams about the presence of activities and artifacts related to this incident. Given that this attack involves the compromise of legitimate software, automatic remediation is not enabled to prevent service interruption. The detections, however, provide visibility into the attack activity. Analysts can then use investigation and remediation tools in Microsoft Defender Endpoint to perform deep investigation and additional hunting.

Microsoft 365 Defender provides visibility beyond endpoints by consolidating threat data from across domains – identities, data, cloud apps, as well as endpoints – delivering coordinated defense against this threat. This cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively resolve whole attack chains. Security operations teams can then hunt using this rich threat data and gain insights for hardening networks from compromise.

Figure 8. Microsoft Defender for Endpoint detections across the Solorigate attack chain

Several Microsoft Defender for Endpoint capabilities are relevant to the Solorigate attack:

Next generation protection

Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines malware, even if the process is running.

Detection for backdoored SolarWinds.Orion.Core.BusinessLayer.dll files:

Detection for Cobalt Strike fragments in process memory and stops the process:

Detection for the second-stage payload, a cobalt strike beacon that might connect to infinitysoftwares[.]com.

Detection for the PowerShell payload that grabs hashes and SolarWinds passwords from the database along with machine information:

Figure 9. Microsoft Defender for Endpoint prevented malicious binaries

Endpoint detection and response (EDR)

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate threat activity on your network:

  • SolarWinds Malicious binaries associated with a supply chain attack
  • SolarWinds Compromised binaries associated with a supply chain attack
  • Network traffic to domains associated with a supply chain attack

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate the possibility that the threat activity in this report occurred or might occur later. These alerts can also be associated with other malicious threats.

  • ADFS private key extraction attempt
  • Masquerading Active Directory exploration tool
  • Suspicious mailbox export or access modification
  • Possible attempt to access ADFS key material
  • Suspicious ADFS adapter process created

Figure 10. Microsoft Defender for Endpoint detections of suspicious LDAP query being launched and attempted ADFS private key extraction

Figure 11. Microsoft Defender for Endpoint alert description and recommended actions for possible attempt to access ADFS key material

Our ability to deliver these protections through our security technologies is backed by our security experts who immediately investigated this attack and continue to look into the incident as it develops. Careful monitoring by experts is critical in this case because we’re dealing with a highly motivated and highly sophisticated threat actor. In the same way that our products integrate with each other to consolidate and correlate signals, security experts and threat researchers across Microsoft are working together to address this advanced attack and ensure our customers are protected.

Threat analytics report

We published a comprehensive threat analytics report on this incident. Threat analytics reports provide technical information, detection details, and recommended mitigations designed to empower defenders to understand attacks, assess its impact, and review defenses.

Figure 12. Threat analytics report on the Solorigate attack

Advanced hunting

Microsoft 365 Defender and Microsoft Defender for Endpoint customers can run advanced hunting queries to hunt for similar TTPs used in this attack.

Malicious DLLs loaded into memory

To locate the presence or distribution of malicious DLLs loaded into memory, run the following query

DeviceImageLoadEvents | where SHA1 in (“d130bd75645c2433f88ac03e73395fba172ef676″,”1acf3108bf1e376c8848fbb25dc87424f2c2a39c”,”e257236206e99f5a5c62035c9c59c57206728b28″,”6fdd82b7ca1c1f0ec67c05b36d14c9517065353b”,”2f1a5a7411d015d01aaee4535835400191645023″,”bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387″,”16505d0b929d80ad1680f993c02954cfd3772207″,”d8938528d68aabe1e31df485eb3f75c8a925b5d9″,”395da6d4f3c890295f7584132ea73d759bd9d094″,”c8b7f28230ea8fbf441c64fdd3feeba88607069e”,”2841391dfbffa02341333dd34f5298071730366a”,”2546b0e82aecfe987c318c7ad1d00f9fa11cd305″,”e2152737bed988c0939c900037890d1244d9a30e”) or SHA256 in (“ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6″,”dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b”,”eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed”,”ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c”,”019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134″,”c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77″,”0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589″,”e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d”,”20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9″,”2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d”,”a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d”,”92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690″,”a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2″,”cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6″)

Malicious DLLs created in the system or locally

To locate the presence or distribution of malicious DLLs created in the system or locally, run the following query

DeviceFileEvents | where SHA1 in (“d130bd75645c2433f88ac03e73395fba172ef676″,”1acf3108bf1e376c8848fbb25dc87424f2c2a39c”,”e257236206e99f5a5c62035c9c59c57206728b28″,”6fdd82b7ca1c1f0ec67c05b36d14c9517065353b”,”2f1a5a7411d015d01aaee4535835400191645023″,”bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387″,”16505d0b929d80ad1680f993c02954cfd3772207″,”d8938528d68aabe1e31df485eb3f75c8a925b5d9″,”395da6d4f3c890295f7584132ea73d759bd9d094″,”c8b7f28230ea8fbf441c64fdd3feeba88607069e”,”2841391dfbffa02341333dd34f5298071730366a”,”2546b0e82aecfe987c318c7ad1d00f9fa11cd305″,”e2152737bed988c0939c900037890d1244d9a30e”) or SHA256 in (“ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6″,”dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b”,”eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed”,”ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c”,”019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134″,”c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77″,”0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589″,”e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d”,”20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9″,”2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d”,”a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d”,”92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690″,”a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2″,”cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6″)

SolarWinds processes launching PowerShell with Base64

To locate SolarWinds processes spawning suspected Base64-encoded PowerShell commands, run the following query 

DeviceProcessEvents| where InitiatingProcessFileName =~ “SolarWinds.BusinessLayerHost.exe”| where FileName =~ “powershell.exe”// Extract base64 encoded string, ensure valid base64 length| extend base64_extracted = extract(‘([A-Za-z0-9+/]{20,}[=]{0,3})’, 1, ProcessCommandLine)| extend base64_extracted = substring(base64_extracted, 0, (strlen(base64_extracted) / 4) * 4)| extend base64_decoded = replace(@’\0′, ”, make_string(base64_decode_toarray(base64_extracted)))//| where notempty(base64_extracted) and base64_extracted matches regex ‘[A-Z]’ and base64_extracted matches regex ‘[0-9]’

SolarWinds processes launching CMD with echo

To locate SolarWinds processes launching CMD with echo,  run the following query 

DeviceProcessEvents| where InitiatingProcessFileName =~ “SolarWinds.BusinessLayerHost.exe”| where FileName == “cmd.exe” and ProcessCommandLine has “echo”

C2 communications

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceEvents| where ActionType == “DnsQueryResponse” //DNS Query Responseand AdditionalFields has “.avsvmcloud”

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceNetworkEvents| where RemoteUrl contains ‘avsvmcloud.com’| where InitiatingProcessFileName != “chrome.exe”| where InitiatingProcessFileName != “msedge.exe”| where InitiatingProcessFileName != “iexplore.exe”| where InitiatingProcessFileName != “firefox.exe”| where InitiatingProcessFileName != “opera.exe”

Find SolarWinds Orion software in your enterprise

To search for Threat and Vulnerability Management data to find SolarWinds Orion software organized by product name and ordered by how many devices the software is installed on, run the following query 

DeviceTvmSoftwareInventoryVulnerabilities| where SoftwareVendor == ‘solarwinds’| where SoftwareName startswith ‘orion’| summarize dcount(DeviceName) by SoftwareName| sort by dcount_DeviceName desc

ADFS adapter process spawning

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

 

Appendix

MITRE ATT&CK techniques observed

This threat makes use of attacker techniques documented in the MITRE ATT&CK framework.

Initial Access

T1195.001 Supply Chain Compromise

Execution

T1072 Software Deployment Tools

Command and Control

T1071.004 Application Layer Protocol: DNS

T1017.001 Application Layer Protocol: Web Protocols

T1568.002 Dynamic Resolution: Domain Generation Algorithms

T1132 Data Encoding

Persistence

T1078 Valid Accounts 

Defense Evasion

T1480.001 Execution Guardrails: Environmental Keying

T1562.001 Impair Defenses: Disable or Modify Tools

Collection

T1005 Data From Local System 

Additional malware discovered

In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor. The malware consists of a small persistence backdoor in the form of a DLL file named App_Web_logoimagehandler.ashx.b6031896.dll, which is programmed to allow remote code execution through SolarWinds web application server when installed in the folder “inetpub\SolarWinds\bin\”. Unlike Solorigate, this malicious DLL does not have a digital signature, which suggests that this may be unrelated to the supply chain compromise.  Nonetheless, the infected DLL contains just one method (named DynamicRun), that can receive a C# script from a web request, compile it on the fly, and execute it.

Figure 13: Original DLL

Figure 14: The malicious addition that calls the DynamicRun method

This code provides an attacker the ability to send and execute any arbitrary C# program on the victim’s device. Microsoft Defender Antivirus detects this compromised DLL as Trojan:MSIL/Solorigate.G!dha.

The post Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect appeared first on Microsoft Security.

Categories: cybersecurity Tags:

Collaborative innovation on display in Microsoft’s insider risk management strategy

December 17th, 2020 No comments

The disrupted work environment, in which enterprises were forced to find new ways to enable their workforce to work remotely, changed the landscape for operations as well as security. One of the top areas of concern is effectively managing insider risks, a complex undertaking even before the pandemic, and even more so in the new remote or hybrid work environment.

Because its scope goes beyond security, insider risk management necessitates diverse perspectives and thus inherently requires collaboration among key stakeholders in the organization. At Microsoft, our insider risk management strategy was built on insights from legal, privacy, and HR teams, as well as security experts and data scientists, who use AI and machine learning to sift through massive amounts of signals to identify possible insider risks.

It was also important for us to extend this collaboration beyond Microsoft. For example, for the past few years, Microsoft has partnered with Carnegie Mellon University to bring in their expertise and experience in insider risks and provide insights about the nature of the broader landscape.

Our partnership with Carnegie Mellon University has helped shape our mindset and influenced our Insider Risk Management product, a Microsoft 365 solution that enables organizations to leverage machine learning to detect, investigate, and act on malicious and unintentional activities. Partnering with organizations like Carnegie Mellon University allows us to bring their rich research and insights to our products and services, so customers can fully benefit from our breadth of signals.

This research partnership with Carnegie Mellon University experiments with innovative ways to identify indicators of insider risk. The output of these experiments become inputs to our research-informed product roadmap. For example, our data scientists and researchers have been looking into using threat data from Microsoft 365 Defender to gain insights that can be used for managing insider risks. Today, we’d like to share our progress on this research in the form of Microsoft 365 Defender advanced hunting queries, now available in a GitHub repo:

  1. Detection Exfiltration to Competitor Organization: This query helps enterprises detect instances of a malicious insider creating a file archive and then emailing that archive to an external “competitor” organization. Effective query use requires prior knowledge of email addresses that may pose a risk to the organization if data is sent to those addresses.
  2. Detecting exfiltration after termination: This query explores instances in which a terminated individual (i.e., one who has an impending termination date, but has not left the company) downloads many files from a non-domain network address.
  3. Detecting steganography exfiltration: This query detects instances of malicious users who attempt to create steganographic images and then immediately browse to a webmail URL. It requires additional investigation to determine indication of a malicious event through the co-occurrence of a) generating a steganographic image; and b) browsing to a webmail URL

As these queries demonstrate, industry partnerships allow us to enrich our own intelligence with other organizations’ depth of knowledge, helping us address some of the bigger challenges of insider risks through the product, while bringing scientifically proven solutions to our customers more quickly through this open-source library.

Microsoft will continue investing in partnerships like Carnegie Mellon University to learn from experts and deliver best-in-class intelligence to our customers. Follow our insider risk podcast and join us in our Insider Risk Management journey!

The post Collaborative innovation on display in Microsoft’s insider risk management strategy appeared first on Microsoft Security.

Security baseline (FINAL) for Windows 10 and Windows Server, version 20H2

December 17th, 2020 No comments

We are pleased to announce the final release of the for Windows 10 and Windows Server, version 20H2 (a.k.a. October 2020 Update) security baseline package!


 


Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and customize and implement as appropriate. If you have questions or issues, please let us know via the Security Baseline Community.


 


This Windows 10 feature update brings very few new policy settings, which we list in the accompanying documentation. At this point, no new 20H2 policy settings meet the criteria for inclusion in the security baseline, but there are a few policies we are going to be making changes to, which we highlight below along with our recommendations.


 


Tip: If you read the Draft release, we will save you another read. There are no changes since the draft to the actual settings. There were two small changes to the package though; the Baseline-LocalInstall.ps1 script has a change to error handling (thanks to a community member’s suggestion) and second, we neglected to include the custom ADMX/L files in the GP Reports so they showed up as additional registry keys which is now fixed also.


 


Block at first sight


We started the journey for cloud protection several years ago. Based on our analysis of the security value versus the cost of implementation, we feel it’s time to add Microsoft Defender Antivirus’ Block At First Sight (BAFS) feature to the security baseline. BAFS was first introduced in Windows 10, version 1607 and allows new malware to be detected and blocked within seconds by leveraging various machine learning techniques and the power of our cloud.


 


BAFS currently requires 6 settings to be configured. Our baseline already sets 2 of them, Join Microsoft MAPS and Send file sample when further analysis is required. We are now recommending the addition of the following settings to enable BAFS:


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MAPS\Configure the ‘Block at first sight’ feature set to Enabled


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Scan all downloaded files and attachments set to Enabled


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Turn off real-time protection set to Disabled


 


Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MPEngine\Select cloud protection level set to High blocking level


 


These new settings have been added to the MSFT Windows 10 20H2 and Server 20H2 – Defender Antivirus group policy.


 


Additional details on BAFS can be found here.


 


Attack Surface Reduction Rules


We routinely evaluate our Attack Surface Reduction configuration, and based on telemetry and customer feedback we are now recommending configuring two additional Attack Surface Reduction controls: Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Microsoft Defender Exploit Guard\Attack Surface Reduction\Configure Attack Surface Reduction rules: Use advanced protection against ransomware and Block persistence through WMI event subscription.


 


Introduced in Windows 10, version 1709 the Use advanced protection against ransomware rule will scan any executable files and determine, using advanced cloud analytics, if the file looks malicious .  If so, it will be blocked unless that file is added to an exclusion list. This rule does have a cloud dependency, so you must have Join Microsoft MAPS also configured (which is already part of the security baseline).


 


Block persistence through WMI event subscription is a rule that was released in Windows 10, version 1903. This rule attempts to ensure WMI persistence is not achieved – a common technique adversaries use to evade detection. Unlike many of the other ASR rules, this rule does not allow any sort of exclusions since it is solely based on the WMI repository.


 


A friendly reminder that the security baselines set all ASR rules to block mode. We recommend first configuring them to audit mode, then testing to ensure you understand the impacts these rules will have in your environment, and then configuring them to block mode. Microsoft Defender for Endpoints (formally Microsoft Defender Advanced Threat Protection, MDATP) will greatly enhance the experience of testing, deployment, and operation of ASR rules. We would encourage you to look at evaluating, monitoring and customizing links to better prepare your environment.


 


These new settings have been added to the MSFT Windows 10 20H2 and Server 20H2 – Defender Antivirus group policy.


 


UEFI MAT


You might recall in the draft release of our security baseline for Windows 10, version 1809 we enabled UEFI Memory Attributes Tables, but based on your feedback we removed that recommendation from the final version. After further testing and discussions, we are recommending that you enable Computer Configuration\Administrative Templates\System\Device Guard\Turn on Virtualization Based Security\Require UEFI Memory Attributes Table.


 


Microsoft Edge


Starting with Windows 10, version 20H2 the new Microsoft Edge (based on Chromium) is now installed as part of the operating system. Please ensure you are applying the security baseline for Microsoft Edge to your Windows 10, version 20H2 machines. We have gotten questions about including it on the Windows security baseline, but since Microsoft Edge is a cross platform product and has a different release cadence, we are going to keep it a separate security baseline.


 


As always, please let us know your thoughts by commenting on this post.

Categories: Uncategorized Tags:

A “quick wins” approach to securing Azure Active Directory and Office 365 and improving your security posture

December 17th, 2020 No comments

In the last post, we discussed Office 365 and how enabling certain features without understanding all the components can lead to a false sense of security. We demonstrated how implementing a break glass account, multi-factor authentication (MFA), and the removal of legacy authentication can help secure your users and point your organization’s security posture in the right direction. While implementing those controls is an excellent start to hardening your environment, it is just the beginning. Read that blog here.

Security is critical, and any way that we can expedite threat prevention is highly welcomed. What if there was a way to get into a more secure state quickly.  How much time would this give you back to focus your attention on other tasks like actual customers (user base, clients)?

Do you wish there was a quick approach for security configurations in Azure Active Directory (Azure AD) and Office 365? I know I do, and thankfully we have some options here, and they are Secure Score and security defaults. Many of our customers are not aware that these features exist, or if they are aware, they fail to take advantage of using them.

“This blog post will provide an overview of Microsoft Secure Score and security defaults—two features that are easy to utilize and can significantly improve your security in Azure AD and Office 365 configurations.” 

What is Microsoft Secure Score? I am glad you asked

Microsoft Secure Score is a measurement developed to help organizations understand where they are now and the steps needed to improve their security posture. Microsoft Secure Score summarizes the different security features and capabilities currently enabled and provides you with the ability to compare your Score with other companies like yours and identify recommendations for areas of improvement.

Microsoft Secure Score screen image

Figure 1: Microsoft Secure Score screen image

How does Secure Score help organizations?

Secure Score provides recommendations for protecting your organization from threats. Secure Score will:

  • Objectively measure your identity security posture.
  • Plan for security improvements.
  • Review the success of your improvements.
  • The Score can also reflect third-party solutions that have been implemented and have addressed recommended actions.
  • The Secure Score reflects new services, thus keeping you up to date with new features and security settings that should be reviewed and if action on your part.

How is the Score determined?

Secure Score compares your organization’s configuration against anonymous data from other organizations with similar features to your organization, such as company size. Each improvement action is worth ten points or less, and most are scored in a binary fashion. If you implement the improvement action, like require MFA for Global Administrators or create a new policy or turn on a specific setting, you get 100 percent of the points. For other improvement actions, points are given as a percentage of the total configuration.

For example, an improvement action states you get ten points by protecting all your users with multi-factor authentication. You only have 50 of 100 total users protected, so that you would get a partial score of five points.

Additionally, your score will drop if routine security tasks are not completed regularly or when security configurations are changed. It will provide directions to the security team about what has changed and the security implications of those changes.

What are security defaults?

Security defaults, a one-click method for enabling basic identity security in an organization, are pre-configured security settings that help defend organizations against frequent identity-related attacks, such as password spray, replay, and phishing. Some of the critical features of Security Defaults include:

  • Requiring all users to register for Azure AD Multi-Factor Authentication (MFA) using the Microsoft Authenticator app.
  • Requiring administrators to perform multi-factor authentication.
  • Blocking legacy authentication protocols.
  • Requiring users to perform multi-factor authentication when necessary.
  • Protecting privileged activities like access to the Azure portal.

When should you use security defaults?

It would be best if you used security defaults in the following cases:

  • If you want to increase the overall security posture and don’t know how or where to start, security defaults are for you.
  • If you are using the free tier of Azure Active Directory licensing, security defaults are for you.

How is the Score determined?

Microsoft Secure Score has recently added improvement actions to support security defaults in Azure Active Directory, making it easier to help protect your organization with pre-configured security settings for frequent attack vectors.

When you turn on security defaults, you will be awarded full points for the following improvement actions:

  • Ensure all users can complete multi-factor authentication for secure access (nine points).
  • Require MFA for administrative roles (ten points).
  • Enable policy to block legacy authentication (seven points).

Get Started with Microsoft Secure Score and security defaults

Microsoft organizes Secure Score improvement actions into groups to help you focus on what you need to address for your organization:

  • Identity (Azure AD accounts and roles).
  • Data (Microsoft Information Protection).
  • Device (Microsoft Defender ATP, known as Configuration score).
  • Application (email and cloud apps, including Office 365 and Microsoft Cloud App Security).
  • Infrastructure (no improvement actions for now).

Secure Score

  • Start by logging into your Secure Score.
  • View your scores and where you need to improve.
  • Export all recommendations for your organization and turn this into an attack plan.
  • Prioritize the recommendations you will implement over the next 30, 60, 90, and 180 days.
  • Pick the tasks that are priorities for your organization and work these into your change control processes.

Security defaults

  • Start by logging in to your  Azure portal as a security administrator, Conditional Access administrator, or global administrator.
  • Browse to Azure Active Directory, and then Properties.
  • Select Manage security defaults.
  • Set the Enable security defaults, then toggle to Yes.
  • Select Save.

Enabling security defaults

Figure 2:  Enabling security defaults

There are many security enhancements that keep coming to Microsoft’s Cloud stack, so be sure you check your secure Score weekly. As the days go by and new security settings appear, your secure Score will reflect these changes. It is critical to check back often to ensure you are addressing any further recommendations.

Bumps in the road

Microsoft Secure Score and security defaults are straight forward ways to evaluate and improve your Azure AD and Office 365 configurations’ security. Security defaults help implement industry recommended practices, while Microsoft Secure Score creates a hands-on interface that simplifies the ongoing process of security assessment and improvement.

Our upcoming blog will explore the necessary built-in Azure tooling and open-source options that an organization can employ during investigative scenarios.

To learn more about Microsoft Security solutions visit our website.  Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post A “quick wins” approach to securing Azure Active Directory and Office 365 and improving your security posture appeared first on Microsoft Security.

A breakthrough year for passwordless technology

December 17th, 2020 No comments

As 2020 draws to a close, most of us are looking forward to putting this year in the rearview mirror. Since we depend even more on getting online for everything in our lives, we’re more than ready to be done with passwords. Passwords are a hassle to use, and they present security risks for users and organizations of all sizes, with an average of one in every 250 corporate accounts compromised each month. According to the Gartner Group, 20 to 50 percent of all help desk calls are for password resets. The World Economic Forum (WEF) estimates that cybercrime costs the global economy $2.9 million every minute, with roughly 80 percent of those attacks directed at passwords.

In November 2019 at Microsoft Ignite, we shared that more than 100 million people were already using Microsoft’s passwordless sign-in each month. In May of 2020, just in time for World Password Day, that number had already grown to more than 150 million people, and the use of biometrics to access work accounts is now almost double what it was then. We’ve drawn strength from our customers’ determination this year and are set to make passwordless access a reality for all our customers in 2021.

2020: A banner year for passwordless technology

Infograph describing the passwordless technology achievements in 2020

February: We announced a preview of Azure Active Directory support for FIDO2 security keys in hybrid environments. The Fast Identity Online (FIDO) Alliance is a “cross-industry consortia providing standards, certifications, and market adoption programs to replace passwords with simpler, stronger authentication.” Following the latest FIDO spec, FIDO2, we enabled users with security keys to access their Hybrid Azure Active Directory (Azure AD) Windows 10 devices with seamless sign-in, providing secure access to on-premises and cloud resources using a strong hardware-backed public and private-key credential. This expansion of Microsoft’s passwordless capabilities followed 2019’s preview of FIDO2 support for Azure Active Directory joined devices and browser sign-ins.

June: I gave a keynote speech at Identiverse Virtual 2020 where I got to talk about how Microsoft’s FIDO2 implementation highlights the importance of industry standards in implementing Zero Trust security and is crucial to enabling secure ongoing remote work across industries. Nitika Gupta, Principal Program Manager of Identity Security in our team, showed how Zero Trust is more important than ever for securing data and resources and provided actionable steps that organizations can take to start their Zero Trust journey.

September: At Microsoft Ignite, the company revealed the new passwordless wizard available through the Microsoft 365 Admin Center. Delivering a streamlined user sign-in experience in Windows 10, Windows Hello for Business replaces passwords by combining strong MFA for an enrolled device with a PIN or user biometric (fingerprint or facial recognition). This approach gives you, our customers, the ability to deliver great user experiences for your employees, customers, and partners without compromising your security posture.

November: Authenticate 2020, “the first conference dedicated to who, what, why and how of user authentication,” featured my boss, Joy Chik, CVP of Identity at Microsoft, as the keynote speaker. Joy talked about how FIDO2 is a critical part of Microsoft’s passwordless vision, and the importance of the whole industry working toward great user experiences, interoperability, and having apps everywhere support passwordless authentication. November also saw Microsoft once again recognized by Gartner as a “Leader” in identity and access management (IAM).

MISA members lead the way

The Microsoft Intelligent Security Association (MISA) is an ecosystem of security partners who have integrated their solutions with Microsoft to better defend against increasingly sophisticated cyber threats. Four MISA members—YubiKey, HID Global, Trustkey, and AuthenTrend—stood out this year for their efforts in driving passwordless technology adoption across industries.

Yubico created the passwordless YubiKey hardware to help businesses achieve the highest level of security at scale.

“We’re providing users with a convenient, simple, authentication solution for Azure Active Directory.”—Derek Hanson, VP of Solutions Architecture and Alliances, Yubico

HID Global engineered the HID Crescendo family of FIDO-enabled smart cards and USB keys to streamline access for IT and physical workspaces—enabling passwordless authentication anywhere.

“Organizations can now secure access to laptops and cloud apps with the same credentials employees use to open the door to their office.”—Julian Lovelock, VP of Global Business Segment Identity and Access Management Solutions, HID

TrustKey provides FIDO2 hardware and software solutions for enterprises who want to deploy passwordless authentication with Azure Active Directory because: “Users often find innovative ways to circumvent difficult policies,” comments Andrew Jun, VP of Product Development at TrustKey, “which inadvertently creates security holes.”

AuthenTrend applied fingerprint-authentication technology to the FIDO2 security key and aspires to replace all passwords with biometrics to help people take back ownership of their credentials.

Next steps for passwordless in 2021

Our team has been working hard this year to join these partners in making passwords a thing of the past. Along with new UX and APIs for managing FIDO2 security keys enabling customers to develop custom solutions and tools, we plan to release a converged registration portal in 2021, where all users can seamlessly manage passwordless credentials via the My Apps portal.

We’re excited about the metrics we tracked in 2020, which show a growing acceptance of passwordless among organizations and users:

  • Passwordless usage in Azure Active Directory is up by more than 50 percent for Windows Hello for Business, passwordless phone sign-in with Microsoft Authenticator, and FIDO2 security keys.
  • More than 150 million total passwordless users across Azure Active Directory and Microsoft consumer accounts.
  • The number of consumers using Windows Hello to sign in to Windows 10 devices instead of a password grew to 84.7 percent from 69.4 percent in 2019.

We’re all hoping the coming year will bring a return to normal and that passwordless access will at least make our online lives a little easier.

Learn more about Microsoft’s passwordless story. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post A breakthrough year for passwordless technology appeared first on Microsoft Security.