Archive

Archive for March, 2021

Zero Trust: 7 adoption strategies from security leaders

March 31st, 2021 No comments

Microsoft considers Zero Trust an essential component of any organization’s security plan. We have partnered with Cloud Security Alliance, a not-for-profit organization that promotes cloud computing best practices, to bring together executive security leaders to discuss and share insights about their Zero Trust journeys.

In our first discussion, we sat down with 10 executive security leaders from prominent energy, finance, insurance, and manufacturing companies in a virtual roundtable, to understand what has worked and discover where they needed to adjust their Zero Trust security model. Our collective goal was to learn from one another and then share what we’ve learned with other organizations. Discussions like these give us valuable opportunities to grow and led us to publish an eBook to share those conversations with other cybersecurity professionals.

Today, we are publishing the “Examining Zero Trust: An executive roundtable discussion” eBook as a result of those conversations. The eBook describes how the Zero Trust security model involves thinking beyond perimeter security and moving to a more holistic security approach. The eBook complements other resources we have published to help organizations expedite their journeys in this critical area, such as the Microsoft Zero Trust Maturity Model and adoption guidance in the Zero Trust Deployment Center. Zero Trust assumes breach and verifies each request as if it originates from an uncontrolled network. If Zero Trust had a motto, it would be: never trust, always verify. That means never trusting anyone or anything—inside or outside the firewall, on the endpoint, on the server, or in the cloud.

Zero Trust strategies

Introducing Zero Trust into your organization requires implementing controls and technologies across all foundational elements: identities, devices, applications, data, infrastructure, and networks. Roundtable participants offered successful Zero Trust strategies that respect the value of each of these foundational elements.

Strategy #1 – Use identities to control access

Identities—representing people, services, and IoT devices—are the common denominator across networks, endpoints, and applications. In a Zero Trust security model, they function as a powerful, flexible, and granular way to control access to data. Or, as one participant explained it, “The new perimeter is identity, and you need a strong identity that is validated.”

When any identity attempts to access any resource, security controls should verify the identity with strong authentication, ensure access is compliant and typical for that identity, and confirm that the identity follows least privilege access principles.

Strategy #2 – Elevate authentication

Incorporating multifactor authentication or continuous authentication into your identity management strategy can substantially improve your organization’s information security posture. One roundtable participant shared that by extending identity management with continuous authentication capabilities, their organization can now validate identity when a user’s IP address or routine behavior pattern changes.

“Zero Trust will only work if it is transparent to the end-user,” said a participant. “You have to make it easy and transparent. If you want to authenticate every five minutes or every second, that’s fine, as long as the end-user doesn’t have to do anything—as long as you can validate through other methods. For example, the endpoint can be one of the factors for multifactor authentication.”

Strategy #3 – Incorporate passwordless authentication

Passwordless authentication replaces the traditional password with two or more verification factors secured with a cryptographic key pair. When registered, the device creates a public and private key. The private key can be unlocked using a local gesture, such as a PIN or biometric authentication (fingerprint scan, facial recognition, or iris recognition).

Strategy #4 – Segment your corporate network

Network segmentation can be a pain point for business IT because firewalls represent early segmentation, and this can complicate development and testing. Ultimately, the IT team relies more on security teams to fix networking connectivity and access issues.

However, segmenting networks and conducting deeper in-network micro-segmentation is important for Zero Trust because in a mobile- and cloud-first world, all business-critical data is accessed over network infrastructure. Networking controls provide critical functionality to enhance visibility and help prevent attackers from moving laterally across the network.

Strategy #5 – Secure your devices

With the Zero Trust model, the same security policies are applied whether the device is corporately owned or a personally owned phone or tablet, also called a “bring your own device” (BYOD). Corporate, contractor, partner, and guest devices are treated the same whether the device is fully managed by IT or only the apps and data are secured. And this is true whether these endpoints—PC, Mac, smartphone, tablet, wearable, or IoT device—are connected using the secure corporate network, home broadband, or public internet.

“In a BYOD world, the device is the explosive piece,” said one participant. “If you allow unpatched devices to connect to your network, it is, in essence, walking into your base with live ordinance, and it can go bad quickly. Why wouldn’t you test outside to begin with?”

Strategy #6 – Segment your applications

Benefitting fully from cloud apps and services requires finding the right balance between providing access and maintaining control to ensure that apps, and the data they contain, are protected. Apply controls and technologies to discover shadow IT, ensure appropriate in-app permissions, gate access based on real-time analytics, monitor for abnormal behavior, restrict user actions, and validate secure configuration options.

“It is becoming easier and more achievable to have segmentation between the applications,” said a participant. “Being able to provide excessive privileges/role-based access is becoming part of the policy engine. The application piece of the puzzle seems to be solving itself more intelligently as time goes on. This approach gets validated every time I hear an end-user is able to dial in on the problem.”

Strategy #7 – Define roles and access controls

With the rapid rise in remote work, organizations must consider alternative ways of achieving modern security controls. It’s useful to operationalize roles and tie them to a policy as part of authorization, single sign-on, passwordless access, and segmentation. However, each role defined must be managed now and, in the future, so be selective about how many roles you create so there aren’t management challenges later.

“If you create a thousand roles in your organization to be that granular, you will have problems with management down the road,” said a participant. “You’re going to end up with massive amounts of accounts that are not updated, and that’s where you have breaches.”

The journey toward Zero Trust

The foundational focus of organizations varies as they start their Zero Trust journey. Some of the organizations represented by roundtable participants began their Zero Trust journey with user identity and access management, while others started with network macro- and micro-segmentations or application sides. These leaders agreed that developing a holistic strategy to address Zero Trust is critical and that you should start small and build confidence before rolling out Zero Trust across your organization.

That usually means taking a phased approach that targets specific areas based on the organization’s Zero Trust maturity, available resources, and priorities. For example, you could start with a new greenfield project in the cloud or experiment in a developer and test environment. Once you’ve built confidence, we recommend extending the Zero Trust model throughout the entire digital estate, while embracing it as an integrated security philosophy and end-to-end strategy moving forward. You’re not alone in this journey. Successful organizations have walked this path, and Microsoft is happy to be with you every step of the way.

Learn more

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 Zero Trust: 7 adoption strategies from security leaders appeared first on Microsoft Security.

Categories: CISO, cybersecurity, Zero Trust Tags:

Security baseline for Microsoft 365 Apps for enterprise (v2103, March 2021) – DRAFT

March 30th, 2021 No comments

Microsoft is pleased to announce the draft release of the recommended security configuration baseline settings for Microsoft 365 Apps for enterprise, version 2103. We invite you to download the draft baseline package (attached to this post), evaluate the proposed baselines, and provide us your comments and feedback below.


 


This baseline builds on the previous Office baseline we released mid-2019. The highlights of this baseline include:



  • Restrict legacy JScript execution for Office to help protect remote code execution attacks while maintaining user productivity as core services continue to function as usual.

  • Expanded macro protection requiring application add-ins to be signed by a trusted publisher. Also, turning off Trust Bar notifications for unsigned application add ins and blocking them to silently disable without notification.

  • Block Dynamic Data Exchange (DDE) entirely.

  • New policies added for Microsoft Defender Application Guard, protecting users from unsafe documents.


Also, see the information at the end of this post regarding updates to Security Policy Advisor and Office Cloud Policy Services.


 


The downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, updated custom administrative template (SecGuide.ADMX/L) file, all the recommended settings in spreadsheet form and a Policy Analyzer rules file. The recommended settings correspond with the Office 365 ProPlus administrative templates version 5140, released February 26, 2021.


 


GPOs included in the baseline


Most organizations can implement the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We’ve broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script (Baseline-LocalInstall.ps1) offers command-line options to control whether these GPOs are installed.


 


The “MSFT Office 365 ProPlus 2103” GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs, each of which is described later:



  • “Legacy JScript Block – Computer” disables the legacy JScript execution for websites in the Internet Zone and Restricted Sites Zone.

  • “Legacy File Block – User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats.

  • “Require Macro Signing – User” is a User Configuration GPO that disables unsigned macros in each of the Office applications.

  • “DDE Block – User” is a User Configuration GPO that blocks using DDE to search for existing DDE server processes or to start new ones.


 


Restrict legacy JScript execution for Office


The JScript engine is a legacy component in Internet Explorer which has been replaced by JScript9. Some organizations may have Office applications and workloads relying on this component, therefore it’s important to determine whether legacy JScript is being used to provide business-critical functionality before you enable this setting. Blocking the legacy JScript engine will help protect against remote code execution attacks while maintaining user productivity as core services continue to function as usual. As a security best practice, we recommend you disable legacy JScript execution for websites in Internet Zone and Restricted Sites Zone. We’ve enabled a new custom setting called “Restrict legacy JScript execution for Office” in the baseline and provided it in a separate GPO “MSFT Office 365 ProPlus 2103 – Legacy JScript Block – Computer” to make it easier to deploy. Learn more about Restrict JScript at a Process Level.


 


Note: It can be a challenge to identify all applications and workloads using the legacy JScript engine, it’s often used by a webpage by setting the script language attribute in HTML to Jscript.Encode or Jscript.Compact, it can also be used by the WebBrowser Control (WebOC). After the policy is applied, Office will not execute legacy JScript for the internet zone or restricted site zone websites. Therefore, applying this Group Policy can impact the functionalities in an Office application or add-ins that require the legacy JScript component and users aren’t notified by the application that legacy JScript execution is restricted. Modern JScript9 will continue to function for all zones.


 


Important: If you disable or don’t configure this Group Policy setting, legacy JScript runs without any restriction at the application level.


 


Comprehensive blocking of legacy file formats


In the last Office baseline we published, we blocked legacy file formats in a separate GPO that can be applied as a cohesive unit. There are no changes to the legacy file formats recommended to block.


 


Blocking DDE entirely


Excel already disabled Dynamic Data Exchange (DDE) as an interprocess communication method, and now Word added a new setting “Dynamic Data Exchange” that we have configured to a disabled state. Because of the new addition from Word the existing GPO has been renamed to “MSFT Office 365 ProPlus 2103 – DDE Block – User”.


 


Macro signing


The “VBA Macro Notification Settings” policy has been updated for Access, Excel, PowerPoint, Publisher, Visio, and Word with a new option. To further control macros we now recommend that macros also need to be signed by a Trusted Publisher. With this new recommendation macros not digitally signed by a Trusted Publisher will be blocked from running. Learn more at Upgrade signed Office VBA macro projects to V3 signature.


 


Note: Enabling “Block macros from running in Office files from the Internet” continues to be considered part of the main baseline and should be enforced by all security-conscious organizations.


 


Application Guard policies


We’re excited to announce the integration of Office with Microsoft Defender Application Guard. When Application Guard is enabled for your tenant, the integration will help prevent untrusted files from accessing trusted resources. New policies for Application Guard are added to the baseline to protect users from unsafe documents including enabling “Prevent users from removing Application Guard protection on files.” and disabling “Turn off protection of unsupported file types in Application Guard for Office.” Learn more about Microsoft Defender Application Guard.


 


Other changes in the baseline



  • New policy: “Control how Office handles form-based sign-in prompts” we recommend enabling and blocking all prompts. This results in no form-based sign-in prompts displayed to the user and the user is shown a message that the sign-in method isn’t allowed. We understand this setting might have some issues, and we value your feedback during the Draft cycle of this baseline posting.

  • New policy: We recommend enforcing the default by disabling “Disable additional security checks on VBA library references that may refer to unsafe locations on the local machine” (Note: This policy description is a double negative, the behavior we recommend is the security checks remain ON).

  • New policy: We recommend enforcing the default by disabling “Allow VBA to load typelib references by path from untrusted intranet locations”. Learn more at FAQ for VBA solutions affected by April 2020 Office security updates.

  • New dependent policy: “Disable Trust Bar Notification for unsigned application add-ins” policy had a dependency that was missed in the previous baseline. To correct, we have added that missing policy, “Require that application add-ins are signed by Trusted Publisher”. This applies to Excel, PowerPoint, Project, Publisher, Visio, and Word.

  • Removed from the baseline: “Do not display ‘Publish to GAL’ button”. While this setting has been there for a long time, after further research, we believe this setting is used to ensure good deployment practices and not to mitigate security concerns.


 


Deploy policies from the cloud, and get tailored recommendations for specific security policies


Deploy user-based policies from the cloud to any Office 365 ProPlus client through the Office cloud policy service. The Office cloud policy service allows administrators to define policies for Office 365 ProPlus and assign these policies to users via Azure Active Directory security groups. Once defined, policies are automatically enforced as users sign in and use Office 365 ProPlus. No need to be domain joined or MDM enrolled, and it works with corporate-owned devices or BYOD. Learn more about Office cloud policy service.


 


Security Policy Advisor can help give you insights on the security and productivity impact of deploying certain security policies. Security Policy Advisor provides you with tailored recommendations based on how Office is used in your enterprise. For example, in most customer environments, macros are typically used in apps such as Excel and only by specific groups of users. Security Policy Advisor helps you identify groups of users and applications where macros can be disabled with minimal productivity impact, and optionally integrate with Office 365 Advanced Threat Protection to provide you details on who is being attacked. Learn more about Security Policy Advisor.


 


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

Categories: Uncategorized Tags:

Security baseline for Office 365 ProPlus (v2103, March 2021) – DRAFT

March 30th, 2021 No comments

Microsoft is pleased to announce the draft release of the recommended security configuration baseline settings for Microsoft Office 365 ProPlus, version 2103. We invite you to download the draft baseline package (attached to this post), evaluate the proposed baselines, and provide us your comments and feedback below.


 


This baseline builds on the previous Office baseline we released mid-2019. The highlights of this baseline include:



  • Restrict legacy JScript execution for Office to help protect remote code execution attacks while maintaining user productivity as core services continue to function as usual.

  • Expanded macro protection requiring application add-ins to be signed by a trusted publisher. Also, turning off Trust Bar notifications for unsigned application add ins and blocking them to silently disable without notification.

  • Block Dynamic Data Exchange (DDE) entirely.

  • New policies added for Microsoft Defender Application Guard, protecting users from unsafe documents.


Also, see the information at the end of this post regarding updates to Security Policy Advisor and Office Cloud Policy Services.


 


The downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, updated custom administrative template (SecGuide.ADMX/L) file, all the recommended settings in spreadsheet form and a Policy Analyzer rules file. The recommended settings correspond with the Office 365 ProPlus administrative templates version 5140, released February 26, 2021.


 


GPOs included in the baseline


Most organizations can implement the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We’ve broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script (Baseline-LocalInstall.ps1) offers command-line options to control whether these GPOs are installed.


 


The “MSFT Office 365 ProPlus 2103” GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs, each of which is described later:



  • “Legacy JScript Block – Computer” disables the legacy JScript execution for websites in the Internet Zone and Restricted Sites Zone.

  • “Legacy File Block – User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats.

  • “Require Macro Signing – User” is a User Configuration GPO that disables unsigned macros in each of the Office applications.

  • “DDE Block – User” is a User Configuration GPO that blocks using DDE to search for existing DDE server processes or to start new ones.


 


Restrict legacy JScript execution for Office


The JScript engine is a legacy component in Internet Explorer which has been replaced by JScript9. Some organizations may have Office applications and workloads relying on this component, therefore it’s important to determine whether legacy JScript is being used to provide business-critical functionality before you enable this setting. Blocking the legacy JScript engine will help protect against remote code execution attacks while maintaining user productivity as core services continue to function as usual. As a security best practice, we recommend you disable legacy JScript execution for websites in Internet Zone and Restricted Sites Zone. We’ve enabled a new custom setting called “Restrict legacy JScript execution for Office” in the baseline and provided it in a separate GPO “MSFT Office 365 ProPlus 2103 – Legacy JScript Block – Computer” to make it easier to deploy. Learn more about Restrict JScript at a Process Level.


 


Note: It can be a challenge to identify all applications and workloads using the legacy JScript engine, it’s often used by a webpage by setting the script language attribute in HTML to Jscript.Encode or Jscript.Compact, it can also be used by the WebBrowser Control (WebOC). After the policy is applied, Office will not execute legacy JScript for the internet zone or restricted site zone websites. Therefore, applying this Group Policy can impact the functionalities in an Office application or add-ins that require the legacy JScript component and users aren’t notified by the application that legacy JScript execution is restricted. Modern JScript9 will continue to function for all zones.


 


Important: If you disable or don’t configure this Group Policy setting, legacy JScript runs without any restriction at the application level.


 


Comprehensive blocking of legacy file formats


In the last Office baseline we published, we blocked legacy file formats in a separate GPO that can be applied as a cohesive unit. There are no changes to the legacy file formats recommended to block.


 


Blocking DDE entirely


Excel already disabled Dynamic Data Exchange (DDE) as an interprocess communication method, and now Word added a new setting “Dynamic Data Exchange” that we have configured to a disabled state. Because of the new addition from Word the existing GPO has been renamed to “MSFT Office 365 ProPlus 2103 – DDE Block – User”.


 


Macro signing


The “VBA Macro Notification Settings” policy has been updated for Access, Excel, PowerPoint, Publisher, Visio, and Word with a new option. To further control macros we now recommend that macros also need to be signed by a Trusted Publisher. With this new recommendation macros not digitally signed by a Trusted Publisher will be blocked from running. Learn more at Upgrade signed Office VBA macro projects to V3 signature.


 


Note: Enabling “Block macros from running in Office files from the Internet” continues to be considered part of the main baseline and should be enforced by all security-conscious organizations.


 


Application Guard policies


We’re excited to announce the integration of Office with Microsoft Defender Application Guard. When Application Guard is enabled for your tenant, the integration will help prevent untrusted files from accessing trusted resources. New policies for Application Guard are added to the baseline to protect users from unsafe documents including enabling “Prevent users from removing Application Guard protection on files.” and disabling “Turn off protection of unsupported file types in Application Guard for Office.” Learn more about Microsoft Defender Application Guard.


 


Other changes in the baseline



  • New policy: “Control how Office handles form-based sign-in prompts” we recommend enabling and blocking all prompts. This results in no form-based sign-in prompts displayed to the user and the user is shown a message that the sign-in method isn’t allowed. We understand this setting might have some issues, and we value your feedback during the Draft cycle of this baseline posting.

  • New policy: We recommend enforcing the default by disabling “Disable additional security checks on VBA library references that may refer to unsafe locations on the local machine” (Note: This policy description is a double negative, the behavior we recommend is the security checks remain ON).

  • New policy: We recommend enforcing the default by disabling “Allow VBA to load typelib references by path from untrusted intranet locations”. Learn more at FAQ for VBA solutions affected by April 2020 Office security updates.

  • New dependent policy: “Disable Trust Bar Notification for unsigned application add-ins” policy had a dependency that was missed in the previous baseline. To correct, we have added that missing policy, “Require that application add-ins are signed by Trusted Publisher”. This applies to Excel, PowerPoint, Project, Publisher, Visio, and Word.

  • Removed from the baseline: “Do not display ‘Publish to GAL’ button”. While this setting has been there for a long time, after further research, we believe this setting is used to ensure good deployment practices and not to mitigate security concerns.


 


Deploy policies from the cloud, and get tailored recommendations for specific security policies


Deploy user-based policies from the cloud to any Office 365 ProPlus client through the Office cloud policy service. The Office cloud policy service allows administrators to define policies for Office 365 ProPlus and assign these policies to users via Azure Active Directory security groups. Once defined, policies are automatically enforced as users sign in and use Office 365 ProPlus. No need to be domain joined or MDM enrolled, and it works with corporate-owned devices or BYOD. Learn more about Office cloud policy service.


 


Security Policy Advisor can help give you insights on the security and productivity impact of deploying certain security policies. Security Policy Advisor provides you with tailored recommendations based on how Office is used in your enterprise. For example, in most customer environments, macros are typically used in apps such as Excel and only by specific groups of users. Security Policy Advisor helps you identify groups of users and applications where macros can be disabled with minimal productivity impact, and optionally integrate with Office 365 Advanced Threat Protection to provide you details on who is being attacked. Learn more about Security Policy Advisor.


 


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

Categories: Uncategorized Tags:

New Security Signals study shows firmware attacks on the rise; here’s how Microsoft is working to help eliminate this entire class of threats

March 30th, 2021 No comments

Cybersecurity threats are always evolving, and today we’re seeing a new wave of advanced attacks targeting areas of computing that don’t have the protection of the cloud. New data shows that firmware attacks are on the rise, and businesses aren’t paying close enough attention to securing this critical layer.

Recently, Microsoft commissioned a study that showed how attacks against firmware are outpacing investments targeted at stopping them. The March 2021 Security Signals report showed that more than 80% of enterprises have experienced at least one firmware attack in the past two years, but only 29% of security budgets are allocated to protect firmware.

Security Signals is a comprehensive research report assembled from interviews with 1,000 enterprise security decision makers (SDMs) from various industries across the U.S., UK, Germany, China, and Japan. Microsoft commissioned Hypothesis Group, an insights, design, and strategy agency, to execute the research.

The study showed that current investment is going to security updates, vulnerability scanning, and advanced threat protection solutions. Yet despite this, many organizations are concerned about malware accessing their system as well as the difficulty in detecting threats, suggesting that firmware is more difficult to monitor and control. Firmware vulnerabilities are also exacerbated by a lack of awareness and a lack of automation.

But the tide may be starting to turn against firmware exploits. There is a growing awareness of the issue worldwide, a new willingness to invest in protections, and an emerging class of secured-core hardware is showing the potential to empower organizations with chip-level security and new automation and analytics capabilities.

Firmware provides fertile ground to plant malicious code

Firmware, which lives below the operating system, is emerging as a primary target because it is where sensitive information like credentials and encryption keys are stored in memory. Many devices in the market today don’t offer visibility into that layer to ensure that attackers haven’t compromised a device prior to the boot process or at runtime bellow the kernel. And attackers have noticed.

If that’s not enough, the National Institute of Science and Technology (NIST) has shown more than a five-fold increase in attacks against firmware in the last four years, and attackers have used this time to further refine their techniques and get ahead of software-only protections.

Yet the Security Signals study shows that awareness of this threat is lagging across industries. Even with this onslaught of firmware attacks, the study shows that SDMs believe software is three times as likely to pose a security threat versus firmware.

“There are two types of companies – those who have experienced a firmware attack, and those who have experienced a firmware attack but don’t know it.” – Azim Shafqat, Partner at ISG and Former Managing VP at Gartner

The OS Kernel is an emerging gap in defense

A look at respondents’ investments bears out this disparity. Hardware-based security features such as Kernel data protection (KDP), or memory encryption, which blocks malware or malicious threat actors from corrupting the operating system’s kernel memory or from reading it at runtime, is a leading indicator of preparedness against sophisticated kernel-level attacks. Security Signals found that only 36% of businesses invest in hardware-based memory encryption and less than half (46%) are investing in hardware-based kernel protections.

Security Signals also found that security teams are too focused on outdated “protect and detect” models of security and are not spending enough time on strategic work — only 39% of security teams’ time is spent on prevention and they don’t see that changing in the next two years. The lack of proactive defense investment in kernel attack vectors is an example of this outdated model.

Physical attacks using hardware

In addition to firmware attacks, respondents identified concerns with attack vectors exposed by hardware. The recent ThunderSpy attack targeted Thunderbolt ports, leveraging direct memory access (DMA) functionality to compromise devices via hardware access to the Thunderbolt controller. Another flaw, this one unpatchable, was found in the T2 security chip used in many common consumer devices. Other major firmware attacks in the last year included the RobbinHood, Uburos, Derusbi, Sauron and GrayFish attacks that exploited driver vulnerabilities.

Lack of automation and investment leads to a gap in focus on firmware

Part of the disconnect may be due to security teams being stuck in reactive cycles and manual processes. The vast majority (82%) of Security Signals respondents reported that they don’t have the resources to allocate to more high-impact security work because they are spending too much time on lower-yield manual work like software and patching, hardware upgrades, and mitigating internal and external vulnerabilities. A full 21% of SDMs admit that their firmware data goes unmonitored today.

Lack of automation is another factor causing organizations to lose time and detracting from building better prevention strategies. Seventy-one percent said their staff spends too much time on work that should be automated, and that number creeps up to 82% among the teams who said they don’t have enough time for strategic work. Overall, security teams are spending 41% of their time on firmware patches that could be automated.

Meanwhile, most SDMs (62%) believe more time should be spent on strategic work like setting the strategy and preparing for sophisticated threats like those targeted at firmware.

New investments are accelerating—and paying off

The challenge is global, and many organizations are realizing the importance of investing in these critical areas. Eighty-one percent of the German companies we surveyed were prepared and willing to invest, as compared to 95% of Chinese organizations and 91% of businesses in the U.S., UK, and Japan. Eighty-nine percent of regulated industry companies felt willing and able to invest in security solutions, although those in the financial services sector are not quite as ready to invest as companies in other markets.

Those that do make the right investments are seeing returns, and surveyed organizations that made a real investment in security saw a big payoff. Almost two-thirds (65%) of SDMs reported that investing in security increased efficiency throughout their organizations because it freed up SecOps teams to work on other projects, promoted business continuity, enabled end-user productivity, decreased downtime and saved on investments needed elsewhere.

Across all industry verticals, proven frameworks can lay the groundwork for a successful security strategy that includes automation, increases proactivity, and measures security progress.

“Firmware runs the hardware, but there isn’t a way to inspect to say you are 100% safe with firmware. Firmware attacks are less common (than software), but a successful attack will be largely disruptive.” – SANS Senior Instructor

Hardware security is paramount to protecting from future threats

With our partners, Microsoft has created a new class of devices specifically designed to eliminate threats aimed at firmware called Secured-core PCs. This was recently extended to Server and IOT announced at this year’s Microsoft Ignite conference. With Zero Trust built in from the ground up, this means SDMs will be able to invest more of their resources in strategies and technologies that will prevent attacks in the future rather than constantly defending against the onslaught of attacks aimed at them today.

The SDMs in the study who reported they have invested in secured-core PCs showed a higher level of satisfaction with their security and enhanced confidentiality, availability, and integrity of data as opposed to those not using them. Based on analysis from Microsoft threat intelligence data, secured-core PCs provide more than twice the protection from infection than non-secured-core PCs. Sixty percent of surveyed organizations who invested in secured-core PCs reported supply chain visibility and monitoring as a top concern. According to Accenture’s State of Cyber Resilience report, indirect attacks into the supply chain now account for 40% of security breaches.

Secured-core PCs provide powerhouse protection out of the box, with capabilities such as Virtualization-Based Security, Credential Guard, and Kernel DMA protection. The subsequent automation and out-of-the-box capabilities also free up time for SDMs to focus more of their efforts on high-value and strategic endeavors and less on low-level activities.

Security Signals also found that companies are investing in larger devices to protect against hardware security breaches: more than half are focusing on servers. Microsoft is planning ahead and innovating there as well. With our partners AMD and Intel, we announced the extension of secured-core to servers and edge devices at our virtual Spring Ignite.

To learn more about the more than 100 certified secured-core PCs available today from Microsoft, Acer, Dell, HP, Lenovo, Panasonic, and more, visit our Secured-core web page.

Server investments are high today because they are used as stepping stones in the cloud migration journey.” – Azim Shafqat, Partner at ISG and Former Managing VP at Gartner

The most important takeaway from the Security Signals report is that companies want to have more proactive strategies in place for security, especially when it comes to addressing firmware attacks. Microsoft is working to address that need by partnering with leading PC manufacturers and silicon vendors to establish a proactive strategy towards device security.

Ultimately, those enterprises who align their resources to develop such preventive strategies will give themselves a better chance for business continuity, productivity, and protection from emerging threats.

 

Methodology

Security Signals research occurred from August – Dec. 2020, when a 20-minute online survey was conducted with 1,000 decision makers involved in security and threat protection decisions at enterprise companies from a range of industries across the US, UK, Germany, China, and Japan.

The Security Signals report works to create a detailed picture of the current security landscape: to understand the unique mindset and priorities that security decision makers (SDMs) bring to their organizations; to shed light on the benefits and challenges of adopting security solutions; to assess what impacts and shapes SDMs’ business decisions; and to see what the future of security may hold. The goal of this paper is to provide up-to-date research on the state of security, across countries and industries, in order to better serve our customers and partners, and enable security decision makers to further their development of security strategies within their organizations.

The post New Security Signals study shows firmware attacks on the rise; here’s how Microsoft is working to help eliminate this entire class of threats appeared first on Microsoft Security.

How to build a successful application security program

March 29th, 2021 No comments

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the latest Voice of the Community blog series post, Microsoft Product Marketing Manager Natalia Godyla talks with Tanya Janca, Founder of We Hack Purple Academy and author of the best-selling book “Alice and Bob Learn Application Security.” Previously, Tanya shared her perspectives on the role of application security (AppSec) and the challenges facing AppSec professionals. In this blog, Tanya shares how to build an AppSec program, find security champions, and measure its success.

Natalia: When you’re building an AppSec program, what are the objectives and requirements?

Tanya: This is sort of a trick question because the way I do it is based on what’s already there and what they want to achieve. For Canada, I did antiterrorism activities, and you better believe that was the strictest security program that any human has ever seen. If I’m working with a company that sells scented soap on the internet, the level of security that they require is very different, their budget is different, and the importance of what they’re protecting is different. I try to figure out what the company’s risks are and what their tolerance is for change. For instance, I’ve been called into a lot of banks and they want the security to be tight, but they’re change-adverse. I find out what matters to them and try to bring their eyes to what should matter to them.

I also usually ask for all scan results. Even if they have almost no AppSec program, usually people have been doing scanning or they’ve had a penetration test. I look at all of it and I look at the top three things and I say, “OK, let’s just obliterate those top three things,” because quite often the top two or three are 40 to 60 percent of their vulnerabilities. First, I stop all the bleeding, and then I create processes and security awareness for developers. We’re going to have a secure coding day and deep dive into each one of these things. I’m going to spend quality time with the people who review all the pull requests so they can look for the top three and start setting specific, measurable goals.

It’s really important to get the developers to help you. When you have a secure coding training, a bunch of developers will self-identify as the security developer. There will be one person who asks multiple questions. We’re going to get that person’s email. They’re our new friend. We’re going to buy that person some books and encourage open communication because that person is going to be our security champion. Eventually, many of my clients start security champion programs and that’s even better because then you have a team of developers—hopefully one per team—that are helping you bring things to their team’s attention.

Natalia: What are some of the key performance indicators (KPIs) for measuring security posture?

Tanya: As application security professionals, we want to minimize the risk of scary apps and then try to bring everything across the board up to a higher security posture. Each organization sets that differently. For an application security program, I would measure that every app receives security attention in every phase of the software development life cycle. For a program, I take inventory of all their apps and APIs. Inventories are a difficult problem in application security; it’s the toughest problem that our field has not solved.

Once you have an inventory, you want to figure out if you can do a quick dynamic application security testing (DAST) scan on everything. You will see it light up like a Christmas tree on some, and on others, it found a couple of lows. It’s not perfect, but it’s what you can do in 30 days. You can scan a whole bunch of things quickly and see OK, so these things are terrifying, these things look OK. Now, let’s concentrate on the terrifying things and make them a little less scary.

Natalia: Do you have any best practices for threat modeling cloud security?

Tanya: For threat modeling generally, I introduce it as a hangout session with a security person and try not to be too formal the first time, because developers usually think, “What is she doing here? Danger, Will Robinson, danger. The security person wants to spend time with us. What have we done wrong?” I say, “I wanted to talk about your app and see if there’s any helpful advice I can offer.” Then, I start asking questions like, “If you were going to hack your app, how would you do it?”

I like the STRIDE methodology, where each of the letters represents a different thing that you need to worry about happening to your apps. Specifically, spoofing, tampering, repudiation, information disclosure, denial of service (DOS), and elevation of privilege. Could someone pretend to be someone else? Could someone pretend to be you? I go through it slowly in a conversational manner because that app is their baby, and I don’t want them to feel like I’m attacking their baby. Eventually, I teach them STRIDE so they can think about these things. Then, we come up with a plan and I say, “OK, I’m going to write up these notes and email them to you.” Writing the notes means you can assign tasks to people.

With threat modeling in the cloud, you must ask more questions, especially if your organization has had previous problems. You want to ask about those because there will be patterns. The biggest issue with the cloud is that we didn’t give them enough education. When we’re bringing them to the cloud, we need to teach them what we expect from them, and then we’ll get it. If we don’t, there’s a high likelihood we won’t get it.

Natalia: How can security professionals convince decision-makers to invest in AppSec?

Tanya: I have a bunch of tricks. The first one is to give presentations on AppSec. I would do lunch and learns. For instance, I sent out an email once to developers: “I’m going to break into a bank at lunch. Who wants to come watch?” and then I showed them this demo of a fake bank. I explained what SQL injection was and I explained how I’d found that vulnerability in one of our apps and what could happen if we didn’t fix it. And they said, “Woah!” Or I’d ask, “Who wants to learn how to hack apps?” and then I showed them a DAST tool. I kept showing them stuff and they started becoming more interested.

Then, I had to interest the developer managers and upper management. Some were still not on board because this was their first AppSec program and my first AppSec program. No one would do what I said, and I had all these penetration test results from a third party, and we had hired four different security assessors and they’d reported big issues that needed to be addressed.

So, I came up with a document called the risk sign-off sheet, which listed all the security risks and exactly what could happen to the business. I was extremely specific about what worried me. I printed it and I had a sign-off for the Director of Security for the whole building and the Chief Information Officer of the entire organization. I went to them and said, “I need your signature that you accept this risk on behalf of your organization.” I put a little note on the risk sign-off sheet that read: Please sign.

The Director of Security called and said, “What is this, Tanya?” and I told him, “No one will fix these things and I don’t have the authority to accept this risk on behalf of the organization. Only you do. I don’t have the authority to make these people fix these things. Only you do. I need you to sign to prove that you were aware of the risks. When we’re in the news, I need to know who’s at fault.” Both the CIO and the Director of Security refused to sign, and I said, “Then you have to give me the authority. I can’t have the responsibility and not have the authority” and it worked. I’ve used it twice at work and it worked.

It’s also important to explain to them using words they understand. The Head of Security, who is in charge of physical security and IT security, was a brilliant man but he didn’t know AppSec. When I explained that because of this vulnerability you can do this with the app, and this is what can result for our customers, he said, “Oh, let’s do something.” I had to learn how to communicate a lot better to do well at AppSec because as a developer, I would just speak developer to other developers.

Learn more

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 How to build a successful application security program appeared first on Microsoft Security.

Securing our approach to domain fronting within Azure

March 26th, 2021 No comments

Every single day our teams analyze the trillions of signals we see to understand attack vectors, and then take those learnings and apply them to our products and solutions. Having that understanding of the threat landscape is key to ensuring our customers are kept safe every day. However, being a security provider in a complex world sometimes requires deeper thinking and reflection on how to address emerging issues, especially when the answer is not always immediately clear. Our approach to domain fronting within Azure is a great example of how the ever-changing dynamics of our world have prompted us to re-examine an important and complicated issue—and ultimately make a change.

Let’s start with some background. Domain fronting is a networking technique that enables a backend domain to utilize the security credentials of a fronting domain. For example, if you have two domains under the same content delivery network (CDN), domain #1 may have certain restrictions placed on it (regional access limitations, etc.) that domain #2 does not. By taking the valid domain #2 and placing it into the SNI header, and then using domain #1 in the HTTP header, it’s possible to circumvent those restrictions. To the outside observer, all subsequent traffic appears to be headed to the fronting domain, with no ability to discern the intended destination for particular user requests within that traffic. It is possible that the fronting domain and the backend domain do not belong to the same owner.

As a company that is committed to delivering technology for good, supporting certain use cases that support free and open communication are an important consideration when weighing the potential impacts of a technique like domain fronting. However, we know that domain fronting is also abused by bad actors and threat actors engaging in illegal activities, and we’ve become aware that in some cases bad actors configure their Azure services to enable this.

When it comes to situations like this, Microsoft—as a security company—leads from a place of providing greater simplicity for our customers when they face increased complexity. Our mission is to give our customers peace of mind and help them adapt quickly to a rapidly shifting threat landscape. Therefore, we’re making a change to our policy to ensure that domain fronting will be stopped and prevented within Azure.

Changes like this one are not made lightly, and we understand that there will be impacts across a number of areas:

  • Our engineering teams are already working to ensure the platform will block anyone from practicing the domain fronting technique on Azure, while also continuing to ensure our products and services provide the highest levels of protection against domain fronting based threats.
  • We’re continuing to provide clear guidance for penetration testing on our Azure properties, and working closely with security researchers around the world to make sure they have a clear understanding of these changes.

These changes are just another example of the broad impact that security has on our ever-changing world and we’ll continue to put the security of our customers and their users at the forefront of everything we do. I’d like to thank my colleagues Nick Carr and Christopher Glyer for their tireless research on Domain Fronting, which helped us to make these policy changes to Azure.

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 Securing our approach to domain fronting within Azure appeared first on Microsoft Security.

Categories: Azure Security Tags:

Analyzing attacks taking advantage of the Exchange Server vulnerabilities

March 25th, 2021 No comments

Microsoft continues to monitor and investigate attacks exploiting the recent on-premises Exchange Server vulnerabilities. These attacks are now performed by multiple threat actors ranging from financially motivated cybercriminals to state-sponsored groups. To help customers who are not able to immediately install updates, Microsoft released a one-click tool that automatically mitigates one of the vulnerabilities and scans servers for known attacks. Microsoft also built this capability into Microsoft Defender Antivirus, expanding the reach of the mitigation. As of today, we have seen a significant decrease in the number of still-vulnerable servers – more than 92% of known worldwide Exchange IPs are now patched or mitigated. We continue to work with our customers and partners to mitigate the vulnerabilities.

As organizations recover from this incident, we continue to publish guidance and share threat intelligence to help detect and evict threat actors from affected environments. Today, we are sharing intelligence about what some attackers did after exploiting the vulnerable servers, ranging from ransomware to data exfiltration and deployment of various second-stage payloads. This blog covers:

  • Threat intelligence and technical details about known attacks, including components and attack paths, that defenders can use to investigate whether on-premises Exchange servers were compromised before they were patched and to comprehensively respond to and remediate these threats if they see them in their environments.
  • Detection and automatic remediation built into Microsoft Defender Antivirus and how investigation and remediation capabilities in solutions like Microsoft Defender for Endpoint can help responders perform additional hunting and remediate threats.

Although the overall numbers of ransomware have remained extremely small to this point, it is important to remember that these threats show how quickly attackers can pivot their campaigns to take advantage of newly disclosed vulnerabilities and target unpatched systems, demonstrating how critical it is for organizations to apply security updates as soon as possible. We strongly urge organizations to identify and update vulnerable on-premises Exchange servers, and to follow mitigation and investigation guidance that we have collected and continue to update here: https://aka.ms/ExchangeVulns.

Mitigating post-exploitation activities

The first known attacks leveraging the Exchange Server vulnerabilities were by the nation-state actor HAFNIUM, which we detailed in this blog. In the three weeks after the Exchange server vulnerabilities were disclosed and the security updates were released, Microsoft saw numerous other attackers adopting the exploit into their toolkits. Attackers are known to rapidly work to reverse engineer patches and develop exploits. In the case of a remote code execution (RCE) vulnerability, the rewards are high for attackers who can gain access before an organization patches, as patching a system does not necessarily remove the access of the attacker.

Figure 1. The Exchange Server exploit chain

In our investigation of the on-premises Exchange Server attacks , we saw systems being affected by multiple threats. Many of the compromised systems have not yet received a secondary action, such as human-operated ransomware attacks or data exfiltration, indicating attackers could be establishing and keeping their access for potential later actions. These actions might involve performing follow-on attacks via persistence on Exchange servers they have already compromised, or using credentials and data stolen during these attacks to compromise networks through other entry vectors.

Attackers who included the exploit in their toolkits, whether through modifying public proof of concept exploits or their own research, capitalized on their window of opportunity to gain access to as many systems as they could. Some attackers were advanced enough to remove other attackers from the systems and use multiple persistence points to maintain access to a network.

We have built protections against these threats into Microsoft security solutions. Refer to the Appendix for a list of indicators of compromise, detection details, and advanced hunting queries. We have also provided additional tools and investigation and remediation guidance here: https://aka.ms/exchange-customer-guidance.

While performing a full investigation on systems is recommended, the following themes are common in many of the attacks. These are prevailing threat trends that Microsoft has been monitoring, and existing solutions and recommendations for prevention and mitigation apply:

  • Web shells – As of this writing, many of the unpatched systems we observed had multiple web shells on them. Microsoft has been tracking the rise of web shell attacks for the past few years, ensuring our products detect these threats and providing remediation guidance for customers. For more info on web shells, read Web shell attacks continue to rise. We have also published guidance on web shell threat hunting with Azure Sentinel.
  • Human-operated ransomware – Ransomware attacks pose some of the biggest security risks for organizations today, and attackers behind these attacks were quick to take advantage of the on-premises Exchange Server vulnerabilities. Successfully exploiting the vulnerabilities gives attackers the ability to launch human-operated ransomware campaigns, a trend that Microsoft has been closely monitoring. For more information about human-operated ransomware attacks, including Microsoft solutions and guidance for improving defenses, read: Human-operated ransomware attacks.
  • Credential theft – While credential theft is not the immediate goal of some of these attacks, access to Exchange servers allowed attackers to access and potentially steal credentials present on the system. Attackers can use these stolen credentials for follow-on attacks later, so organizations need to prioritize identifying and remediating impacted identities. For more information, read best practices for building credential hygiene.

In the following sections, we share our analysis of known post-compromise activities associated with exploitation of the Exchange server vulnerabilities because it is helpful to understand these TTPs, in order to defend against other actors using similar tactics or tools. While levels of disruptive post-compromise activity like ransomware may be limited at the time of this writing, Microsoft will continue to track this space and share information with the community. It’s important to note that with some post-compromise techniques, attackers may gain highly privileged persistent access, but many of the impactful subsequent attacker activities can be mitigated by practicing the principle of least privilege and mitigating lateral movement.

DoejoCrypt ransomware

DoejoCrypt was the first ransomware to appear to take advantage of the vulnerabilities, starting to encrypt in limited numbers shortly after the patches were released. Ransomware attackers often use multiple tools and exploits to gain initial access, including purchasing access through a broker or “reseller” who sells access to systems they have already compromised. The DoejoCrypt attacks start with a variant of the Chopper web shell being deployed to the Exchange server post-exploitation.

The web shell writes a batch file to C:\Windows\Temp\xx.bat. Found on all systems that received the DoejoCrypt ransomware payload, this batch file performs a backup of the Security Account Manager (SAM) database and the System and Security registry hives, allowing the attackers later access to passwords of local users on the system and, more critically, in the LSA Secrets portion of the registry, where passwords for services and scheduled tasks are stored.

Figure 2. xx.bat

Given configurations that administrators typically use on Exchange servers, many of the compromised systems are likely to have had at least one service or scheduled task configured with a highly privileged account to perform actions like backups. As service account credentials are not frequently changed, this could provide a great advantage to an attacker even if they lose their initial web shell access due to an antivirus detection, as the account can be used to elevate privileges later, which is why we strongly recommend operating under the principle of least privileged access.

The batch file saves the registry hives to a semi-unique location, C:\windows\temp\debugsms, assembles them into a CAB file for exfiltration, and then cleans up the folders from the system. The file also enables Windows Remote Management and sets up an HTTP listener, indicating the attacker might take advantage of the internet-facing nature of an Exchange Server and use this method for later access if other tools are removed.

Figure 3. xx.bat actions

The xx.bat file has been run on many more systems than have been ransomed by the DoejoCrypt attacker, meaning that, while not all systems have moved to the ransom stage, the attacker has gained access to multiple credentials. On systems where the attacker moved to the ransom stage, we saw reconnaissance commands being run via the same web shell that dopped the xx.bat file (in this instance, a version of Chopper):

Figure 4. DoejoCrypt recon command

After these commands are completed, the web shell drops a new payload to C:\Windows\Help which, like in many human-operated ransomware campaigns, leads to the attack framework Cobalt Strike. In observed instances, the downloaded payload is shellcode with the file name new443.exe or Direct_Load.exe. When run, this payload injects itself into notepad.exe and reaches out to a C2 to download Cobalt Strike shellcode.

Figure 5. DoejoCrypt ransomware attack chain

During the hands-on-keyboard stage of the attack, a new payload is downloaded to C:\Windows\Help with names like s1.exe and s2.exe. This payload is the DoejoCrypt ransomware, which uses a .CRYPT extension for the newly encrypted files and a very basic readme.txt ransom note. In some instances, the time between xx.bat being dropped and a ransomware payload running was under half an hour.

Figure 6. DoejoCrypt ransom note

While the DoejoCrypt payload is the most visible outcome of this attackers’ actions, the access to credentials they have gained could serve them for future campaigns if organizations do not reset credentials on compromised systems. An additional overlapping activity observed on systems where xx.bat was present and the attackers were able to get Domain Administrator rights was the running of scripts to snapshot Active Directory with ntdsutil—an action that, if executed successfully, could give the attackers access to all the passwords in Active Directory from a single compromised system.

Lemon Duck botnet

Cryptocurrency miners were some of the first payloads we observed being dropped by attackers from the post-exploit web shells. In the first few days after the security updates were released, we observed multiple cryptocurrency miner campaigns, which had been previously targeting SharePoint servers, add Exchange Server exploitation to their repertoire. Most of these coin miners were variations on XMRig miners, and many arrived via a multi-featured implant with the capability to download new payloads or even move laterally.

Lemon Duck, a known cryptocurrency botnet named for a variable in its code, dove into the Exchange exploit action, adopting different exploit styles and choosing to use a fileless/web shell-less option of direct PowerShell commands from w3wp (the IIS worker process) for some attacks. While still maintaining their normal email-based campaigns, the Lemon Duck operators compromised numerous Exchange servers and moved in the direction of being more of a malware loader than a simple miner.

Using a form of the attack that allows direct execution of commands versus dropping a web shell, the Lemon Duck operators ran standard Invoke Expression commands to download a payload. Having used the same C2 and download servers for some time, the operators applied a varied degree of obfuscation to their commands on execution.

Fig 7. Example executions of Lemon Duck payload downloads

The Lemon Duck payload is an encoded and obfuscated PowerShell script. It first removes various security products from the system, then creates scheduled tasks and WMI Event subscription for persistence. A second script is downloaded to attempt to evade Microsoft Defender Antivirus, abusing their administrative access to run the Set-MPPreference command to disable real-time monitoring (a tactic that Microsoft Defender Tamper protection blocks) and add scanning exclusions for the C:\ drive and the PowerShell process.

Figure 8. Lemon Duck payloads

One randomly named scheduled task connects to a C2 every hour to download a new payload, which includes various lateral movement and credential theft tools. The operators were seen to download RATs and information stealers, including Ramnit payloads.

Figure 9. Lemon Duck post-exploitation activities

In some instances, the operators took advantage of having compromised mail servers to access mailboxes and send emails containing the Lemon Duck payload using various colorful email subjects.

Figure 10. Email subjects of possibly malicious emails

Figure 11. Attachment variables

In one notable example, the Lemon Duck operators compromised a system that already had xx.bat and a web shell. After establishing persistence on the system in a non-web shell method, the Lemon Duck operators were observed cleaning up other attackers’ presence on the system and mitigating the CVE-2021-26855 (SSRF) vulnerability using a legitimate cleanup script that they hosted on their own malicious server. This action prevents further exploitation of the server and removes web shells, giving Lemon Duck exclusive access to the compromised server. This stresses the need to fully investigate systems that were exposed, even if they have been fully patched and mitigated, per traditional incident response process.

Pydomer ransomware

While DoejoCrypt was a new ransomware payload, the access gained by attackers via the on-premises Exchange Server vulnerabilities will likely become part of the complex cybercriminal economy where additional ransomware operators and affiliates take advantage of it. The first existing ransomware family to capitalize on the vulnerabilities was Pydomer. This ransomware family was previously seen using vulnerabilities in attacks, notably taking advantage of Pulse Secure VPN vulnerabilities, for which Pulse Secure has released security patches, to steal credentials and perform ransomware attacks.

In this campaign, the operators scanned and mass-compromised unpatched Exchange Servers to drop a web shell. They started later than some other attackers, with many compromises occurring between March 18 and March 20, a window when fewer unpatched systems were available. They then dropped a web shell, with a notable file name format: “Chack[Word][Country abbreviation]”:

Figure 12. Example web shell names observed being used by the Pydomer attackers

These web shells were observed on around 1,500 systems, not all of which moved to the ransomware stage. The attackers then used their web shell to dump a test.bat batch file that performed a similar function in the attack chain to the xx.bat of the DoejoCrypt operators and allowed them to perform a dump of the LSASS process.

Figure 13. Pydomer post-exploitation activities

This access alone would be valuable to attackers for later attacks, similar to the credentials gained during their use of Pulse Secure VPN vulnerabilities. The highly privileged credentials gained from an Exchange system are likely to contain domain administrator accounts and service accounts with backup privileges, meaning these attackers could perform ransomware and exfiltration actions against the networks they compromised long after the Exchange Server is patched and even enter via different means.

On systems where the attackers did move to second-stage ransomware operations, they utilized a Python script compiled to an executable and the Python cryptography libraries to encrypt files. The attackers then executed a PowerShell script via their web shell that acts as a downloader and distribution mechanism for the ransomware.

Figure 14. PowerShell downloader and spreader used to get the Pydomer payload

The script fetches a payload from a site hosted on a domain generation algorithm (DGA) domain, and attempts to spread the payload throughout the network, first attempting to spread the payload over WMI using Invoke-WMIMethod to attempt to connect to systems, and falling back to PowerShell remoting with Enter-PSSession if that fails. The script is run within the context of the web shell, which in most instances is Local System, so this lateral movement strategy is unlikely to work except in organizations that are running highly insecure and unrecommended configurations like having computer objects in highly privileged groups.

The Pydomer ransomware is a Python script compiled to an executable and uses the Python cryptography libraries to encrypt files. The ransomware encrypts the files and appends a random extension, and then drops a ransom note named decrypt_file.TxT.

Figure 15. Pydomer ransom note

Interestingly, the attackers seem to have deployed a non-encryption extortion strategy. Following well-known ransomware groups like Maze and Egregor which leaked data for pay, the Pydomer hackers dropped an alternative readme.txt onto systems without encrypting files. This option might have been semi-automated on their part or a side effect of a failure in their encryption process, as some of the systems they accessed were test systems that showed no data exfiltration. The note should be taken seriously if encountered, as the attackers had full access to systems and were likely able to exfiltrate data.

Figure 16. Pydomer extortion readme.txt

Credential theft, turf wars, and dogged persistence

If a server is not running in a least-privilege configuration, credential theft could provide a significant return on investment for an attacker beyond their initial access to email and data. Many organizations have backup agent software and scheduled tasks running on these systems with domain admin-level permissions. For these organizations, the attackers might be able to harvest highly privileged credentials without lateral movement, for example, using the COM services DLL as a living-off-the-land binary to perform a dump of the LSASS process:

Figure 17. Use of COM services DLL to dump LSASS process

The number of observed credential theft attacks, combined with high privilege of accounts often given to Exchange servers, means that these attacks could continue to impact organizations that don’t fully remediate after a compromise even after patches have been applied. While the observed ransomware attempts were small-scale or had errors, there is still the possibility of more skillful groups utilizing credentials gained in these attacks for later attacks.

Attackers also used their access to perform extensive reconnaissance using built-in Exchange commandlets and dsquery to exfiltrate information about network configurations, user information, and email assets.

While Lemon Duck operators might have had the boldest method for removing other attackers from the systems they compromised, they were not the only attacker to do so. Others were observed cleaning up .aspx and .bat files to remove other attackers, and even rebuilding the WMI database by deleting .mof files and restarting the service. As the window on unpatched machines closes, attackers showed increased interest in maintaining the access to the systems they exploited. By utilizing “malwareless” persistence mechanisms like enabling RDP, installing Shadow IT tools, and adding new local administrator accounts, the attackers are hoping to evade incident response efforts that might focus exclusively on web shells, AV scans, and patching.

Defending against exploits and post-compromise activities

Attackers exploit the on-premises Exchange Server vulnerabilities in combination to bypass authentication and gain the ability to write files and run malicious code. The best and most complete remediation for these vulnerabilities is to update to a supported Cumulative Update and to install all security updates. Comprehensive mitigation guidance can be found here: https://aka.ms/ExchangeVulns.

As seen in the post-exploitation attacks discussed in this blog, the paths that attackers can take after successfully exploiting the vulnerabilities are varied and wide-ranging. If you have determined or have reason to suspect that these threats are present on your network, here are immediate steps you can take:

  • Investigate exposed Exchange servers for compromise, regardless of their current patch status.
  • Look for web shells via our guidance and run a full AV scan using the Exchange On-Premises Mitigation Tool.
  • Investigate Local Users and Groups, even non-administrative users for changes, and ensure all users require a password for sign-in. New user account creations (represented by Event ID 4720) during the time the system was vulnerable might indicate a malicious user creation.
  • Reset and randomize local administrator passwords with a tool like LAPS if you are not already doing so.
  • Look for changes to the RDP, firewall, WMI subscriptions, and Windows Remote Management (WinRM) configuration of the system that might have been configured by the attacker to allow persistence.
  • Look for Event ID 1102 to determine if attackers cleared event logs, an activity that attackers perform with exe in an attempt to hide their tracks.
  • Look for new persistence mechanisms such as unexpected services, scheduled tasks, and startup items.
  • Look for Shadow IT tools that attackers might have installed for persistence, such as non-Microsoft RDP and remote access clients.
  • Check mailbox-level email forwarding settings (both ForwardingAddress and ForwardingSMTPAddress attributes), check mailbox inbox rules (which might be used to forward email externally), and check Exchange Transport rules that you might not recognize.

While our response tools check for and remove known web shells and attack tools, performing a full investigation of these systems is recommended. For comprehensive investigation and mitigation guidance and tools, see https://aka.ms/exchange-customer-guidance.

Additionally, here are best practices for building credential hygiene and practicing the principle of least privilege:

  • Follow guidance to run Exchange in least-privilege configuration: https://adsecurity.org/?p=4119.
  • Ensure service accounts and scheduled tasks run with the least privileges they need. Avoid widely privileged groups like domain admins and backup operators and prefer accounts with access to just the systems they need.
  • Randomize local administrator passwords to prevent lateral movement with tools like LAPS.
  • Ensure administrators practice good administration habits like Privileged Admin Workstations.
  • Prevent privileged accounts like domain admins from signing into member servers and workstations using Group Policy to limit credential exposure and lateral movement.

 

Appendix

Microsoft Defender for Endpoint detection details

Antivirus                                                                                                                                   

Microsoft Defender Antivirus detects exploitation behavior with these detections:

Web shells are detected as:

Ransomware payloads and associated files are detected as:

Lemon Duck malware is detected as:

Some of the credential theft techniques highlighted in this report are detected as:

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network:

  • Suspicious Exchange UM process creation
  • Suspicious Exchange UM file creation
  • Suspicious w3wp.exe activity in Exchange
  • Possible exploitation of Exchange Server vulnerabilities
  • Possible IIS web shell
  • Possible web shell installation
  • Web shells associated with Exchange Server vulnerabilities
  • Network traffic associated with Exchange Server exploitation

Alerts with the following titles in the security center can indicate threat activity on your network specific to the DoejoCrypt and Pydomer ransomware campaign:

  • DoejoCrypt ransomware
  • Pydomer ransomware
  • Pydomer download site

Alerts with the following titles in the security center can indicate threat activity on your network specific to the Lemon Duck botnet:

  • LemonDuck Malware
  • LemonDuck botnet C2 domain activity

The following behavioral alerts might also indicate threat activity associated with this threat:

  • Possible web shell installation
  • A suspicious web script was created
  • Suspicious processes indicative of a web shell
  • Suspicious file attribute change
  • Suspicious PowerShell command line
  • Possible IIS Web Shell
  • Process memory dump
  • A malicious PowerShell Cmdlet was invoked on the machine
  • WDigest configuration change
  • Sensitive information lookup
  • Suspicious registry export

Advanced hunting

To locate possible exploitation activities in Microsoft Defender for Endpoint, run the following queries.

Processes run by the IIS worker process

Look for processes executed by the IIS worker process

// Broadly search for processes executed by the IIS worker process. Further investigation should be performed on any devices where the created process is indicative of reconnaissance
DeviceProcessEvents
| where InitiatingProcessFileName == 'w3wp.exe'
| where InitiatingProcessCommandLine contains "MSExchange"
| where FileName !in~ ("csc.exe","cvtres.exe","conhost.exe","OleConverter.exe","wermgr.exe","WerFault.exe","TranscodingService.exe")
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for PowerShell spawned from the IIS worker process, observed most frequently in Lemon Duck with Base64 encoding to obfuscate C2 domains

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName =~ "w3wp.exe"
| where InitiatingProcessCommandLine contains "MSExchange"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Tampering

Search for Lemon Duck tampering with Microsoft Defender Antivirus

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("Set-MpPreference", "DisableRealtimeMonitoring", "Add-MpPreference", "ExclusionProcess")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Batch script actions

Search for batch scripts performing credential theft, as observed in DoejoCrypt infections

DeviceProcessEvents
| where InitiatingProcessFileName == "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"C:\Windows\Temp"
| where ProcessCommandLine has "reg save"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Look for evidence of batch script execution that leads to credential dumping

// Search for batch script execution, leading to credential dumping using rundll32 and the COM Services DLL, dsquery, and makecab use
DeviceProcessEvents
| where InitiatingProcessFileName =~ "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"\inetpub\wwwroot\aspnet_client\"
| where InitiatingProcessParentFileName has "w3wp"
| where FileName != "conhost.exe"
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Suspicious files dropped under an aspnet_client folder

Look for dropped suspicious files like web shells and other components

// Search for suspicious files, including but not limited to batch scripts and web shells, dropped under the file path C:\inetpub\wwwroot\aspnet_client\
DeviceFileEvents
| where InitiatingProcessFileName == "w3wp.exe"
| where FolderPath has "\\aspnet_client\\"
| where InitiatingProcessCommandLine contains "MSExchange"
| project FileName, FolderPath, InitiatingProcessCommandLine, DeviceId, Timestamp

Checking for persistence on systems that have been suspected as compromised

Search for creations of new local accounts

DeviceProcessEvents
| where FileName == "net.exe"
| where ProcessCommandLine has_all ("user", "add")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for installation events that were used to download ScreenConnect for persistence

Note that this query may be noisy and is not necessarily indicative of malicious activity alone.

DeviceProcessEvents
| where FileName =~ "msiexec.exe"
| where ProcessCommandLine has @"C:\Windows\Temp\"
| parse-where kind=regex flags=i ProcessCommandLine with @"C:\\Windows\\Temp\\" filename:string @".msi"
| project filename, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Hunting for credential theft

Search for logon events related to services and scheduled tasks on devices that may be Exchange servers. The results of this query should be used to verify whether any of these users have privileged roles that might have enabled further persistence.

let devices =
DeviceProcessEvents
| where InitiatingProcessFileName == "w3wp.exe" and InitiatingProcessCommandLine contains "MSExchange"
| distinct DeviceId;
//
DeviceLogonEvents
| where DeviceId in (devices)
| where LogonType in ("Batch", "Service")
| project AccountName, AccountDomain, LogonType, DeviceId, Timestamp

Search for WDigest registry key modification, which allows for the LSASS process to store plaintext passwords.

DeviceRegistryEvents
| where RegistryValueName == "UseLogonCredential"
| where RegistryKey has "WDigest" and RegistryValueData == "1"
| project PreviousRegistryValueData, RegistryValueData, RegistryKey, RegistryValueName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for the COM services DLL being executed by rundll32, which can be used to dump LSASS memory.

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("rundll32.exe", "comsvcs.dll")
| project FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for Security Account Manager (SAM) or SECURITY databases being saved, from which credentials can later be extracted.

DeviceProcessEvents
| where FileName == "reg.exe"
| where ProcessCommandLine has "save" and ProcessCommandLine has_any ("hklm\\security", "hklm\\sam")
| project InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Indicators

Selected indicators from attacks are included here, the threats may utilize files and network indicators not represented here.

Files (SHA-256)

The following are file hashes for some of the web shells observed during attacks:

  • 201e4e9910dcdc8c4ffad84b60b328978db8848d265c0b9ba8473cf65dcd0c41
  • 2f0bc81c2ea269643cae307239124d1b6479847867b1adfe9ae712a1d5ef135e
  • 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
  • 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
  • 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
  • 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
  • 8e90ed33c7ee82c0b64078ea36ec95f7420ba435c693b3b3dd728b494abf7dfc
  • a291305f181e24fe7194154b4cd355ccb039d5765709c80999e392efec69c90a
  • b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
  • dd29e8d47dde124c7d14e614e03ccaab3ecaa50e0a0bef985ed59e98928bc13d

DoejoCrypt associated hashes:

  • 027119161d11ba87acc908a1d284b93a6bcafccc012e52ce390ecb9cd745bf27
  • 10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25da
  • 2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bff
  • 904fbea2cd68383f32c5bc630d2227601dc52f94790fe7a6a7b6d44bfd904ff3
  • bf53b637683f9cbf92b0dd6c97742787adfbc12497811d458177fdeeae9ec748
  • e044d9f2d0f1260c3f4a543a1e67f33fcac265be114a1b135fd575b860d2b8c6
  • fdec933ca1dd1387d970eeea32ce5d1f87940dfb6a403ab5fc149813726cbd65
  • feb3e6d30ba573ba23f3bd1291ca173b7879706d1fe039c34d53a4fdcdf33ede

Lemon Duck associated hashes:

  • 0993cc228a74381773a3bb0aa36a736f5c41075fa3201bdef4215a8704e582fc
  • 3df23c003d62c35bd6da90df12826c1d3fdd94029bf52449ba3d89920110d5ec
  • 4f0b9c0482595eee6d9ece0705867b2aae9e4ff68210f32b7425caca763723b9
  • 56101ab0881a6a34513a949afb5a204cad06fd1034f37d6791f3ab31486ba56c
  • 69ce57932c3be3374e8843602df1c93e1af622fc53f3f1d9b0a75b66230a1e2e
  • 737752588f32e4c1d8d20231d7ec553a1bd4a0a090b06b2a1835efa08f9707c4
  • 893ddf0de722f345b675fd1ade93ee1de6f1cad034004f9165a696a4a4758c3e
  • 9cf63310788e97f6e08598309cbbf19960162123e344df017b066ca8fcbed719
  • 9f2fe33b1c7230ec583d7f6ad3135abcc41b5330fa5b468b1c998380d20916cd
  • a70931ebb1ce4f4e7d331141ad9eba8f16f98da1b079021eeba875aff4aeaa85
  • d8b5eaae03098bead91ff620656b9cfc569e5ac1befd0f55aee4cdb39e832b09
  • db093418921aae00187ae5dc6ed141c83614e6a4ec33b7bd5262b7be0e9df2cd
  • dc612f5c0b115b5a13bdb9e86f89c5bfe232e5eb76a07c3c0a6d949f80af89fd
  • f517526fc57eb33edb832920b1678d52ad1c5cf9c707859551fe065727587501
  • f8d388f502403f63a95c9879c806e6799efff609001701eed409a8d33e55da2f
  • fbeefca700f84373509fd729579ad7ea0dabdfe25848f44b2fbf61bf7f909df0

Pydomer associated hashes:

  • 7e07b6addf2f0d26eb17f4a1be1cba11ca8779b0677cedc30dbebef77ccba382
  • 866b1f5c5edd9f01c5ba84d02e94ae7c1f9b2196af380eed1917e8fc21acbbdc
  • 910fbfa8ef4ad7183c1b5bdd3c9fd1380e617ca0042b428873c48f71ddc857db
  • a387c3c5776ee1b61018eeb3408fa7fa7490915146078d65b95621315e8b4287
  • b9dbdf11da3630f464b8daace88e11c374a642e5082850e9f10a1b09d69ff04f
  • c25a5c14269c990c94a4a20443c4eb266318200e4d7927c163e0eaec4ede780a
  • c4aa94c73a50b2deca0401f97e4202337e522be3df629b3ef91e706488b64908

Network indicators

Domains abused by Lemon Duck:

  • down[.]sqlnetcat[.]com
  • t[.]sqlnetcat[.]com
  • t[.]netcatkit[.]com

Pydomer DGA network indicators:

  • uiiuui[.]com/search/*
  • yuuuuu43[.]com/vpn-service/*
  • yuuuuu44[.]com/vpn-service/*
  • yuuuuu46[.]com/search/*

The post Analyzing attacks taking advantage of the Exchange Server vulnerabilities appeared first on Microsoft Security.

Analyzing attacks taking advantage of the Exchange Server vulnerabilities

March 25th, 2021 No comments

Microsoft continues to monitor and investigate attacks exploiting the recent on-premises Exchange Server vulnerabilities. These attacks are now performed by multiple threat actors ranging from financially motivated cybercriminals to state-sponsored groups. To help customers who are not able to immediately install updates, Microsoft released a one-click tool that automatically mitigates one of the vulnerabilities and scans servers for known attacks. Microsoft also built this capability into Microsoft Defender Antivirus, expanding the reach of the mitigation. As of today, we have seen a significant decrease in the number of still-vulnerable servers – more than 92% of known worldwide Exchange IPs are now patched or mitigated. We continue to work with our customers and partners to mitigate the vulnerabilities.

As organizations recover from this incident, we continue to publish guidance and share threat intelligence to help detect and evict threat actors from affected environments. Today, we are sharing intelligence about what some attackers did after exploiting the vulnerable servers, ranging from ransomware to data exfiltration and deployment of various second-stage payloads. This blog covers:

  • Threat intelligence and technical details about known attacks, including components and attack paths, that defenders can use to investigate whether on-premises Exchange servers were compromised before they were patched and to comprehensively respond to and remediate these threats if they see them in their environments.
  • Detection and automatic remediation built into Microsoft Defender Antivirus and how investigation and remediation capabilities in solutions like Microsoft Defender for Endpoint can help responders perform additional hunting and remediate threats.

Although the overall numbers of ransomware have remained extremely small to this point, it is important to remember that these threats show how quickly attackers can pivot their campaigns to take advantage of newly disclosed vulnerabilities and target unpatched systems, demonstrating how critical it is for organizations to apply security updates as soon as possible. We strongly urge organizations to identify and update vulnerable on-premises Exchange servers, and to follow mitigation and investigation guidance that we have collected and continue to update here: https://aka.ms/ExchangeVulns.

Mitigating post-exploitation activities

The first known attacks leveraging the Exchange Server vulnerabilities were by the nation-state actor HAFNIUM, which we detailed in this blog. In the three weeks after the Exchange server vulnerabilities were disclosed and the security updates were released, Microsoft saw numerous other attackers adopting the exploit into their toolkits. Attackers are known to rapidly work to reverse engineer patches and develop exploits. In the case of a remote code execution (RCE) vulnerability, the rewards are high for attackers who can gain access before an organization patches, as patching a system does not necessarily remove the access of the attacker.

Figure 1. The Exchange Server exploit chain

In our investigation of the on-premises Exchange Server attacks , we saw systems being affected by multiple threats. Many of the compromised systems have not yet received a secondary action, such as human-operated ransomware attacks or data exfiltration, indicating attackers could be establishing and keeping their access for potential later actions. These actions might involve performing follow-on attacks via persistence on Exchange servers they have already compromised, or using credentials and data stolen during these attacks to compromise networks through other entry vectors.

Attackers who included the exploit in their toolkits, whether through modifying public proof of concept exploits or their own research, capitalized on their window of opportunity to gain access to as many systems as they could. Some attackers were advanced enough to remove other attackers from the systems and use multiple persistence points to maintain access to a network.

We have built protections against these threats into Microsoft security solutions. Refer to the Appendix for a list of indicators of compromise, detection details, and advanced hunting queries. We have also provided additional tools and investigation and remediation guidance here: https://aka.ms/exchange-customer-guidance.

While performing a full investigation on systems is recommended, the following themes are common in many of the attacks. These are prevailing threat trends that Microsoft has been monitoring, and existing solutions and recommendations for prevention and mitigation apply:

  • Web shells – As of this writing, many of the unpatched systems we observed had multiple web shells on them. Microsoft has been tracking the rise of web shell attacks for the past few years, ensuring our products detect these threats and providing remediation guidance for customers. For more info on web shells, read Web shell attacks continue to rise. We have also published guidance on web shell threat hunting with Azure Sentinel.
  • Human-operated ransomware – Ransomware attacks pose some of the biggest security risks for organizations today, and attackers behind these attacks were quick to take advantage of the on-premises Exchange Server vulnerabilities. Successfully exploiting the vulnerabilities gives attackers the ability to launch human-operated ransomware campaigns, a trend that Microsoft has been closely monitoring. For more information about human-operated ransomware attacks, including Microsoft solutions and guidance for improving defenses, read: Human-operated ransomware attacks.
  • Credential theft – While credential theft is not the immediate goal of some of these attacks, access to Exchange servers allowed attackers to access and potentially steal credentials present on the system. Attackers can use these stolen credentials for follow-on attacks later, so organizations need to prioritize identifying and remediating impacted identities. For more information, read best practices for building credential hygiene.

In the following sections, we share our analysis of known post-compromise activities associated with exploitation of the Exchange server vulnerabilities because it is helpful to understand these TTPs, in order to defend against other actors using similar tactics or tools. While levels of disruptive post-compromise activity like ransomware may be limited at the time of this writing, Microsoft will continue to track this space and share information with the community. It’s important to note that with some post-compromise techniques, attackers may gain highly privileged persistent access, but many of the impactful subsequent attacker activities can be mitigated by practicing the principle of least privilege and mitigating lateral movement.

DoejoCrypt ransomware

DoejoCrypt was the first ransomware to appear to take advantage of the vulnerabilities, starting to encrypt in limited numbers shortly after the patches were released. Ransomware attackers often use multiple tools and exploits to gain initial access, including purchasing access through a broker or “reseller” who sells access to systems they have already compromised. The DoejoCrypt attacks start with a variant of the Chopper web shell being deployed to the Exchange server post-exploitation.

The web shell writes a batch file to C:\Windows\Temp\xx.bat. Found on all systems that received the DoejoCrypt ransomware payload, this batch file performs a backup of the Security Account Manager (SAM) database and the System and Security registry hives, allowing the attackers later access to passwords of local users on the system and, more critically, in the LSA Secrets portion of the registry, where passwords for services and scheduled tasks are stored.

Figure 2. xx.bat

Given configurations that administrators typically use on Exchange servers, many of the compromised systems are likely to have had at least one service or scheduled task configured with a highly privileged account to perform actions like backups. As service account credentials are not frequently changed, this could provide a great advantage to an attacker even if they lose their initial web shell access due to an antivirus detection, as the account can be used to elevate privileges later, which is why we strongly recommend operating under the principle of least privileged access.

The batch file saves the registry hives to a semi-unique location, C:\windows\temp\debugsms, assembles them into a CAB file for exfiltration, and then cleans up the folders from the system. The file also enables Windows Remote Management and sets up an HTTP listener, indicating the attacker might take advantage of the internet-facing nature of an Exchange Server and use this method for later access if other tools are removed.

Figure 3. xx.bat actions

The xx.bat file has been run on many more systems than have been ransomed by the DoejoCrypt attacker, meaning that, while not all systems have moved to the ransom stage, the attacker has gained access to multiple credentials. On systems where the attacker moved to the ransom stage, we saw reconnaissance commands being run via the same web shell that dopped the xx.bat file (in this instance, a version of Chopper):

Figure 4. DoejoCrypt recon command

After these commands are completed, the web shell drops a new payload to C:\Windows\Help which, like in many human-operated ransomware campaigns, leads to the attack framework Cobalt Strike. In observed instances, the downloaded payload is shellcode with the file name new443.exe or Direct_Load.exe. When run, this payload injects itself into notepad.exe and reaches out to a C2 to download Cobalt Strike shellcode.

Figure 5. DoejoCrypt ransomware attack chain

During the hands-on-keyboard stage of the attack, a new payload is downloaded to C:\Windows\Help with names like s1.exe and s2.exe. This payload is the DoejoCrypt ransomware, which uses a .CRYPT extension for the newly encrypted files and a very basic readme.txt ransom note. In some instances, the time between xx.bat being dropped and a ransomware payload running was under half an hour.

Figure 6. DoejoCrypt ransom note

While the DoejoCrypt payload is the most visible outcome of this attackers’ actions, the access to credentials they have gained could serve them for future campaigns if organizations do not reset credentials on compromised systems. An additional overlapping activity observed on systems where xx.bat was present and the attackers were able to get Domain Administrator rights was the running of scripts to snapshot Active Directory with ntdsutil—an action that, if executed successfully, could give the attackers access to all the passwords in Active Directory from a single compromised system.

Lemon Duck botnet

Cryptocurrency miners were some of the first payloads we observed being dropped by attackers from the post-exploit web shells. In the first few days after the security updates were released, we observed multiple cryptocurrency miner campaigns, which had been previously targeting SharePoint servers, add Exchange Server exploitation to their repertoire. Most of these coin miners were variations on XMRig miners, and many arrived via a multi-featured implant with the capability to download new payloads or even move laterally.

Lemon Duck, a known cryptocurrency botnet named for a variable in its code, dove into the Exchange exploit action, adopting different exploit styles and choosing to use a fileless/web shell-less option of direct PowerShell commands from w3wp (the IIS worker process) for some attacks. While still maintaining their normal email-based campaigns, the Lemon Duck operators compromised numerous Exchange servers and moved in the direction of being more of a malware loader than a simple miner.

Using a form of the attack that allows direct execution of commands versus dropping a web shell, the Lemon Duck operators ran standard Invoke Expression commands to download a payload. Having used the same C2 and download servers for some time, the operators applied a varied degree of obfuscation to their commands on execution.

Fig 7. Example executions of Lemon Duck payload downloads

The Lemon Duck payload is an encoded and obfuscated PowerShell script. It first removes various security products from the system, then creates scheduled tasks and WMI Event subscription for persistence. A second script is downloaded to attempt to evade Microsoft Defender Antivirus, abusing their administrative access to run the Set-MPPreference command to disable real-time monitoring (a tactic that Microsoft Defender Tamper protection blocks) and add scanning exclusions for the C:\ drive and the PowerShell process.

Figure 8. Lemon Duck payloads

One randomly named scheduled task connects to a C2 every hour to download a new payload, which includes various lateral movement and credential theft tools. The operators were seen to download RATs and information stealers, including Ramnit payloads.

Figure 9. Lemon Duck post-exploitation activities

In some instances, the operators took advantage of having compromised mail servers to access mailboxes and send emails containing the Lemon Duck payload using various colorful email subjects.

Figure 10. Email subjects of possibly malicious emails

Figure 11. Attachment variables

In one notable example, the Lemon Duck operators compromised a system that already had xx.bat and a web shell. After establishing persistence on the system in a non-web shell method, the Lemon Duck operators were observed cleaning up other attackers’ presence on the system and mitigating the CVE-2021-26855 (SSRF) vulnerability using a legitimate cleanup script that they hosted on their own malicious server. This action prevents further exploitation of the server and removes web shells, giving Lemon Duck exclusive access to the compromised server. This stresses the need to fully investigate systems that were exposed, even if they have been fully patched and mitigated, per traditional incident response process.

Pydomer ransomware

While DoejoCrypt was a new ransomware payload, the access gained by attackers via the on-premises Exchange Server vulnerabilities will likely become part of the complex cybercriminal economy where additional ransomware operators and affiliates take advantage of it. The first existing ransomware family to capitalize on the vulnerabilities was Pydomer. This ransomware family was previously seen using vulnerabilities in attacks, notably taking advantage of Pulse Secure VPN vulnerabilities, for which Pulse Secure has released security patches, to steal credentials and perform ransomware attacks.

In this campaign, the operators scanned and mass-compromised unpatched Exchange Servers to drop a web shell. They started later than some other attackers, with many compromises occurring between March 18 and March 20, a window when fewer unpatched systems were available. They then dropped a web shell, with a notable file name format: “Chack[Word][Country abbreviation]”:

Figure 12. Example web shell names observed being used by the Pydomer attackers

These web shells were observed on around 1,500 systems, not all of which moved to the ransomware stage. The attackers then used their web shell to dump a test.bat batch file that performed a similar function in the attack chain to the xx.bat of the DoejoCrypt operators and allowed them to perform a dump of the LSASS process.

Figure 13. Pydomer post-exploitation activities

This access alone would be valuable to attackers for later attacks, similar to the credentials gained during their use of Pulse Secure VPN vulnerabilities. The highly privileged credentials gained from an Exchange system are likely to contain domain administrator accounts and service accounts with backup privileges, meaning these attackers could perform ransomware and exfiltration actions against the networks they compromised long after the Exchange Server is patched and even enter via different means.

On systems where the attackers did move to second-stage ransomware operations, they utilized a Python script compiled to an executable and the Python cryptography libraries to encrypt files. The attackers then executed a PowerShell script via their web shell that acts as a downloader and distribution mechanism for the ransomware.

Figure 14. PowerShell downloader and spreader used to get the Pydomer payload

The script fetches a payload from a site hosted on a domain generation algorithm (DGA) domain, and attempts to spread the payload throughout the network, first attempting to spread the payload over WMI using Invoke-WMIMethod to attempt to connect to systems, and falling back to PowerShell remoting with Enter-PSSession if that fails. The script is run within the context of the web shell, which in most instances is Local System, so this lateral movement strategy is unlikely to work except in organizations that are running highly insecure and unrecommended configurations like having computer objects in highly privileged groups.

The Pydomer ransomware is a Python script compiled to an executable and uses the Python cryptography libraries to encrypt files. The ransomware encrypts the files and appends a random extension, and then drops a ransom note named decrypt_file.TxT.

Figure 15. Pydomer ransom note

Interestingly, the attackers seem to have deployed a non-encryption extortion strategy. Following well-known ransomware groups like Maze and Egregor which leaked data for pay, the Pydomer hackers dropped an alternative readme.txt onto systems without encrypting files. This option might have been semi-automated on their part or a side effect of a failure in their encryption process, as some of the systems they accessed were test systems that showed no data exfiltration. The note should be taken seriously if encountered, as the attackers had full access to systems and were likely able to exfiltrate data.

Figure 16. Pydomer extortion readme.txt

Credential theft, turf wars, and dogged persistence

If a server is not running in a least-privilege configuration, credential theft could provide a significant return on investment for an attacker beyond their initial access to email and data. Many organizations have backup agent software and scheduled tasks running on these systems with domain admin-level permissions. For these organizations, the attackers might be able to harvest highly privileged credentials without lateral movement, for example, using the COM services DLL as a living-off-the-land binary to perform a dump of the LSASS process:

Figure 17. Use of COM services DLL to dump LSASS process

The number of observed credential theft attacks, combined with high privilege of accounts often given to Exchange servers, means that these attacks could continue to impact organizations that don’t fully remediate after a compromise even after patches have been applied. While the observed ransomware attempts were small-scale or had errors, there is still the possibility of more skillful groups utilizing credentials gained in these attacks for later attacks.

Attackers also used their access to perform extensive reconnaissance using built-in Exchange commandlets and dsquery to exfiltrate information about network configurations, user information, and email assets.

While Lemon Duck operators might have had the boldest method for removing other attackers from the systems they compromised, they were not the only attacker to do so. Others were observed cleaning up .aspx and .bat files to remove other attackers, and even rebuilding the WMI database by deleting .mof files and restarting the service. As the window on unpatched machines closes, attackers showed increased interest in maintaining the access to the systems they exploited. By utilizing “malwareless” persistence mechanisms like enabling RDP, installing Shadow IT tools, and adding new local administrator accounts, the attackers are hoping to evade incident response efforts that might focus exclusively on web shells, AV scans, and patching.

Defending against exploits and post-compromise activities

Attackers exploit the on-premises Exchange Server vulnerabilities in combination to bypass authentication and gain the ability to write files and run malicious code. The best and most complete remediation for these vulnerabilities is to update to a supported Cumulative Update and to install all security updates. Comprehensive mitigation guidance can be found here: https://aka.ms/ExchangeVulns.

As seen in the post-exploitation attacks discussed in this blog, the paths that attackers can take after successfully exploiting the vulnerabilities are varied and wide-ranging. If you have determined or have reason to suspect that these threats are present on your network, here are immediate steps you can take:

  • Investigate exposed Exchange servers for compromise, regardless of their current patch status.
  • Look for web shells via our guidance and run a full AV scan using the Exchange On-Premises Mitigation Tool.
  • Investigate Local Users and Groups, even non-administrative users for changes, and ensure all users require a password for sign-in. New user account creations (represented by Event ID 4720) during the time the system was vulnerable might indicate a malicious user creation.
  • Reset and randomize local administrator passwords with a tool like LAPS if you are not already doing so.
  • Look for changes to the RDP, firewall, WMI subscriptions, and Windows Remote Management (WinRM) configuration of the system that might have been configured by the attacker to allow persistence.
  • Look for Event ID 1102 to determine if attackers cleared event logs, an activity that attackers perform with exe in an attempt to hide their tracks.
  • Look for new persistence mechanisms such as unexpected services, scheduled tasks, and startup items.
  • Look for Shadow IT tools that attackers might have installed for persistence, such as non-Microsoft RDP and remote access clients.
  • Check mailbox-level email forwarding settings (both ForwardingAddress and ForwardingSMTPAddress attributes), check mailbox inbox rules (which might be used to forward email externally), and check Exchange Transport rules that you might not recognize.

While our response tools check for and remove known web shells and attack tools, performing a full investigation of these systems is recommended. For comprehensive investigation and mitigation guidance and tools, see https://aka.ms/exchange-customer-guidance.

Additionally, here are best practices for building credential hygiene and practicing the principle of least privilege:

  • Follow guidance to run Exchange in least-privilege configuration: https://adsecurity.org/?p=4119.
  • Ensure service accounts and scheduled tasks run with the least privileges they need. Avoid widely privileged groups like domain admins and backup operators and prefer accounts with access to just the systems they need.
  • Randomize local administrator passwords to prevent lateral movement with tools like LAPS.
  • Ensure administrators practice good administration habits like Privileged Admin Workstations.
  • Prevent privileged accounts like domain admins from signing into member servers and workstations using Group Policy to limit credential exposure and lateral movement.

 

Appendix

Microsoft Defender for Endpoint detection details

Antivirus                                                                                                                                   

Microsoft Defender Antivirus detects exploitation behavior with these detections:

Web shells are detected as:

Ransomware payloads and associated files are detected as:

Lemon Duck malware is detected as:

Some of the credential theft techniques highlighted in this report are detected as:

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network:

  • Suspicious Exchange UM process creation
  • Suspicious Exchange UM file creation
  • Suspicious w3wp.exe activity in Exchange
  • Possible exploitation of Exchange Server vulnerabilities
  • Possible IIS web shell
  • Possible web shell installation
  • Web shells associated with Exchange Server vulnerabilities
  • Network traffic associated with Exchange Server exploitation

Alerts with the following titles in the security center can indicate threat activity on your network specific to the DoejoCrypt and Pydomer ransomware campaign:

  • DoejoCrypt ransomware
  • Pydomer ransomware
  • Pydomer download site

Alerts with the following titles in the security center can indicate threat activity on your network specific to the Lemon Duck botnet:

  • LemonDuck Malware
  • LemonDuck botnet C2 domain activity

The following behavioral alerts might also indicate threat activity associated with this threat:

  • Possible web shell installation
  • A suspicious web script was created
  • Suspicious processes indicative of a web shell
  • Suspicious file attribute change
  • Suspicious PowerShell command line
  • Possible IIS Web Shell
  • Process memory dump
  • A malicious PowerShell Cmdlet was invoked on the machine
  • WDigest configuration change
  • Sensitive information lookup
  • Suspicious registry export

Advanced hunting

To locate possible exploitation activities in Microsoft Defender for Endpoint, run the following queries.

Processes run by the IIS worker process

Look for processes executed by the IIS worker process

// Broadly search for processes executed by the IIS worker process. Further investigation should be performed on any devices where the created process is indicative of reconnaissance
DeviceProcessEvents
| where InitiatingProcessFileName == 'w3wp.exe'
| where InitiatingProcessCommandLine contains "MSExchange"
| where FileName !in~ ("csc.exe","cvtres.exe","conhost.exe","OleConverter.exe","wermgr.exe","WerFault.exe","TranscodingService.exe")
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for PowerShell spawned from the IIS worker process, observed most frequently in Lemon Duck with Base64 encoding to obfuscate C2 domains

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName =~ "w3wp.exe"
| where InitiatingProcessCommandLine contains "MSExchange"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Tampering

Search for Lemon Duck tampering with Microsoft Defender Antivirus

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("Set-MpPreference", "DisableRealtimeMonitoring", "Add-MpPreference", "ExclusionProcess")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Batch script actions

Search for batch scripts performing credential theft, as observed in DoejoCrypt infections

DeviceProcessEvents
| where InitiatingProcessFileName == "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"C:\Windows\Temp"
| where ProcessCommandLine has "reg save"
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Look for evidence of batch script execution that leads to credential dumping

// Search for batch script execution, leading to credential dumping using rundll32 and the COM Services DLL, dsquery, and makecab use
DeviceProcessEvents
| where InitiatingProcessFileName =~ "cmd.exe"
| where InitiatingProcessCommandLine has ".bat" and InitiatingProcessCommandLine has @"\inetpub\wwwroot\aspnet_client\"
| where InitiatingProcessParentFileName has "w3wp"
| where FileName != "conhost.exe"
| project FileName, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Suspicious files dropped under an aspnet_client folder

Look for dropped suspicious files like web shells and other components

// Search for suspicious files, including but not limited to batch scripts and web shells, dropped under the file path C:\inetpub\wwwroot\aspnet_client\
DeviceFileEvents
| where InitiatingProcessFileName == "w3wp.exe"
| where FolderPath has "\\aspnet_client\\"
| where InitiatingProcessCommandLine contains "MSExchange"
| project FileName, FolderPath, InitiatingProcessCommandLine, DeviceId, Timestamp

Checking for persistence on systems that have been suspected as compromised

Search for creations of new local accounts

DeviceProcessEvents
| where FileName == "net.exe"
| where ProcessCommandLine has_all ("user", "add")
| project ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Search for installation events that were used to download ScreenConnect for persistence

Note that this query may be noisy and is not necessarily indicative of malicious activity alone.

DeviceProcessEvents
| where FileName =~ "msiexec.exe"
| where ProcessCommandLine has @"C:\Windows\Temp\"
| parse-where kind=regex flags=i ProcessCommandLine with @"C:\\Windows\\Temp\\" filename:string @".msi"
| project filename, ProcessCommandLine, InitiatingProcessCommandLine, DeviceId, Timestamp

Hunting for credential theft

Search for logon events related to services and scheduled tasks on devices that may be Exchange servers. The results of this query should be used to verify whether any of these users have privileged roles that might have enabled further persistence.

let devices =
DeviceProcessEvents
| where InitiatingProcessFileName == "w3wp.exe" and InitiatingProcessCommandLine contains "MSExchange"
| distinct DeviceId;
//
DeviceLogonEvents
| where DeviceId in (devices)
| where LogonType in ("Batch", "Service")
| project AccountName, AccountDomain, LogonType, DeviceId, Timestamp

Search for WDigest registry key modification, which allows for the LSASS process to store plaintext passwords.

DeviceRegistryEvents
| where RegistryValueName == "UseLogonCredential"
| where RegistryKey has "WDigest" and RegistryValueData == "1"
| project PreviousRegistryValueData, RegistryValueData, RegistryKey, RegistryValueName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for the COM services DLL being executed by rundll32, which can be used to dump LSASS memory.

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("rundll32.exe", "comsvcs.dll")
| project FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Search for Security Account Manager (SAM) or SECURITY databases being saved, from which credentials can later be extracted.

DeviceProcessEvents
| where FileName == "reg.exe"
| where ProcessCommandLine has "save" and ProcessCommandLine has_any ("hklm\\security", "hklm\\sam")
| project InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, InitiatingProcessParentFileName, DeviceId, Timestamp

Indicators

Selected indicators from attacks are included here, the threats may utilize files and network indicators not represented here.

Files (SHA-256)

The following are file hashes for some of the web shells observed during attacks:

  • 201e4e9910dcdc8c4ffad84b60b328978db8848d265c0b9ba8473cf65dcd0c41
  • 2f0bc81c2ea269643cae307239124d1b6479847867b1adfe9ae712a1d5ef135e
  • 4edc7770464a14f54d17f36dc9d0fe854f68b346b27b35a6f5839adf1f13f8ea
  • 511df0e2df9bfa5521b588cc4bb5f8c5a321801b803394ebc493db1ef3c78fa1
  • 65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5
  • 811157f9c7003ba8d17b45eb3cf09bef2cecd2701cedb675274949296a6a183d
  • 8e90ed33c7ee82c0b64078ea36ec95f7420ba435c693b3b3dd728b494abf7dfc
  • a291305f181e24fe7194154b4cd355ccb039d5765709c80999e392efec69c90a
  • b75f163ca9b9240bf4b37ad92bc7556b40a17e27c2b8ed5c8991385fe07d17d0
  • dd29e8d47dde124c7d14e614e03ccaab3ecaa50e0a0bef985ed59e98928bc13d

DoejoCrypt associated hashes:

  • 027119161d11ba87acc908a1d284b93a6bcafccc012e52ce390ecb9cd745bf27
  • 10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25da
  • 2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bff
  • 904fbea2cd68383f32c5bc630d2227601dc52f94790fe7a6a7b6d44bfd904ff3
  • bf53b637683f9cbf92b0dd6c97742787adfbc12497811d458177fdeeae9ec748
  • e044d9f2d0f1260c3f4a543a1e67f33fcac265be114a1b135fd575b860d2b8c6
  • fdec933ca1dd1387d970eeea32ce5d1f87940dfb6a403ab5fc149813726cbd65
  • feb3e6d30ba573ba23f3bd1291ca173b7879706d1fe039c34d53a4fdcdf33ede

Lemon Duck associated hashes:

  • 0993cc228a74381773a3bb0aa36a736f5c41075fa3201bdef4215a8704e582fc
  • 3df23c003d62c35bd6da90df12826c1d3fdd94029bf52449ba3d89920110d5ec
  • 4f0b9c0482595eee6d9ece0705867b2aae9e4ff68210f32b7425caca763723b9
  • 56101ab0881a6a34513a949afb5a204cad06fd1034f37d6791f3ab31486ba56c
  • 69ce57932c3be3374e8843602df1c93e1af622fc53f3f1d9b0a75b66230a1e2e
  • 737752588f32e4c1d8d20231d7ec553a1bd4a0a090b06b2a1835efa08f9707c4
  • 893ddf0de722f345b675fd1ade93ee1de6f1cad034004f9165a696a4a4758c3e
  • 9cf63310788e97f6e08598309cbbf19960162123e344df017b066ca8fcbed719
  • 9f2fe33b1c7230ec583d7f6ad3135abcc41b5330fa5b468b1c998380d20916cd
  • a70931ebb1ce4f4e7d331141ad9eba8f16f98da1b079021eeba875aff4aeaa85
  • d8b5eaae03098bead91ff620656b9cfc569e5ac1befd0f55aee4cdb39e832b09
  • db093418921aae00187ae5dc6ed141c83614e6a4ec33b7bd5262b7be0e9df2cd
  • dc612f5c0b115b5a13bdb9e86f89c5bfe232e5eb76a07c3c0a6d949f80af89fd
  • f517526fc57eb33edb832920b1678d52ad1c5cf9c707859551fe065727587501
  • f8d388f502403f63a95c9879c806e6799efff609001701eed409a8d33e55da2f
  • fbeefca700f84373509fd729579ad7ea0dabdfe25848f44b2fbf61bf7f909df0

Pydomer associated hashes:

  • 7e07b6addf2f0d26eb17f4a1be1cba11ca8779b0677cedc30dbebef77ccba382
  • 866b1f5c5edd9f01c5ba84d02e94ae7c1f9b2196af380eed1917e8fc21acbbdc
  • 910fbfa8ef4ad7183c1b5bdd3c9fd1380e617ca0042b428873c48f71ddc857db
  • a387c3c5776ee1b61018eeb3408fa7fa7490915146078d65b95621315e8b4287
  • b9dbdf11da3630f464b8daace88e11c374a642e5082850e9f10a1b09d69ff04f
  • c25a5c14269c990c94a4a20443c4eb266318200e4d7927c163e0eaec4ede780a
  • c4aa94c73a50b2deca0401f97e4202337e522be3df629b3ef91e706488b64908

Network indicators

Domains abused by Lemon Duck:

  • down[.]sqlnetcat[.]com
  • t[.]sqlnetcat[.]com
  • t[.]netcatkit[.]com

Pydomer DGA network indicators:

  • uiiuui[.]com/search/*
  • yuuuuu43[.]com/vpn-service/*
  • yuuuuu44[.]com/vpn-service/*
  • yuuuuu46[.]com/search/*

The post Analyzing attacks taking advantage of the Exchange Server vulnerabilities appeared first on Microsoft Security.

Introducing Bounty Awards for Teams Desktop Client Security Research

March 24th, 2021 No comments

Partnering with the security research community is an important part of Microsoft’s holistic approach to defending against security threats. As much of the world has shifted to working from home in the last year, Microsoft Teams has enabled people to stay connected, organized, and collaborate remotely. Microsoft and security researchers across the planet continue to …

Introducing Bounty Awards for Teams Desktop Client Security Research Read More »

How one data scientist is pioneering techniques to detect security threats

March 24th, 2021 No comments

Data science is an increasingly popular field of study that’s relevant to every industry. When Maria Puertas Calvo was a student, she never imagined that one day she would pioneer data science techniques to detect security threats. She started her Microsoft career on the Safety Platform team, developing algorithms to identify Microsoft accounts that send spam emails. She then worked on machine learning to detect account compromise in real-time for Microsoft accounts.

Maria now leads the data science team for security in the identity division, working on several problems: protecting users from account compromise, protecting our own infrastructure from fraud and abuse, and making sure that spammers and bots don’t create accounts that will harm people or other organizations. Her work has been so critical that her team is doubling in size, expanding from Redmond to Dublin and Atlanta.

In honor of Women’s History Month, Alex Simons, Corporate Vice President of Identity Program Management, sat down with Maria to learn more about her groundbreaking work and inspiring story. The interview has been edited for clarity and length. 

Maria Puertas Calvo leaning against a wall next to an open window.

 

Alex: Maria, how did you get into engineering?

Maria: I am originally from Madrid, Spain. I was always interested in math and science. Since I was little, I was always the straight-A student—really in love with numbers. When I started studying physics in high school, I knew that I wanted to have a career in science, doing something innovative.

In Spain, you don’t really leave for college. You go to class during the day, and then you go back to your parents’ home at night. A really good university was only 10 minutes away from my house. It wasn’t really engineering-focused, but it did have one technical school that offered electrical engineering and computer science.

Alex: What prompted you to make the transition from pure electrical engineering into something more forensics-focused and then eventually data science-focused?

Maria: It was all pretty accidental, not something I had planned. I did really well in college—I was first in my class. And I finished in 2010, in the middle of the Great Recession, which hit the Spanish labor market horribly. At that time, the unemployment rate was 25 percent. The lucky ones, like people in engineering, were getting job offers. But when you’re in technology, the only options in Spain are to work for a consulting company or to do support or sales. There weren’t any entry-level jobs in research and development.

So, I started a master’s with a group doing research on biometrics. The master’s was also in computer science and very related to artificial intelligence and a lot of interconnected fields like multimedia signal processing, computer vision, and natural language processing. I did my thesis on statistics around forensic fingerprints, and the probability of a random match between a latent fingerprint found at a crime scene and a random person that could have been wrongly convicted of that crime.

Alex: So what is the likelihood of that happening?

Maria: It’s really, really low. But it’s not zero.

Alex: Okay, that’s totally fascinating! I recall that you actually did your graduate work here in the United States, right?

Maria: When I finished my master’s, I was dating my now-husband, who is American. And I did not want to finish the whole PhD. I wanted to go work in the industry because I had been a student for seven years already, plus the rest of my life before that. I also wanted to start a life, and not do long distance between Madrid and Washington, D.C. So, I took advantage of my scholarship to become a visiting researcher at the University of Maryland working on iris recognition biometrics. I ended up staying about nine months.

Alex: Oh, wow. My father actually got his PhD from the University of Maryland—I was born there. Small world! So then, tell us how you ended up at Microsoft.

Maria: I didn’t find academia very rewarding. So, I said, “Let’s go find an industry job.” I was living in the U.S. with my fiancé on a student visa. And in the D.C. area, most technology companies are government contractors that require security clearances, which only American citizens can get. I also didn’t have any industry experience whatsoever.

I spent a couple months applying for jobs and never getting called back. Then out of the blue, I got a LinkedIn message from a Microsoft recruiter saying, “Hey, I have a role for a data scientist on the Safety Platform team in Seattle.” And I was like, “Seattle, no, no way.” All I knew about Seattle is that it rains a lot, and it’s on the other side of the country. And it’s so far away from Spain. But my husband said, “Hey, you got an interview, go do it, see how it goes, you’ll get to practice.”

Alex: In the Safety Platform team, you did innovative work that has been the underpinnings of the success we’ve had so far. Tell us a little more.

Maria: I worked on machine learning to detect compromises in real-time for Microsoft accounts. When a user signed into their Outlook.com account or Xbox account, or any service Microsoft offers, we would run a machine learning (ML) model to determine if that sign-in was legitimate, or if some hacker had gotten the user’s password. I was the data scientist working on training the model and improving its accuracy. Although I stopped working on it a while ago, we’re still monitoring it and it’s still working really well.

Alex: At the time, nobody else in the industry was succeeding at this kind of work. Today, there’s a whole industry around user entity behavioral analytics, but you were one of the first in the world to do it! I love the work your team does, Maria. I feel like you are superheroes defending the world, but I don’t know that our customers have a great view into the kind of magic you do.

Maria: Thanks, Alex. We use analytics and machine learning to detect bad activity in the identity ecosystem. Our goal is to protect our customers from fraud and account compromise using advanced AI techniques and data science. We come up with ways to detect malicious attacks, fraud, or account compromises among all the security data that we examine at Microsoft, which is hundreds of terabytes every day. It’s a complicated problem, but it’s really cool.

Alex: Some of your most innovative work recently was around password spray detection. Can you tell us how having data from multiple customers enables you to detect things maybe no one else could?

Maria: In a password spray attack, a person grabs a list of email addresses that they find or collect from a breach. And then they try a few common passwords against all those email addresses—against thousands of users from thousands of organizations.

We knew these attacks were happening to our customers, but we wanted to detect them really accurately. These attacks are spread across tons of different IP addresses and countries and proxies, so it’s not easy to isolate the sign-ins that are part of an actual attack. We created a detection rule that says, “Okay, we’re seeing IP addresses that have a lot of failed sign-ins that all are using the same password.” And then we see these attempts move to a different password.

Doing that, we can isolate a possible attack, but there’s also a lot of noise. So, one of the awesome data scientists in my team, Sergio, added a layer of artificial intelligence and trained a model with known attacks. He improved the accuracy of the initial heuristic by 50 percent.

Alex: This is such an important key set of capabilities for us. I’m really excited we’re growing your team. Switching gears, another thing that you and I share in common is the joy of being the parent of twins. My twins are obviously a lot older than yours, but tell us how you manage the challenge of, “Hey, I want to be a family person and I also want to be a real leader in the industry.”

Maria: I’m still figuring it out! It’s definitely a lot of work and you have to learn to better manage your time in order to be successful at both jobs. Luckily, Microsoft offers great parental leave that both my husband and I could enjoy (he’s an engineer in Azure). I have an amazing team and they kept things running really smoothly in my absence. Also, working remotely because of the pandemic has made things easier for me. I can check on my kids in between meetings, and not having a commute gives me more time to be with my family.

Alex: The pandemic has definitely accelerated the move to remote work. As a parent, I think it’s a beautiful thing to be able to manage your time and not have to worry about your location.

So, Maria, one last question. Let’s say I’m a college student, or maybe I’m working on my master’s or PhD in data science and AI. If I wanted to come work on your team, what would you suggest I work on or think about to prepare for that kind of job?

Maria: One good approach is to find an internship that has some connection between doing data science and security and fraud, even if it’s just loosely related. Right now, there are so many people studying data science and machine learning, so specializing and really understanding the world of the cloud and cybersecurity is important. There are tons of resources just to learn about it, such as specific courses in cybersecurity. An internship doesn’t have to be specific to hardcore security—it could be fraud, like finance fraud. Anything in an adversarial-type world where you’re trying to catch bad things happening would be useful. Internships are easier to get without any kind of specialization but having done an internship gives you a foot in the door for a full-time position that specializes in cybersecurity. In addition, Microsoft Security sponsors many cybersecurity educational programs and I would encourage women in high school to investigate these.

Learn more

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.

Security Unlocked podcast icon displaying illustration of lock with microphone inside

Listen to the Security Unlocked podcast

To learn more about applying data science to cybersecurity, listen to Maria’s guest appearance on the episode Identity Threats, Tokens, and Tacos.

Listen now

The post How one data scientist is pioneering techniques to detect security threats appeared first on Microsoft Security.

Introducing Bounty Awards for Teams Desktop Client Security Research

Partnering with the security research community is an important part of Microsoft’s holistic approach to defending against security threats. As much of the world has shifted to working from home in the last year, Microsoft Teams has enabled people to stay connected, organized, and collaborate remotely. Microsoft and security researchers across the planet continue to partner to help secure customers and the technologies we use for remote collaboration.

Categories: Uncategorized Tags:

Secure containerized environments with updated threat matrix for Kubernetes

March 23rd, 2021 No comments

Last April, we released the first version of the threat matrix for Kubernetes. It was the first attempt to systematically map the threat landscape of Kubernetes. As we described in the previous post, we chose to adapt the structure of MITRE ATT&CK® framework which, became almost an industry standard for describing threats.

Since the publication of the threat matrix last year, things have changed:

  • New threats were discovered as attackers targeted more and more Kubernetes workloads.
  • We were glad to see that the security community adopted the matrix and added more techniques.
  • As Kubernetes evolves, it becomes more secure by default and some techniques are no longer relevant.

Today, we are releasing the second version of the threat matrix for Kubernetes, which considers these changes. The updated matrix adds new techniques that were found by Microsoft researchers, as well as techniques that were suggested by the community. We also deprecate several techniques, which do not apply anymore to newer versions of Kubernetes. In this version, we also add a new tactic taken from MITRE ATT&CK®: collection.

The threat matrix to Kubernetes. The matrix consists of the various attacking techniques that target Kubernetes.

What has deprecated?

Kubernetes evolved and became more secure by default; techniques that appeared in last year’s matrix aren’t relevant to newer environments. Therefore, we decided to deprecate some of the techniques:

Exposed Kubernetes Dashboard

The Kubernetes dashboard’s usage has been in decline for a while now. Cloud-managed clusters, such as Microsoft’s AKS and Google’s GKE, deprecated this service and moved to a centralized interface in their portals. Moreover, the recent versions of the Kubernetes dashboard require authentication and it’s less likely to find exposed dashboards that do not require authentication. Consequently, we also removed the technique, “Access Kubernetes dashboard,” under lateral movement tactic. Older versions of Kubernetes, including newer clusters that have the dashboard manually installed, are still affected by this technique. The concept of this technique was generalized in the new technique: exposed sensitive interfaces (see below).

Access tiller endpoint­

As of version 3, Helm doesn’t use its server-side component, Tiller. This is a major improvement in the security of Helm. Currently, Helm operates (by default) on behalf of the user’s credentials as they appear in the kubeconfig file. Users of older versions of Helm are still affected by this technique.

New techniques for the threat matrix

1. Initial access

Exposed sensitive interfaces

Exposing a sensitive interface to the internet poses a security risk. Some popular frameworks were not intended to be exposed to the internet, and therefore don’t require authentication by default. Thus, exposing them to the internet allows unauthenticated access to a sensitive interface which might enable running code or deploying containers in the cluster by a malicious actor. Examples of such interfaces that were seen exploited include Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, and the Kubernetes dashboard.

2. Execution

Sidecar injection

A Kubernetes Pod is a group of one or more containers with shared storage and network resources. Sidecar container is a term that is used to describe an additional container that resides alongside the main container. For example, service-mesh proxies are operating as sidecars in the applications’ pods. Attackers can run their code and hide their activity by injecting a sidecar container to a legitimate pod in the cluster instead of running their own separated pod in the cluster.

3. Persistence

Malicious admission controller

Admission controller is a Kubernetes component that intercepts, and possibly modifies, requests to the Kubernetes API server. There are two types of admissions controllers: validating and mutating controllers. As the name implies, a mutating admission controller can modify the intercepted request and change its properties. Kubernetes has a built-in generic admission controller named MutatingAdmissionWebhook. The behavior of this admission controller is determined by an admission webhook that the user deploys in the cluster. Attackers can use such webhooks for gaining persistence in the cluster. For example, attackers can intercept and modify the pod creation operations in the cluster and add their malicious container to every created pod.

4. Credential access

Access managed identity credential

Managed identities are identities that are managed by the cloud provider and can be allocated to cloud resources, such as virtual machines. Those identities are used to authenticate with cloud services. The identity’s secret is fully managed by the cloud provider, which eliminates the need to manage the credentials. Applications can obtain the identity’s token by accessing the Instance Metadata Service (IMDS). Attackers who get access to a Kubernetes pod can leverage their access to the IMDS endpoint to get the managed identity’s token. With a token, the attackers can access cloud resources.

Malicious admission controller

In addition to persistency, a malicious admission controller can be used to access credentials. One of the built-in admission controllers in Kubernetes is ValidatingAdmissionWebhook. Like MutatingAdmissionWebhook, this admission controller is also generic, and its behavior is determined by an admission webhook that is deployed in the cluster. Attackers can use this webhook to intercept the requests to the API server, record secrets, and other sensitive information.

5. Lateral movement

CoreDNS poisoning

CoreDNS is a modular Domain Name System (DNS) server written in Go, hosted by Cloud Native Computing Foundation (CNCF). CoreDNS is the main DNS service that is being used in Kubernetes. The configuration of CoreDNS can be modified by a file named corefile. In Kubernetes, this file is stored in a ConfigMap object, located at the kube-system namespace. If attackers have permissions to modify the ConfigMap, for example by using the container’s service account, they can change the behavior of the cluster’s DNS, poison it, and take the network identity of other services.

ARP poisoning and IP spoofing

Kubernetes has numerous network plugins (Container Network Interfaces or CNIs) that can be used in the cluster. Kubenet is the basic, and in many cases the default, network plugin. In this configuration, a bridge is created on each node (cbr0) to which the various pods are connected using veth pairs. The fact that cross-pod traffic is through a bridge, a level-2 component, means that performing ARP poisoning in the cluster is possible. Therefore, if attackers get access to a pod in the cluster, they can perform ARP poisoning, and spoof the traffic of other pods. By using this technique, attackers can perform several attacks at the network-level which can lead to lateral movements, such as DNS spoofing or stealing cloud identities of other pods (CVE-2021-1677).

6. Collection

In this update, we also add a new tactic to the threat matrix: collection. In Kubernetes, collection consists of techniques that are used by attackers to collect data from the cluster or through using the cluster.

Images from private registry

The images that are running in the cluster can be stored in a private registry. For pulling those images, the container runtime engine (such as Docker or containerd) needs to have valid credentials to those registries. If the registry is hosted by the cloud provider, in services like Azure Container Registry (ACR) or Amazon Elastic Container Registry (ECR), cloud credentials are used to authenticate to the registry. If attackers get access to the cluster, in some cases they can obtain access to the private registry and pull its images. For example, attackers can use the managed identity token as described in the “Access managed identity credential” technique. Similarly, in EKS, attackers can use the AmazonEC2ContainerRegistryReadOnly policy that is bound by default to the node’s IAM role.

Protect your containerized environments

Understanding the attack surface of containerized environments is the first step of building security solutions for these environments. The revised threat matrix for Kubernetes can help organizations identify the current gaps in their defenses’ coverage against the different threats that target Kubernetes.

We recommend that you start protecting your containerized environment with Azure Defender today. Learn more about Azure Defender’s support for container security.

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 Secure containerized environments with updated threat matrix for Kubernetes appeared first on Microsoft Security.

Medius’ small IT team supports distributed workforce with Azure Active Directory

March 22nd, 2021 No comments

In today’s Voice of the Customer blog post, IT Manager Jacob Andersson and IT Systems Architect Fredrik Frööjd of Medius share how Azure Active Directory (Azure AD) has inspired employees to live by the cloud commitment the company encourages from customers and helped their small team support a remote workforce with fewer resources. Atea, one of our Azure AD system integration partners, played a key role in this effort.

Medius logo

Securing a remote workforce with fewer resources with Azure Active Directory

At Medius, we develop cloud-based spend management solutions, including the accounts payable workflow solution MediusFlow (Microsoft offers an online tutorial on configuring MediusFlow for automatic user provisioning). We’re one of the largest Microsoft partners in the Nordics to build and offer an entire solution in Azure. Because we advocate the value of cloud for customers, we decided it was fitting to turn to the cloud solution offered by Azure AD to meet our identity requirements.

Providing a fully remote work environment

Our 3,500 customers typically want to restrict access to their financial documents by title or division. Since most have more than 200 employees, it would be cumbersome to manually set access for each employee. Being able to assign users through Azure AD using known Microsoft protocols is a big selling point of our spend management solution.

We can relate to our customers’ need for secure authentication in systems and applications; it’s important to us too. While headquartered in Sweden, Medius has offices in eight other countries and our employees work from across the globe. Teams are both distributed and virtual. It’s not unusual for project meetings with customers to include Medius employees from three countries. We’ve prioritized providing a fully remote environment, in part because the consulting nature of our business requires that some employees travel to customer sites.

That fully remote experience extends to offboarding. When employees leave Medius, Azure AD identity and access management makes it easier to abide by our HR processes, which are reviewed by external auditors. Each employee is associated with an active ID. When an employee is offboarded, we can disable accounts and block user access to everything at once from Azure AD.

Freeing up IT time with features and user self-service

As a small IT team, we couldn’t support Medius’ 400 employees without the increased security and high reliability offered by Azure AD. Time savings is among the biggest benefits of using Azure AD for secure management of users and identities. If a partner requires access, Medius can add them as a guest in Azure AD so the external identity is trusted in required Medius’ internal systems.

Azure AD serves as a trusted source of information that we can depend on in every situation. Rather than navigating islands of systems with unique identities, Azure AD is our single place for everything related to identity management. Because of that, we can help users in any time zone from wherever we’re working. However, users appreciate that the solution is user-friendly, and they can handle some identity tasks themselves. This frees up the IT service desk to focus on other work, and in a growing company, there’s plenty to do.

Users tell us they appreciate the simplicity of single sign-on, which allows them to log in with a single ID and password to SaaS apps like Salesforce, Zuora, Jira, Confluence, DocuSign, and Freshdesk. They also like the flexible integration, ease of use for frictionless workflow, and convenience of Azure AD multifactor authentication, which lets them verify their identity via multiple credentials.

Self-service password reset is another popular feature. We operate in just about every time zone, but our IT team is located in European time zones. Before self-service password reset, it could take as long as two days for an employee to have a password reset by the IT team. Now, employees can reset a forgotten or locked password themselves 24/7 and stay productive.

Connecting during the health crisis

Before the recent healthcare crisis sent employees home, Medius switched from Skype to Microsoft Teams, making it easier for everyone to remotely collaborate and share files. That’s been even more valuable now that in-person meetings are not possible.

Medius is a growing company that has been hiring throughout the crisis. With Azure AD, we can ship laptops directly to the homes of new employees and have them login remotely using Windows Autopilot, which is a collection of technologies to set up and pre-configure new devices.

Improving processes with support from Atea

Our partner Atea, one of the leading providers of IT infrastructure in the Nordic and Baltic regions, offers a full range of hardware and software from the world’s leading technology companies and a team of consultants. The company played a key role in our effort to migrate apps to Azure AD and ramp up new employees.

Atea has told us that they do a lot of work for their customers when it comes to migrating apps to the cloud, helping them to benefit from the security and time-saving benefits of Azure AD. For instance, the pre-defined instructions on configuring applications in the app gallery facilitate the process of setting up a new integration.

Atea calls the partnership with Microsoft “extremely important” and has appreciated seeing product roadmaps and gaining access to private previews, which help it shape future offerings.

We look forward to sharing our next big successes: the introduction of the Conditional Access feature and a broader rollout of passwordless identity authentication.

Voice of the Customer: Looking ahead

Many thanks to Jacob and Fredrik for sharing the benefits they’ve realized with Azure AD. Our customers have told us how valuable it is to learn from their peers. The Voice of the Customer blog series is designed to share our customers’ security and implementation insights more broadly. Bookmark the Microsoft Security blog Voice of the Customer so you don’t miss the next blog in this series!

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 Medius’ small IT team supports distributed workforce with Azure Active Directory appeared first on Microsoft Security.

サイバーセキュリティ月間期間の取り組みのおさらい

Categories: Uncategorized Tags:

Automatic on-premises Exchange Server mitigation now in Microsoft Defender Antivirus

March 18th, 2021 No comments

As cybercriminals continue to exploit unpatched on-premises versions of Exchange Server 2013, 2016, and 2019, we continue to actively work with customers and partners to help them secure their environments and respond to associated threats. To date, we have released a comprehensive Security Update, a one-click interim Exchange On-Premises Mitigation Tool for both current and out-of-support versions of on-premises Exchange Servers, and step-by-step guidance to help address these attacks.

Today, we have taken an additional step to further support our customers who are still vulnerable and have not yet implemented the complete security update. With the latest security intelligence update, Microsoft Defender Antivirus and System Center Endpoint Protection will automatically mitigate CVE-2021-26855 on any vulnerable Exchange Server on which it is deployed. Customers do not need to take action beyond ensuring they have installed the latest security intelligence update (build 1.333.747.0 or newer), if they do not already have automatic updates turned on.

The Exchange security update is still the most comprehensive way to protect your servers from these attacks and others fixed in earlier releases. This interim mitigation is designed to help protect customers while they take the time to implement the latest Exchange Cumulative Update for their version of Exchange.

Microsoft will provide guidance to our security partners so that they have the option to make available similar, simple mitigations in their products as well.

We are deeply committed to protecting our customers.  To stay up to date please continue to review the content posted at https://aka.ms/exchangevulns.

Frequently Asked Questions

Q: If I have Microsoft Defender Antivirus installed on my Exchange Server do I need to take any further action to get this mitigation?

A: Customers that install Microsoft Defender Antivirus and have automatic definition updates enabled (default setting) do not have to take further action to receive the mitigation.

Q: My organization manages Microsoft Defender Antivirus definition updates.  What do I need to do to ensure I have this mitigation?

A: Customers that manage Microsoft Defender Antivirus definition updates need to select the new detection build (1.333.747.0 or newer) and deploy that to the Exchange Server.

Q: After this mitigation, do I still need to install the security update?

A: Yes.  This automatic mitigation breaks the attack chain by mitigating CVE-2021-26855.  Customers should still prioritize getting current on security updates for Exchange Server to comprehensively address the vulnerabilities.

Q: When does Microsoft Defender Antivirus apply the mitigation?

A: Microsoft Defender Antivirus will automatically identify if a vulnerable version of Exchange Server is installed and apply the mitigations the first time the security intelligence update is deployed.  The mitigation is deployed once per machine.

Q: Is cloud protection required to receive the mitigation?

A: No.  However, enabling cloud protection is a best practice that will keep you with the most current protections against the ever-changing threat environment.  Customers are encouraged to enable cloud protection.

Q: What can I do if I don’t have Microsoft Defender Antivirus?

A: Use the One-Click Microsoft Exchange On-Premises Mitigation Tool found here.

The post Automatic on-premises Exchange Server mitigation now in Microsoft Defender Antivirus appeared first on Microsoft Security.

オンプレミス Exchange Server の脆弱性の調査や修復に対応する方向けのガイダンス

Categories: Uncategorized Tags:

Guidance for responders: Investigating and remediating on-premises Exchange Server vulnerabilities

March 16th, 2021 No comments

This guidance will help customers address threats taking advantage of the recently disclosed Microsoft Exchange Server on-premises vulnerabilities CVE-2021-26855, CVE-2021-26858, CVE-2021-26857, and CVE-2021-27065. Microsoft will continue to monitor these threats and provide updated tools and investigation guidance to help organizations defend against, identify, and remediate associated attacks.  

Categories: Uncategorized Tags:

Guidance for responders: Investigating and remediating on-premises Exchange Server vulnerabilities

This guidance will help customers address threats taking advantage of the recently disclosed Microsoft Exchange Server on-premises vulnerabilities CVE-2021-26855, CVE-2021-26858, CVE-2021-26857, and CVE-2021-27065, which are being exploited. We strongly urge customers to immediately update systems. Failing to address these vulnerabilities can result in compromise of your on-premises Exchange Server and, potentially, other parts of your internal network.

Categories: Uncategorized Tags:

オンプレミス Exchange 緩和ツール (ワンクリックの緩和ツール)

「One-Click Microsoft Exchange On-Premises Mitigation Tool – March 2021」の日本語抄訳です。 最近のオンプレミスの Exchange Server を狙った攻撃に

Categories: Uncategorized Tags:

One-Click Microsoft Exchange On-Premises Mitigation Tool – March 2021

March 15th, 2021 No comments

We have been actively working with customers through our customer support teams, third-party hosters, and partner network to help them secure their environments and respond to associated threats from the recent Exchange Server on-premises attacks. Based on these engagements we realized that there was a need for a simple, easy to use, automated solution that …

One-Click Microsoft Exchange On-Premises Mitigation Tool – March 2021 Read More »