Microsoft Power Platform DLP Bypass Uncovered – Finding #3 – Custom Connectors

Hello everyone! I’m Yuval Adler, Customer Success Director at Zenity.

I’m inviting you to read my blog series where I will share new Microsoft Power Platform DLP Bypass findings we uncovered.

Finding #3: Custom Connectors

Low-code and no-code platforms such as Microsoft Power Platform can provide many benefits for organizations, but they can also introduce many security risks if not implemented properly.

To try to mitigate the risk, Microsoft enables users to implement data loss prevention (DLP) policies to define the consumer connectors that enable specific business data to be shared with, as well as which connectors are blocked for usage – similar to an allow and block list (check out this blog post to learn more).

In our latest security investigation, we discovered another concerning way to bypass Microsoft’s DLP policies. Using Microsoft’s custom connectors, users can gain access to any blocked connectors in the DLP policies and easily go around the restrictions put in place by security administrators – behavior which could lead to data breaches or compliance violations. Power Platform connectors are integration points that make it possible to create workflows, automate processes, and build custom apps. While Power Platform offers many official connectors to choose from, you may want to communicate with services that aren’t available as pre-built connectors. 

A custom connector in Power Platform is a way for users to connect to and work with data from different sources, such as a database or a web service, within Power Apps and Power Automate. Custom connectors can be created using the Power Platform Connectors platform. Once created, custom connectors can be used in the same way as pre-built connectors in Power Platform. Here are a few common use cases for which custom connectors are often used:

• Connecting to a custom API or in-house systems: If you need to connect to a custom API that is not supported by Power Platform out-of-the-box, or need to integrate with applications with in-house systems, such as a proprietary database or an on-premises application, you can use a custom connector to create a connection to that API and expose its functionality to Power Apps or Power Automate flows.
• Integrate legacy systems with modern applications: Many organizations still use legacy systems that may not be compatible with newer applications. Custom connectors can be created to bridge the gap between these systems, allowing data to be shared seamlessly.
• Specific requirements or additional functionality: A custom connector may be necessary if you have specific requirements that are not met by the pre-built connectors, and it can also provide additional functionality such as custom data transformations or additional data validation.
• Automating a complex workflow: If you need to automate a complex workflow that involves multiple systems or services, you can use a custom connector to create a custom workflow that integrates with those systems and services.

Custom connectors have multiple legitimate purposes, but at the same time, they can also be very appealing to hackers for a variety of reasons and in diverse ways:

• Defense evasion: Hackers can use custom connectors to hide their malicious activities and gain access to systems or data by creating connectors that appear to be used for legitimate purposes, but are actually carrying out unauthorized activities. For example, a hacker could create a custom connector that appears to be used for data backup or transfer, but is actually copying sensitive data to a remote server for later retrieval.
• Lack of oversight: Custom connectors are typically developed and maintained by third-party developers or in-house teams, which can make them more difficult for organizations to monitor and secure effectively.
• Unfamiliarity with custom connectors: Because custom connectors are not always widely used or well known, they can potentially fly under the radar of security teams and go unnoticed by organizations until it’s too late.
• Potential for data exfiltration: Custom connectors can potentially be used by hackers to exfiltrate sensitive data from an organization’s systems, either directly or through a chain of connected systems.
• Exploiting vulnerabilities: If a custom connector has vulnerabilities, hackers can exploit these to gain unauthorized access to systems or data. For instance, they might use a custom connector to inject malicious code into an application or network, or skip security measures and acquire access to sensitive resources.

As part of our latest research, we uncovered that by using a custom connector you can reach out to any connector which has been blocked by DLP policies. This is an easy way to bypass blocked connectors in Power Platform DLP, with very high risk attached. Administrators have no visibility on which flows/applications are currently accessing blocked connectors and no actual power to block or restrict the use of risky connectors (the endpoint filtering feature is covered in my previous blog post).

In the following screenshots, you can see a demonstration of an admin trying to block the use of the Outlook connector in the organization’s DLP policy “Blocked Outlook DLP” (Screenshot 1).

As a user trying to bypass this limitation, I’ve created my own custom connector which contains a POST API send mail call to Outlook, to send an email to my personal email address, in order to demonstrate a data leakage scenario. In the following screenshots 2-4 you can see the custom connector definition and configuration:

In screenshot 5 you can see that running the connector as a test was finished successfully (status = 200) and screenshot 6 is the email I received.

I also created the flow “DLP Outlook Bypass” using this custom connector and was able to run it successfully (screenshot 7).

What we’ve seen here is how custom connectors can be used to access blocked connectors in a Power Platform DLP policy, which is a direct bypass of the organization’s security policies. This could result in sensitive data being exposed or shared with unauthorized parties.

In order to try to mitigate the risk here, Microsoft added the ability to specify an ordered list of Allow and Deny URL patterns for custom connectors. You can do this in the DLP policy configuration under the section called “custom connectors” which will allow you to label URL patterns as business, non-business and blocked. Although this seems like a nice solution, for this to really work in practice you would also need to know in advance which URL patterns you need to block. Given that for this to be effective you’d need to think through literally any and every URL that’s out there – this is not very realistic. 

You can also try to add specific custom connectors to the DLP policy block list, but as mentioned in Microsoft docs as part of their known limitations, “When an environment admin creates or updates an environment-level DLP policy, they can only view custom connectors for which they are an owner or that have been shared with them”. That means if you, as an administrator, didn’t create that custom connector, or it was shared with you, you won’t be able to view it in order to restrict it. 

As presented today, it is absolutely crucial to prioritize security when it comes to using custom connectors. Although they can be advantageous when pre-built connectors are unavailable, they can also expose your organization to significant security risks that must be monitored.

DLP policies are insufficient to ensure your organization’s safety and custom connectors must comply with your organization’s security and compliance standards.

Our recommendations to reduce risk when it comes to the usage of custom connectors are:

• Restricting the use of custom connectors to a specific group of users, such as IT or security
• Reviewing and approving custom connectors before they are used in production
• Monitoring the usage of custom connectors to detect any unauthorized access to blocked connectors
• Regularly auditing the custom connectors to ensure they are not being used to bypass DLP policies

In order to address these security risks and provide our customers with more visibility, we’ve added dedicated rules to our security rules set to monitor these specific scenarios and alert our customers on any use of custom connectors.

To learn more about the security risks mentioned, feel free to reach out over email to yuvala@zenity.io and I’ll be happy to help! We continue this series, this time discussing unblockable connectors, in post #4.