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.

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.

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.

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:

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 »

5 steps to enable your corporate SOC to rapidly detect and respond to IoT/OT threats

March 15th, 2021 No comments

As organizations connect massive numbers of IoT/OT devices to their networks to optimize operations, boards and management teams are increasingly concerned about the expanding attack surface and corporate liability that they represent. These connected devices can be compromised by adversaries to pivot deeper into corporate networks and threaten safety, disrupt operations, steal intellectual property, expose resources for Distributed Denial of Service (DDoS) botnets and cryptojacking, and cause significant financial losses.

For example, in June 2017, a destructive cyber attack known as “NotPetya” infected thousands of computers globally and resulted in dozens of enterprises experiencing significant financial losses. One of NotPetya’s victims, a global shipping and logistics company, lost $300 million as a result of production downtime and cleanup activities.

Why industrial and critical infrastructure OT networks are at risk

According to CyberX’s 2020 Global IoT/ICS Risk Report, which analyzed network traffic from over 1,800 production OT networks, 71 percent of OT sites are running unsupported versions of Windows that no longer receive security patches; 64 percent have cleartext passwords traversing their networks; 54 percent have devices that can be remotely managed using remote desktop protocol (RDP), secure shell (SSH), and virtual network computing (VNC), enabling attackers to pivot undetected; 66 percent are not automatically updating their Windows systems with the latest antivirus definitions; 27 percent of sites have direct connections to the internet.

These vulnerabilities make it significantly easier for adversaries to compromise OT networks, whether their initial entry is via systems exposed to the internet or via lateral movement from the corporate IT network (using compromised remote access credentials, for example).

CISOs are increasingly accountable for both IT and IoT/OT security. However, according to a SANS survey, IT security teams lack visibility into the security and resiliency of their OT networks, with most respondents (59 percent) stating they are only “somewhat confident” in their organization’s ability to secure their industrial IoT devices.

How should organizations secure their IoT/OT environments?

Organizations need to invest in strengthening their IoT/OT security and structure the appropriate policies and procedures so that new IoT/OT monitoring and alerting systems will be successfully operationalized.

A key success factor is to obtain organizational alignment and solid collaboration with teams that will operate the system. In many organizations, these teams have traditionally worked in separate silos. Visibility and well-defined roles and responsibilities between IoT/OT, IT, and security personnel are key for a successful alignment. Although there can be more connectivity between the IT and the IoT/OT networks, they are still separate networks with different characteristics. Personnel operating the IoT/OT network are not always security trained, and the security staff are not familiar with the IoT/OT network infrastructure, devices, protocols, or applications. In particular, the top priority for OT personnel is maintaining the availability and integrity of their control networks—whereas IT security teams have traditionally been focused on maintaining the confidentiality of sensitive data.

To be effective, IT security teams will need to adapt their existing procedures and policies to be inclusive of the IoT/OT security world.

Gaining continuous security operations center (SOC) visibility into IoT/OT risk with Azure Defender for IoT

Azure Defender for IoT is an agentless, network-layer IoT/OT security platform that’s easy to deploy and provides real-time visibility to all IoT/OT devices, vulnerabilities, and threats—within minutes of being connected to the OT network. Based on technology from Microsoft’s acquisition of CyberX, Azure Defender for IoT uses specialized IoT/OT-aware behavioral analytics and threat intelligence to auto-discover unmanaged IoT/OT assets and rapidly detect anomalous or unauthorized activities in your IoT/OT network. Additionally, it enables you to centralize IoT/OT security monitoring and governance via built-in integration with Azure Sentinel and third-party SOC solutions such as Splunk, IBM QRadar, and ServiceNow.

According to SANS, there’s a clear difference between the detection of an attack on corporate companies versus industrial and critical infrastructure organizations with control networks. While 72 percent of organizations without OT environments detected a compromise within seven days, only 45 percent of organizations with OT environments were able to do the same.

Reducing the time between compromise and detection is a key catalyst for enabling your SOC with real-time IoT/OT alerts and detailed contextual information about your IoT/OT assets and vulnerabilities.

Detect and respond to IoT/OT incidents faster

To operationalize security alerts from the IoT/OT network, you must integrate them with your existing SOC workflows and tools. Given the significant investments that organizations have already made in a centralized SOC, it makes sense to bring IoT/OT security into their existing SOC and to expand the SOC responsibilities to be able to manage IoT/OT incidents as well. This next step will create a productive working environment between the teams. Integration of the SOC within the IoT/OT environment can create a competitive advantage for the organization.

Modern SOCs rely heavily on SIEM solutions to operate efficiently. This means that IoT/OT security alerts and investigation processes should be delivered to the SOC team via their preferred SIEM solution. SIEM solutions provide security value by normalizing and correlating data across the enterprise, including data ingested from firewalls, applications, servers, and endpoints.

As of today, most of our customers (78 percent) who have deployed Azure Defender for IoT and have SIEM, have integrated (or are in the process of integrating) IoT/OT security into their SIEM platform and SOC workflows.

Integrating IoT/OT security with your SIEM in five steps:

Step 1: Forward IoT/OT security events to the SIEM

The first step in a successful SOC integration is to integrate IoT/alerts with your organizational SIEM. This capability is supported out of the box with Azure Defender for IoT. After integrating Azure Defender for IoT with a SIEM, clients typically spend a short time tuning which alerts are forwarded to the SIEM to reduce alert fatigue.

Azure Defender for IoT drop-down menu showing built-in integrations with broad range of SIEM, ticketing, firewall, and NAC systems

Figure 1: Azure Defender for IoT integrates out-of-the-box with a broad range of SIEM, ticketing, firewall, and NAC systems.

Step 2: Identify and define IoT/OT security threats and SOC incidents

The second step is agreeing on which IoT/OT security threats the organization would like to monitor in the SOC, based on the organizational threat landscape, industry needs, compliance, and more. Once relevant threats are defined, you can define the use cases that constitute an incident within the SOC.

For example, a common use case is an unauthorized change to OT equipment, such as an unauthorized change to Programmable Logic Controller (PLC) code—since this can take down production and potentially cause a safety incident. In the TRITON attack on the safety controllers in a petrochemical facility, for example, the adversary initially compromised a Windows workstation in the OT network and then uploaded a malicious back door to the PLC using a legitimate industrial control system (ICS) command (you may recognize this as an excellent example of an OT-specific living-off-the-land tactic).

This type of activity is immediately detected when Azure Defender for IoT detects a deviation from the OT network baseline, such as a programming command sent from a new device. Azure Defender for IoT incorporates Layer 7 Deep Packet Inspection (DPI) and patented IoT/OT-aware behavioral analytics using Finite-State Machine (FSM) modeling to create a baseline of OT network activity. Compared to generic baselining algorithms developed for IT networks (which are largely non-deterministic), this approach is optimized for the deterministic nature of OT networks—resulting in a faster learning period with fewer false positives and false negatives. Additionally, deeply analyzing high-fidelity network traffic, including at the application layer, enables the platform to identify malicious OT commands and not just deviations in source/destination information.

In this particular use case, unauthorized changes to PLC ladder logic code can be an indication of either new functionality or parameters being programmed into the PLC, which typically only happens on rare occasions: an error on the part of a control engineer or a misconfigured application. In all these cases, the SOC should investigate with plant personnel to determine if the activity was malicious or legitimate.

Step 3: Create SIEM detection rules

Once IoT/OT security threat use cases are defined, you can create detection rules and severity levels in the SIEM. Only relevant incidents will be triggered, thus reducing unnecessary noise. For example, you would define PLC code changes performed from unauthorized devices, or outside of work hours, as a high severity incident due to the high fidelity of this specific alert.

Step 4: Define SOC workflows for resolution

The fourth step is to define workflows for resolution. This will also help remove ambiguity between IT security and OT teams about who is responsible for investigating unusual activities (note that unclear roles and responsibilities were also an important factor in the TRITON incident, until a second attack two months later).

The goal is to enable Tier 1 SOC analysts to handle most IoT/OT incidents and only escalate to specialized IoT/OT security experts when needed. This means defining the appropriate workflow for mitigation and creating automated investigation playbooks for each use case.

For example, when the SOC receives an alert that PLC code changes have been initiated, check first if the programming device is an authorized engineering workstation, and then if it occurred during normal work hours, whether it happened during a scheduled change window, etc. If the answer to these questions is no, you should immediately disconnect the rogue workstation from the network (or block it with a firewall rule, if possible).

Here’s an example of a logical workflow for resolution:

Example of a built-in automated SOAR playbook for Azure Sentinel initiated by an OT-specific alert generated by Azure Defender for IoT

Figure 2: Example of a built-in automated SOAR playbook for Azure Sentinel initiated by an OT-specific alert generated by Azure Defender for IoT

Step 5: Training and knowledge transfer

The fifth step is to provide comprehensive training to all stakeholders – for example, teach the SOC team about the unique characteristics of OT environments, so they can have intelligent conversations with IoT/OT personnel when resolving incidents and can implement remediation actions that are relevant (and not harmful) for OT environments.

Azure Defender for IoT and Azure Sentinel: Better together

Azure Sentinel is the first cloud-native SIEM/SOAR platform on a major public cloud. It delivers all the advantages of a cloud-based service, including simplicity, scalability, and lower total cost of ownership; provides a bird’s eye view across IT and OT to enable rapid detection and response for multistage attacks that cross IT/OT boundaries (like TRITON); incorporates machine learning combined with continuously-updated threat intelligence from trillions of signals collected daily.

Azure Defender for IoT is deeply integrated with Azure Sentinel, providing rich contextual information to SOC analysts beyond the basic information provided by simple Syslog alerts. For example, it provides detailed information about which IoT/OT assets associated with an alert including device type, manufacturer, the protocol used, firmware level, etc.

Azure Sentinel has also been enhanced with IoT/OT-specific SOAR playbooks. The integrated combination of these two solutions helps SOC analysts detect and respond to IoT/OT incidents faster—so you can prevent incidents before they have a material impact on your firm.

In the screenshot below, you can see a built-in Sentinel investigation experience for an IoT/OT security use case:

Interactive investigation graph in Azure Sentinel, produced from real-time OT monitoring data generated by Azure Defender for IoT

Figure 3: Interactive investigation graph in Azure Sentinel, produced from real-time OT monitoring data generated by Azure Defender for IoT. 

Learn more

If you’d like to learn more and see a full demo of how Azure Defender for IoT and Azure Sentinel can be used together to detect and investigate a sophisticated attack, check out our Microsoft Ignite session or read the blog “Go inside the new Azure Defender for IoT including CyberX.”

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 5 steps to enable your corporate SOC to rapidly detect and respond to IoT/OT threats appeared first on Microsoft Security.

Categories: cybersecurity, IoT, IoT security, SIEM Tags:

Protecting on-premises Exchange Servers against recent attacks

March 12th, 2021 No comments

For the past few weeks, Microsoft and others in the security industry have seen an increase in attacks against on-premises Exchange servers. The target of these attacks is a type of email server most often used by small and medium-sized businesses, although larger organizations with on-premises Exchange servers have also been affected. Exchange Online is not vulnerable to these attacks.

While this began as a nation-state attack, the vulnerabilities are being exploited by other criminal organizations, including new ransomware attacks, with the potential for other malicious activities.

This is now what we consider a broad attack, and the severity of these exploits means protecting your systems is critical. While Microsoft has regular methods for providing tools to update software, this extraordinary situation calls for a heightened approach. In addition to our regular software updates, we are also providing specific updates for older and out-of-support software with the intent to make it as easy as possible to quickly protect your business.

The first step is making sure all relevant security updates are applied to every system. Find the version of Exchange Server you are running and apply the update. This will provide protection for known attacks and give your organization time to update servers to a version that has a full security update.

The next critical step is to identify whether any systems have been compromised, and if so, remove them from the network. We have provided a recommended series of steps and tools to help — including scripts that will let you scan for signs of compromise, a new version of the Microsoft Safety Scanner to identify suspected malware, and a new set of indicators of compromise that is updated in real time and shared broadly. These tools are available now, and we encourage all customers to deploy them.

Our customer service team has been working around the clock alongside hosting companies and our partner community to raise awareness with potentially affected customers. With the help of the community, we are working to raise awareness about these critical updates and tools with more than 400,000 customers.

To illustrate the scope of this attack and show the progress made in updating systems, we’ve been working with RiskIQ. Based on telemetry from RiskIQ, we saw a total universe of nearly 400,000 Exchange servers on March 1. By March 9 there were a bit more than 100,000 servers still vulnerable. That number has been dropping steadily, with only about 82,000 left to be updated. We released one additional set of updates on March 11, and with this, we have released updates covering more than 95% of all versions exposed on the Internet.

Finally, groups trying to take advantage of this vulnerability are attempting to implant ransomware and other malware that could interrupt business continuity. To best protect against this, we encourage all customers to review the ransomware guidance from the U.S. Cybersecurity Agency and Infrastructure Security as well as Microsoft’s own guidance on how to prepare for and protect against this sort of exploit.

This is the second time in the last four months that nation state actors have engaged in cyberattacks with the potential to affect businesses and organizations of all sizes. We continue to monitor these sophisticated attacks closely and apply the breadth and depth of our technology, human expertise, and threat intelligence to better prevent, detect, and respond.

Microsoft is deeply committed to supporting our customers against these attacks, to innovating on our security approach, and to partnering closely with governments and the security industry to help keep our customers and communities secure.

The post Protecting on-premises Exchange Servers against recent attacks appeared first on Microsoft Security.

Categories: cybersecurity Tags:

Finalists announced in second annual Microsoft Security 20/20 awards

March 11th, 2021 No comments

2020 was a transformational year. Seemingly overnight, COVID-19 reshaped our perspective on work, home life, and security. Setting up home offices and powering through online presentations in our pajama bottoms (with cameos by pets and children), our industry rose to the challenge. All that challenging work kept firstline workers, students, medical professionals, and the rest of us connected and secure through a dark year. Now as we approach a full year, we will again celebrate our colleagues in security, compliance, and identity at the second annual Microsoft Security 20/20 awards ceremony on May 12, 2021.

“The past 12 months have reshaped our industry. We’ve all been pushed to reach new heights—creating integrated security, compliance, and identity solutions that work across platforms and cloud environments. We want to recognize the partners who helped get us there by creating their own game-changing Microsoft-based solutions and services.” —Vasu Jakkal, CVP Microsoft Security, Compliance & Identity

Perspective

According to the American Optometric Association: “20/20 vision does not necessarily mean you have perfect vision, it only indicates the sharpness or clarity of vision at a distance.” Last year’s theme of “Vision and Clarity” focused on shaping Microsoft’s vision for the security ecosystem alongside our partners, but the past year has prompted all of us to have a new perspective. The last 12 months have, in a way, forced us all to step back and reexamine the solutions we offer. Our industry burned the midnight oil, retooling products to better support a new remote workplace. The Microsoft Security 20/20 awards ceremony will acknowledge our new reality and shifted viewpoint with the theme of “Perspective—Through the looking glass.”

Unlike the online meetings we all know too well, this awards show will be an immersive, digital experience, ripe with dazzling visuals and soundscapes. We’re going all-in to celebrate our finalists and winners across 18 award categories honoring the best in the security, compliance, and identity ecosystem. We promise to engage all five of your senses to get you out of that office chair (figuratively, anyway), traveling through lush forests, bright meadows, and along a breezy beach.

Everyone is welcome. In this short-but-sweet awards show, we’ll skip the speeches and double down on creativity and fun. You’re invited to watch the 90-minute event and engage with us on social media. Feel free to invite your spouse, fur baby, or favorite houseplant. Just don’t forget to snap a selfie and share it with the hashtag: #MSFTSecurity2020.

Click to register for the Microsoft Security 20/20 awards!

Security for all

Microsoft is committed to building solutions that safeguard your entire organization—delivering integrated security, compliance, identity, and management across platforms and cloud environments. We want to help our customers prioritize risks using unified management tools and strategic guidance that maximize the human experience. The Microsoft Security 20/20 awards honor partners who align with Microsoft’s focus on customer obsession and have developed innovative, integrated solutions during the past year—helping us realize our vision of security for all.

This year’s finalists

The award categories and finalists were selected by a cross-functional group within Microsoft for their excellence in innovation, integration, and customer implementation. This year, winners will be voted on by members of the Microsoft Intelligent Security Association (MISA), making this truly a celebration among peers. Each MISA member company will get one vote and winners will be announced at the event (finalists, you’ll have to watch to find out if you won!).

Security Trailblazer

Partners who drive major security-related initiatives and educate the market on how to be more secure.

Most Transformative Integration Partner

Partners that are actively building integration across the Microsoft Security portfolio, along with demonstrating leadership in driving new, differentiated integrations.

Compliance Trailblazer

Partners who further major compliance-related initiatives and educate the market on compliance risks.

Microsoft Security System Integrator of the Year

System Integrators that work closely with field sellers to close deals, integrate, and deploy Microsoft Security into customers’ environments.

Identity Trailblazer

Partners who drive major identity-related initiatives and educate the market on how to protect identities.

Microsoft Security GTM partner of the Year

Partners who complete the largest number of workshops with the highest degree of excellence.

Microsoft 365 Security Deployment Partner of the Year

Service providers that increase usage and adoption rates for Microsoft 365 security products.

SCI Advisory of the Year

Security advisory firms that are building core competencies on top of Microsoft Security solutions and acting as a trusted advisor to Microsoft customers.

Microsoft Azure Security Deployment Partner of the Year

Service providers that increase usage and adoption rates for Azure security products.

The Security Industry Changemaker

Individuals that make a standout contribution to improve the security community.

Zero Trust Champion – ISV (Independent Software Vendors)

Software vendors that increase usage and adoption rates with solutions aligned with Microsoft’s Zero Trust strategy.

Top MDR (Managed Detection and Response) Team

Managed Detection and Response teams that provide incident responses for the world’s largest customers and partner with Microsoft Security to continually improve customer security.

Zero Trust Champion – SI (Systems Integrators)

System Integrators that accelerate secure remote work and help customers accelerate their Zero Trust strategy.

Top Managed SOC (Security Operations Centers)

Security Operations Centers that provide managed security services to the world’s largest customers and partner with Microsoft to continually improve customer security.

Emerging Security ISV Disruptor

Independent Software Vendors who show growth potential and have innovative emerging capabilities.

Microsoft Security Customer Impact

Partners who have driven a significant number of customers wins and have a proven track record for customer satisfaction.

Compliance Services Innovator of the Year

Service partners that demonstrate leadership and innovation in managed compliance service scenarios.

Security ISV of the Year

Independent Software Vendors that have shown innovation and the ability to drive revenue.

Our partners in the security, compliance, and identity ecosystem continually inspire us to create stronger, more integrated solutions. Please join us in celebrating their achievements at the Microsoft Security 20/20 awards, May 12, 2021—we look forward to seeing you there!

Click to register for the Microsoft Security 20/20 awards!

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 Finalists announced in second annual Microsoft Security 20/20 awards appeared first on Microsoft Security.

The biggest challenges—and important role—of application security

March 11th, 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.” In this conversation, Tanya shares her insights on application security (AppSec), its role in the security organization, and challenges for AppSec professionals.

Natalia: How do you define application security?

Tanya: Application security, or AppSec, is every activity you do to make sure your software is secure. Let’s say there’s a Java developer that uses Spring Boot, and there’s a vulnerability. They hear a podcast about it and say, “I think we should probably update it because it sounded really scary on the podcast.” That contributes to application security.

However, quite often when people talk about application security, they are talking about a formalized program at a workplace to make sure that the applications being released are reliably secure. We want to make sure every single application gets security attention, and that each gets the same security attention and support. We want to do the best we can to verify that it is at the posture that we have decided is our goal.  Each organization sets that differently, which I talk about a lot in the book I released last year, but basically, application security professionals want to minimize the risk of the scary apps and then bring everything across the board up to a better security posture. That requires talking to almost everyone in IT on a regular basis. I like to think of application security folks as techie social butterflies.

Natalia: How does the security skills gap impact AppSec?

Tanya: I’m obviously biased because I run a training company, but I started it because people kept asking me to train them on how to do it because there is a gap. There is a gap, in general, in IT security with finding someone who has experience and understands best practices rather than just guessing how to train people.

In application security, there tends to be an even wider gap. I started a podcast in August 2020 called Cyber Mentoring Monday. I started it because I run #CyberMentoringMonday on Twitter, and the entire first year, every single person said, “I want to be a penetration tester,” but then I would ask them more questions because I am trying to find them a skilled professional mentor and lots of them didn’t know what AppSec was. They didn’t know what threat hunting was. They didn’t know what risk analysis was. They didn’t know that forensics or incident response existed. We would talk more and it would turn out that there is a different security focus that they’re really interested in, but they had only ever heard of penetration testing.

That was the same for me. I thought you had to be a penetration tester or a risk analyst, but there are a plethora of jobs. I started this podcast so people could figure out what types of jobs they wanted and because I really want to attract more people to our field. A big problem is there is no perfect way to enter AppSec.

Natalia: What are the biggest challenges for those in AppSec?

Tanya: The first AppSec challenge is education, with some developers not understanding how to create secure code. It’s not that they don’t want to. It’s that they don’t understand the risk. They don’t understand what they are supposed to do and a lot of them feel frustrated because they think, “I want my app to be perfect and the best ever,” and they know security is part of that, but they do not have the means to do it.

The second challenge that I see at almost every single workplace is trying to get buy-in. When I did AppSec full time, at certain places I would spend 50 percent of every day just trying to be allowed to do my job. For instance, I want this new tool, and here are the reasons why, and people would respond by saying, “That’s expensive. Developer tools are cheaper.” I would say, “I’m not a developer.” I had to learn how to communicate with management in a way I never had to do as a developer. When I was a developer, I would just say, “It’s going to be two weeks.” If they asked if I could do it faster, I would ask, “Do you want to pay overtime?” and then they would say either yes, and we would do overtime, or they would say no. There is no persuasion.

With AppSec, I had to say, “We have 20 apps. I know you want to spend a zillion dollars on hiring four penetrating testers to test our one mission-critical, super fancy app. But can we hire one for that and could we take the money and look at these legacy things that are literally on fire?” There is a lot of negotiation and persuasion that I had to learn to work in AppSec, which I was surprised about.

Natalia: What is the role of AppSec when it comes to cloud security?

Tanya: I find that everything that’s not taken becomes the AppSec person’s role because no one’s doing it and you’re freaking out about it. If you do AppSec in a company where everything is on-prem, quite often there’s an operations team and they will handle all the infrastructure, so you don’t have to. When you move to the cloud, and especially if you’re working in an org that does DevOps, you must suddenly learn cloud technology, at least the basics.

I’ve talked to many AppSec people and I’ve said, “If you’re moving to the cloud, I know that you think that you’re only in charge of the security of the software, but that’s not true anymore because of the shared responsibility model.” The shared responsibility model means that even if the cloud provider handles patches and the physical security of the data center, if you choose bad configurations, you are responsible for those. So, the first thing you need to do is check out the shared responsibility model to know what your side must do so you don’t miss super important stuff.

When we move to the cloud, understanding shared responsibility is really important and then setting out a process so you get reliable results. Ideally, every phase of the software development lifecycle has one or more security-supporting activities. If you’re using the cloud, there is a decent chance that you’re doing DevOps, in which case the developers become DevOps people. You want to talk to them about securing both development and operations. If they’re just doing development and there is a separate team doing operations, there is a security team helping the operations team but you want to make sure that they receive security assistance. It’s important for developers to understand the basics of cloud security so they don’t accidentally do something terrifying.

With the cloud, one of my favorite things is automation. I used to work for Microsoft and am an Azure fan. Azure has Security Center, which is the best and can automate a bunch of policies and check up on a lot of things for you. Learning how to use it to your advantage is important—learning which parts you want to turn on, which parts you need to budget for in the future, and which parts you’d rather have a third-party tool for. Making those decisions is important for the cloud security team and the AppSec person and then figuring out how to deploy safely and reliably into the cloud.

Keep an eye out for the second part of the interview, as Tanya Janca shares best practices on how to build an application security program and measure its success.

Elevate your security posture with Microsoft Cloud App Security and Microsoft’s Cloud Access Security Broker.

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 The biggest challenges—and important role—of application security appeared first on Microsoft Security.

Azure LoLBins: Protecting against the dual use of virtual machine extensions

March 9th, 2021 No comments

Azure Defender for Resource Manager offers unique protection by automatically monitoring the resource management operations in your organization, whether they’re performed through the Azure portal, Azure REST APIs, Azure CLI, or other Azure programmatic clients. In this blog, we will look into the threats that are caused by “Living off the land Binaries” (LoLBins).

The term “Living off the land,” or LoL in short, is used to describe attackers leveraging built-in utilities to carry out attacks. LoLBins usually refer to pre-installed Windows or Linux binary tools that are normally used for legitimate purposes, but on compromised resources, can be leveraged by attackers. This tactic challenges defenders aiming to distinguish between the dual uses of these tools.

The usage of LoLBins is frequently seen, mostly combined with fileless attacks, where attacker payloads surreptitiously persist within the memory of compromised processes and perform a wide range of malicious activities. Together with the use of legitimate LoLBins, attackers’ activities are more likely to remain undetected.

Attackers are increasingly employing stealthier methods to avoid detection. Evidence for a variety of campaigns has been witnessed. Please find a detailed overview of how such an attack unfolds, along with recommendations on how to detect malicious LoLBins’ activities on Windows.

Azure LoLBins

The concept of LoLBins is not limited to traditional operation systems. In this post, we explore different types of Azure Compute virtual machine extensions, which are small applications that provide post-deployment configuration and automation tasks on Azure Virtual Machines. For example, if a virtual machine requires software installation, anti-virus protection, or to run a script inside of it, a virtual machine (VM) extension can be used.

Custom Script Extension downloads and executes scripts on Azure Virtual Machines, Anti-Malware extension for Windows warps different configuration types and applies them into Windows Defender, and VMAccess Extension manages administrative users, SSH keys and enables recovery features such as resetting the administrative password of a virtual machine (VM).

All these extensions serve thousands of administrators coming to orchestrate their Azure fleet. But in cases where an attacker assumes certain roles within a subscription, these Azure built-in capabilities will come in handy bypassing any network defense lines. Therefore, we named them Azure LoLBins.

How does it work?

Every image on Azure Marketplace contains an Azure guest agent implanted into it (VM Agent). The guest agent is a secure, lightweight process that manages VM interaction with the Azure Fabric Controller. The VM Agent has a primary role in enabling and executing Azure Virtual Machine extensions. Without the Azure VM Agent, VM extensions cannot be run.

The Guest Agent is responsible for managing VM extension operations such as installing, reporting status, updating individual extensions, and removing them. Extension packages are downloaded from the Azure Storage extension repository by the guest agent through communication with Azure fabric (over channel to 168.63.129.16).

To perform its tasks, the guest agent runs a Local System. Consequently, payloads of extensions, such as Custom Script Extension and Run Command, run on Azure Virtual Machines with extensive privileges on the local computer.

Impact

In this section, we will examine several behaviors we recently witnessed that demonstrate the exceptionality and potential strength of the VM extensions, making the specific Azure IAM roles, containing the rights to call them a lucrative target for attackers.

Case 1: Custom Script Extension

Custom Script Extension downloads and executes scripts on Azure Virtual Machines. This extension is useful for post-deployment configuration, software installation, or any other configuration or management tasks. Scripts can be downloaded from Azure Storage or GitHub, or provided to the Azure portal at extension run time. The Custom Script Extension can be run using the Azure CLI, PowerShell, Azure portal, or the Azure Virtual Machine REST API.

Usage of Custom Script Extension was seen spanning across different customers to fetch an executable from the same GitHub repository. We followed the traces to GitHub, finding the repository in question being publicly accessible allowed us to confirm the suspicion. The code intention within the executed payload (hack1.sh, see snippet below) is to mine cryptocurrency.

Example showing Case 1: Custom Script Extension

This behavior was observed across multiple customers from different countries within a noticeably short timeframe, together with the GitHub repository being inactive increased our suspicion this activity should not be associated with normal pen-test, red-team, or intended activity.

Case 2: VMAccess Extension

VMAccess Extension can create new administrator accounts, reset the password of an existing administrator account, reset the built-in administrator account and or reset the Remote Desktop service Configuration. Moreover, for Linux VMs, the extension can reset SSH public keys. Furthermore, similarly to other extensions, the VMAccess Extension can be executed through the Azure portal, Azure CLI, Powershell, or the Azure Virtual Machine REST API.

VM Access is extremely useful when managing your VMs. As an example, for Linux servers, an alternative would be to connect to the VM and execute the equivalent commands manually. Hence, it is one of the most accessible extensions due to its simplified user interface (UI) which you can access from the Azure Portal.

There is no doubt that the VMAccess Extension is a handy way for an attacker to gain initial access to VMs with elevated privileges. Such notorious usages of the extension may sometimes be difficult to notice. As an example, leveraging VM Access to create a common service user or modifying an existing one.

Example showing Case 2: VMAccess Extension

Case 3: Antimalware Extension

Microsoft Antimalware Extension for Azure is a free real-time protection capability that helps identify and remove viruses, spyware, and other malicious software, with configurable alerts when known malicious or unwanted software attempts to install itself or run on your Azure systems. Microsoft Antimalware for Azure is a single-agent solution designed to run in the background without human intervention.

The Microsoft Antimalware for Azure solution includes the Microsoft Antimalware Client and Service, and when used in Windows environment with Windows Defender enabled, the extension will apply any optional configuration policies to be used by Windows Defender, the extension will not deploy any additional antimalware service.

While experimenting with Microsoft Defender for Endpoint alerts for Windows and usage of the Anti-Malware extension, we noticed a correlation between alerts fired on the node followed by API calls to Azure Resource Manager. This orchestrates VM extensions, with configurations to the Anti-Malware extension that excluded the same alert-triggered payloads from being scanned in the future.

Using the Anti-Malware extension, attackers can potentially also disable the real-time protection before loading suspectable tools into the node or exclude specific files and directories for going unnoticed while conducting their malicious activity. Enjoying the benefit that Azure Resource Manager logs was rarely crossed in correlation to in-node telemetry.

Example showing Case 3: Antimalware Extension

Learn more

Microsoft recommends you implement detection and mitigation strategies to minimize exposure to new threats the Cloud brings. Azure Defender goes deep into dissecting attack techniques in order to define and build a depth protection plan.

Detection

Azure Defender has expanded its threat detection capabilities and recently introduced Azure Defender for Resource Manager, a new coverage for Azure deployment and management service. Every request to the Azure Resource Manager Endpoint on management.azure.com is logged and analyzed to reveal malicious intentions and threats.

Azure Defender for Resource Manager monitors all resource management operations performed in your organization performed through the Azure portal, Azure REST APIs, Azure CLI, or other Azure programmatic clients. Azure Defender runs advanced security analytics to detect threats and alert you when suspicious activity occurs. For a list of the Azure Defender for Resource Manager alerts, see the reference table of alerts.

Mitigation

Least privilege principle is a fundamental concept in Cloud environments. Ensuring that minimum access necessary to perform a legitimate operation would be granted to all identity types (human or non-human). A least privilege model for the cloud relies on the ability to continuously adjust access controls. We recommend monitoring all access events and establish a decision-making framework that distinguishes between legitimate and excessive permissions.

Get started for free today

Protect your entire Azure environment with a few clicks and enable Azure Defender for Resource Manager. This offer is free during the preview period. Turn Azure Defender on now.

To learn more about Microsoft Security solutions and our Integrated Threat protection solution 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 Azure LoLBins: Protecting against the dual use of virtual machine extensions appeared first on Microsoft Security.