Earlier this month, we published the 2021 Microsoft Digital Defense Report to help organizations better understand this evolving threat landscape, as well as provide guidance on securing your supply chain and IoT and OT assets. In the spirit of security for all, some highlights of these chapters are presented here for easy reference.

Securing supply chains

The practice of adopting multiple tools to monitor different tiers of suppliers increases complexity, which in turn increases the odds that a cyberattack can produce a significant return for your adversary. Siloes can create additional problems—different teams have different priorities, which may lead to different risk priorities and practices. This inconsistency can create a duplication of efforts and gaps in risk analysis. Suppliers’ personnel also are a top concern. Organizations want to know who has access to their data; so they can protect themselves from human liability, shadow IT, and other insider threats.

For supplier risk management, an always-on, automated, integrated approach is needed, but current processes aren’t well-suited to the task. To secure your supply chain, it’s important to have a repeatable process that will scale as your organization innovates. At Microsoft, we group our investments into nine secure supply chain (SSC) workstreams to methodically evaluate and mitigate risk in each area:

Figure 1: Nine areas of investment for a secure end-to-end supply chain.

For supply chain risk management, having integrated solutions and greater visibility into who ultimately has access to an organization’s data are top priorities. While there are many places to begin a Zero Trust journey, instituting multifactor authentication (MFA) should be your first step.

From the White House

On May 12, 2021, the White House issued Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity outlining steps for federal agencies and their technology providers to enhance supply chain security. For software providers, the EO calls for requirements to enhance resistance to attack, including secure software development practices, software verification and vulnerability checks, a software bill of materials (SBOM), a vulnerability disclosure program, and other secure practices.

For federal agency users of software with privileged access, EO 14028 calls for implementing security measures published by the National Institute of Standards and Technology (NIST). Microsoft has long been invested in developing best practices for secure software development, and we’ve contributed to efforts to define industry-wide practices and consensus standards, including through SAFECode, ISO/IEC, and NIST’s National Cybersecurity Center of Excellence (NCCoE) on the Implementing a Zero Trust Architecture project.

IoT and OT security

With the prevalence of cloud connectivity, IoT and OT have become another part of your network. And because IoT and OT devices are typically deployed in diverse environments—from inside factories or office buildings to remote worksites or critical infrastructure—they’re exposed in ways that can make them easy targets. When you add in privacy concerns and regulatory compliance, it’s clear that a holistic approach is needed for enabling seamless security and governance across all your devices.

Securing IoT solutions with a Zero Trust security model is built upon five requirements:

• Implement strong identity to authenticate devices: Register devices, issue renewable credentials, employ passwordless authentication, and use a hardware root of trust to ensure identity before making decisions.
• Maintain least privilege access to mitigate blast radius: Implement device and workload access controls to limit any potential damage from identities that may have been compromised, or those running unapproved workloads.
• Monitor device health to gate access or flag for remediation: Check security configurations, assess for vulnerabilities and insecure passwords, and monitor for active threats and anomalous behavioral alerts to build risk profiles.
• Deploy continual updates to keep devices healthy: Utilize a centralized configuration and compliance management solution, as well as a robust update mechanism, to ensure devices are up to date and healthy.
• Maintain security monitoring and response: Employ proactive monitoring to rapidly identify unauthorized or compromised devices.

Figure 2: How an attacker can get into an enterprise through IoT.

“Attackers will choose the ‘soft targets’ as a point of ingress. Spear phishing or similar attacks allow access to IT systems that can then provide a pathway for attackers to reach OT systems, and the reverse is also possible. In one example, attackers used an aquarium system to access a casino’s high-roller databases, demonstrating that any device with connectivity can present a motivated attacker with an opening.”—2021 Microsoft Digital Defense Report

Default passwords cause problems

Microsoft’s sensor network provides us with raw data on more than 280,000 attacks, including password data. Unsurprisingly, we saw that 96 percent of attacks used a password with fewer than 10 characters. Within these password attempts, only 2 percent included a special character and 72 percent didn’t even contain a number. The word “admin” was found more than 20 million times in IoT passwords over a 45 day period.

Figure 3: Prevalence of common passwords in IoT and OT settings.

Maintain your IoT just like IT

It’s essential for organizations to assess the security of their IoT and OT systems with the same rigor applied to IT systems. While PCs are routinely required to have updated certificates, IoT devices are often deployed with factory-default passwords. Attackers are also focusing on how IoT and OT interact, which brings real dangers. Industrial control systems (ICS) are often retrofitted with remote capabilities—meaning, virtual attacks can cause physical harm.

Microsoft supported a research study conducted by the Global Cyber Alliance (GCA) to demonstrate the effectiveness of commonly recommended controls in preventing attacks. GCA’s analysis of real attack data shows that default passwords factory-set by device manufacturers, or weak passwords set by users, represent the most exploited security vulnerability for IoT devices. Their findings can be boiled down to four simple takeaways for IoT and OT security:

1. No default passwords.
2. Implement a vulnerability disclosure policy.
3. Keep software updated.
4. Continuously monitor IoT communication for unauthorized communications and attacks.

Learn more

Learn how Microsoft Defender for IoT can secure your IoT and OT devices.

To find out more about protecting your organization against supply chain and IoT/OT attacks, including the seven properties of highly secured devices, download the 2021 Microsoft Digital Defense Report. Also, see our past blog posts providing information for each themed week of Cybersecurity Awareness Month 2021:

• #BeCyberSmart: When we learn together, we’re more secure together
• How cyberattacks are changing according to new Microsoft Digital Defense Report
• Get career advice from 7 inspiring leaders in cybersecurity
• Defenders wanted—building the new cybersecurity professionals
• New insights on nation-state attacks
• New insights on cybersecurity in the age of hybrid work

Be sure to visit our Cybersecurity Awareness Month page for more resources and information on protecting your organization year-round. Do your part. #BeCyberSmart

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.

¹Hackers Breached Colonial Pipeline Using Compromised Password, William Turton, Kartikay Mehrotra, Bloomberg. 4 June 2021.

²Microsoft Warns of 25 Critical Vulnerabilities in IoT, Industrial Devices, Elizabeth Montalbano, Threatpost. 30 April 2021.

³Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop, Microsoft 365 Defender Research Team, Microsoft Threat Intelligence Center (MSTIC), Microsoft Cyber Defense Operations Center (CDOC), Microsoft Security. 20 January 2021.

⁴Kaseya ransomware attack sets off race to hack service providers -researchers, Joseph Menn, Reuters. 3 August 2021.

The post Learn how Microsoft strengthens IoT and OT security with Zero Trust appeared first on Microsoft Security Blog.

Microsoft Defender for Endpoint received the highest possible scores in the control, data security, and mobile security criteria, as well as in the Zero Trust framework alignment and security community involvement criteria. Forrester also noted our “impact on endpoint is also notably low when actively running on the endpoint, and that the number of reported false positives by customers is also the lowest in this evaluation.”

As Vasu Jakkal, Corporate Vice President of Marketing for Security, Compliance, and Identity, states in her blog, we are operating in the most complex cybersecurity landscape we’ve ever seen and security has never been more important. It’s clearer than ever that a Zero Trust approach is critical to success. Our continued investments in extending Microsoft Defender for Endpoint’s industry-leading capabilities across non-Windows platforms, such as macOS, Linux, Android, and iOS, help customers get visibility into all endpoints accessing corporate data and apply the right controls necessary to minimize their growing attack surface. Our strengths in threat detection and integrated XDR approach across endpoints, email and collaboration, identities, and cloud apps further enable security teams’ ability to enable a true Zero Trust strategy.

Also critical to all of our success is the need to share and contribute to the security community so that all can be equipped to strengthen defenses and respond to attacks such as what we’ve seen with web shell attacks, NOBELIUM (Solorigate), and HAFNIUM. As we have seen in recent months, with attacks becoming more coordinated and sophisticated, community collaboration and sharing can help us all take the steps needed for a safer world.

Our continued leadership in security is due in part to the close partnership we have with customers who give us continuous feedback in the product development process. We are grateful for their continued trust in us and are committed to delivering innovative security capabilities that help them secure their organizations.

Microsoft Defender for Endpoint is seamlessly built into Microsoft 365 Defender, our solution offering XDR capabilities for identities, endpoints, cloud apps, email, and documents. Microsoft 365 Defender delivers intelligent, automated, and integrated security in a unified security operations (SecOps) experience, with detailed threat analytics and insights, unified threat hunting, and rapid detection and automation across domains—detecting and stopping attacks anywhere in the kill chain and eliminating persistent threats.

Our mission is to empower defenders with the best security capabilities in the industry so that you can focus on what’s important: preventing and remediating threats.

You can download The Forrester Wave™: Endpoint Security Software as a Service, Q2 2021 complimentary report to get more details about our position as a Leader. We thank our customers and partners for being on this journey with us.

Learn more

Microsoft Defender for Endpoint is an industry-leading, cloud-powered endpoint security solution offering vulnerability management, endpoint protection, endpoint detection and response, and mobile threat defense. With our solution, threats are no match. If you are not yet taking advantage of Microsoft’s unrivaled threat optics and proven capabilities, sign up for a free trial of Microsoft Defender for Endpoint today.

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 Forrester Wave™: Endpoint Security Software as a Service, Q2 2021, Chris Sherman, May 13, 2021.

This graphic was published by Forrester Research as part of a larger research document and should be evaluated in the context of the entire document. The Forrester document is available upon request here.

The post Microsoft is a Leader in the 2021 Forrester Endpoint Security Software as a Service Wave appeared first on Microsoft Security Blog.

For my team, seeing the Microsoft Intelligent Security Association (MISA) grow to 190 partner companies has been a bright spot in a dark year. To date, MISA members have created 215 product integrations, and I’m pleased to announce that our pilot program for adding managed security service providers (MSSPs) has formally transitioned. MISA now includes 39 MSSP members who have created 76 MSSP offers since the beginning of the fiscal year.

“Microsoft Security integrates with a broad ecosystem of platforms and cloud providers, so they work with the things you already have in your environment; whether those things are from Microsoft, or not. Our partners are key to helping facilitate this integration.”—Vasu Jakkal, CVP, Security, Compliance and Identity

“Adding managed security service providers promises to increase the ecosystem’s value even more by offering an extra layer of threat protection—reducing the day-to-day involvement of in-house security teams. It’s another important step in strengthening and simplifying security at a time when risk mitigation is one of IT’s highest priorities.”—Shawn O’Grady, Senior Vice President and General Manager, Cloud + Data Center Transformation at Insight

Because Microsoft’s footprint extends across many technologies, we have an advantage in creating holistic solutions that encompass the full breadth of security, compliance, and identity. In keeping with that end-to-end approach, we’ve expanded MISA to include 5 new compliance products, growing the MISA product portfolio to 18.

“The explosion of data from digital transformation and remote work make the integration of security and compliance tools across internal and external ecosystems more critical than ever. Together with the deep expertise of our MISA members, we can help our customers address their complex, evolving security and compliance needs.”—Alym Rayani, General Manager, Microsoft Compliance

Compliance comes to MISA

Microsoft compliance products help our customers assess their compliance risk, protect their sensitive data, and govern it according to regulatory requirements. Through MISA, members get support in building managed services and integrations that:

1. Protect and govern data wherever it lives.
2. Identify and take actions on critical insider risks.
3. Simplify compliance and reducing risk.
4. Investigate and respond with relevant data.

“TeleMessage is excited to bring our Mobile Communication Archiving products to be a part of Microsoft’s security solutions. Being a MISA member allows us to work closely with the Microsoft teams and allows us to provide seamless, secure, and compliant integrations delivering all popular forms of mobile communication.”—Guy Levit, CEO at TeleMessage

Microsoft Information Protection has been part of MISA since the association began in 2018, providing broad coverage across devices, apps, cloud services, and on-premises systems. This year, we’re continuing to develop our holistic partner community across security, compliance, and identity by adding five additional Microsoft compliance products to our portfolio:

• Microsoft Information Governance: Keep what you need and delete what you don’t. Apply compliance solutions and a deletion workflow for email, documents, instant messages, social media, document collaboration platforms, and more.
• Microsoft Data Loss Prevention: Help users stay compliant without interrupting their workflow—prevent the accidental sharing of sensitive information across Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, and desktop versions of Excel, PowerPoint, and Microsoft Word.
• Microsoft 365 Insider Risk Management: Identify critical insider risks and take the appropriate action. With built-in privacy controls, use native and third-party signals to identify, investigate, and remediate malicious and inadvertent activities in your organization.
• Microsoft Advanced eDiscovery: Gain an end-to-end workflow to collect, analyze, preserve, and export content that’s responsive to your organization’s internal and external investigations. Identify persons of interest and their data sources, then manage the legal-hold communication process.
• Microsoft Compliance Manager: Get help throughout your compliance journey, from taking inventory of your data protection risks to managing the complexities of implementing controls, staying current with regulations and certifications, and reporting to auditors.

“Joining MISA enhances our relationship with Microsoft and our commitment to being an information governance and compliance leader providing solutions for organizations to bring third-party data into Microsoft 365 archive,” said Charles Weeden, Managing Partner of 17a-4, LCC. “DataParser’s connectors will allow Microsoft 365 Compliance users to ingest content from various sources, such as Bloomberg, Slack, Symphony, Webex Teams and many others.”

Connectors and APIs to extend compliance capabilities

Organizations today face an intimidating amount of data to protect across disparate systems, both on-premises and in the cloud. That’s why Microsoft compliance solutions span information protection and governance, data-loss prevention, insider risk, eDiscovery, audit, and compliance management—including your non-Microsoft data.

Microsoft 365 compliance enables organizations to extend, integrate, accelerate, and support their compliance solutions with three key building blocks:

• Data connectors: Import, archive, and apply Microsoft 365 protection and governance capabilities to third-party data.
• APIs: Enable programmatic access to Microsoft 365 compliance capabilities.
• Power Automate Integrations: Gain seamless automation and workflow customizations.

All of these new capabilities exist within Microsoft’s integrated compliance platform. Meaning, customers only need to set compliance policies a single time, regardless of the data source.

“The Veritas Merge1 connector platform integration with M365 allows our joint customers to configure, connect, and capture a vast number of data sources from within the M365 compliance center. The integration makes it easy to quickly identify which data sources need to be captured, to configure connectivity to those data sources and to pull data into M365 all from within the Azure infrastructure. Our development teams have worked closely together for over 12 months to make sure the workflow is simple and the capabilities are robust. With the increase in global regulations over the past several years, our goal is to simplify compliance, and we believe we have achieved that by working together with Microsoft.”—David Scott, Sr. Director, Digital Compliance at Veritas Technologies

Microsoft Security lights the way

As the global pandemic forced millions into remote work last year, hackers took advantage and upped their game, as seen with the recent Solorigate attack. Many organizations saw their sensitive data created, viewed, and distributed across multiple fragmented platforms that increased the potential attack surface. Because we view security as part of the common good, we chose to take a proactive approach; shifting cybersecurity away from the shadows and into a place of innovation and empowerment.

“MISA has helped us promote successful integrations with Azure Security Graph API and Azure Active Directory, both now deeply embedded in Barracuda security solutions.”—Tim Jefferson, SVP Data, Networking, and Applications, Barracuda Networks

During Microsoft Ignite, March 2-4, 2021, you’ll see added investment in our security, compliance, and identity portfolio as we continue to innovate and create holistic solutions that support cultures of security for our customers and partners, based on four basic principles:

• Protect everything: Safeguard your entire organization with integrated security, compliance, and identity solutions built to work across platforms and cloud environments.
• Simplify the complex: Prioritize risks with unified management tools and strategic guidance created to maximize the human expertise inside your company.
• Catch what others miss: Enable AI, automation, and human expertise to help you detect threats quickly, respond effectively, and fortify your security posture.
• Grow your future: Gain the peace of mind that comes with a comprehensive security solution, empowering you to grow, create, and innovate across your business.

To learn more about upcoming big announcements at Microsoft Ignite this week, visit our latest blog posts:

• 4 Ways Microsoft Is Delivering Security for All in a Zero Trust World by Vasu Jakkal.
• Securing & Governing Data in a New Hybrid Work Reality by Alym Rayani.
• Microsoft Compliance joins the Microsoft Intelligent Security Association (MISA) as we continue to extend the Microsoft Compliance ecosystem by Hammad Rajjoub.

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 Compliance joins Microsoft Intelligent Security Association (MISA) appeared first on Microsoft Security Blog.

As defenders ourselves, we are passionate proponents of a Zero Trust mindset, encompassing all types of threats—both outside in and inside out. We believe the right approach is to address security, compliance, identity, and device management as an interdependent whole and to extend protection to all data, devices, identities, platforms, and clouds—whether those things are from Microsoft or not.

You may have heard us talk about our commitment to security for all, and that’s at the heart of it. We are deeply inspired to empower people everywhere to do the important work of defending their communities and their organizations in an ever-evolving threat landscape.

With that approach in mind, today I’m excited to share several additional innovations across four key areas with you—identity, security, compliance, and skilling—to give you the holistic security protection you need to meet today’s most challenging security demands.

1. Identity: The starting point of a Zero Trust approach

Adopting a Zero Trust strategy is a journey. Every single step you take will make you more secure. In today’s world, with disappearing corporate network perimeters, identity is your first line of defense. While your Zero Trust journey will be unique, if you are wondering where to start, our recommendation is to start with a strong cloud identity foundation. The most fundamental steps like strong authentication, protecting user credentials, and protecting devices are the most essential.

Today we are announcing new ways that Azure Active Directory (Azure AD), the cloud identity solution of choice for more than 425 million users, can help you on your Zero Trust journey:

• Passwordless authentication, which eliminates one of the weakest links in security today, is now generally available for cloud and hybrid environments. Now you can create end-to-end experiences for all employees, so they no longer need passwords to sign in to the network. Instead, Azure AD now lets them sign in with biometrics or a tap using Windows Hello for Business, the Microsoft Authenticator app, or a compatible FIDO2 security key from Microsoft Intelligent Security Association partners such as Yubico, Feitian, and AuthenTrend. With Temporary Access Pass, now in preview, you can generate a time-limited code to set up or recover a passwordless credential.
• Azure AD Conditional Access, the policy engine at the heart of our Zero Trust solution, now uses authentication context to enforce even more granular policies based on user actions within the app they are using or sensitivity of data they are trying to access. This helps you appropriately protect important information without unduly restricting access to less sensitive content.
• Azure AD verifiable credentials is entering preview in just a few weeks. Verifiable credentials let organizations confirm information—like their education or the professional certifications someone provides—without collecting and storing their personal data, thereby improving security and privacy. In addition, new partnerships integrating Azure AD verifiable credentials with leading identity verification providers like Onfido, Socure, and others will improve verifiability and secure information exchange. Customers such as Keio University, the government of Flanders, and the National Health Service in the UK are already piloting verifiable credentials.

Learn more about our Azure AD announcements in today’s blog post by Joy Chik.

2. Security: Simplifying the “assume breach” toolset

In today’s landscape, your security approach should start with the key Zero Trust principle of assume breach. But too often, complexity and fragmentation stand in the way. It is our commitment to helping you solve this, as we build security for all, delivered from the cloud.

This begins with integrated solutions that let you focus on what matters and deliver visibility across all your platforms and all your clouds. Some vendors deliver endpoint or email protection, while others deliver Security Information and Event Management (SIEM) tools, and integrating those pieces together can be a time-consuming challenge. Microsoft takes a holistic approach that combines best-of-breed SIEM and extended detection and response (XDR) tools built from the ground up in the cloud to improve your posture, protection, and response. This gives you the best-of-breed combined with the best-of-integration so you don’t have to compromise.

Today we are making the following announcements to simplify the experience for defenders with modern and integrated capabilities:

• Microsoft Defender for Endpoint and Defender for Office 365 customers can now investigate and remediate threats from the Microsoft 365 Defender portal. It provides unified alerts, user and investigation pages for deep, automated analysis and simple visualization, and a new Learning Hub where customers can leverage instructional resources with best practices and how-tos.
• Incidents, schema, and user experiences are now common between Microsoft 365 Defender and Azure Sentinel. We also continue to expand connectors for Azure Sentinel and work to simplify data ingestion and automation.
• The new Threat Analytics provides a set of reports from expert Microsoft security researchers that help you understand, prevent, and mitigate active threats, like the Solorigate attacks, directly within Microsoft 365 Defender.
• We are bringing Secured-core to Windows Server and edge devices to help minimize risk from firmware vulnerabilities and advanced malware in IoT and hybrid cloud environments.

Learn more about our threat protection announcements in today’s blog post by Rob Lefferts and Eric Doerr. Learn more about our Secured-core announcements in today’s blog post by David Weston. You can also learn more about new security features in Microsoft Teams in today’s blog post by Jared Spataro.

Today’s announcements continue, and strengthen, our commitment to deliver best-of-breed protection, detection, and response for all clouds and all platforms with solutions like Defender for Endpoint—a leader in the Gartner Magic Quadrant, available for Android, iOS, macOS, Linux, and Windows; and Azure Sentinel—which looks across your multi-cloud environments, including AWS, Google Cloud Platform, Salesforce service cloud, VMware, and Cisco Umbrella.

3. Compliance: Protection from the inside out

At Microsoft, we think of Zero Trust as not only the practice of protecting against outside-in threats, but also protecting from the inside out. For us, addressing the area of compliance includes managing risks related to data.

And that isn’t just the data stored in the Microsoft cloud, but across the breadth of clouds and platforms you use. We’ve invested in creating that inside-out protection by extending our capabilities to third parties to help you reduce risk across your entire digital estate.

Today we are announcing these new innovations in compliance:

• Co-authoring of documents protected with Microsoft Information Protection. This enables multiple users to work simultaneously on protected documents while taking advantage of the intelligent, unified, and extensible protection for documents and emails across Microsoft 365 apps.
• Microsoft 365 Insider Risk Management Analytics, which can identify potential insider risk activity within an organization and help inform policy configurations. With one click, customers can have the system run a daily scan of their tenant audit logs, including historical activity, and leverage Microsoft 365’s Insider Risk Management machine learning engine to identify potential risky activity with privacy built-in by design.
• Microsoft 365 now offers data loss prevention (DLP) for Chrome browsers and on-premises server-based environments such as file shares and SharePoint Server.
• Azure Purview is integrated with Microsoft Information Protection, enabling you to apply the same sensitivity labels defined in Microsoft 365 Compliance Center to data residing in other clouds or on-premises. With Azure Purview, a unified data governance solution for on-premises, multi-cloud, and software as a service (SaaS) data, you can scan and classify data residing in AWS Simple Storage Services (S3), SAP ECC, SAP S4/HANA, and Oracle Database.

Learn more about our compliance announcements in today’s blog post by Alym Rayani.

4. Skilling: Power your future through security skilling

We know that many of you continue to struggle to fill the security skills gap with an estimated shortfall of 3.5 million security professionals by 2021. That’s why we strive to ensure you have the skilling and learning resources you need to keep up in our world of complex cybersecurity attacks. We are excited to announce two different ways Microsoft is supporting skilling cybersecurity professionals.

First, Microsoft has four new security, compliance, and identity certifications tailored to your roles and needs, regardless of where you are in your skilling journey. To learn more about these new certifications, please visit our resource page for Microsoft Certifications.

• Security, Compliance, and Identity Fundamentals certification will help individuals get familiar with the fundamentals of security, compliance, and identity across cloud-based and related Microsoft services.
• Information Protection Administrator Associate certification focuses on planning and implementing controls that meet organizational compliance needs.
• Security Operations Analyst Associate certification helps security operational professionals design threat protection and response systems.
• Identity and Access Administrator Associate certification help individuals design, implement and operate an organization’s identity and access management systems by using Azure Active Directory.

We also recognize that the world we live in is complex but growing your skills shouldn’t be. The Microsoft Security Technical Content Library will help you find content relevant to your needs. Use it to access content based on your own needs today.

You can also learn more on today’s Tech Community blog post.

Security for all

We at Microsoft Security are committed to helping build a safer world for all. Every day, we are inspired by the work of our defenders and we are focused on delivering innovations, expertise, and resources that tip the scale in favor of defenders everywhere because the work you do matters. Security is a team sport, and we’re all in this together.

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 4 ways Microsoft is delivering security for all in a Zero Trust world appeared first on Microsoft Security Blog.

UPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving forward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the examples of malware used by the actors. Microsoft Threat Intelligence Center (MSTIC) has named the actor behind the attack against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM. As we release new content and analysis, we will use NOBELIUM to refer to the actor and the campaign of attacks.

A key aspect of the Solorigate attack is the supply chain compromise that allowed the attacker to modify binaries in SolarWinds’ Orion product. These modified binaries were distributed via previously legitimate update channels and allowed the attacker to remotely perform malicious activities, such as credential theft, privilege escalation, and lateral movement, to steal sensitive information. The incident has reminded organizations to reflect not just on their readiness to respond to sophisticated attacks, but also the resilience of their own codebases.

Microsoft believes in leading with transparency and sharing intelligence with the community for the betterment of security practices and posture across the industry as a whole. In this blog, we’ll share our journey in reviewing our codebases, highlighting one specific technique: the use of CodeQL queries to analyze our source code at scale and rule out the presence of the code-level indicators of compromise (IoCs) and coding patterns associated with Solorigate. We are open sourcing the CodeQL queries that we used in this investigation so that other organizations may perform a similar analysis. Note that the queries we cover in this blog simply serve to home in on source code that shares similarities with the source in the Solorigate implant, either in the syntactic elements (names, literals, etc.) or in functionality. Both can occur coincidentally in benign code, so all findings will need review to determine if they are actionable. Additionally, there is no guarantee that the malicious actor is constrained to the same functionality or coding style in other operations, so these queries may not detect other implants that deviate significantly from the tactics seen in the Solorigate implant. These should be considered as just a part in a mosaic of techniques to audit for compromise.

Microsoft has long had integrity controls in place to verify that the final compiled binaries distributed to our servers and to our customers have not been maliciously modified at any point in the development and release cycle. For example, we verify that the source file hashes generated by the compiler match the original source files. Still, at Microsoft, we live by the “assume breach” philosophy, which tells us that regardless of how diligent and expansive our security practices are, potential adversaries can be equally as clever and resourced. As part of the Solorigate investigation, we used both automated and manual techniques to validate the integrity of our source code, build environments, and production binaries and environments.

Microsoft’s contribution during Solorigate investigations reflects our commitment to a community-based sharing vision described in Githubification of InfoSec. In keeping with our vision to grow defender knowledge and speed community response to sophisticated threats, Microsoft teams have openly and transparently shared indicators of compromise, detailed attack analysis and MITRE ATT&CK techniques, advanced hunting queries, incident response guidance, and risk assessment workbooks during this incident. Microsoft encourages other security organizations that share the “Githubification” vision to open source their own threat knowledge and defender techniques to accelerate defender insight and analysis. As we have shared before, we have compiled a comprehensive resource for technical details of the attack, indicators of compromise, and product guidance at https://aka.ms/solorigate. As part of Microsoft’s sweeping investigation into Solorigate, we reviewed our own environment. As we previously shared, these investigations found activity with a small number of internal accounts, and some accounts had been used to view source code, but we found no evidence of any modification to source code, build infrastructure, compiled binaries, or production environments.

A primer on CodeQL and how Microsoft utilizes it

CodeQL is a powerful semantic code analysis engine that is now part of GitHub. Unlike many analysis solutions, it works in two distinct stages. First, as part of the compilation of source code into binaries, CodeQL builds a database that captures the model of the compiling code. For interpreted languages, it parses the source and builds its own abstract syntax tree model, as there is no compiler. Second, once constructed, this database can be queried repeatedly like any other database. The CodeQL language is purpose-built to enable the easy selection of complex code conditions from the database.

One of the reasons we find so much utility from CodeQL at Microsoft is specifically because this two-stage approach unlocks many useful scenarios, including being able to use static analysis not just for proactive Secure Development Lifecycle analysis but also for reactive code inspection across the enterprise. We aggregate the CodeQL databases produced by the various build systems or pipelines across Microsoft to a centralized infrastructure where we have the capability to query across the breadth of CodeQL databases at once. Aggregating CodeQL databases allows us to search semantically across our multitude of codebases and look for code conditions that may span between multiple assemblies, libraries, or modules based on the specific code that was part of a build. We built this capability to analyze thousands of repositories for newly described variants of vulnerabilities within hours of the variant being described, but it also allowed us to do a first-pass investigation for Solorigate implant patterns similarly, quickly.

We are open sourcing several of the C# queries that assess for these code-level IoCs, and they can currently be found in the CodeQL GitHub repository. The Solorigate-Readme.md within that repo contains detailed descriptions of each query and what code-level IoCs each one is attempting to find. It also contains guidance for other query authors on making adjustments to those queries or authoring queries that take a different tactic in finding the patterns.

GitHub will shortly publish guidance on how they are deploying these queries for existing CodeQL customers. As a reminder, CodeQL is free for open-source projects hosted by GitHub.

Our approach to finding code-level IoCs with CodeQL queries

We used two different tactics when looking for code-level Solorigate IoCs. One approach looks for particular syntax that stood out in the Solorigate code-level IoCs; the other approach looks for overall semantic patterns for the techniques present in the code-level IoCs.

The syntactic queries are very quick to write and execute while offering several advantages over comparable regular expression searches; however, they are brittle to the malicious actor changing the names and literals they use. The semantic patterns look for the overall techniques used in the implant, such as hashing process names, time delays before contacting the C2 servers, etc. These are durable to substantial variation, but they are more complicated to author and more compute-intensive when analyzing many codebases at once.

By combining these two approaches, the queries are able to detect scenarios where the malicious actor changed techniques but used similar syntax, or changed syntax but employed similar techniques. Because it’s possible that the malicious actor could change both syntax and techniques, CodeQL was but one part of our larger investigative effort.

Next steps with CodeQL

The queries we shared in this blog and described in Solorigate-Readme.md target patterns specifically associated with the Solorigate code-level IoCs, but CodeQL also provides many other options to query for backdoor functionality and detection-evasion techniques.

These queries were relatively quick to author, and we were able to hunt for patterns much more accurately across our CodeQL databases and with far less effort to manually review the findings, compared to using text searches of source code. CodeQL is a powerful developer tool, and our hope is that this post inspires organizations to explore how it can be used to improve reactive security response and act as a compromise detection tool.

In future blog posts, we’ll share more ways that Microsoft uses CodeQL. We’ll also continue open-sourcing queries and utilities that build upon CodeQL so that others may benefit from them and further build upon them.

The post Microsoft open sources CodeQL queries used to hunt for Solorigate activity appeared first on Microsoft Security Blog.

In part three of this series, we will further explore what it takes for security leaders to pivot their program from looking at their mission as purely defending against technical attacks to one that focuses on protecting valuable business assets, data, and applications. This pivot will enable business and cybersecurity leaders to remain better aligned and more resilient to a broader spectrum of attack vectors and attacker motivations.

What problem do we face?

First, let’s set a quick baseline on the characteristics of human-operated cyberattacks.

This diagram depicts commonalities and differences between for-profit ransomware and espionage campaigns:

Figure 1: Comparison of human-operated attack campaigns.

Typically, the attackers are:

• Flexible: Utilize more than one attack vector to gain entry to the network.
• Objective driven: Achieve a defined purpose from accessing your environment. This could be specific to your people, data, or applications, but you may also just fit a class of targets like “a profitable company that is likely to pay to restore access to their data and systems.”
• Stealthy: Take precautions to remove evidence or obfuscate their tracks (though at different investment and priority levels, see figure one)
• Patient: Take time to perform reconnaissance to understand the infrastructure and business environment.
• Well-resourced and skilled in the technologies they are targeting (though the depth of skill can vary).
• Experienced: They use established techniques and tools to gain elevated privileges to access or control different aspects of the estate (which grants them the privileges they need to fulfill their objective).

There are variations in the attack style depending on the motivation and objective, but the core methodology is the same. In some ways, this is analogous to the difference between a modern electric car versus a “Mad Max” style vehicle assembled from whatever spare parts were readily and cheaply available.

What to do about it?

Because human attackers are adaptable, a static technology-focused strategy won’t provide the flexibility and agility you need to keep up with (and get ahead of) these attacks. Historically, cybersecurity has tended to focus on the infrastructure, networks, and devices—without necessarily understanding how these technical elements correlate to business objectives and risk.

By understanding the value of information as a business asset, we can take concerted action to prevent compromise and limit risk exposure. Take email, for example, every employee in the company typically uses it, and the majority of communications have limited value to attackers. However, it also contains potentially highly sensitive and legally privileged information (which is why email is often the ultimate target of many sophisticated attacks). Categorizing email through only a technical lens would incorrectly categorize email as either a high-value asset (correct for those few very important items, but impossible to scale) or a low-value asset (correct for most items, but misses the “crown” jewels in email).

Figure 2: Business-centric security.

Security leaders must step back from the technical lens, learn what assets and data are important to business leaders, and prioritize how teams spend their time, attention, and budget through the lens of business importance. The technical lens will be re-applied as the security, and IT teams work through solutions, but looking at this only as a technology problem runs a high risk of solving the wrong problems.

It is a journey to fully understand how business value translates to technical assets, but it’s critical to get started and make this a top priority to end the eternal game of ‘whack-a-mole’ that security plays today.

Security leaders should focus on enabling this transformation by:

1. Aligning the business in a two-way relationship:

• Communicate in their language: explain security threats in business-friendly language and terminology that helps to quantify the risk and impact to the overall business strategy and mission.
• Participate in active listening and learning: talk to people across the business to understand the important business services and information and the impact if that were compromised or breached. This will provide clear insight into prioritizing the investment in policies, standards, training, and security controls.

2. Translating learnings about business priorities and risks into concrete and sustainable actions:

• Short term focus on dealing with burning priorities:
  • Protecting critical assets and high-value information with appropriate security controls (that increases security while enabling business productivity)
  • Focus on immediate and emerging threats that are most likely to cause business impact.
  • Monitoring changes in business strategies and initiatives to stay in alignment.

• Long term set direction and priorities to make steady progress over time, to improve overall security posture:
  • Zero Trust: Create a clear vision, strategy, plan, and architecture for reducing risks in your organization aligned to the zero trust principles of assuming breach, least privilege, and explicit verification. Adopting these principles shifts from static controls to more dynamic risk-based decisions that are based on real-time detections of anomalous behavior irrespective of where the threat derived.
  • Burndown technical debt as a consistent strategy by operating security best practices across the organization such as replacing password-based authentication with passwordless and multi-factor authentication (MFA), applying security patches, and retiring (or isolating) legacy systems. Just like paying off a mortgage, you need to make steady payments to realize the full benefit and value of your investments.
  • Apply data classifications, sensitivity labels, and role-based access controls to protect data from loss or compromise throughout its lifecycle. While these can’t completely capture the dynamic nature and richness of business context and insight, they are key enablers to guide information protection and governance, limiting the potential impact of an attack.

3. Establishing a healthy security culture by explicitly practicing, communicating, and publicly modeling the right behavior. The culture should focus on open collaboration between business, IT, and security colleagues and applying a ‘growth mindset’ of continuous learning. Culture changes should be focused on removing siloes from security, IT, and the larger business organization to achieve greater knowledge sharing and resilience levels.

You can read more on Microsoft’s recommendations for security strategy and culture here.

In the next blog of the series, we will explore the most common attack vectors, how and why they work so effectively, and the strategies to mitigate evolving cybersecurity threats.

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 Becoming resilient by understanding cybersecurity risks: Part 3—a security pro’s perspective appeared first on Microsoft Security Blog.

The Microsoft Security Research Center (MSRC), which has shared learnings and guidance throughout the Solorigate incident, confirmed today that following the completion of our internal investigation we’ve seen no evidence that Microsoft systems were used to attack others. There was also no evidence of access to our production services or customer data.  

However, a concerning aspect of this attack is that security companies were a clear target. Microsoft, given the expansive use of our productivity tools and leadership in security, of course was an early target. 

But while this highly-sophisticated nation state actor was able to breach the gate, they were met by a unified team of human and digital defenders. There are several reasons why we were able to limit the scope and impact of this incident for our company, customers, and partners, but ultimately, they all boil down to a few fundamental ways we approach security.  

We believe these approaches represent an opportunity for all IT and security teams as we collectively navigate a rapidly evolving and sophisticated threat landscape.  

Adopt a Zero Trust mindset

A key action is implementing a Zero Trust architecture. In this approach, companies must assume all activity—even by trusted users—could be an attempt to breach systems, and everything a company does should be designed around that assumption.  

To guard against these pervasive threats, it’s recommended that organizations deploy zero-trust architecture and defense-in-depth protections, installing defenses like a layer cake across code, coding tools, email, cloud apps, endpoints, identities, the developer community, defender products—everything. 

Zero Trust is a proactive mindset. When every employee at a company assumes attackers are going to land at some point, they model threats and implement mitigations to ensure that any potential exploit can’t expand. The value of defense-in-depth is that security is built into key areas an actor might try to break, beginning at the code level and extending to all systems in an end-to-end way.  

Customer Guidance: As companies think about deploying a zero-trust posture and making a transition from implicit trust to explicit verification, the first step to consider is protecting identities, especially privileged user accounts. Gaps in protecting identities (or user credentials), like weak passwords or lack of multifactor authentication, are opportunities for an actor to find their way into a system, elevate their status, and move laterally across the environments targeting email, source code, critical databases and more. We witnessed this in Solorigate when abandoned app accounts with no multi-factor authentication were used to access cloud administrative settings with high privilege. To explore protecting privileged identity and access, companies should review our post on Securing privileged access overview | Microsoft Docs. 

Embrace the cloud

We were also reminded of the importance of cloud technology over on-premises software. Cloud technologies like Microsoft 365, Azure, and the additional premium layers of services available as part of these solutions, improve a defender’s ability to protect their own environment.  

Baseline layers of protection are not enough for today’s sophisticated threats. Defense strategies must match up to these increasingly sophisticated attacks while factoring in the complexities of securing a remote workforce. If you are not thinking about advanced layers of protection that can detect, alert, prevent and respond to attacks across identities, email, cloud apps, and endpoints, you may be locking a door while leaving the window open. From Microsoft, consider technologies like Azure Active Directory and Microsoft 365 Defender. 

One of the most important pieces of guidance for any security posture that we can share right now is to layer up, no matter who your security vendors are. 

In addition, with the Microsoft cloud, customers benefit from industry-leading threat intelligence, powerful AI, machine learning, and defense-in-depth capabilities that most companies simply could not develop on their own. Our platform and services assess over eight trillion security signals every day, enabling Microsoft to take more of the work off a defender’s plate. Our technology can surface and correlate security alerts that could represent a larger issue or remediate issues on demand with our own threat experts. As an example, in 2020 over 30 billion email threats were blocked by Microsoft cloud technology. 

Customer Guidance: One of the things our customers should consider is managing identity and access from the cloud. When you rely on on-premises services, like authentication server, it is up to a customer to protect their identity infrastructure. With a cloud identity, like Azure Active Directory, we protect the identity infrastructure from the cloud. Our cloud-scale machine learning systems reason over trillions of signals in real time. So, we can detect and remediate attacks that nobody else can see. 

Strengthen the community of defenders

Finally, we know that we all have an important role to play in strengthening and empowering the defender community at large. It was great to see this sharing in action in December when FireEye first alerted the community of a “global intrusion campaign.”  

At Microsoft, communicating and collaborating with our customers and partners is a top priority. Over the past several weeks, security teams across Microsoft (Microsoft Threat Intelligence Center/MSTIC, Microsoft Detection and Response Team/DART, Microsoft Cyber Defense Operations Center/CDOC and Microsoft Security Response Center/MSRC) met daily and directly collaborated with customers and partners to share information and respond. We shared the latest threat intelligence, indicators of compromise (IOC), published more than 15 blogs with technical guidance and best practices, and notified customers of potentially related activity. We also offered security trials across our end-to-end product portfolio to give organizations the tools needed to combat this threat.  

This sharing is invaluable to the entire community.  

Customer Guidance: We encourage every company, of every size, to work with the community to share information, strengthen defenses and respond to attacks. Join our Microsoft Security and Compliance Tech Community to start or participate in a variety of community discussions. 

Security is a journey of progress over perfection, and with these three approaches working in unison, we can all help to make the world more safe and secure. 

The post Turning the page on Solorigate and opening the next chapter for the security community appeared first on Microsoft Security Blog.

Microsoft’s response to Nobelium

Since December, the United States, its government, and other critical institutions including security firms have been addressing the world’s latest serious nation-state cyberattack, sometimes referred to as ‘Solorigate’ or ‘SUNBURST’ and now referred to as Nobelium. As we shared earlier this is a moment of reckoning for our industry and needs a unified response of defenders across public and private sectors. Microsoft is committed to protecting our customers and safeguarding our communities and we are proud to partner with industry partners to respond to this attack and strengthen our collective defenses. We believe transparency and clarity are important for strong cybersecurity and in that spirit, we are sharing information about some commonly asked questions. We look forward to serving and protecting our customers and communities.

Question: What has Microsoft’s role been in the Nobelium incident?

Answer:

As Brad Smith wrote on December 17, 2020, this is a moment of reckoning for security. We believe the Nobelium incident is an opportunity for the industry to work together to share information, strengthen defenses, and respond to attacks. We are proud to be part of the collaborative work being done to empower the defender community. Over the past two months, there have been several disclosures related to the actor, Nobelium and Microsoft has had a unique perspective from several angles:

• Helping investigate with FireEye.
• Using indicators to find unusual activity and notifying customers and partners.
• Helping with customer investigations.
• Investigating our own environment.

In all of our investigations to date, data hosted in Microsoft services (including email) was sometimes a target in the incidents, but the attacker had gained privileged credentials in some other way.

Find the latest findings and guidance on Nobelium here.

Question: With your broad engagement, you’ve been criticized for not disclosing details as soon as you knew about them. How do you respond?

Answer:

We believe the Nobelium incident is an opportunity for the industry to work together to share information, strengthen defenses, and respond to attacks.

We have a very talented and experienced cybersecurity response team. In those situations where we provide investigative support to other organizations, we are restricted from sharing details. In these engagements, as well as when we notify organizations, those organizations have control in deciding what details they disclose and when they disclose them.

Additionally, investigations sometimes discover early indicators that require further research before they are actionable. Taking the time to thoroughly investigate incidents is necessary in order to provide the best guidance to the broader security community, our customers, and our partners.

We share actionable information regularly on our Nobelium resource center, and we are committed to providing additional updates if and when we discover new information to help inform and enable the community.

Question: The Cybersecurity & Infrastructure Security Agency (CISA) says other attack vectors have been discovered apart from SolarWinds. Has Microsoft in any way been an initial entry point for the Nobelium?

Answer:

No. In our investigations to date, data hosted in Microsoft services (including email) was sometimes a target in the incidents, but the attacker had gained privileged credentials in some other way.

From the beginning, we have said that we believe this is a sophisticated actor that has many tools in its toolkit, so it is not a surprise that a sophisticated actor would also use other methods to gain access to targets. In our investigations and through collaboration with our industry peers, we have confirmed several additional compromise techniques leveraged by the actor, including password spraying, spearphishing, use of webshell, through a web server, and delegated credentials.

As we learn more from our engagements, we will continue to improve our security products and share learnings with the community. For the most up-to-date information and guidance, please visit our resource center.

Question: What should we know about the Microsoft notifications to customers? Does that mean you detected a compromise in Microsoft services?

Answer:

No, it means our telemetry indicated unusual activity in authorized accounts.

As part of the investigative team working with FireEye, we were able to analyze the attacker’s behavior with a forensic investigation and identify unusual technical indicators that would not be associated with normal user interactions. We then used our telemetry to search for those indicators and identify organizations where credentials had likely been compromised by Nobelium.

Microsoft directly notifies the affected customers to provide the indicators they need to investigate the observed behavior with their organizational knowledge and within their specific context.

Question: Some have interpreted the wording in the SolarWinds 8K to mean that they were made aware of or were investigating an attack vector related to Microsoft Office 365. Has that been investigated?

The 8K wording is, “SolarWinds uses Microsoft Office 365 for its email and office productivity tools. SolarWinds was made aware of an attack vector that was used to compromise the Company’s emails and may have provided access to other data contained in the Company’s office productivity tools.”

Answer:

We have investigated thoroughly and have found no evidence they were attacked via Office 365. The wording of the SolarWinds 8K filing was unfortunately ambiguous, leading to erroneous interpretation and speculation, which is not supported by the results of our investigation. SolarWinds has confirmed these findings in their blog on February 3, 2021.

Question: Reuters broke news on December 17, 2020, alleging that “Microsoft’s own products were then used to further the attacks” and saying it was not immediately clear “how many Microsoft users were affected by the tainted products.” Is that article accurate?

Answer:

No, it is not accurate. As we said at the time, and based upon all investigations since, we have found no indications that our systems were used to attack others. Data hosted in Microsoft services (including email) were sometimes a post-compromise target of attack, but only after an attacker had gained privileged credentials in some other way.

Question: Some companies say the hackers entered its systems via Microsoft products. Do you dispute this?

Answer:

We’ve investigated each situation as we became aware of it and in each case, data hosted in Microsoft services (including email) were a target in the incident, but the attacker had gained privileged credentials in another way.

Question: When did Microsoft know about being attacked by Nobelium?

Answer:

Our security teams work continually to protect users, devices, and data from ongoing threats to our environment, but the investigations specifically focused on the Nobelium actor began when we became aware of the malicious SolarWinds applications.

We published a Microsoft Internal Investigation Update on December 31, 2020, and will provide another update soon.

Question: Given how serious Nobelium is, what can be done? What is the big takeaway?

Answer:

The cybersecurity industry has long been aware that sophisticated and well-funded actors were theoretically capable of advanced techniques, patience, and operating below the radar, but this incident has proven that it isn’t just theoretical.

We believe the Nobelium incident has proven the benefit of the industry working together to share information, strengthen defenses, and respond to attacks.

Additionally, the attacks have reinforced two key points that the industry has been advocating for a while now—defense-in-depth protections and embracing a zero trust mindset.

Defense-in-depth protections and best practices are really important because each layer of defense provides an extra opportunity to detect an attack and take action before they get closer to valuable assets. We saw this ourselves in our internal investigation, where we found evidence of attempted activities that were thwarted by defense-in-depth protections. So, we again want to reiterate the value of industry best practices such as outlined here, and implementing Privileged Access Workstations (PAW) as part of a strategy to protect privileged accounts.

A zero trust, “assume breach” philosophy is an important approach to defense. Many of the techniques we’ve observed are post-compromise techniques, so security companies and Microsoft are looking for ways to improve detections and provide protection even when an attacker gains unauthorized access.

The post Sophisticated cybersecurity threats demand collaborative, global response appeared first on Microsoft Security Blog.

UPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving forward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the examples of malware used by the actors. Microsoft Threat Intelligence Center (MSTIC) has named the actor behind the attack against SolarWinds, the SUNBURST backdoor, TEARDROP malware, and related components as NOBELIUM. As we release new content and analysis, we will use NOBELIUM to refer to the actor and the campaign of attacks.

More than a month into the discovery of Solorigate, investigations continue to unearth new details that prove it is one of the most sophisticated and protracted intrusion attacks of the decade. Our continued analysis of threat data shows that the attackers behind Solorigate are skilled campaign operators who carefully planned and executed the attack, remaining elusive while maintaining persistence. These attackers appear to be knowledgeable about operations security and performing malicious activity with minimal footprint. In this blog, we’ll share new information to help better understand how the attack transpired. Our goal is to continue empowering the defender community by helping to increase their ability to hunt for the earliest artifacts of compromise and protect their networks from this threat.

We have published our in-depth analysis of the Solorigate backdoor malware (also referred to as SUNBURST by FireEye), the compromised DLL that was deployed on networks as part of SolarWinds products, that allowed attackers to gain backdoor access to affected devices. We have also detailed the hands-on-keyboard techniques that attackers employed on compromised endpoints using a powerful second-stage payload, one of several custom Cobalt Strike loaders, including the loader dubbed TEARDROP by FireEye and a variant named Raindrop by Symantec.

One missing link in the complex Solorigate attack chain is the handover from the Solorigate DLL backdoor to the Cobalt Strike loader. Our investigations show that the attackers went out of their way to ensure that these two components are separated as much as possible to evade detection. This blog provides details about this handover based on a limited number of cases where this process occurred. To uncover these cases, we used the powerful, cross-domain optics of Microsoft 365 Defender to gain visibility across the entire attack chain in one complete and consolidated view.

We’ll also share our deep dive into additional hands-on-keyboard techniques that the attackers used during initial reconnaissance, data collection, and exfiltration, which complement the broader TTPs from similar investigative blogs, such as those from FireEye and Volexity.

The missing link: From the Solorigate backdoor to Cobalt Strike implants

An attack timeline that SolarWinds disclosed in a recent blog showed that a fully functional Solorigate DLL backdoor was compiled at the end of February 2020 and distributed to systems sometime in late March.  The same blog also said that the attackers removed the Solorigate backdoor code from SolarWinds’ build environment in June 2020.

Considering this timeline and the fact that the Solorigate backdoor was designed to stay dormant for at least two weeks, we approximate that the attackers spent a month or so in selecting victims and preparing unique Cobalt Strike implants as well as command-and-control (C2) infrastructure. This approximation means that real hands-on-keyboard activity most likely started as early as May.

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

Figure 1. Timeline of the protracted Solorigate attack

But how exactly does this jump from the Solorigate backdoor (SUNBURST) to the Cobalt Strike loader (TEARDROP, Raindrop, and others) happen? What code gets triggered, and what indicators should defenders look for?

Figure 2. Diagram of transition between Stage 1 and Stage 2 of the Solorigate attack

Sophisticated attackers like those behind Solorigate have a goal of expansion and stealthy persistence to maximize the amount of time they can remain undetected and collect valuable information. It’s important for organizations to be able to look at forensic data across their entire environment to see how far attackers have traversed the network and how long they were there, in order to have confidence that attacks have been properly remediated from the environment. The best way to do that is with an extended detection and response (XDR) solution that enables organizations to replay past events to look for activity that might reveal the presence of an attacker on the network. Affected organizations without an XDR solution like Microsoft 365 Defender in place will have a difficult job of performing incident response.

What we found from our hunting exercise across Microsoft 365 Defender data further confirms the high level of skill of the attackers and the painstaking planning of every detail to avoid discovery. To illustrate, the following diagram shows the entry vector attack chain at a glance:

Figure 3. Transition from Solorigate backdoor to Cobalt Strike

We spent countless hours investigating Microsoft Defender telemetry and other signals from potential patient-zero machines running the backdoored version of SolarWinds DLL. Most of these machines communicated with the initial randomly generated DNS domain .avsvmcloud.com but without significant activity (step #1). However, we saw limited cases in May and June where the initial DNS network communication was closely followed by network activity on port 443 (HTTPS) to other legit-looking domains (step #7). On these handful of machines, we performed deep inspection of telemetry.

We know that the Solorigate backdoor only activates for certain victim profiles, and when this happens, the executing process (usually SolarWinds.BusinessLayerHost.exe) creates two files on disk (step #2):

• A VBScript, typically named after existing services or folders to blend into legitimate activities on the machine
• A second-stage DLL implant, a custom Cobalt Strike loader, typically compiled uniquely per machine and written into a legitimate-looking subfolder in %WinDir% (e.g., C:\Windows)

At this point the attackers are ready to activate the Cobalt Strike implant. However, the attackers apparently deem the powerful SolarWinds backdoor too valuable to lose in case of discovery, so they tried to separate the Cobalt Strike loader’s execution from the SolarWinds process as much as possible. Their hope is that, even if they lose the Cobalt Strike implant due to detection, the compromised SolarWinds binary and the supply chain attack that preceded it are not exposed.

The attackers achieved this by having the SolarWinds process create an Image File Execution Options (IFEO) Debugger registry value for the process dllhost.exe (step #3). This is a known MITRE ATT&CK technique used for persistence, but it could also be abused to trigger execution of malicious code when a certain process is launched. Once the registry value is created, the attackers simply wait for the occasional execution of dllhost.exe, which might happen naturally on a system. This execution triggers a process launch of wscript.exe configured to run the VBScript file dropped in step #4.

The VBScript in turn runs rundll32.exe, activating the Cobalt Strike DLL (step #5) using a clean parent/child process tree completely disconnected from the SolarWinds process. Finally, the VBScript removes the previously created IFEO value to clean up any traces of execution (step #6) and also deletes the following registry keys related to HTTP proxy:

• HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoDetect
• HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL

Analyzing the custom Cobalt Strike loaders

In our investigation, we identified several second-stage malware, including TEARDROP, Raindrop, and other custom loaders for the Cobalt Strike beacon. During the lateral movement phase, the custom loader DLLs are dropped mostly in existing Windows sub-directories. Below are some example paths (additional paths are listed at the end of this blog):

• C:\Windows\ELAMBKUP\WdBoot.dll
• C:\Windows\Registration\crmlog.dll
• C:\Windows\SKB\LangModel.dll
• C:\Windows\AppPatch\AcWin.dll
• C:\Windows\PrintDialog\appxsig.dll
• C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
• C:\Windows\Panther\MainQueueOnline.dll
• C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
• C:\Windows\LiveKernelReports\KerRep.dll

The files have names that resemble legitimate Windows file and directory names, once again demonstrating how the attackers attempted to blend in the environment and hide in plain sight:

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

Figure 4. Structure of the two variants of Cobalt Strike Beacon loaders observed in Solorigate attacks

In the succeeding sections, we discuss the Cobalt Strike Beacon variants we observed in our Solorigate investigations.

Variant 1: TEARDROP

To date, Microsoft has analyzed two versions of the second-stage custom Cobalt Strike Beacon loader known as TEARDROP (detected as Trojan:Win64/Solorigate.SA!dha by Microsoft):

• A service DLL (loaded by svchost.exe) with a ServiceMain function typically named NetSetupServiceMain
• A standard non-Service DLL loaded by rundll32.exe

Irrespective of the loading methodology, both versions have an export function that contains the trigger for the malicious code. The malicious code is executed in a new thread created by the export function. Upon execution, the malicious code attempts to open a file with a .jpg extension (e.g., festive_computer.jpg, upbeat_anxiety.jpg, gracious_truth.jpg, and confident_promotion.jpg). Further analysis is required to determine the purpose and role of the .jpg file referenced by each sample. The code also checks the presence of the Windows registry key SOFTWARE\Microsoft\CTF and terminates if the registry key is present or accessible. Next, the code proceeds to decode and subsequently execute an embedded custom preliminary loader.

Figure 5. Structure of Variant 1 custom loader

The preliminary loader used by this variant of custom loader is typically generated using a Cobalt Strike Artifact Kit template (e.g., bypass-pipe.c):

Figure 6. Disassembled function from preliminary loader compiled from Artifact Kit’s bypass-pipe.c template

In its true form, the custom Artifact Kit-generated preliminary loader is a DLL that has been transformed and loaded like shellcode in memory. The preliminary loader is responsible for loading the next-stage component, which is a Beacon Reflective Loader/DLL (Cobalt Strike Beacon is compiled as a reflective DLL). The Reflective Loader ultimately initializes and executes Beacon in memory.

Variant 2: Additional custom loaders

In our investigations, we came across additional custom loaders for Cobalt Strike’s Beacon that appear to be generated using custom Cobalt Strike Artifact Kit templates. Unlike TEARDROP, in which the malicious code is triggered by an export function, the malicious code in these variants is triggered directly from the DLL’s entry point, which creates a new thread to execute the malicious code. These Variant 2 custom loaders also contain an attacker-introduced export (using varying names) whose only purpose is to call the Sleep() function every minute.

Figure 7. Example of a custom export function from a Variant 2 loader

Additionally, unlike TEARDROP, these variants do not contain a custom preliminary loader, meaning the loader DLL de-obfuscates and subsequently executes the Cobalt Strike Reflective DLL in memory.

Figure 8. Structure of Variant 2 custom Loader

These custom loaders can be further divided into two types:

• Type A: A set of large DLLs that decode and load the Cobalt Strike Reflective Loader from the DLL’s DATA section (detected as Trojan:Win64/Solorigate.SC!dha by Microsoft)
• Type B: A set of smaller DLLs that de-obfuscate and load the Reflective Loader from the DLL’s CODE section (also referred to as Raindrop by Symantec, detected as Trojan:Win64/Solorigate.SB!dha by Microsoft)

Figure 9. Two subtypes of the custom Loader

The ultimate goal of both Type A and B loaders is to de-obfuscate and load a Cobalt Strike Reflective Loader in memory. Type A loaders use a simple rolling XOR methodology to decode the Reflective Loader, while Type B loaders (Raindrop) utilize a combination of the AES-256 encryption algorithm (unique key per sample), LZMA compression, and a single-byte XOR decoding routine to de-obfuscate the embedded Reflective Loader in memory. At the conclusion of the de-obfuscation process, both variants proceed to load the Reflective Loader in memory, which subsequently executes Cobalt Strike Beacon in memory.

Forensic observations about the Solorigate Cobalt Strike loaders

Metadata and timeline analysis of the custom loaders, combined with analysis of the configuration data extracted from each Beacon payload, led to following discoveries:

• The custom loader DLLs were introduced to compromised systems between the hours of 8:00 AM and 5:00 PM UTC. In one intrusion, the first second-stage custom loader (TEARDROP) was introduced to the environment by BusinessLayerHost.exe at around 10:00 AM UTC.
• The custom loader DLLs dropped on disk carried compile timestamps ranging from July 2020 to October 2020, while the embedded Reflective DLLs carried compile timestamps ranging from March 2016 to November 2017. The presence of 2016-2017 compile timestamps is likely due to attackers’ usage of custom Malleable C2 profiles with synthetic compile timestamp (compile_time) values. At first glance it would appear as if the actor did not timestamp the compile time of the custom loader DLLs (2020 compile timestamps). However, forensic analysis of compromised systems revealed that in a few cases, the timestamp of the custom loader DLLs’ introduction to systems predated the compile timestamps of the custom loader DLLs (i.e., the DLLs appear to have been compiled at a future date).
• Both Variant 1 and 2 custom loader DLLs were configured with PE version information that masquerades version information belonging to legitimate applications and files from Windows (e.g., DLL), 7-Zip (e.g., 7z.dll), Far Manager (e.g., Far.dll), LibIntl (e.g., libintl3.dll), and other legitimate applications. The Variant 2 custom loaders were mostly compiled from open-source source code of legitimate applications, such as 7-Zip and Far Manager (i.e., the open-source source code for these applications was modified to add in the malicious code). In some instances, certain development artifacts were left behind in the custom loader samples. For example, the following C++ header (.hpp) path was observed in a loader compiled from a modified Far Manager open-source source code (c:\build\workspace\cobalt_cryptor_far (dev071)\farmanager\far\platform.concurrency.hpp):

Figure 10. File path for a C++ header file (.hpp) observed in custom Cobalt Strike loader samples

• Each custom loader DLL contains a designated PE export function that either triggers the malicious functionality of the loader (in Variant 1) or calls the Sleep() function (Variant 2). A non-comprehensive list of these PE export function names (one per loader DLL) is included below (note the repeating “Tk” prefix in the export names that can be a useful indicator for hunting purposes):

• In addition to the attackers dropping the custom loaders in unique locations on each system during the lateral movement phase, most Beacon and Reflective Loader instances discovered during our investigation were configured with a unique C2 domain name, unique Watermark ID, unique PE compile timestamp, PE Original Name (), DNS Idle IP (e.g., 84[.]200[.]70[.]40 , 208[.]67[.]220[.]220, 208[.]67[.]222[.]222, 9[.]9[.]9[.]9, and 8[.]8[.]4[.]4), unique User-Agent and HTTP POST/GET transaction URI, sleep time, and jitter factor. This is notable since no two Beacon instances shared the same C2 domain name, Watermark, or other aforementioned configuration values. Other than certain internal fields, most Beacon configuration fields are customizable via a Malleable C2 profile. If the actor did indeed use custom Malleable C2 profiles, as evidenced in the list above, the profiles varied greatly for Beacon instances used during different lateral movement campaigns within the same network. As mentioned above, each Beacon instance carries a unique Watermark value. Analysis of the Watermark values revealed that all Watermark values start with the number ‘3’, for example:

• As for post-exploitation artifacts, the observed Beacon instances were configured to use different “spawnto” values, which Cobalt Strike uses to spawn a temporary process and inject its post-exploitation-related components or features into the spawned process. This detail could be valuable for hunting process creation events originated by exe. Below are some example paths used by the observed Beacon instances:
  • %WINDIR%\System32\conhost.exe
  • %WINDIR%\System32\control.exe
  • %WINDIR%\System32\dllhost.exe
  • %WINDIR%\System32\help.exe
  • %WINDIR%\System32\LogonUI.exe
  • %WINDIR%\System32\msiexec.exe
  • %WINDIR%\System32\print.exe
  • %WINDIR%\SysWOW64\audiodg.exe
  • %WINDIR%\SysWOW64\help.exe
  • %WINDIR%\SysWOW64\msiexec.exe
  • %WINDIR%\SysWOW64\msinfo32.exe
  • %WINDIR%\SysWOW64\print.exe
  • %WINDIR%\SysWOW64\WerFault.exe

Additional attacker tactics, anti-forensic behavior, and operational security

As mentioned, the attackers behind Solorigate are skillful and methodic operators who follow operations security (OpSec) best practices to minimize traces, stay under the radar, and avoid detection.

During our in-depth analysis of the attacker’s tactics, techniques, and procedures (TTPs) seen through the lens of Microsoft 365 Defender’s rich telemetry, we observed a few techniques that are worth disclosing to help other defenders better respond to this incident and use hunting tools like Microsoft 365 Defender advanced hunting or Azure Sentinel queries to search for potential traces of past activity.

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

• Methodic avoidance of shared indicators for each compromised host. As discussed in the previous section, each Cobalt Strike DLL implant was prepared to be unique per machine and avoided at any cost overlap and reuse of folder name, file name, export function names, C2 domain/IP, HTTP requests, timestamp, file metadata, config, and child process launched. This extreme level of variance was also applied to non-executable entities, such as WMI persistence filter name, WMI filter query, passwords used for 7-zip archives, and names of output log files. Applying this level of permutations for each individual compromised machine is an incredible effort normally not seen with other adversaries and done to prevent full identification of all compromised assets inside a network or effective sharing of threat intel between victims.
• Camouflage and blending into the environment. Tools and binaries used by the attackers (e.g., ADFIND legit tool) were always renamed and placed in folders that mimicked existing programs and files already present on a machine. This blending was not just used for files, but for other elements. For example, WMI persistence filters were created with names and queries matching other scripts present in affected organizations.
• Before running intensive and continued hands-on keyboard activity, the attackers took care of disabling event logging using AUDITPOL and re-enabling it afterward.
• In a similar way, before running noisy network enumeration activities (such as repeated NSLOOKUP or LDAP queries), the attackers carefully prepared special firewall rules to minimize outgoing packets for certain protocols. The firewall rules were also methodically removed after the network reconnaissance was completed.
• Lateral movement activities were never executed without preparation. To increase the likelihood that their activities remain undetected, the attackers first enumerated remote processes and services running on the target host and decided to move laterally only after disabling certain security services.
• We believe that the attackers used timestomping to change timestamps of artifacts and also leveraged professional wiping procedures and tools to complicate finding and recovering of DLL implants from affected environments.

See some of the most interesting and unique TTPs in the table below. In most cases, commands and tools are executed via an intermediate “cmd.exe /C” process launched from the Cobalt Strike main parent process. We are actively working with MITRE to make sure that any novel technique emerging from this incident is documented in future updates of the ATT&CK framework.

Conclusion

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

Modern attacks like Solorigate highlight the need for organizations to use advanced security solutions like Microsoft 365 Defender and Azure Sentinel and operate security response under an “assume breach” mentality. Microsoft 365 Defender harnesses the power of multiple capabilities and coordinates protection across domains to provide comprehensive defense. Azure Sentinel collects data from multiple data sources, including Microsoft 365 Defender, to connect data together and allow broad hunting for attacker activity.

In our ongoing forensic analysis of known Solorigate cases with malicious activity occurring between May and November 2020, we have in some instances seen the following relevant alerts generated by Microsoft Defender for Endpoint and Microsoft Defender for Identity. Incident responders and defenders investigating Solorigate incidents during that timeframe can refer to these alerts, alone or in combination, as potential indicators of the Solorigate activity.

Microsoft Defender for Endpoint alerts:

• Low-reputation arbitrary code executed by signed executable
• Suspicious ‘Atosev’ behavior was blocked
• Suspicious Remote WMI Execution
• A WMI event filter was bound to a suspicious event consumer

Microsoft Defender for Identity alerts:

• User and IP address reconnaissance (SMB)
• Suspected Kerberos SPN exposure

Figure 11. Alert raised by Microsoft Defender for Endpoint on Solorigate-related malicious activity in June 2020

The disclosure of the Solorigate attack and the investigations that followed unearthed more details and intelligence that we used to improve existing detections and build new ones. Security operations teams looking to get a comprehensive guide on detecting and investigating Solorigate can refer to Using Microsoft 365 Defender to protect against Solorigate.

Meanwhile, security administrators can use the recommendations for hardening networks against Solorigate and similar sophisticated cyberattacks outlined in Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender.

To get the latest information and guidance from Microsoft, visit https://aka.ms/solorigate.

Microsoft 365 Defender Research Team

Microsoft Threat Intelligence Center (MSTIC)

Microsoft Cyber Defense Operations Center (CDOC)

Indicators of compromise (IoCs)

Custom Cobalt Strike Beacon loader (SHA-256):

118189f90da3788362fe85eafa555298423e21ec37f147f3bf88c61d4cd46c51
1817a5bf9c01035bcf8a975c9f1d94b0ce7f6a200339485d8f93859f8f6d730c
1ec138f21a315722fb702706b4bdc0f544317f130f4a009502ec98345f85e4ad
2a276f4b11f47f81dd2bcb850a158d4202df836769da5a23e56bf0353281473e
327f1d94bc26779cbe20f8689be12c7eee2e390fbddb40b92ad00b1cddfd6426
3985dea8e467c56e8cc44ebfc201253ffee923765d12808aaf17db2c644c4c06
557f91404fb821d7c1e98d9f2f5296dc12712fc19c87a84602442b4637fb23d4
5cf85c3d18cd6dba8377370883a0fffda59767839156add4c8912394f76d6ef0
5f8650ca0ed22ad0d4127eb4086d4548ec31ad035c7aec12c6e82cb64417a390
674075c8f63c64ad5fa6fd5e2aa6e4954afae594e7b0f07670e4322a60f3d0cf
6ff3a4f7fd7dc793e866708ab0fe592e6c08156b1aa3552a8d74e331f1aea377
7c68f8d80fc2a6347da7c196d5f91861ba889afb51a4da4a6c282e06ef5bdb7e
915705c09b4bd108bcd123fe35f20a16d8c9c7d38d93820e8c167695a890b214
948bfdfad43ad52ca09890a4d2515079c29bdfe02edaa53e7d92858aa2dfbe4c
955609cf0b4ea38b409d523a0f675d8404fee55c458ad079b4031e02433fdbf3
b348546f4c6a9bcafd81015132f09cf8313420eb653673bf3d65046427b1167f
b35e0010e0734fcd9b5952ae93459544ae33485fe0662fae715092e0dfb92ad3
b820e8a2057112d0ed73bd7995201dbed79a79e13c79d4bdad81a22f12387e07
be9dbbec6937dfe0a652c0603d4972ba354e83c06b8397d6555fd1847da36725
c5a818d9b95e1c548d6af22b5e8663a2410e6d4ed87df7f9daf7df0ef029872e
c741797dd400de5927f8b5317165fc755d6439749c39c380a1357eac0a00f90c
c7924cc1bc388cfcdc2ee2472899cd34a2ef4414134cbc23a7cb530650f93d98
c96b7a3c9acf704189ae8d6124b5a7b1f0e8c83c246b59bc5ff15e17b7de4c84
cbbe224d9854d6a4269ed2fa9b22d77681f84e3ca4e5d6891414479471f5ca68
cdd9b4252ef2f6e64bccc91146ec5dc51d94e2761184cd0ffa9909aa739fa17e
dbd26ccb3699f426dc6799e218b91d1a3c1d08ad3006bc2880e29c755a4e2338
e60e1bb967db273b922deeea32d56fc6d9501a236856ef9a3e5f76c1f392000a
f2d38a29f6727f4ade62d88d8a68de0d52a0695930b8c92437a2f9e4de92e418
f61a37aa8581986ba600286d65bb76100fb44e347e253f1f5ad50051e5f882f5
f81987f1484bfe5441be157250b35b0a2d7991cf9272fa4eacd3e9f0dee235de

File paths for the custom Cobalt Strike Beacon loader:

C:\Windows\ms\sms\sms.dll
C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
C:\Windows\AUInstallAgent\auagent.dll
C:\Windows\apppatch\apppatch64\sysmain.dll
C:\Windows\Vss\Writers\Application\AppXML.dll
C:\Windows\PCHEALTH\health.dll
C:\Windows\Registration\crmlog.dll
C:\Windows\Cursors\cursrv.dll
C:\Windows\AppPatch\AcWin.dll
C:\Windows\CbsTemp\cbst.dll
C:\Windows\AppReadiness\Appapi.dll
C:\Windows\Panther\MainQueueOnline.dll
C:\Windows\AppReadiness\AppRead.dll
C:\Windows\PrintDialog\PrintDial.dll
C:\Windows\ShellExperiences\MtUvc.dll
C:\Windows\PrintDialog\appxsig.dll
C:\Windows\DigitalLocker\lock.dll
C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
C:\Windows\Migration\WTR\ctl.dll
C:\Windows\ELAMBKUP\WdBoot.dll
C:\Windows\LiveKernelReports\KerRep.dll
C:\Windows\Speech_OneCore\Engines\TTS\en-US\enUS.Name.dll
C:\Windows\SoftwareDistribution\DataStore\DataStr.dll
C:\Windows\RemotePackages\RemoteApps\RemPack.dll
C:\Windows\ShellComponents\TaskFlow.dll

Cobalt Strike Beacon:

aimsecurity[.]net
datazr[.]com
ervsystem[.]com
financialmarket[.]org
gallerycenter[.]org
infinitysoftwares[.]com
mobilnweb[.]com
olapdatabase[.]com
swipeservice[.]com
techiefly[.]com

Advanced hunting queries

A collection of Advanced Hunting Queries (AHQ) related to Solorigate is located in our AHQ repository in GitHub. To locate possible exploitation activity related to the contents of this blog, you can run the following advanced hunting queries via Microsoft Defender for Endpoint:

Anomalous usage of 7zip

Look for anomalous usage or running process of 7zip. Run query in Microsoft Defender for Endpoint.

DeviceProcessEvents
| where InitiatingProcessFileName in~("rundll32.exe", "dllhost.exe") 
and InitiatingProcessCommandLine != "" 
and InitiatingProcessCommandLine !contains " "
| extend RundllTime = Timestamp
| join DeviceProcessEvents on $left.DeviceId == $right.DeviceId
| where InitiatingProcessFileName hasprefix "7z" 
or InitiatingProcessCommandLine has "-mx9"
| extend DateDiff = datetime_diff("day", Timestamp, RundllTime)
| where DateDiff < 2

Presence of custom Cobalt Strike

Look for presence of custom cobalt strike loaders. Run query in Microsoft Defender for Endpoint.

DeviceProcessEvents
| where FileName =~ "rundll32.exe"
| where InitiatingProcessIntegrityLevel in ("High", "System")
| where ProcessCommandLine matches regex 
@'(?i)rundll32\s+c\:\\windows(\\[^\\]+)+\.dll\s+[a-zA-Z0-9_]{3,}'

Command and control

Look for command-and-control connections. Run query in Microsoft Defender for Endpoint.

DeviceNetworkEvents
| where InitiatingProcessParentFileName =~ "rundll32.exe"
| where InitiatingProcessFileName =~ "dllhost.exe" 
and InitiatingProcessCommandLine != "" 
and InitiatingProcessCommandLine !contains " "

Look for network connections to known command and control domains. Run query in Microsoft Defender for Endpoint.

DeviceNetworkEvents
| where RemoteUrl in~('aimsecurity.net',
'datazr.com',
'ervsystem.com',
'financialmarket.org',
'gallerycenter.org',
'infinitysoftwares.com',
'mobilnweb.com',
'olapdatabase.com',
'swipeservice.com',
'techiefly.com')

The post Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop appeared first on Microsoft Security Blog.

Companies operating with a Zero Trust mentality across their entire environment are more resilient, consistent, and responsive to new attacks—Solorigate is no different. As threats increase in sophistication, Zero Trust matters more than ever, but gaps in the application of the principles—such as unprotected devices, weak passwords, and gaps in multi-factor authentication (MFA) coverage can be exploited by actors.

Applying Zero Trust

Zero Trust in practical terms is a transition from implicit trust—assuming that everything inside a corporate network is safe—to the model that assumes breach and explicitly verifies the security status of identity, endpoint, network, and other resources based on all available signals and data. It relies on contextual real-time policy enforcement to achieve least privileged access and minimize risks. Automation and Machine Learning are used to enable rapid detection, prevention, and remediation of attacks using behavior analytics and large datasets.

Verify explicitly

To verify explicitly means we should examine all pertinent aspects of access requests instead of assuming trust based on a weak assurance like network location. Examine the identity, endpoint, network, and resource then apply threat intelligence and analytics to assess the context of each access request.

When we look at how attackers compromised identity environments with Solorigate, there were three major vectors: compromised user accounts, compromised vendor accounts, and compromised vendor software. In each of these cases, we can clearly see where the attacker exploited gaps in explicit verification.

• Where user accounts were compromised, known techniques like password spray, phishing, or malware were used to compromise user credentials and gave the attacker critical access to the customer network. On-premises identity systems are more vulnerable to these common attacks because they lack cloud-powered protections like password protection, recent advances in password spray detection, or enhanced AI for account compromise prevention.
• Again, in cases where the actor succeeded, highly privileged vendor accounts lacked protections such as MFA, IP range restrictions, device compliance, or access reviews. In other cases, user accounts designated for use with vendor software were configured without MFA or policy restrictions. Vendor accounts should be configured and managed with the same rigor as used for the accounts which belong to the organization.
• Even in the worst case of SAML token forgery, excessive user permissions and missing device and network policy restrictions allowed the attacks to progress. The first principle of Zero Trust is to verify explicitly—be sure you extend this verification to all access requests, even those from vendors and especially those from on-premises environments.

Cloud identity, like Azure Active Directory (Azure AD), is simpler and safer than federating with on-premises identity. Not only is it easier to maintain (fewer moving parts for attackers to exploit), your Zero Trust policy should be informed by cloud intelligence. Our ability to reason over more than eight trillion signals a day across the Microsoft estate coupled with advanced analytics allows for the detection of anomalies that are very subtle and only detectable in very large data sets. User history, organization history, threat intelligence, and real-time observations are an essential mechanism in a modern defense strategy. Enhance this signal with endpoint health and compliance, device compliance policies, app protection policies, session monitoring, and control, and resource sensitivity to get to a Zero Trust verification posture.

For customers that use federation services today, we continue to develop tools to simplify migration to Azure AD. Start by discovering the apps that you have and analyzing migration work using Azure AD Connect health and activity reports.

Least privileged access

Least privileged access helps ensure that permissions are only granted to meet specific business goals from the appropriate environment and on appropriate devices. This minimizes the attacker’s opportunities for lateral movement by granting access in the appropriate security context and after applying the correct controls—including strong authentication, session limitations, or human approvals and processes. The goal is to compartmentalize attacks by limiting how much any compromised resource (user, device, or network) can access others in the environment.

With Solorigate, the attackers took advantage of broad role assignments, permissions that exceeded role requirements, and in some cases abandoned accounts and applications which should have had no permissions at all. Conversely, customers with good least-privileged access policies such as using Privileged Access Workstations (PAW) devices were able to protect key resources even in the face of initial network access by the attackers.

Assume breach

Our final principle is to Assume Breach, building our processes and systems assuming that a breach has already happened or soon will. This means using redundant security mechanisms, collecting system telemetry, using it to detect anomalies, and wherever possible, connecting that insight to automation to allow you to prevent, respond and remediate in near-real-time.

Sophisticated analysis of anomalies in customer environments was key to detecting this complex attack. Customers that used rich cloud analytics and automation capabilities, such as those provided in Microsoft 365 Defender, were able to rapidly assess attacker behavior and begin their eviction and remediation procedures.

Importantly, organizations such as Microsoft who do not model “security through obscurity” but instead model as though the attacker is already observing them are able to have more confidence that mitigations are already in place because threat models assume attacker intrusions.

Summary and recommendations

It bears repeating that Solorigate is a truly significant and advanced attack. However ultimately, the attacker techniques observed in this incident can be significantly reduced in risk or mitigated by the application of known security best practices. For organizations—including Microsoft—thorough application of a Zero Trust security model provided meaningful protection against even this advanced attacker.

To apply the lessons from the Solorigate attack and the principles of Zero Trust that can help protect and defend, get started with these recommendations:

1. More than any other single step, enable MFA to reduce account compromise probability by more than 99.9 percent. This is so important, we made Azure AD MFA free for any Microsoft customer using a subscription of a commercial online service.
2. Configure for Zero Trust using our Zero Trust Deployment Guides.
3. Look at our Identity workbook for Solorigate.

Stay safe out there.

— Alex Weinert

For more information about Microsoft Zero Trust please 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 Using Zero Trust principles to protect against sophisticated attacks like Solorigate appeared first on Microsoft Security Blog.