Pentesting Apps in Dynamics 365
Introduction
There are not many resources on how to pentest applications built or deployed using Microsoft Dynamics 365. Dynamics 365 is officially described as a suite of AI-powered ERP and CRM applications that help organizations manage sales, service, finance, and supply chain operations. In simpler terms, it is a platform for building business applications that support CRM and ERP workflows such as customer interactions, inventory management, financial processing, booking, and more.
A key point for pentesters is that when building applications in Dynamics 365 (whether Customer Engagement apps or Power Apps built on the Power Platform), you generally do not deploy your own UI code like you would in a traditional web application. Instead, you use built-in tools such as the App Designer, Command Designer, and Power Pages if you need an external website. While you can inject limited custom JavaScript or CSS, the UI framework and authentication are fully controlled by Microsoft. Most applications built on Dynamics 365 are internal-facing and require Microsoft Entra ID (Azure AD) SSO. This often leads teams to assume that pentesting a Dynamics-based application is equivalent to pentesting Microsoft flows / logic, which is something typically out of scope. However, this is not entirely correct.
Although you do not pentest the UI layer or the authentication flow, you must test the application for misconfigurations, just like you would when assessing cloud environments such as Azure or AWS. The primary attack surface lies in the application’s configuration, permissions, data exposure, and business logic.
What Are We Looking For?
Simply put, we are looking for the Broken Access Control vulnerabilities as well as for Information Disclosure issues.
Use Case 1: Internet-Facing App – No Authentication
In rare cases, the application may be public-facing (for example, a Power Pages site). When this happens, test whether unauthenticated users can access sensitive information or API endpoints. This is uncommon but still possible.
Use Case 2: Internal-Facing App – Authentication Required
The more common scenario is an internal application protected by Entra ID / Microsoft SSO.
Since these apps typically have multiple user roles, a major focus is role segregation:
- Does a low-privileged user have access to administrator-level data or functions?
- Can a non-admin list system users, read environment variables, access custom entities, view secrets, or enumerate sensitive endpoints?
You should request accounts for all relevant roles and validate whether permissions are correctly enforced. Separately you should also test custom (not Dynamics 365 related) APIs that are called by Dynamics 365 applications if such APIs are built by the team.
Dataverse / Dynamics 365 Metadata Endpoint:
The Dataverse $metadata endpoint is a private API endpoint that exposes the full schema of the Dynamics environment: tables, fields, relationships, option sets, and data types. It does not expose business data and can only be accessed by authenticated users. For pentesters, this endpoint acts as a map of the entire backend. It reveals where sensitive information would exist, and therefore helps identify which endpoints should be restricted from lower-privileged users. For example, a standard user should probably not be able to query the system users entity or read environment variables. In practice, teams often misconfigure these permissions, unintentionally exposing sensitive metadata or allowing unauthorized access.
Use Case 3: Dynamics 365 Used as a Backend for an External Application
In some architectures, an external customer-facing application (built outside Dynamics 365) integrates with a Dynamics backend through API calls or embedded actions.
As a dummy arhitecture example:
In such cases:
- The external application requires a regular web application pentest.
- The Dynamics 365 environment must still be tested for role misconfigurations, exposed entities, and improper integration permissions.
This means that alongside your regular pentest of the web application, you should try to look for information about the Dynamics 365 endpoint URL. If found try to authenticate against this endpoint using users your have access to and from there repeat steps shown in the use case 2.
Demo
***Please note that all the screenshots provided in this walkthrough are taken from demos and not from a real engagement. That being said, this methods have been proven to work on a real engagement. Well you will have to take my word on it.***
In this demo we will show a few PoCs of artifacts that can be found following the methodology outlined earlier.
Use Case 2: Internal-Facing App – Authentication Required
Assuming you have already logged in to the application using your low privileged user credentials and Microsoft Entra ID SSO. The URL of the app will typically be:
your-app.crm(number).dynamics.comFor example:
testapp.crm4.dynamics.com/main.aspx?appid=(app-id-guid)After authentication navigate to the metadata endpoint:
Metadata endpoint:
https://testapp.crm4.dynamics.com/api/data/v9.1/$metadataNote: if “v9.1” does not work try changing the version number to “9.2” etc..
This endpoint should be accessible to all authenticated users. Navigate through all properties and entities of the endpoint to look for some default entity names as well as some custom ones related to your application.
Once you mapped interesting endpoints, start querying them looking for sensitive information.
System users endpoint:
https://testapp.crm4.dynamics.com/api/data/v9.1/systemusers
Navigating to this endpoint will help you enumerate system users, exploring sensitive information such as user GUIDs, emails, names etc..
Additional sensitive endpoint to check is "environmental variables".
Enumerating this endpoint can potentially leak secrets for accessing services and APIs.
Environmental variables and their values:
https://<your-app>.crm11.dynamics.com/api/data/v9.1/environmentvariabledefinitions?$select=environmentvariabledefinitionid,schemaname,displayname&$expand=environmentvariabledefinition_environmentvariablevalue($select=environmentvariablevalueid,value)
Exploring the screenshot you will notice the presense of a plain text secret in the value key.
Another endpoint to look for secrets is “workflows”
Enumerating this endpoint can potentially leak secrets for accessing services and APIs.
Workflows endpoint:
https://<your-app>.crm<number>.dynamics.com/api/data/v9.0/workflows?$select=createdby
Exploring the screenshot you will notice the presense of a plain text secret in the value key.
You can also enumerate user roles and privileges and what user is assigned what role and privilege
Workflows endpoint:
https://<your-app>.crm<number>.dynamics.com/api/data/v9.1/roles
Privileges endpoint:
https://<your-app>.crm<number>.dynamics.com/api/data/v9.1/priveleges
Exploring theese screenshots you will notice the that you can enumerate existing privileges and roles for the relevant users.
Additional Tips
Enumerate the $metadata endpoint to find additional sensitive endpoints and try to query them.
Another very sensitive endpoint is “credentials” but usually it is not accessible. To access it a user usually needs to have a “System Administrator” security role or to be specifically granted a “prvReadCredential” permission. See if you can access and change security groups with your user to potentially grant yourself that role. This is however an unlikely scenario and doing that crosses with Azure AWS pentesting, which is irrelevant for this article.
Use Case 3: Dynamics 365 Used as a Backend for an External Application
Here we assume that there is an external public application that manages user authentication via Entra ID SSO and hosts its backend data in Dynamics 365. Let’s assume that when enumerating the web application, you came across a JavaScript file that contained a URL to the backend Dynamics 365 endpoint
your-app.crm(number).dynamics.comFor example:
testapp.crm4.dynamics.com/main.aspx?appid=app-id-guidYou will proceed by navigating to the Dynamics 365 endpoints, trying to authenticate using your user and enumerating the backend using Dynamics 365 UI and the $metadata endpoint.
If you have access to the Master Data tab you will be able to manipulate users and change their access permissions and more.
From there try to see what sensitive actions you can do with your low privilege user.
Conclusion
To conclude, while testing the frontend and authentication flows of applications hosted on Dynamics 365 is typically out of scope, since those components are managed by Microsoft, there is still significant risk introduced through customer-managed configuration. Improperly configured roles, permissions, and data access can lead to broken access control vulnerabilities, allowing low-privileged users to access or manipulate sensitive enterprise data. These issues commonly rate as high or critical severity under the CVSS 4.0 scoring system, as their exploitation can highly impact the confidentiality, integrity, and availability of assets.